Network performance monitoring method and apparatus

Abstract

Embodiments of the present application provide a network performance monitoring method and apparatus. The method comprises: an acquired first packet comprising a service packet and a packet header, the packet header comprising a first identifier, and the first identifier being used for determining a tail node for reporting network performance; and performing monitoring on the basis of a parameter used for determining the tail node for reporting network performance. The packet header provided by the present application has the capability to specify a tail node on the basis of a flow, and can correctly identify the tail node in various scenarios.

Description

Network performance monitoring method and device

[0001] [Corrected 27.11.2024 according to Rule 91] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 17, 2023, with application number 202311553646.8, and with the invention name “Network Performance Monitoring Method and Device”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a network performance monitoring method and device. Background Art

[0003] Currently, when it is detected that the traffic in the network does not meet the business needs, the control node can send a network performance monitoring instruction to one or more nodes in the network and designate one of the nodes as the head node. The head node encapsulates the message header containing the network performance detection information in the business message, and then forwards the message header encapsulated with the network performance detection information to the next-hop node, so that each node on the forwarding path of the business message can perform network performance monitoring based on the message header. After the tail node receives the business message encapsulated with the message header, in addition to performing network performance monitoring, it also needs to strip the message header from the business message. How to determine the tail node is a problem that needs to be considered at present.

[0004] Summary of the Invention

[0005] An embodiment of the present application provides a network performance monitoring method and device, which carries a first identifier for determining the tail node for reporting network performance in the message header forwarded along the flow. Therefore, monitoring can be performed based on the first identifier, and the device has the ability to determine the tail node based on the message flow.

[0006] In a first aspect, an embodiment of the present application provides a network performance monitoring method, applied to a network node, the method comprising:

[0007] Obtain a first message, where the first message includes a service message and a message header, where the message header includes a first identifier, and the first identifier is used to determine an egress node for reporting network performance;

[0008] Monitoring is performed based on the parameters used to determine the tail node for reporting network performance.

[0009] In an embodiment of the present application, the message header includes a first identifier, and the tail node for network performance reporting can be determined based on the first identifier. Therefore, the first identifier enables the ability to plan the tail node in the message header, thereby supporting network performance monitoring scenarios for some network elements in the network and flexibly controlling the boundaries of network performance monitoring. It can be seen that the network node can perform detection based on the parameters used to determine the tail node for network performance reporting, without relying on other information to determine the tail node. This avoids incorrect processing of the first message due to the inability to identify the tail node. For example, in the Native Internet Protocol version 6 (Native IPv6) scenario, because there is no outer layer (underlay) encapsulation, there is no action to decapsulate the underlay encapsulation. According to the existing method, it may not be recognized as the tail node, and therefore the message header of the first message will not be stripped. The message header will follow the service message out of the detection domain. Because the message header is encapsulated in the service message, the service message will be discarded according to the existing method. However, through the embodiments of the present application, it is possible to avoid the situation where service messages are lost due to failure to identify the tail node, thereby ensuring network quality and improving network performance.

[0010] In a possible implementation of the first aspect, obtaining the first message includes:

[0011] receiving the service message, where the service message includes a destination address, and the destination address corresponds to the egress node;

[0012] Generate the first message based on the destination address and the service message.

[0013] As can be seen, the destination address corresponds to the egress node, which is the node that requires network performance monitoring. Therefore, the forwarding path corresponding to the destination address requires network performance monitoring. Therefore, based on the destination address, the head node can encapsulate the message header into the service message to generate a first message, allowing the first message to be forwarded along the forwarding path. Each node along the forwarding path can then perform network performance monitoring based on the message header in the first message.

[0014] In a possible implementation of the first aspect, obtaining the first message includes:

[0015] Receive the first message. It is understandable that, in the detection domain, nodes other than the head node receive messages including message headers.

[0016] In a possible implementation of the first aspect, the first identifier includes at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

[0017] It can be seen that the first identifier includes different types of node identifiers, so the present application can be applied to different scenarios, such as a scenario where the tail node belongs to a node group, or a scenario where the tail node is a single network element.

[0018] In one possible implementation of the first aspect, the first identifier further includes: at least one of a second identifier and a third identifier, wherein the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the egress node. As can be seen, the second identifier can be used to determine the service message transmission direction, thereby ensuring network performance monitoring based on the first identifier in the desired transmission direction. The third identifier can be used to determine the type of egress node carried in the message header, thereby determining whether it is an egress node based on the specific type.

[0019] In a possible implementation of the first aspect, the monitoring based on the parameter used to determine the egress node for reporting network performance includes:

[0020] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0021] As can be seen, the packet header carries information used to determine whether it is an egress node, such as at least one of the group ID and the egress node ID. Therefore, the packet header has the ability to carry the egress node ID. Determining whether a packet is not an egress node based on the packet header can be applied to more scenarios, such as Native IPv6.

[0022] In a possible implementation of the first aspect, the monitoring based on the parameter used to determine the egress node for reporting network performance includes:

[0023] Based on the three identifiers, determining that the message header includes at least one of the group identifier and the egress node identifier;

[0024] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0025] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0026] It can be seen that when the transmission direction of the service message is downlink, it can be determined based on at least one of the group identifier and the identifier of the tail node that it is not the tail node, indicating that it is not yet at the boundary of the detection domain. Therefore, it is necessary to continue sending the first message so that subsequent nodes can perform network performance monitoring based on the first message.

[0027] In a possible implementation of the first aspect, the monitoring based on the parameter used to determine the egress node for reporting network performance includes:

[0028] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0029] It can be seen that the packet header carries information used to determine whether it is an egress node, such as at least one of the group ID and the egress node ID. Therefore, the packet header has the ability to carry the egress node ID. Determining the egress node based on the packet header can be applied to more scenarios, such as Native IPv6.

[0030] In a possible implementation of the first aspect, the monitoring based on the parameter used to determine the egress node for reporting network performance includes:

[0031] Based on the three identifiers, determining that the message header includes at least one of the group identifier and the egress node identifier;

[0032] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0033] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0034] It can be seen that when the transmission direction of the service message is downlink, it can be determined as the tail node based on the group identifier and at least one of the identifiers of the tail node, indicating that it is already at the boundary of the detection domain. Therefore, it is necessary to strip the message header from the first message to obtain the service message, so as to ensure that the information in the message header is forwarded within the detection domain where network performance monitoring is required and will not be leaked to other nodes.

[0035] In one possible implementation of the first aspect, the message header is an iFit header for in-flow detection, and the iFit header includes an extension bit for carrying at least one of the group identifier and the identifier of the tail node. This application is applicable to iFit scenarios, and information can be extended by using the extension bit in the iFit header, enabling messages carrying the iFit header to identify the tail node, thereby facilitating convenient operation and widespread application.

[0036] In a possible implementation of the first aspect, the message header is an in-band operation management and maintenance IOAM header, and the IOAM header includes a directly derived DEX option type, and the DEX option type is used to carry at least one of the group identifier and the tail node identifier. It can be seen that the present application is applicable to IOAM scenarios, and the information can be extended by the DEX option type so that the message carrying the IOAM header has the ability to identify the tail node, which is convenient to operate and widely used. Among them, the DEX option type includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the tail node identifier.

[0037] In a second aspect, an embodiment of the present application provides a device, comprising a communication module and a processing module, wherein:

[0038] The communication module is configured to obtain a first message, where the first message includes a service message and a message header, the message header includes a first identifier, and the first identifier is used to determine an egress node for reporting network performance;

[0039] The processing module is used to monitor based on the parameters used to determine the tail node for reporting network performance.

[0040] In a possible implementation of the second aspect, the communication module is specifically configured to:

[0041] receiving the service message, where the service message includes a destination address, and the destination address corresponds to the egress node;

[0042] Generate the first message based on the destination address and the service message.

[0043] In a possible implementation of the second aspect, the communication module is specifically configured to:

[0044] Receive the first message.

[0045] In a possible implementation of the second aspect, the first identifier includes at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

[0046] In a possible implementation of the second aspect, the first identifier further includes: at least one of a second identifier and a third identifier, the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the tail node.

[0047] In a possible implementation manner of the second aspect, the processing module is specifically configured to:

[0048] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0049] In a possible implementation manner of the second aspect, the processing module is specifically configured to:

[0050] Determining, based on the third identifier, that the message header includes at least one of the group identifier and the egress node identifier;

[0051] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0052] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0053] In a possible implementation manner of the second aspect, the processing module is specifically configured to:

[0054] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0055] In a possible implementation manner of the second aspect, the processing module is specifically configured to:

[0056] Based on the three identifiers, determining that the message header includes at least one of the group identifier and the egress node identifier;

[0057] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0058] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0059] In a possible implementation of the second aspect, the message header is an in-flow detection iFit header, the iFit header includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the identifier of the egress node.

[0060] In a possible implementation of the second aspect, the message header is an in-band operation, administration, and maintenance (IOAM) header, the IOAM header includes a direct export (DEX) option type, and the DEX option type is used to carry at least one of the group identifier and the tail node identifier.

[0061] In a possible implementation of the second aspect, the DEX option type includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the egress node identifier.

[0062] In a third aspect, the present application provides a network node, the network node comprising a processor and a memory;

[0063] The processor is used to execute instructions stored in the memory so that the computing device implements the method described in any one of the first aspects above.

[0064] Optionally, the computing device further includes a communication interface, wherein the communication interface is used to receive and / or send data, and / or the communication interface is used to provide input and / or output for the processor.

[0065] It should be noted that the above embodiments are described using a processor (or general-purpose processor) that executes a method by calling a computer instruction. In specific implementations, the processor may also be a dedicated processor, in which case the computer instructions are pre-loaded into the processor. Alternatively, the processor may include both a dedicated processor and a general-purpose processor.

[0066] Optionally, the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together.

[0067] In a fourth aspect, an embodiment of the present application further provides a computing device cluster, which includes at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes any method described in the first aspect.

[0068] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, and when the instructions are executed on at least one processor, the method described in any one of the first aspects is implemented.

[0069] In a sixth aspect, the present application provides a computer program product, which includes computer instructions. When the instructions are executed on at least one processor, the method described in any one of the first aspects is implemented.

[0070] Optionally, the computer program product may be a software installation package or an image package. When the aforementioned method is required, the computer program product may be downloaded and executed on a computing device.

[0071] The beneficial effects of the technical solutions provided in the second to sixth aspects of this application can refer to the beneficial effects of the technical solution in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] FIG1A is a schematic diagram of the structure of an iFit message header provided in an embodiment of the present application;

[0073] FIG1B is a schematic diagram of the structure of a DEX option type provided in an embodiment of the present application;

[0074] FIG2 is a schematic diagram of a network architecture provided in an embodiment of the present application;

[0075] FIG3A is a schematic diagram of a tunnel splicing application scenario provided by an embodiment of the present application;

[0076] FIG3B is a schematic diagram of a scenario of underlay-free packaging provided by an embodiment of the present application;

[0077] FIG4 is a flow chart of a network performance monitoring method provided in an embodiment of the present application;

[0078] FIG5 is a schematic structural diagram of a first identifier provided in an embodiment of the present application;

[0079] FIG6 is a schematic diagram of a network architecture of a scenario 1 provided in an embodiment of the present application;

[0080] FIG7 is a schematic diagram of a network architecture for scenario 2 provided in an embodiment of the present application;

[0081] FIG8 is a schematic diagram of a network architecture for scenario 3 provided in an embodiment of the present application;

[0082] FIG9 is a schematic diagram of a network architecture for scenario 4 provided in an embodiment of the present application;

[0083] FIG10 is a schematic diagram of a network architecture of a scenario 5 provided in an embodiment of the present application;

[0084] FIG11 is a schematic structural diagram of a device provided in an embodiment of the present application;

[0085] FIG12 is a schematic diagram of the structure of another network node provided in an embodiment of the present application. DETAILED DESCRIPTION

[0086] The following is a clear and detailed description of the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "or" in the text is only a description of the association relationship between related objects, indicating that there can be three relationships, for example, A or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0087] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of the technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0088] For ease of understanding, the following examples provide some explanations of concepts related to the embodiments of the present application for reference.

[0089] 1. Flow detection technology (iFit)

[0090] iFit is a standardized detection protocol developed by the Internet Engineering Task Force (IETF). It uses in-flow detection (iFit) information carried in packets to tag network traffic with signatures, also known as coloring. Nodes passing through the traffic report collected data, such as timestamps and packet counts, to a control and management device, which then uses this data to calculate network latency and packet loss.

[0091] The in-flow detection (iFit) information can constitute an iFit message header as a whole, for example, as an extension header of the Multi-Protocol Label Switching (MPLS) protocol; or, the iFit information can also be included in an Internet Protocol (IP) header in a dispersed manner according to field information.

[0092] For example, FIG1A is a schematic diagram of the structure of an iFit message header provided in an embodiment of the present application. As shown in FIG1A , the iFitT message header includes three fields: a flow instruction indicator (FII) field, a flow instruction extension header (FIH) field, and an optional flow instruction extension header (FIEH) field. Among them:

[0093] The FII field is used to indicate that an iFit test is currently required for the service message. The FII field includes but is not limited to the following field information:

[0094] 1) Flow Instruction Indicator Label (FII Lable): used to identify the beginning of the iFit message header.

[0095] 2) Length: The total length of the iFit message header.

[0096] 3) Reserved field: reserved for future expansion.

[0097] The FIH field is also called the in-flow detection header or the flow detection header. This field is mainly used to carry information related to iFit detection, such as but not limited to the following fields:

[0098] 1) Flow ID: This field is 20 bits long and is used to uniquely identify a service message. It is unique within the entire detection domain.

[0099] 2) L flag, packet loss detection coloring mark, for example: the L flag value is "1" to collect packet loss, "0" to not collect packet loss.

[0100] 3) D flag, delay measurement coloring mark, for example, the D flag value is "1" to indicate that the timestamp is collected, and "0" to indicate that the timestamp is not collected.

[0101] 4) The R flag can be used as a reserved flag.

[0102] 5) R / S flag: If the boot tag is at the bottom of the stack (R), it is set to 1; if the boot tag is not at the bottom of the stack (S), it is set to 0. The default value is 1.

[0103] 6) Header type indicator (HTI), which marks the range of nodes that need to send iFit test results and the range of test content. For example, different tag values ​​can be used to distinguish whether to test the path nodes with iFit capabilities in addition to testing the two end nodes, and whether the FIEH field is valid, etc.

[0104] The FIEH field is also known as the stream extension detection header or extended stream detection header. This field is an extension field and includes extension bit 0 to extension bit 6. It is mainly used to carry other iFit detection-related information, such as but not limited to the following fields:

[0105] 1) Flow ID Ext: This field is 20 bits long and is used to extend the flow ID bit width. This field records the flow ID together with the flow ID field in the FIH.

[0106] 2) E flag, statistical mode mark, including hop-by-hop mode and E2E mode. For example, the E flag value of "1" identifies the E2E mode.

[0107] 3) The P flag is used in IPv4 encapsulation to prevent Probe Marker mismatches. For example, a P flag value of "1" indicates a mismatch, and no statistics are required at this time.

[0108] 4) F flag, forward flow flag, for example: F flag position "1" indicates forward flow.

[0109] 5) Extended length (Length), extended length mark.

[0110] 6) Trace type, used to identify the extended header field type, such as carrying a timestamp, or automatically building a reverse flow, etc.

[0111] 7) Timestamp: This field is 32 bits long and is used to detect packet-by-packet delay in nanoseconds (ns).

[0112] 8) Destination IP (DIP) / Source IP (SIP) mask, indicating the IPv4 / IPv6 mask length.

[0113] 9) Protocol flag (proto / ports), which indicates the protocol number, the source port number, and the destination port number of the transport layer. For example, a value of "1" indicates valid.

[0114] 10) V flag, indicating whether reverse flow needs to be established. For example, a V flag value of "1" indicates that a reverse flow is established.

[0115] 11) Period: indicates the synchronization reporting period in seconds.

[0116] 2. In-band Operation, Administration, and Maintenance (IOMA) is a network measurement and monitoring technology that samples service traffic in real time and at high speed. IOMA information, such as metadata (device ID, input and output interfaces, timestamps, and other information), is added to the sampled data. The sampled data is then proactively sent to an analyzer or controller for analysis, providing real-time awareness of network operational status.

[0117] The IOMA header option types include a Direct Export (DEX) option type, which is used for triggers to directly export or locally aggregate IOMA data without pushing it into a dynamic data package.

[0118] Please refer to Figure 1B, which is a schematic diagram of the structure of a DEX option type provided in an embodiment of the present application. As shown in Figure 1B, the DEX option type includes one or more of the following fields:

[0119] 1) Namespace ID: This field is 16 bits long.

[0120] 2) Flags: The length of this field is 8 bits.

[0121] 3) Extension-Flags: This field is 8 bits long. Each bit set to 1 in this field indicates the presence of a corresponding optional field.

[0122] 4) IOMA-Trace Type: This field is 24 bits long and is used to indicate which IOMA data fields are exported.

[0123] 5) Reserved bit (Reserved).

[0124] 6) Flow ID: This is an optional field that indicates a flow identifier, the presence of which is indicated by a corresponding flag in the Extension-Flags field.

[0125] 7) Sequence Number: This is an optional field whose presence is indicated by the corresponding flag in the Extension-Flags field. It starts at 0 and increments by 1 for packets from the same flow on an encapsulating node that includes the DEX option.

[0126] 3. Detection Domain

[0127] In a network, a detection domain can be specified to define the network range within which in-stream detection is to be performed. Nodes within the detection domain typically transmit in-stream detection information to implement in-stream detection and send the corresponding information obtained after in-stream detection to the control and management device. The detection scope of a detection domain can be determined in a variety of ways. For example, it can be determined based on the network scenario, such as specifying the core network as the detection domain; or it can be determined based on the service type, such as specifying different detection domains for video and voice services.

[0128] The iFit detection domain includes three types of nodes: head nodes, iFit path nodes, and iFit end nodes. Intermediate nodes can be referred to as hop-by-hop path nodes. Head nodes, end nodes, and intermediate nodes can be network nodes in the network.

[0129] For a service message, the first network node that transmits the message within the detection range specified by the detection domain is considered the head node. The last network node that transmits the message within the detection range specified by the detection domain is considered the tail node. Each node that transmits the message between the head node and the tail node is considered an intermediate node. In-stream detection information can be added by the head node and removed by the tail node.

[0130] 4. Tunneling technology

[0131] Tunneling is a method of transmitting data between networks using the internetwork infrastructure. The data (or payload) transmitted through a tunnel can be data frames or packets from different protocols. The tunneling protocol re-encapsulates these data frames or packets in a new header and transmits them. This new header provides routing information, enabling the encapsulated payload data to be transmitted across the internetwork.

[0132] The encapsulated data packets are routed through the public internet between the two endpoints of the tunnel. The logical path that the encapsulated data packets take as they travel across the public internet is called a tunnel. Once at the network endpoint, the data is unpacked and forwarded to its final destination.

[0133] Next, a possible network architecture for network performance monitoring is introduced. Please refer to Figure 2, which is a schematic diagram of a network architecture provided in an embodiment of the present application. Network 100 includes a control and management device and multiple network nodes, and the multiple network nodes are connected by communication links for transmitting service messages. As shown in Figure 2, the head node, intermediate node 1, intermediate node 2 and tail node in the detection domain are connected by communication links. In addition to the nodes shown in Figure 2, the detection domain may also include other nodes not shown.

[0134] In one implementation, the tail node can also be connected to an external node via a communication connection. The head node can receive service messages from other devices, and the service messages can reach the external node via the head node, intermediate node 1, intermediate node 2, and the tail node.

[0135] The control and management device in network 100 may be, for example, a centralized manager, a network management system, or a traffic analysis device that performs traffic analysis. For example, the control and management device may be a single device or a collection of multiple devices. The control and management device may be a functional module integrated into a specific physical device, or may be a physical device used to implement the functions described in the present application as being implemented by the control and management device.

[0136] In an embodiment of the present application, a detection domain can be determined by a control and management device. The detection domain is the detection range determined by the control and management device, or it can be configured separately on each forwarding device in the detection domain to form a detection domain. On the transmission path of the detection domain, the network nodes located between the head node and the tail node of the detection domain are intermediate nodes, such as intermediate node 1 and intermediate node 2 in Figure 2. The control and management device can deploy flow detection technology on each node in the detection domain to detect transmission delay and packet loss in the detection domain.

[0137] At present, network performance monitoring technology has certain limitations. Specifically, the stripping of the message header depends on the decapsulation of the underlay encapsulation in the service message. The so-called underlay encapsulation refers to the message encapsulation format corresponding to the bearer protocol, and the message encapsulation formats corresponding to different bearer protocols are different. In the case where a bearer protocol is deployed in the detection domain, when a network node in the detection domain decapsulates the underlay encapsulation in the service message, the network node can be considered as the tail node in the on-line detection, and the tail node can strip the message header of the service message. However, in on-line detection without underlay encapsulation, or in on-line detection with multiple underlay encapsulations, there is a problem that the tail node cannot strip the message header, which may cause the data message in the service message to be discarded due to inability to identify it.

[0138] Deploying a bearer protocol in the detection domain can also be considered as deploying a network that supports the bearer protocol in the detection domain. For example, deploying the Segment Routing Internet Protocol Version 6 (SRv6) protocol in the detection domain means deploying an SRv6 network in the detection domain.

[0139] For ease of understanding, the limitations of the network performance monitoring technology mentioned above are described below in conjunction with specific application scenarios. The limitations of network performance monitoring technology are not limited to the two application scenarios described below. Accordingly, the methods provided in the embodiments of this application are not limited to the two application scenarios described below.

[0140] Please refer to Figure 3A, which is a schematic diagram of a scenario for a tunnel splicing application provided in an embodiment of the present application. In the scenario shown in Figure 3A, a virtual extensible local area network (VXLAN) is deployed between the ingress provider edge (ingress PE) device and the service function forwarding (SFF) device, and an SRv6 network is deployed between the SFF device and the egress PE device. The customer edge (CE) device CE1 sends a service message to the customer edge device CE2, and the message passes through the VXLAN and SRv6 networks during the forwarding process.

[0141] In some scenarios, the ingress PE shown in FIG3A may be a LAN switch (LSW), the SFF device may be a gateway, and the egress PE may be a router.

[0142] In some scenarios, the network between the ingress PE and the egress PE can be designated as a detection domain, and the performance of the detection domain can be monitored using flow detection technology. Next, we will discuss the limitations of current flow detection technology for the transmission of service packets within the detection domain.

[0143] In step 1, after receiving the service message from CE1, the ingress PE performs underlay encapsulation on the service message, re-encapsulates the service message into a VXLAN message, and encapsulates the network performance monitoring information into the VXLAN message to instruct the node that receives the network performance monitoring information to perform flow detection.

[0144] Step 2: Ingress PE sends the VXLAN packet to SFF.

[0145] In step 3, the SFF performs underlay encapsulation on the received VXLAN message, re-encapsulates it into an SRv6 message, and sends the SRv6 message to the egress PE.

[0146] In one implementation, the SFF strips the network performance monitoring information from the VXLAN message when re-encapsulating the VXLAN message. In other words, the SRv4 message sent by the SFF to the egress PE does not include the network performance monitoring information.

[0147] Step 4: The egress PE sends the SRv6 packet to CE2.

[0148] As can be seen from the preceding description, network performance monitoring information is not transmitted throughout the entire detection domain. This is because the SFF strips the network performance monitoring information from the VXLAN packet when re-encapsulating it in step 3. However, the SFF is not the egress node (i.e., the egress PE) in the detection domain. Therefore, in scenarios where service packets span multiple underlay encapsulations, the egress node in the detection domain cannot be identified based on underlay encapsulation decapsulation.

[0149] Please refer to Figure 3B, which is a schematic diagram of a scenario without underlay encapsulation provided by an embodiment of the present application. In the scenario shown in Figure 3B, data is exchanged between CE3 and CE4, a Native IPv6 network is deployed between the ingress PE and the SFF, and a Native IPv6 network is deployed between the SFF and the egress PE. In some scenarios, the ingress PE shown in Figure 3B can be a wireless access point (AP), the SFF can be a gateway, and the egress PE can be a router.

[0150] As shown in Figure 3B, when CE3 sends an IPv6 packet to CE4, it passes through the ingress PE, SFF, and egress PE in the detection domain. Because IPv6 packets lack underlay encapsulation, underlay encapsulation and decapsulation are not necessary. Therefore, in a native IPv6 scenario, the egress PE cannot be identified as the egress node, and network performance monitoring information cannot be stripped. This information may leave the detection domain along with the IPv6 packet, potentially causing the IPv6 packet to be discarded due to unrecognized information.

[0151] In the scenarios shown in Figures 3A and 3B, the tail node can be specified based on interface configuration, but this increases configuration complexity and cannot be set based on service packets. Current network performance monitoring only supports orchestration of the head node, not the tail node, making it impossible to flexibly control the measurement domain boundaries.

[0152] In view of this, the present application provides a network performance monitoring method, which is applied to a network node, such as at least one of a head node, an intermediate node, and an egress node in a detection domain. The network node obtains a first message, wherein the first message includes a service message and a message header. The message header includes a first identifier, and the first identifier is used to identify the egress node to report network performance. In this way, the network node can perform monitoring based on the first identifier. In one implementation, the node determines that it is not a egress node based on the first identifier, and then sends the first message. In another implementation, the node determines that it is a egress node based on the first identifier, and then obtains a service message based on the first message.

[0153] Please refer to Figure 4, which is a flow chart of a network performance monitoring method provided by an embodiment of the present application. Optionally, the method can be applied to the aforementioned flow detection scenario, such as the scenario shown in Figures 2, 3A and 3B.

[0154] The network performance monitoring method shown in Figure 4 may include one or more steps from step S401 to step S402. It should be understood that for the sake of convenience, this application describes the steps from S401 to S402 in this order, and is not intended to limit execution to the above order. The embodiments of this application do not limit the order of execution, execution time, number of executions, etc. of the above one or more steps.

[0155] Steps S401 to S402 are specifically as follows:

[0156] Step S401: A network node obtains a first message.

[0157] The first message includes a service message and a message header, the message header includes a first identifier, and the first identifier is used to determine the tail node for reporting network performance.

[0158] In one implementation, the network node is a head node in the detection domain (such as the head node shown in Figure 2, or the ingress PE shown in Figure 3A or Figure 3B). The head node receives and stores a message header from a control and management device (for example, the control and management device shown in Figure 2). The head node receives a service message from a user device (for example, CE1 shown in Figure 3A or CE2 shown in Figure 3B). The service message includes a destination address. The head node can determine the forwarding path of the service message based on the destination address. The tail node can be a node on the forwarding path of the service message. The head node can determine whether the service message requires network performance monitoring based on part or all of the information in the header information of the service message (for example, a four-tuple, a five-tuple, or a seven-tuple). If it is determined that the service message requires network performance monitoring, the head node encapsulates the above message header in the service message to generate a first message. Furthermore, the head node sends the first message to the next hop node in the detection domain. For example, in a hop-by-hop scenario, the head node sends the first message to an intermediate node in the detection domain. In an end-to-end scenario, the head node sends the first message to the tail node in the detection domain.

[0159] The four-tuple includes: source Internet Protocol (IP) address, source port, destination IP address, and destination port.

[0160] The five-tuple includes: source IP address, source port, destination IP address, destination port, and protocol number.

[0161] The seven-tuple includes: source IP address, source port, destination IP address, destination port, protocol number, service type, and interface index.

[0162] In one implementation, the network node is not the head node in the detection domain. For example, in a hop-by-hop scenario, the network node is an intermediate node in the detection domain and receives the first message from the head node. Alternatively, if the network node is an egress node in the detection domain, the egress node receives the first message from the intermediate node. For another example, in an end-to-end measurement scenario, the network node is an egress node in the detection domain and receives the first message from the head node.

[0163] The message header is used to indicate the network performance of the monitoring detection domain, and the detection domain includes the network between the head node and the tail node.

[0164] Please refer to Figure 5, which is a schematic diagram of the structure of a first identifier provided in an embodiment of the present application.

[0165] In one implementation, the first identifier includes at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

[0166] In one scenario, the packet header is an iFit header, which includes an extension bit that carries at least one of a group identifier and an egress node identifier. The FIEH field in the iFit header serves as an extension field, and at least one extension bit of the Trace type field under the FIEH field carries at least one of the group identifier and the egress node identifier.

[0167] In one scenario, the message header is an in-band operations administration and maintenance (IOAM) header, and the IOAM header includes a direct export (DEX) option type, wherein the DEX option type includes an extension bit, and the extension bit is used to carry at least one of a group identifier and an egress node identifier.

[0168] For example, the first identifier includes but is not limited to the following field information:

[0169] 1) Number of egress nodes (egressID_cnt): This field is 10 bits long and is used to indicate the number of egress nodes. For example, the egress node can be a network element ID, a network element group ID, an egress node management IP address, or an interface IP.

[0170] 2) Egress node size (egressID_size): This field is 6 bits long and is used to indicate the size of an egress node.

[0171] 3) The second identifier is the direction (dir) field, which is 1 bit long and is used to identify the service message transmission direction. For example, a value of "0" in the direction field indicates that the service message transmission direction is downlink and the tail node is matched in the downlink direction; a value of "1" indicates that the service message transmission direction is uplink and the tail node is matched in the uplink direction.

[0172] 4) The third identifier: the tail node type (egressID_type) field: This field is 3 bits long and is used to identify that the first identifier carries at least one of the group identifier and the tail node identifier. For example, a value of "0" indicates that the first identifier carries the tail node identifier (nodeID); a value of "1" indicates that the first identifier carries the network element group identifier (nodeGroupID).

[0173] 5) Reserved field: reserved for future expansion.

[0174] 6) Egress node list (egressID_list): EgressID1 (the bit width is specified by the egress node size), used to represent a list of group identifiers or egress node identifiers (including the number of egress nodes).

[0175] In step S402, the network node performs monitoring based on parameters used to determine the tail node for reporting network performance.

[0176] The present application carries information for determining the tail node for reporting network performance through at least one extended bit in the message header, so that the message header has the ability to identify the tail node.

[0177] In one implementation, the network node determines that it is not a tail node (for example, an intermediate node) based on at least one of the group identifier and the tail node identifier, and forwards the first message to the next hop.

[0178] In one implementation, the network node determines that it is the egress node in the detection domain based on at least one of the group identifier and the egress node identifier, and obtains the service message based on the first message.

[0179] In one possible implementation, the network node stores a flow table, which is a data structure for storing rules, including matching conditions for service messages and corresponding operations. The network node may process the first message based on the first identifier and the flow table.

[0180] In one implementation, at least one of the group identifier and the tail node identifier is not stored in the flow table. After the network node obtains the first message, since at least one of the group identifier and the tail node identifier is not stored in the flow table, the first message misses the flow table based on the first identifier. Therefore, the network node can determine that it is a tail node based on the first identifier, or determine that it is not a tail node (for example, an intermediate node) based on the first identifier. Then, the network node stores the identifier corresponding to the tail node (such as at least one of the group identifier and the tail node identifier) ​​in the flow table, or stores the identifier of the non-tail node in the flow table. When the next business message reaches the network node, the network node can determine that it is a tail node based on the identifier stored in the flow table, and obtain the business message based on the first message. Alternatively, the network node can determine that it is not a tail node based on the identifier stored in the flow table, and forward the first message to the next node.

[0181] In one implementation, the flow table stores an identifier corresponding to the tail node (such as at least one of the group identifier and the tail node identifier) ​​or an identifier corresponding to a non-tail node (such as an intermediate node). After the network node obtains the first message, since the flow table stores an identifier corresponding to the tail node or an identifier corresponding to the non-tail node, the network node can determine whether it is a tail node or not based on the first identifier carried by the first message. Exemplarily, if at least one of the group identifier and the tail node identifier included in the first identifier is consistent with the identifier stored in the flow table, it is determined to be a tail node, and a service message is obtained based on the first message. Exemplarily, if at least one of the group identifier and the tail node identifier included in the first identifier is inconsistent with the identifier stored in the flow table, it is determined to be not a tail node, and the first message is forwarded.

[0182] Exemplarily, it can be seen from Figure 5 that the first identifier is at least one of the second identifier and the third identifier, the second identifier is used to identify the transmission direction of the service message, and the third identifier is used to identify that the message header carries at least one of the group identifier and the tail node identifier.

[0183] In one possible implementation, the network node determines, based on the second identifier, that the transmission direction of the service message is downlink. Based on the third identifier, the network node determines that the message header includes at least one of a group identifier and an identifier of an egress node. Based on at least one of the group identifier and the egress node identifier, the network node determines that the egress node is not the egress node and transmits the first message.

[0184] In one implementation, the network node determines, based on the second identifier, that an egress node match is performed when the transmission direction of the service message is downlink, or determines, based on the second identifier, that an egress node match is performed when the transmission direction of the service message is uplink. Therefore, if the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which the network node forwards the first message, the network node determines that it is not the egress node and sends the first message.

[0185] Exemplarily, "inconsistency" includes one or more of the following: based on the second identifier, the transmission direction of the message is determined to be downlink, and the network node forwards the first message in an uplink direction; based on the second identifier, the transmission direction of the message is determined to be uplink, and the network node forwards the first message in a downlink direction.

[0186] In one implementation, the network node determines, based on the second identifier, to perform tail node matching when the service message is transmitted in the downlink direction, or determines, based on the second identifier, to perform tail node matching when the service message is transmitted in the uplink direction. Therefore, if the service message transmission direction determined based on the second identifier is consistent with the direction in which the network node forwards the first message, the network node obtains a locally stored node identifier based on at least one of a group identifier or a representation of the tail node. If at least one of the group identifier or the tail node identifier is not present in the locally stored node identifiers, the node is determined not to be a tail node and the first message is sent.

[0187] In another possible implementation, the network node determines, based on the second identifier, that the transmission direction of the service message is downlink. Based on the third identifier, the network node determines that the message header includes at least one of a group identifier and an egress node identifier. Based on at least one of the group identifier and the egress node identifier, the network node determines that it is the egress node and sends the first message.

[0188] In one implementation, the network node determines, based on the second identifier, to perform tail node matching when the service message is transmitted in the downlink direction, or determines, based on the second identifier, to perform tail node matching when the service message is transmitted in the uplink direction. Therefore, if the service message transmission direction determined based on the second identifier is consistent with the direction in which the network node forwards the first message, the network node obtains a locally stored node identifier based on at least one of a group identifier or a representation of the tail node. If at least one of the group identifier or the tail node identifier is present in the locally stored node identifiers, the node is determined to be the tail node and the first message is sent.

[0189] Exemplarily, "consistency" includes one or more of the following: based on the second identifier, the transmission direction of the message is determined to be downlink, and the network node forwards the first message in the downlink direction; based on the second identifier, the transmission direction of the message is determined to be uplink, and the network node forwards the first message in the uplink direction.

[0190] Exemplarily, the first identifier also includes a tail node list and the number of tail nodes. After obtaining the locally stored node identifiers, the network node traverses the locally stored node identifiers and compares at least one of the group identifiers, the tail node identifiers, and the tail node identifiers based on the number of tail nodes in the tail node list with the locally stored node identifiers. If a node identifier among the locally stored node identifiers is consistent with any tail node identifier in the tail node list, the network node is identified as a tail node.

[0191] In another implementation, when the traffic matching direction is consistent with the forwarding direction of the first message, a locally stored node identifier is obtained based on the type of the egress node identifier. If the egress node identifier is not present in the node identifier, it indicates that the network node is not an egress node in the detection domain, and the network node performs measurement processing on the first message in an intermediate node manner.

[0192] Next, the network performance monitoring method provided by this application is introduced in conjunction with specific application scenarios.

[0193] The message header includes a first identifier, and the first identifier is used to determine the tail node for reporting network performance.

[0194] In one implementation, the first identifier includes at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

[0195] In one implementation, the first identifier further includes: at least one of a second identifier and a third identifier, the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the tail node.

[0196] Scenario 1: The egress node is determined based on the egress node identifier and the service message transmission direction is downlink and / or is determined not to be the egress node.

[0197] FIG6 is a schematic diagram of a network architecture of a scenario 1 provided by an embodiment of the present application. The network 60 includes a control management device 600 and multiple network nodes, which are connected by communication links for transmitting service messages. As shown in FIG6 , the first network node 601, the second network node 602, and the third network node 603 in the detection domain are connected by communication links. In addition to the nodes shown in FIG6 , the detection domain may also include other nodes not shown. Among them,

[0198] In scenario 1 shown in Figure 6 , the control and management device 600 can configure a message header to be deployed on the first network node 601. At least one extension bit in the message header is used to carry a first identifier. For a detailed description, refer to Figure 5 . The service message sent by the user equipment includes a destination address, which corresponds to the third network node 603. On the forwarding path corresponding to the destination address, the external node can receive the service message via forwarding by the first network node 601, the second network node 602, and the third network node 603. The node identifier of the first network node 601 is nodeID_A, the node identifier of the second network node 602 is nodeID_B, and the node identifier of the third network node 603 is nodeID_C.

[0199] After receiving the service message, the entry 6011 of the first network node 601 determines, based on the destination address, that the service message is a message requiring network performance monitoring, and encapsulates the message header within the service message to generate a first message. The message header includes a first identifier, which includes, but is not limited to, the following fields: number of egress nodes EgressID_cnt = 1, egress node size EgressID_size = 4, second identifier dir = 0, third identifier EgressID_type = 0, and EgressID1 is nodeID_C.

[0200] When the egress 6012 of the first network node 601 forwards the first message, based on the second identifier dir=0 in the first identifier, it is determined that the tail node matching is performed when the service message transmission direction is downstream, because the direction in which the first network node 601 forwards the first message at the egress 6012 is downstream. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the first network node forwards the first message at the egress 6012. The first network node 601 determines that the message header includes the identifier of the tail node based on the third identifier EgressID_type=0. The first network node 601 obtains the locally stored network element ID (for example, nodeID_A), and then determines based on the field EgressID1 that nodeID_C is inconsistent with the current network element (nodeID_A), and determines that it is not the tail node. The egress 6012 of the first network node 601 forwards the first message to the next-hop node (for example, the second network node 602).

[0201] When second network node 602 receives the first message and forwards the first message through ingress 6021, it determines, based on the second identifier dir = 0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which second network node 602 forwards the first message at ingress 6021 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which second network node 602 forwards the first message at ingress 6021. Second network node 602 determines that it is not an egress node and forwards the first message.

[0202] When the second network node 602 forwards the first message through the egress 6022, based on the second identifier dir=0 in the first identifier, it determines to match the tail node when the service message transmission direction is downlink, because the direction in which the second network node 602 forwards the first message at the egress 6022 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the second network node forwards the first message at the egress 6022. The second network node 602 determines that the message header includes the identifier of the tail node based on the third identifier EgressID_type=0. The second network node 602 obtains the locally stored network element ID (for example, nodeID_B), and then determines based on the field EgressID1 that nodeID_C is inconsistent with the current network element (nodeID_B), and determines that it is not the tail node. The egress 6022 of the second network node 602 forwards the first message to the next-hop node (for example, the third network node 603).

[0203] When third network node 603 receives the first message and forwards the first message through ingress 6031, it determines, based on the second identifier dir=0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which third network node 603 forwards the first message at ingress 6031 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which third network node 603 forwards the first message at ingress 6031. Third network node 603 determines that it is not an egress node and forwards the first message.

[0204] When the third network node 603 forwards the first message through the egress 6032, based on the second identifier dir=0 in the first identifier, it determines to match the tail node when the service message transmission direction is downlink, because the direction in which the third network node 603 forwards the first message at the egress 6032 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the third network node forwards the first message at the egress 6032. The third network node 603 determines that the message header includes the identifier of the tail node based on the third identifier EgressID_type=0. The third network node 603 obtains the locally stored network element ID (for example, nodeID_C), and then determines that nodeID_C is consistent with the current network element (nodeID_C) based on the field EgressID1, and determines it to be the tail node. The third network node 603 obtains the service message based on the first message at the egress 6032.

[0205] Scenario 2: The egress node is determined to be uplink and / or is not the egress node based on the egress node identifier and the service message transmission direction.

[0206] FIG7 is a schematic diagram of a network architecture for scenario 2 provided by an embodiment of the present application. For the description of network 70 , reference can be made to the description of network 60 in FIG6 , which will not be repeated here.

[0207] In scenario 2 shown in Figure 7 , the message header is deployed on first network node 701, and at least one extension bit in the message header is used to carry a first identifier. For a detailed description, see Figure 5 . The service message sent by the user equipment includes a destination address, which corresponds to third network node 703. Along the forwarding path corresponding to the destination address, the service message reaches the external node via forwarding by first network node 701, second network node 702, and third network node 703. The node identifier of first network node 701 is nodeID_A, the node identifier of second network node 702 is nodeID_B, and the node identifier of third network node 703 is nodeID_C.

[0208] After receiving the service message, the entry 7011 of the first network node 701 determines, based on the destination address, that the service message is a message requiring network performance monitoring, and encapsulates the message header within the service message to generate a first message. The message header includes a first identifier, which includes, but is not limited to, the following fields: number of egress nodes EgressID_cnt = 1, egress node size EgressID_size = 4, second identifier dir = 1, third identifier EgressID_type = 0, and egress node list EgressID1 is nodeID_C.

[0209] When egress 7012 of first network node 701 forwards the first message, based on the second identifier dir=1 in the first identifier, it determines to perform tail node matching when the service message transmission direction is uplink, because the direction in which first network node 701 forwards the first message at egress 7012 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which first network node 701 forwards the first message at egress 7012. First network node 701 determines that it is not the tail node and forwards the first message to the next-hop node (e.g., second network node 702).

[0210] The second network node 702 receives the first message, and when forwarding the first message through the ingress 7021, it determines to match the tail node when the service message transmission direction is uplink based on the second identifier dir=1 in the first identifier. Because the direction in which the second network node 702 forwards the first message at the ingress 7021 is uplink, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the second network node 702 forwards the first message at the ingress 7021. The second network node 702 determines that the message header includes the identifier of the tail node based on the third identifier EgressID_type=0. The second network node 702 obtains the locally stored network element ID (for example, nodeID_B), and then determines based on the field EgressID1 that nodeID_C is inconsistent with the current network element (nodeID_B), and determines that it is not the tail node. The second network node 702 forwards the first message.

[0211] When second network node 702 forwards the first message through egress 7022, based on the second identifier dir=1 in the first identifier, it determines to perform tail node matching when the service message transmission direction is uplink, because the direction in which second network node 702 forwards the first message at egress 7022 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which the second network node forwards the first message at egress 7022. Second network node 702 determines that it is not the tail node and forwards the first message to the next-hop node (e.g., third network node 703).

[0212] When the third network node 703 receives the first message and forwards the first message through the ingress 7031, it determines, based on the second identifier dir=1 in the first identifier, that an egress node match is performed when the service message transmission direction is uplink. Because the direction in which the third network node 703 forwards the first message at the ingress 7031 is uplink, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the third network node 703 forwards the first message at the ingress 7031. The third network node 703 determines, based on the third identifier EgressID_type=0, that the message header includes an egress node identifier. The third network node 703 obtains the locally stored network element ID (e.g., nodeID_C), and then, based on the field EgressID1, determines that nodeID_C is consistent with the local network element (nodeID_B), determining it to be the egress node. The third network node 703 obtains the service message based on the first message at the ingress 7031.

[0213] Scenario three: The egress node is determined based on the identifiers of multiple egress nodes and the service message transmission direction is downlink and / or is determined not to be the egress node.

[0214] FIG8 is a schematic diagram of a network architecture for scenario 3 provided by an embodiment of the present application. For the description of network 80 , reference can be made to the description of network 60 in FIG6 , which will not be repeated here.

[0215] For example, in scenario three shown in FIG8 , a message header is deployed on first network node 801, and at least one extension bit in the message header is used to carry a first identifier. For a detailed description, refer to FIG5 . A service message sent by a user device includes a destination address, which corresponds to at least one of third network node 803 and / or fourth network node 804. Along the forwarding path corresponding to the destination address, the service message can reach an external node via forwarding by first network node 801, second network node 802, third network node 803, and / or fourth network node 804. The node identifier of first network node 801 is nodeID_A, the node identifier of second network node 802 is nodeID_B, the node identifier of third network node 803 is nodeID_C, and the node identifier of fourth network node 804 is nodeID_D.

[0216] After receiving the service message, the entry 8011 of the first network node 801 determines, based on the destination address, that the service message is a message requiring network performance monitoring, and encapsulates the message header within the service message to generate a first message. The message header includes a first identifier, which includes, but is not limited to, the following fields: number of egress nodes EgressID_cnt = 2, egress node size EgressID_size = 4, a second identifier dir = 0, a third identifier EgressID_type = 0, and a list of egress nodes, including EgressID1 as nodeID_C and EgressID2 as nodeID_D.

[0217] When egress 8012 of first network node 801 forwards the first message, based on the second identifier dir = 0 in the first identifier, it determines to perform an egress node match when the service message transmission direction is downlink, because the direction in which first network node 801 forwards the first message at egress 8012 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which first network node 801 forwards the first message at egress 8012. First network node 801 determines that the message header includes the egress node identifier based on the third identifier EgressID_type = 0, and that the message header includes two egress node identifiers based on the number of egress nodes EgressID_cnt = 2. First network node 801 obtains a locally stored network element ID (e.g., nodeID_A), then determines based on the EgressID1 field that nodeID_C is inconsistent with the current network element (nodeID_A), and based on the EgressID2 field that nodeID_D is inconsistent with the current network element (nodeID_A), thereby determining that it is not an egress node. The egress 8012 of the first network node 801 forwards the first message to the next-hop node (eg, the second network node 802 ).

[0218] When second network node 802 receives the first message and forwards the first message through ingress 8021, it determines, based on the second identifier dir = 0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which second network node 802 forwards the first message at ingress 8021 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which second network node 802 forwards the first message at ingress 8021. Second network node 802 determines that it is not an egress node and forwards the first message.

[0219] When second network node 802 forwards the first message through egress 8022, based on the second identifier dir = 0 in the first identifier, it determines to perform an egress node match when the service message transmission direction is downlink, because the direction in which second network node 802 forwards the first message at egress 8022 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the second network node forwards the first message at egress 8022. Second network node 802 determines that the message header includes the egress node identifier based on the third identifier EgressID_type = 0, and that the message header includes two egress node identifiers based on the number of egress nodes EgressID_cnt = 2. Second network node 802 obtains a locally stored network element ID (e.g., nodeID_B), then determines based on the EgressID1 field that nodeID_C is inconsistent with the current network element (nodeID_B), and based on the EgressID2 field that nodeID_D is inconsistent with the current network element (nodeID_A), thereby determining that it is not an egress node. The egress 8022 of the second network node 802 forwards the first message to the next-hop node (eg, the third network node 803 ).

[0220] When third network node 803 receives the first message and forwards the first message through ingress 8031, it determines, based on the second identifier dir=0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which third network node 803 forwards the first message at ingress 8031 ​​is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which third network node 803 forwards the first message at ingress 8031. Third network node 803 determines that it is not an egress node and forwards the first message.

[0221] When third network node 803 forwards the first message through egress 8032, based on the second identifier dir=0 in the first identifier, it determines to match an egress node when the service message transmission direction is downlink, because the direction in which third network node 803 forwards the first message at egress 8032 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the third network node forwards the first message at egress 8032. Third network node 803 determines that the message header includes the egress node identifier based on the third identifier EgressID_type=0, and that the message header includes two egress node identifiers based on the number of egress nodes EgressID_cnt=2. Third network node 803 obtains a locally stored network element ID (e.g., nodeID_C), and then, based on the field EgressID1, determines that nodeID_C is consistent with the current network element (nodeID_C), identifying it as the egress node. At egress 8032, third network node 803 obtains a service message based on the first message.

[0222] When fourth network node 804 receives the first message and forwards the first message through ingress 8041, it determines, based on the second identifier dir = 0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which fourth network node 804 forwards the first message at ingress 8041 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which fourth network node 804 forwards the first message at ingress 8041. Fourth network node 804 determines that it is not an egress node and forwards the first message.

[0223] When fourth network node 804 forwards the first message through egress 8042, based on the second identifier dir = 0 in the first identifier, it determines to match an egress node when the service message transmission direction is downlink. This is because the direction in which fourth network node 804 forwards the first message at egress 8042 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the fourth network node forwards the first message at egress 8042. Fourth network node 804 determines that the message header includes the egress node identifier based on the third identifier EgressID_type = 0, and that the message header includes two egress node identifiers based on the number of egress nodes EgressID_cnt = 2. Fourth network node 804 obtains a locally stored network element ID (e.g., nodeID_C), then traverses the list of egress nodes and, based on the field EgressID2, determines that nodeID_D is consistent with the current network element (nodeID_D), thus determining it to be the egress node. At egress 8042, fourth network node 804 obtains a service message based on the first message.

[0224] Scenario 4: The tail node is determined to be downlink and / or is not the tail node based on the group identifier and the service message transmission direction.

[0225] FIG9 is a schematic diagram of a network architecture for scenario 4 provided by an embodiment of the present application. For the description of network 90 , reference can be made to the description of network 60 in FIG6 , which will not be repeated here.

[0226] For example, in scenario 4 shown in FIG. 9 , a packet header is deployed on first network node 901, and at least one extension bit in the packet header is used to carry a first identifier. For a detailed description, refer to FIG. 5 . The service packet sent by the user equipment includes a destination address, and the destination address corresponds to at least one of third network node 903 and / or fourth network node 904. On the forwarding path corresponding to the destination address, the external node can receive the service packet via forwarding by first network node 901, second network node 902, third network node 903, and / or fourth network node 904.

[0227] The first network node 901, the second network node 902, the third network node 903, and the fourth network node 904 are each configured as a node group. The node identifier of the first network node 901 is nodeID_A, the node identifier of the second network node 902 is nodeID_B, the node identifier of the third network node 903 is nodeID_C, and the node identifier of the fourth network node 904 is nodeID_D. The node groups of the first network node 901 and the second network node 902 do not have a tail node. The group identifiers of the first network node 901 and the second network node 902 are node_groupID. The node group of the third network node 903 includes nodeID_C and nodeID_D, and the node group of the fourth network node 904 includes nodeID_C and nodeID_D. Therefore, the group identifiers of the third network node 903 and the fourth network node 904 are node_groupID1.

[0228] After receiving the service message, the ingress 9011 of the first network node 901 determines, based on the destination address, that the service message is a message requiring network performance monitoring, and encapsulates the message header within the service message to generate a first message. The message header includes a first identifier, which includes, but is not limited to, the following fields: number of egress nodes (EgressID_cnt = 1), egress node size (EgressID_size = 4), a second identifier (dir = 0), a third identifier (EgressID_type = 1), and an egress node list (EgressID list): ID1 = nodegroupID_C and nodegroupID_D.

[0229] It should be noted that when there are no members in the node group, the forwarding plane of the forwarder is not delivered, but the network-wide uniqueness of the group identifier must be guaranteed.

[0230] When the egress 9012 of the first network node 901 forwards the first message, based on the second identifier dir=0 in the first identifier, it is determined that the tail node matching is performed when the service message transmission direction is downlink, because the direction in which the first network node 901 forwards the first message at the egress 9012 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the first network node forwards the first message at the egress 9012. The first network node 901 determines that the message header includes a group identifier based on the third identifier EgressID_type=1. The first network node 901 obtains the local transaction node group (such as node_groupID), and then determines based on the field EgressID1 that node_groupID1 is inconsistent with the local network element (node_groupID), and determines that it is not the tail node. The egress 9012 of the first network node 901 forwards the first message to the next-hop node (such as the second network node 902).

[0231] When second network node 902 receives the first message and forwards the first message through ingress 9021, it determines, based on the second identifier dir = 0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which second network node 902 forwards the first message at ingress 9021 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which second network node 902 forwards the first message at ingress 9021. Second network node 902 determines that it is not an egress node and forwards the first message.

[0232] When the second network node 902 forwards the first message through the egress 9022, based on the second identifier dir=0 in the first identifier, it is determined that the tail node matching is performed when the service message transmission direction is downlink, because the direction in which the second network node 902 forwards the first message at the egress 9022 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the second network node forwards the first message at the egress 9022. The second network node 902 determines that the message header includes a group identifier based on the third identifier EgressID_type=1. The second network node 902 obtains the local group identifier (such as node_groupID), and then determines based on the field EgressID1 that node_groupID1 is inconsistent with the local group identifier (node_groupID), and determines that it is not a tail node. The egress 9022 of the second network node 902 forwards the first message to the next-hop node (such as the third network node 903).

[0233] When third network node 903 receives the first message and forwards the first message through ingress 9031, it determines, based on the second identifier dir=0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which third network node 903 forwards the first message at ingress 9031 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which third network node 903 forwards the first message at ingress 9031. Third network node 903 determines that it is not an egress node and forwards the first message.

[0234] When the third network node 903 forwards the first message through egress 9032, based on the second identifier dir=0 in the first identifier, it determines to perform tail node matching when the service message transmission direction is downlink, because the direction in which the third network node 903 forwards the first message at egress 9032 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the third network node forwards the first message at egress 9032. The third network node 903 determines that the message header includes a group identifier based on the third identifier EgressID_type=1. The third network node 903 obtains a local group identifier (e.g., node_groupID1), and then determines based on the field EgressID1 that node_groupID1 is consistent with the local group identifier (node_groupID1), determining that it is the tail node. The third network node 903 obtains a service message based on the first message at egress 9032.

[0235] When fourth network node 904 receives the first message and forwards the first message through ingress 9041, it determines, based on the second identifier dir = 0 in the first identifier, that an egress node match is performed when the service message transmission direction is downlink. Because the direction in which fourth network node 904 forwards the first message at ingress 9041 is uplink, the transmission direction of the service message determined based on the second identifier is inconsistent with the direction in which fourth network node 904 forwards the first message at ingress 9041. Fourth network node 904 determines that it is not an egress node and forwards the first message.

[0236] When the fourth network node 904 forwards the first message through the egress 9042, based on the second identifier dir=0 in the first identifier, it determines to perform tail node matching when the service message transmission direction is downlink, because the direction in which the fourth network node 904 forwards the first message at the egress 9042 is downlink. Therefore, the transmission direction of the service message determined based on the second identifier is consistent with the direction in which the fourth network node forwards the first message at the egress 9042. The fourth network node 904 determines that the message header includes a group identifier based on the fourth identifier EgressID_type=1. The fourth network node 904 obtains the local group identifier (for example, node_groupID1), and then determines based on the field EgressID1 that node_groupID1 is consistent with the local group identifier (node_groupID1), determining that it is the tail node. The fourth network node 904 obtains the service message based on the first message at the egress 9042.

[0237] Scenario 5: Based on the identifier of the egress node and the service packet transmission direction, the egress node is determined to be downstream and / or is not the egress node, and the determination result is stored in the flow table of the forwarding engine.

[0238] Figure 10 is a schematic diagram of a network architecture for scenario 5 provided by an embodiment of the present application. For the description of network 101, reference can be made to the description of network 60 in Figure 6, which will not be repeated here.

[0239] For example, in scenario five shown in FIG10 , the message header is deployed on the first network node 1001 . For a description of the message, please refer to FIG6 , which will not be repeated here.

[0240] For the relevant description of the entry 1011 of the first network node 1001, reference may be made to the relevant description of the entry 6011 of the first network node 601 in FIG6 , which will not be repeated here.

[0241] When the exit 1021 of the first network node 1001 forwards the first message, if at least one of the storage group identifier and the tail node identifier is not stored in the flow table 1031, the first identifier of the first message does not hit the flow table, and the relevant information of the first identifier in the message header is sent to the software layer. The first network node 1001 determines that it is not a tail node (for example, it is determined to be an intermediate node) based on the first identifier. The first network node 1001 sends the network element type of the exit 1021 (for example, an intermediate node) to the forwarding engine, and the forwarding engine performs corresponding processing based on the network type in the flow table, such as forwarding the first message. Among them, for the relevant description of "the first network node 1001 determines that it is not a tail node based on the first identifier", please refer to Figure 6, which will not be repeated here.

[0242] After the second network node 1002 receives the first message, when forwarding the first message through the entry 1012, if the first identifier based on the first message does not hit the flow table 1032, the relevant information of the first identifier in the message header is sent to the software layer. At the entry 1012, the second network node 1002 determines that it is not a tail node (for example, it is determined to be an intermediate node) based on the first identifier. The second network node 1002 sends the network element type of the entry 1012 (for example, an intermediate node) to the flow table to the forwarding engine, and the forwarding engine performs corresponding processing based on the network element type in the flow table, such as forwarding the first message. Among them, for the relevant description of "the second network node 1002 is at the entry 1012, and it is determined that it is not a tail node based on the first identifier", please refer to Figure 6, which will not be repeated here.

[0243] When the second network node 1002 forwards the first message through the exit 1022, if the first identifier based on the first message does not hit the flow table 1032, the relevant information of the first identifier in the message header is sent to the software layer. The second network node 1002 is at the exit 1022, and determines that it is not the tail node (for example, it is determined to be an intermediate node) based on the first identifier. The second network node 1002 sends the network element type of the exit 1022 (for example, the intermediate node) to the flow table to the forwarding engine, and the forwarding engine performs corresponding processing based on the network element type in the flow table, such as forwarding the first message. Among them, the relevant description of "the second network node 1002 is at the exit 1022, and determines that it is not the tail node based on the first identifier" can be referred to Figure 6, which will not be repeated here.

[0244] After the third network node 1003 receives the first message, when forwarding the first message through the entry 1013, if the first identifier based on the first message does not hit the flow table 1033, the relevant information of the first identifier in the message header is sent to the software layer. At the entry 1013, the third network node 1003 determines that it is not a tail node (for example, it is determined to be an intermediate node) based on the first identifier. The third network node 1003 sends the network element type of the entry 1013 (for example, it is determined to be an intermediate node) to the flow table to the forwarding engine, and the forwarding engine performs corresponding processing based on the network element type in the flow table, such as forwarding the first message. Among them, the relevant description of "the third network node 1003 is at the entry 1013, and it is determined that it is not a tail node based on the first identifier" can be referred to Figure 6, which will not be repeated here.

[0245] When the third network node 1003 forwards the first message through the exit 1023, if the first identifier based on the first message does not hit the flow table 1033, the relevant information of the first identifier in the message header is sent to the software layer. The third network node 1003 is determined to be the tail node based on the first identifier at the exit 1023. The third network node 1003 sends the network element type of the exit 1023 (for example, the tail node) to the forwarding engine. The forwarding engine performs corresponding processing based on the network element type in the flow table, such as obtaining a service message based on the first message. Among them, the relevant description of "the third network node 1003 is determined to be the tail node based on the first identifier at the exit 1023" can be referred to Figure 6, which will not be repeated here.

[0246] It should be noted that, in addition to being applied to the scenarios provided in this application, the network performance monitoring method provided in this application can also be applied to other scenarios, such as one or more of the following: "Determining the tail node and / or determining that it is not the tail node based on the identifiers of multiple tail nodes and the transmission direction of the service message for uplink", "Determining the tail node and / or determining that it is not the tail node based on the group identifier and the transmission direction of the service message for uplink", "Determining the tail node and / or determining that it is not the tail node based on the identifier of the tail node and the transmission direction of the service message for downlink, and storing the determined result in the flow table of the forwarding engine", "Determining the tail node and / or determining that it is not the tail node based on the identifier of the tail node and the transmission direction of the service message for uplink, and storing the determined result in the flow table of the forwarding engine". The scenarios of “determining the tail node for downlink and / or determining that it is not the tail node based on the identifiers of multiple tail nodes and the transmission direction of the business message, and storing the determined result in the flow table of the forwarding engine”, “determining the tail node for downlink and / or determining that it is not the tail node based on the group identifier and the transmission direction of the business message, and storing the determined result in the flow table of the forwarding engine”, “determining the tail node for uplink and / or determining that it is not the tail node based on the identifiers of multiple tail nodes and the transmission direction of the business message, and storing the determined result in the flow table of the forwarding engine”, and “determining the tail node for uplink and / or determining that it is not the tail node based on the group identifier and the transmission direction of the business message, and storing the determined result in the flow table of the forwarding engine”.

[0247] The method of the embodiment of the present application is described above, and the device of the embodiment of the present application is provided below.

[0248] Please refer to Figure 11, which is a schematic diagram of the structure of an apparatus 110 provided in an embodiment of the present application. The apparatus 110 may include a communication module 1101 and a processing module 1102. The apparatus 110 is used to implement the aforementioned network performance monitoring method, such as the network performance monitoring method in the embodiment of Figure 4, and the network performance monitoring methods mentioned in the scenarios of Figures 6-10.

[0249] Optionally, the device 110 may be a network node in the aforementioned embodiment, for example, the network node in the embodiment shown in FIG4 , or the first network node, the second network node, the third network node, or the fourth network node in the embodiments shown in FIG6 to FIG10 .

[0250] In a possible implementation, the communication module is configured to obtain a first message, where the first message includes a service message and a message header, the message header includes a first identifier, and the first identifier is used to determine an egress node for reporting network performance;

[0251] The processing module is used to monitor based on the parameters used to determine the tail node for reporting network performance.

[0252] In a possible implementation, the communication module is specifically configured to:

[0253] receiving the service message, where the service message includes a destination address, and the destination address corresponds to the egress node;

[0254] Generate the first message based on the destination address and the service message.

[0255] In a possible implementation, the communication module is specifically configured to:

[0256] Receive the first message.

[0257] In a possible implementation, the first identifier includes at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

[0258] In a possible implementation, the first identifier further includes: at least one of a second identifier and a third identifier, the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the tail node.

[0259] In a possible implementation, the processing module is specifically configured to:

[0260] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0261] In a possible implementation manner of the second aspect, the processing module is specifically configured to:

[0262] Based on the three identifiers, determining that the message header includes at least one of the group identifier and the egress node identifier;

[0263] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0264] Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

[0265] In a possible implementation, the processing module is specifically configured to:

[0266] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0267] In a possible implementation, the processing module is specifically configured to:

[0268] Based on the three identifiers, determining that the message header includes at least one of the group identifier and the egress node identifier;

[0269] Determining, based on the second identifier, that the transmission direction of the service message is downlink;

[0270] The egress node is determined based on at least one of the group identifier and the identifier of the egress node, and the service message is obtained based on the first message.

[0271] In a possible implementation, the message header is an in-flow detection iFit header, and the iFit header includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the identifier of the tail node.

[0272] In a possible implementation, the message header is an in-band operations administration and maintenance (IOAM) header, and the IOAM header includes a direct export (DEX) option type, and the DEX option type is used to carry at least one of the group identifier and the tail node identifier.

[0273] In a possible implementation, the DEX option type includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the identifier of the tail node.

[0274] Figure 12 is a schematic diagram of the structure of a network node 120 provided in an embodiment of the present application. The network node 120 is a device with computing capabilities. The device here can be a physical device, such as a controller, processor, server (such as a rack server), host, etc., or it can be a virtual device, such as a virtual machine, container, etc.

[0275] As shown in Figure 12, network node 120 includes a processor 1202 and a memory 1201, and optionally a bus 1204 and a communication interface 1203. Processor 1202 and memory 1201 communicate with each other via bus 1204. It should be understood that the present application does not limit the number of processors and memories in network node 120.

[0276] Memory 1201 is used to provide storage space, which can optionally store application data, user data, operating systems, and computer programs. Memory 1201 may include volatile memory, such as random access memory (RAM). Memory 1201 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0277] The processor 1202 is a module for performing calculations and may include any one or more of a controller (e.g., a storage controller), a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), a digital signal processor (DSP), a coprocessor (to assist the central processor in completing corresponding processing and applications), an application-specific integrated circuit (ASIC), a microcontroller unit (MCU), and the like.

[0278] The communication interface 1203 is used to provide information input or output for the at least one processor. And / or, the communication interface 1203 can be used to receive data sent externally and / or send data to the outside. The communication interface 1203 can be a wired link interface such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission and other wireless communication technologies, etc.). Optionally, the communication interface 1203 can also include a transmitter (such as a radio frequency transmitter, antenna, etc.) coupled to the interface, or a receiver, etc.

[0279] Bus 1204 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG12 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1204 may include a pathway for transmitting information between various components of network node 120 (e.g., memory 1201, processor 1202, and communication interface 1203).

[0280] In the embodiment of the present application, the memory 1201 stores executable instructions, and the processor 1202 executes the executable instructions to implement the aforementioned network performance monitoring method, such as the network performance monitoring method in the embodiment of FIG. 4 , and the network performance monitoring methods mentioned in the scenarios of FIG. 6 to FIG. 10 . That is, the memory 1201 stores instructions for executing the network performance monitoring method.

[0281] The present application also provides a computer-readable storage medium including instructions for implementing the aforementioned network performance monitoring method, such as the network performance monitoring method in the embodiment of FIG. 4 and the network performance monitoring methods mentioned in the scenarios of FIG. 6 to FIG. 10 .

[0282] The computer-readable storage medium may be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, or a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive).

[0283] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0284] The “at least one” mentioned in the embodiments of this application refers to one or more, and “plurality” refers to two or more. “At least one of the following items” or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), where a, b, c can be single or multiple. “And / or” describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character “ / ” generally indicates that the previous and next associated objects are in an “or” relationship.

[0285] Furthermore, unless otherwise indicated, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish multiple objects and are not intended to limit the order, timing, priority, or importance of multiple objects. For example, the references to a first container storage management device and a second container storage management device are merely for ease of description and do not indicate differences in device structure, deployment order, or importance between the first and second container storage management devices.

[0286] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0287] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A network performance monitoring method, characterized in that: The method comprises: Obtain a first message, where the first message includes a service message and a message header, where the message header includes a first identifier, and the first identifier is used to determine an egress node for reporting network performance; Monitoring is performed based on the parameters used to determine the tail node for reporting network performance.

2. The method according to claim 1, characterized in that The obtaining of the first message comprises: receiving the service message, where the service message includes a destination address, and the destination address corresponds to the egress node; Generate the first message based on the destination address and the service message.

3. The method according to claim 1, characterized in that The obtaining of the first message comprises: Receive the first message.

4. The method according to any one of claims 1 to 3, characterized in that: The first identifier includes: at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

5. The method according to claim 4, characterized in that The first identifier also includes: at least one of a second identifier and a third identifier, the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the tail node.

6. The method according to claim 4, characterized in that The monitoring based on the parameter used to determine the tail node for reporting network performance includes: Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

7. The method according to claim 5, characterized in that The monitoring based on the parameter used to determine the tail node for reporting network performance includes: Based on the three identifiers, determine that the message header includes at least one of the group identifier and the tail node identifier; Based on the second identifier, determining that the transmission direction of the service message is downlink; Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

8. The method according to claim 4, characterized in that The monitoring based on the parameter used to determine the tail node for reporting network performance includes: The tail node is determined based on at least one of the group identifier and the identifier of the tail node, and the service message is obtained based on the first message.

9. The method according to claim 5, characterized in that The monitoring based on the parameter used to determine the tail node for reporting network performance includes: Based on the three identifiers, determine that the message header includes at least one of the group identifier and the tail node identifier; Based on the second identifier, determining that the transmission direction of the service message is downlink; The tail node is determined based on at least one of the group identifier and the identifier of the tail node, and the service message is obtained based on the first message.

10. The method according to any one of claims 4 to 9, characterized in that: The message header is an iFit header for in-flow detection, and the iFit header includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the tail node identifier.

11. The method according to any one of claims 4 to 9, characterized in that: The message header is an in-band operation administration and maintenance IOAM header, and the IOAM header includes a direct export DEX option type, and the DEX option type is used to carry at least one of the group identifier and the tail node identifier.

12. The method according to claim 11, characterized in that The DEX option type includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the tail node identifier.

13. A device, characterized in that: The device comprises a communication module and a processing module, wherein: The communication module is used to obtain a first message, where the first message includes a service message and a message header, where the message header includes a first identifier, and the first identifier is used to determine an egress node for reporting network performance; The processing module is used to monitor based on the parameters used to determine the tail node for reporting network performance.

14. The device according to claim 13, characterized in that The communication module is specifically used for: receiving the service message, where the service message includes a destination address, and the destination address corresponds to the egress node; Generate the first message based on the destination address and the service message.

15. The device according to claim 13, characterized in that The communication module is specifically used for: Receive the first message.

16. The device according to any one of claims 13 to 15, characterized in that: The first identifier includes: at least one of a group identifier and an identifier of the tail node, and the group identifier is used to identify the node group to which the tail node belongs.

17. The device according to claim 16, characterized in that The first identifier also includes: at least one of a second identifier and a third identifier, the second identifier is used to identify the service message transmission direction, and the third identifier is used to identify at least one of the identifiers carrying the group identifier and the tail node.

18. The device according to claim 16, characterized in that The processing module is specifically used for: Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

19. The device according to claim 17, characterized in that The processing module is specifically used for: Based on the three identifiers, determine that the message header includes at least one of the group identifier and the tail node identifier; Based on the second identifier, determining that the transmission direction of the service message is downlink; Based on at least one of the group identifier and the identifier of the tail node, it is determined that the node is not the tail node, and the first message is sent.

20. The device according to claim 16, characterized in that The processing module is specifically used for: The tail node is determined based on at least one of the group identifier and the identifier of the tail node, and the service message is obtained based on the first message.

21. The device according to claim 17, characterized in that The processing module is specifically used for: Based on the three identifiers, determine that the message header includes at least one of the group identifier and the tail node identifier; Based on the second identifier, determining that the transmission direction of the service message is downlink; The tail node is determined based on at least one of the group identifier and the identifier of the tail node, and the service message is obtained based on the first message.

22. The device according to any one of claims 16 to 21, characterized in that The message header is an iFit header for in-flow detection, and the iFit header includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the tail node identifier.

23. The device according to any one of claims 16 to 21, characterized in that The message header is an in-band operations administration and maintenance IOAM header, and the IOAM header includes a direct export (DEX) option type, and the DEX option type is used to carry at least one of the group identifier and the tail node identifier.

24. The device according to claim 23, characterized in that The DEX option type includes an extension bit, and the extension bit is used to carry at least one of the group identifier and the tail node identifier.

25. A network node, characterized in that: The network node comprises a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the computing device implements the method according to any one of claims 1 to 12.

26. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program instructions, and when the program instructions are executed on a computer or a processor, the method according to any one of claims 1 to 12 is implemented.

27. A computer program product, characterized in that The computer program product comprises program instructions, and when the program instructions are executed on a computer or a processor, the method according to any one of claims 1 to 12 is implemented.

Images