WO2025241475A1 - Message processing method, apparatus and system - Google Patents

Abstract

The present disclosure relates to the technical field of data communication, and provides a message processing method, an apparatus and a system. In some embodiments, the message processing method comprises: generating an ICMPv6 echo request message, the echo request message comprising first indication information and second instruction information, the first indication information being used for indicating an IPv6 extension header to be returned, and the second instruction information being used for instructing each node on an outbound path to add IOAM data to said IPv6 extension header; sending the echo request message to a destination node; and receiving an echo response message from the destination node, the echo response message comprising said IPv6 extension header carrying the IOAM data added by each node on the outbound path.

Description

A message processing method, apparatus and system

Cross-reference to related applications

This application is based on and claims priority to CN application No. 202410645311.7, filed on May 23, 2024, the disclosure of which is incorporated herein by reference in its entirety.

Technical Field

This disclosure relates to the field of data communication technology, and in particular to a message processing method, apparatus and system.

Background Technology

Internet Control Message Protocol version 6 (ICMPv6) is an important component of the TCP/IP protocol stack. ICMPv6 messages primarily include two message types: error messages and informational messages. Informational messages include Echo Requests and Echo Replies. Informational messages are widely used for connectivity testing in IP networks, for example, in the Packet Internet Groper (PING) command. The PING command is used to test bidirectional connectivity between two nodes; it requires the source node to send an Echo Request to the destination node, and the destination node to send an Echo Response back to the source node.

ICMPv6 messages are encapsulated within IPv6 messages. In addition to the IPv6 header (or IPv6 basic header), IPv6 messages may also carry IPv6 extension headers. These extension headers include hop-by-hop options headers and destination options headers, and are defined for flow measurement and collecting path tracking information. The information collected by the IPv6 extension headers is then reported to a centralized data collector or controller for further processing.

Summary of the Invention

This disclosure provides a message processing method, apparatus, and system.

According to a first aspect of this disclosure, a message processing method is proposed, comprising: generating an echo request message of Internet Control Message Protocol version 6 (ICMPv6), the echo request message including first indication information and second indication information, the first indication information being used to indicate an IPv6 extension header to be returned, the second indication information being used to indicate each node on the outgoing path to add Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned, the outgoing path being the transmission path from the source node to the destination node of the echo request message; sending the echo request message to the destination node; and receiving an echo response message from the destination node, the echo response message including an IPv6 extension header to be returned carrying the IOAM data added by each node on the outgoing path.

In some embodiments, the IPv6 extension header to be returned is the first hop-by-hop option header in the echo request message.

In some embodiments, the echo request message further includes an IPv6 header, an Internet Control Message Protocol (ICMP) v6 header, and an ICMP extension structure field; the first indication information is encapsulated in the ICMP extension structure field, and/or the second indication information is encapsulated in the first hop-by-hop option header.

In some embodiments, the first hop-by-hop option header includes an IOAM data field, and the second indication information is encapsulated in the IOAM data field.

In some embodiments, the IOAM data field includes an IOAM trace type field, and the second indication information is characterized by the value of the IOAM trace type field.

In some embodiments, generating an echo request message for Internet Control Message Protocol version 6 (ICMPv6) includes: encapsulating the IOAM trace type field into a first hop-by-hop option header, and setting the most significant bit and the second most significant bit of the IOAM trace type field to a set value.

In some embodiments, generating an echo request message for Internet Control Message Protocol version 6 (ICMPv6) further includes adding the IOAM data corresponding to the source node to the first hop-by-hop option header.

In some embodiments, the echo response message further includes IOAM data added to each node on the backhaul path, where the backhaul path is the transmission path from the destination node to the source node for the echo response message.

In some embodiments, the message processing method further includes: determining the link information traversed by the specified service flow based on the IOAM data added to each node on the backhaul path and the IOAM data added to each node on the outbound path in the echo response message; and/or performing path consistency detection based on the IOAM data added to each node on the backhaul path and the IOAM data added to each node on the outbound path in the echo response message.

In some embodiments, the echo response message includes an IPv6 header, a second hop-by-hop options header, an Internet Control Message Protocol (ICMP) v6 header, and an ICMP extended structure field; the IOAM data added by each node on the return path is encapsulated in the second hop-by-hop options header, and/or the IPv6 extended header to be returned carrying the IOAM data added by each node on the outgoing path is encapsulated in the ICMP extended structure field of the echo response message.

In some embodiments, the IOAM data includes at least one of a hop limit, an ingress interface identifier, an egress interface identifier, and a node identifier.

According to a second aspect of this disclosure, a message processing method is proposed, executed by a destination node, comprising: receiving an echo request message of Internet Control Message Protocol version 6 (ICMPv6) from a source node, the echo request message including first indication information and second indication information, the first indication information being used to indicate an IPv6 extension header to be returned, the second indication information being used to indicate each node on the outgoing path to add Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned, the outgoing path being the transmission path from the source node to the destination node for the echo request message; generating an echo response message based on the echo request message, the echo response message including an IPv6 extension header to be returned carrying the IOAM data added by each node on the outgoing path; and sending the echo response message to the source node.

In some embodiments, the IPv6 extension header to be returned is the first hop-by-hop option header in the echo request message.

In some embodiments, generating an echo response message based on the echo request message includes: obtaining a first hop-by-hop option header from the echo request message according to the first indication information; adding IOAM data corresponding to the destination node to the first hop-by-hop option header according to the second indication information to obtain an IPv6 extension header to be returned carrying IOAM data added to each node on the outgoing path; and encapsulating the IPv6 extension header to be returned carrying IOAM data added to each node on the outgoing path into the echo response message.

In some embodiments, the echo response message includes an IPv6 header, an ICMPv6 header, and an ICMP extension structure, wherein the IPv6 extension header to be returned, carrying IOAM data added by each node on the outbound path, is encapsulated in the ICMP extension structure.

In some embodiments, the echo response message further includes a second hop-by-hop option header, which encapsulates third indication information. The third indication information is used to instruct each node on the return path to add IOAM data to the second hop-by-hop option header. The return path is the transmission path from the destination node to the source node for the echo response message.

In some embodiments, the second hop-by-hop option header includes an IOAM data field, and the third indication information is encapsulated in the IOAM data field.

In some embodiments, the IOAM data field includes an IOAM trace type field, and the third indication information is characterized by the value of the IOAM trace type field.

In some embodiments, generating an echo response message based on the echo request message further includes: encapsulating the IOAM trace type field into a second hop-by-hop option header, and setting the highest and second-highest bits of the IOAM trace type field to a set value.

In some embodiments, generating an echo response message based on the echo request message further includes adding the IOAM data corresponding to the destination node to the second hop-by-hop option header.

In some embodiments, the IOAM data includes at least one of a hop limit, an ingress interface identifier, an egress interface identifier, and a node identifier.

According to a third aspect of this disclosure, a message processing apparatus is provided, comprising: a generation module configured to generate an echo request message of Internet Control Message Protocol version 6 (ICMPv6), the echo request message including first indication information and second indication information, the first indication information being used to indicate an IPv6 extension header to be returned, the second indication information being used to indicate each node on the outgoing path to add Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned, the outgoing path being the transmission path from the source node to the destination node; a sending module configured to send the echo request message to the destination node; and a receiving module configured to receive an echo response message from the destination node, the echo response message including an IPv6 extension header to be returned carrying the IOAM data added by each node on the outgoing path.

According to a fourth aspect of this disclosure, a message processing apparatus is provided, comprising: a receiving module configured to receive an echo request message of Internet Control Message Protocol version 6 (ICMPv6) from a source node, the echo request message including first indication information and second indication information, the first indication information indicating an IPv6 extension header to be returned, the second indication information indicating that each node on the outgoing path adds Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned, the outgoing path being the transmission path from the source node to the destination node of the echo request message; a generating module configured to generate an echo response message based on the echo request message, the echo response message including an IPv6 extension header to be returned carrying the IOAM data added by each node on the outgoing path; and a sending module configured to send the echo response message to the source node.

According to a fifth aspect of this disclosure, a message processing system is proposed, comprising: a source node including the message processing apparatus as described above; and a destination node including the message processing apparatus as described above.

In some embodiments, the message processing system further includes: at least one first forwarding node, configured on the outbound path, for forwarding the echo request message; and at least one second forwarding node, configured on the return path, for forwarding the echo response message.

According to a sixth aspect of this disclosure, a message processing apparatus is provided, comprising: a memory; and a processor coupled to the memory, the processor being configured to perform the message processing method as described above based on instructions stored in the memory.

According to the seventh aspect of this disclosure, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the message processing method as described above.

According to the eighth aspect of this disclosure, a computer program product is provided that stores computer program instructions which, when executed by a processor, implement the message processing method as described above.

Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings.

Attached Figure Description

The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the specification, serve to explain the principles of this disclosure.

This disclosure can be more clearly understood with reference to the accompanying drawings and the following detailed description.

Figure 1 is a schematic flowchart of a message processing method according to some embodiments of the present disclosure;

Figure 2 is a schematic diagram of the format of an echo request message according to some embodiments of the present disclosure;

Figure 3 is a schematic diagram of the ICMP header format in an echo request message according to some embodiments of the present disclosure;

Figure 4 is a schematic diagram of the format of a first ICMP extended structure according to some embodiments of the present disclosure;

Figure 5 is a schematic diagram of the format of an echo response message according to some embodiments of the present disclosure;

Figure 6 is a schematic diagram of the ICMP header format in an echo response message according to some embodiments of the present disclosure;

Figure 7 is a schematic diagram of the format of a second ICMP extended structure according to some embodiments of the present disclosure;

Figure 8 is a schematic flowchart of a message processing method according to some other embodiments of the present disclosure;

Figure 9 is a schematic flowchart of a message processing method according to some embodiments of the present disclosure;

Figure 10 is a schematic diagram of the structure of a message processing apparatus according to some embodiments of the present disclosure;

Figure 11 is a schematic diagram of a message processing apparatus according to some other embodiments of the present disclosure;

Figure 12 is a schematic diagram of the structure of a message processing apparatus according to some embodiments of the present disclosure;

Figure 13 is a schematic diagram of the structure of a message processing system according to some embodiments of the present disclosure;

Figure 14 is a schematic diagram of the structure of a computer system according to some embodiments of the present disclosure.

Detailed Implementation

Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

In all examples shown and discussed herein, any specific values should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

In many application scenarios, the source node needs to understand the forwarding status of packets in the network. Related technologies require the support of a centralized collector or controller to obtain the Operation, Administration and Maintenance (OAM) data carried in the IPv6 extension header, resulting in a complex architecture and significant communication overhead.

In view of this, this disclosure provides a message processing method, apparatus and system that enables outbound path information to be directly returned to the source node without the need for a centralized collector or controller, thereby simplifying the communication architecture and reducing communication overhead.

Figure 1 is a schematic flowchart of a message processing method according to some embodiments of the present disclosure. As shown in Figure 1, the message processing method includes steps S1 to S3.

In step S1, the source node generates an ICMPv6 echo request message.

The source node (also known as the encapsulation node) can be, for example, a network device. For instance, the source node could be a router or other network device. Alternatively, the source node can be a host device, such as a personal computer (PC) or a server. In some examples, the packet processing mechanism (described later) is configured in the source node, and packet processing methods are executed through this mechanism.

The echo request message encapsulates first and second indication information. The first indication information indicates the IPv6 extension header to be returned. The second indication information instructs each node on the outbound path to add IOAM data to the IPv6 extension header to be returned. The outbound path is the transmission path from the source node to the destination node for the echo request message.

The first indication information may include, for example, type indication information to indicate the type of the IPv6 extension header to be returned. For example, the first indication information may include: Type = Hop by Hop Options header. This indication information indicates that the IPv6 extension header to be returned is a hop by hop options header. As another example, the first indication information may include: Type = Destination Options header. This indication information indicates that the IPv6 extension header to be returned is a destination options header. Furthermore, in specific implementations, the first indication information may also include other extension header types.

In some examples, the format of the echo request message in the related art has been modified to carry the first indication information. The modified echo request message satisfies the following: the echo request message includes an ICMPv6 header and an ICMP extended structure field, and the first indication information is encapsulated in the ICMP extended structure field.

The second instruction information can be used to indicate which IOAM data each node needs to add. For example, the second instruction information could indicate that each node needs to add its own identifier. Or, the second instruction information could indicate that each node needs to add at least one of the following: hop limit, inbound interface, and outbound interface, as well as its own identifier.

In this embodiment of the disclosure, by carrying first indication information in the echo request message, the destination node can determine the IPv6 extension header to be returned based on the echo request message, without needing to inform the destination node of the indication information of the IPv6 extension header to be returned through other devices or other signaling, thus reducing communication overhead; by carrying second indication information in the echo request message, each node on the outbound path can add its own corresponding IOAM data when forwarding the echo request message, without needing to inform each node that IOAM data needs to be added through other devices or other signaling, thus reducing communication overhead.

In some embodiments, the echo request message includes an IPv6 header, a first hop-by-hop options header, an ICMPv6 header, and an ICMP extension structure. In these embodiments, step S1 includes: the source node encapsulating first indication information into the ICMP extension structure, and/or, the source node encapsulating second indication information into the first hop-by-hop options header.

In some examples, the ICMP extended structure in the echo request message includes an object field, and the first hop-by-hop option header in the echo request message includes an IOAM data field. In these examples, step S1 specifically includes: the source node encapsulating the first indication information into the object field and encapsulating the second indication information into the IOAM data field.

In some embodiments, when generating an echo request message, the source node, in addition to encapsulating the first indication information and the second indication information into the echo request message, further includes adding the IOAM data corresponding to the source node to the first hop-by-hop option header in the echo request message. For example, the source node adds the source node's identifier, the ingress interface of the echo request message, and the egress interface of the echo request message to the first hop-by-hop option header.

In step S2, the source node sends an echo request message to the destination node.

In some examples, the source node sends an echo request message to the transport node, which (also known as an intermediate node) forwards the echo request message to the destination node. For example, the transport nodes include transport node 1, transport node 2, and transport node 3. The source node sends the echo request message to transport node 1, transport node 1 receives the echo request message and forwards it to transport node 2, transport node 2 receives the echo request message and forwards it to transport node 3, and transport node 3 receives the echo request message and forwards it to the destination node. Furthermore, each transport node adds its own corresponding IOAM data to the echo request message when forwarding it.

In other examples, the source node sends the echo request message directly to the destination node.

After receiving the echo request message, the destination node generates an echo response message and then sends the echo response message to the source node. Subsequently, step S3 is executed.

In step S3, the source node receives an echo response message from the destination node.

The echo response message includes a pending IPv6 extension header carrying IOAM data added for each node on the outbound path.

For example, the IPv6 extension header to be returned is the first hop-by-hop options header in the echo request message. The echo response message includes a first hop-by-hop options header carrying IOAM data added for each node on the outbound path.

In some embodiments, after step S3, the message processing method further includes: the source node determines the link information through which the specified service flow passes based on the IOAM data (referred to as outbound path information) added by each node on the outbound path in the echo response message.

In some embodiments, the echo response message also includes IOAM data (referred to as backhaul path information) added by each node on the backhaul path. The backhaul path refers to the transmission path along which the echo response message is transmitted from the destination node to the source node. By enabling the echo response message to carry not only outbound path information but also backhaul path information, the sending node can easily and efficiently obtain the bidirectional path information of the message.

The return path information and the IPv6 extension header to be returned can be encapsulated in the echo response message in the following exemplary manner. For example, the echo response message includes an IPv6 header, a second hop-by-hop options header, an ICMPv6 header, and an ICMP extension structure field. The second hop-by-hop options header encapsulates the return path information, and/or, the IPv6 extension header to be returned, carrying the outbound path information, is encapsulated in the ICMP extension structure field.

In some of the above embodiments, after step S3, the message processing method may further include: the source node determining the link information through which the specified service flow passes based on the outbound path information and return path information in the echo response message; and/or, the source node performing path consistency detection based on the outbound path information and return path information; and/or, in an Equal Multiple Path (ECMP) scenario, the source node determining which ECMP path the message should be forwarded to.

Compared with related technologies, the embodiments of this disclosure can achieve the following technical effects through the above methods: 1. The echo request message and echo response message in the related technologies can only be used for bidirectional network connectivity detection. The embodiments of this disclosure enhance the functionality of the echo request message and echo response message by extending them; 2. It enables the IPv6 extension header carrying outbound path information to be directly returned to the source node without the support of a centralized collector or controller, simplifying the communication architecture and reducing communication overhead; 3. It facilitates the subsequent source node to understand the path trace of the packet in detail based on the outbound path information carried in the IPv6 extension header, thereby helping to realize network diagnosis and provide a basis for packet path optimization.

Figure 2 is a schematic diagram of the format of an echo request message according to some embodiments of the present disclosure. As shown in Figure 2, the echo request message in some embodiments of the present disclosure includes an IPv6 header, a first hop-by-hop option header, an ICMPv6 header, and a first ICMP extension structure.

The IPv6 header includes fields such as the source node's IP address, the destination node's IP address, and the flow label. In some examples, to simulate the path of a specific service flow, such as in an Equal Cost Multi-path (ECMP) scenario, the source node's IP address, destination node's IP address, and flow label in the echo request message are made consistent with the corresponding values in the specified service flow message.

The first hop-by-hop optional headers encapsulate the second instruction information. In some examples, the first hop-by-hop optional headers include IOAM data fields, and the second instruction information is encapsulated within the IOAM data fields.

The IOAM data field may include an IOAM trace type field, and the second indication information is represented by the value of the IOAM trace type field. For example, the second indication information is represented by the most significant bit and the second most significant bit of the IOAM trace type field. In these examples, when the source node generates an echo request message, it encapsulates the IOAM trace type field into the first hop-by-hop option header and sets the most significant bit and the second most significant bit of the IOAM trace type field to a set value. For example, it sets the most significant bit and the second most significant bit of the IOAM trace type field to 1. Setting the most significant bit of the IOAM trace type field to 1 indicates that hop limits and node identifiers need to be filled, and setting the second most significant bit of the IOAM trace type field to 1 indicates that ingress interface identifiers and egress interface identifiers need to be added. In addition, the remaining bits of the IOAM trace type field can be set to 1 or 0 as needed.

In this embodiment of the disclosure, by encapsulating the IOAM data field in the hop-by-hop option header of the echo request message, it is convenient to carry the second indication information, which helps to concisely and efficiently instruct each node on the outgoing path to add its corresponding IOAM data to the hop-by-hop option header, thereby helping to improve the processing effect of the entire message processing flow.

The ICMPv6 header includes the following fields as shown in Figure 3: Type, Code, Checksum, Identifier, and Sequence Number. The Type field indicates the message type (or packet type); the Code field indicates a more specific type of this packet; the Checksum field is used to verify the ICMPv6 packet; the Identifier field is an identifier used to indicate a match between an echo request and an echo response packet; and the Sequence Number is an identifier used to indicate a match between an echo request and an echo response packet.

The first ICMP extension structure encapsulates first indication information. In some examples, as shown in Figure 4, the first ICMP extension structure includes a first extension header field and at least one first object field. The first indication information is encapsulated within the first object field.

In some examples, the first extended header fields include a version number field, a reserved field, and a checksum field. The sizes of the version number field, reserved field, and checksum field in the first extended header fields can be set as follows: for example, the version number field is 4 bits in size, used to indicate the version number of the message; the reserved field is 12 bits in size, with all bits set to 0; and the checksum field is 16 bits in size.

In some examples, the first object field includes a length field, an object category field, and an object subcategory field. The length field, represented by `Length`, identifies the object's length; the object category field, represented by `Class-Num`, represents the first indication information; and the object subcategory field, represented by `C-Type` (also known as the object subtype field), defines the object's sub-type. The object subcategory field can be reserved for future expansion of message functionality based on actual needs.

In some examples, the first object field includes a length field, an object category field, and an object subcategory field, but does not include an object payload field.

In this embodiment of the disclosure, by including a first ICMP extended structure field in the echo request message, it is easier to carry the first indication information. Furthermore, by omitting the object payload field from the first ICMP extended structure field, the echo request message becomes more concise, reducing the communication overhead required for transmitting ICMPv6 messages between the source and destination nodes.

Figure 5 is a schematic diagram of the format of an echo response message according to some embodiments of the present disclosure. As shown in Figure 5, the echo response message in some embodiments of the present disclosure includes an IPv6 header, a second hop-by-hop options header, an ICMPv6 header, and a second ICMP extension structure.

The IPv6 header includes fields such as the source node's IP address, the destination node's IP address, and the flow label.

The second hop-by-hop optional headers encapsulate a third indication. In some examples, the second hop-by-hop optional headers include IOAM data fields, and the third indication is encapsulated within the IOAM data fields.

The IOAM data fields include the IOAM Trace Type field, and the third indication information is represented by the value of the IOAM Trace Type field. For example, setting the highest and second-highest bits of the IOAM Trace Type field to 1 indicates that the following IOAM data needs to be added to each node on the return path: hop limit, node representation, ingress interface identifier, and egress interface identifier.

In this embodiment of the disclosure, by encapsulating the IOAM data field in the hop-by-hop option header of the echo response message, it is convenient to carry third indication information, which helps to concisely and efficiently instruct each node on the return path to add its corresponding IOAM data to the hop-by-hop option header, thereby helping to improve the processing effect of the entire message processing flow.

The ICMPv6 header includes the following fields as shown in Figure 6: Type, Code, Checksum, Identifier, and Sequence Number. The Type field indicates the message type (or packet type); the Code field indicates a more specific type of this packet; the Checksum field is used to verify the ICMPv6 packet; the Identifier field is an identifier used to indicate a match between an echo request and an echo response packet; and the Sequence Number is an identifier used to indicate a match between an echo request and an echo response packet.

The second ICMP extension structure encapsulates a returnable IPv6 extension header carrying outbound path information. In some examples, as shown in Figure 7, the second ICMP extension structure includes a second extension header field and at least one second object field. The returnable IPv6 extension header carrying outbound path information is encapsulated within the second object field.

In some examples, the second object field includes a length field, an object class field, an object subclass field, and an object payload field. The length field, represented by Length, identifies the object length; the object class field, represented by Class-Num; the object subclass field, represented by C-Type; and the object payload field, represented by Object payload, encapsulates the IPv6 extension header to be returned, carrying out the outbound path information.

In practice, the size of each field in the second object field can be flexibly set. For example, the length field can be set to 16 bits, the object category field to 8 bits, the object subcategory field to 8 bits, and the object payload field to n*32 bits.

In this embodiment of the disclosure, by carrying a second extended structure field in the echo response message, it is convenient to carry the IPv6 extension header to be returned, thereby enabling the source node to easily obtain the outbound path information in the IPv6 extension header to be returned. Moreover, by carrying third indication information in the second hop-by-hop option header in the echo response message, it is convenient to simply and efficiently instruct each node on the return path to add its corresponding IOAM data, thereby enabling the source node to easily and efficiently obtain the return path information.

Figure 8 is a schematic flowchart of a message processing method according to some other embodiments of the present disclosure. As shown in Figure 8, the message processing method includes steps S11 to S13.

In step S11, the destination node receives an ICMPv6 echo request message from the source node.

The destination node (also known as the decapsulation node) can be a network device. For example, the destination node may be a router or other network device. Alternatively, the destination node can be a host device. For example, the destination node may be a personal computer (PC) or a server. In some examples, the message processing device described later is configured in the destination node, and the message processing device performs the message processing method.

The echo request message encapsulates first and second indication information. The first indication information indicates the IPv6 extension header to be returned. The second indication information instructs each node on the outbound path to add IOAM data to the IPv6 extension header to be returned. The outbound path is the transmission path from the source node to the destination node for the echo request message. For the format of the echo request message, please refer to the relevant content described above.

In step S12, the destination node generates an echo response message based on the echo request message.

The echo response message includes a pending IPv6 extension header information carrying the IOAM data added for each node on the outbound path. In some examples, the pending IPv6 extension header is the first hop-by-hop options header in the echo request message. In some examples, the IOAM data added for each node on the outbound path carried in the pending IPv6 extension header includes: the node identifier, hop limit, ingress interface identifier, and egress interface identifier for each node on the outbound path.

In some embodiments, the destination node generates an echo response message as follows: according to a first instruction, it obtains a first hop-by-hop option header from the echo request message; according to a second instruction, it adds IOAM data corresponding to the destination node to the first hop-by-hop option header to obtain an IPv6 extension header to be returned carrying outgoing path information; and encapsulates the IPv6 extension header to be returned carrying outgoing path information into the echo response message.

In some examples, the echo response message includes an IPv6 header, an ICMPv6 header, and an ICMP extension structure. In these examples, when the destination node generates the echo response message, it encapsulates the IPv6 extension header carrying outbound path information into the ICMP extension structure.

In other examples, the echo response message includes a second hop-by-hop options header in addition to the IPv6 header, ICMPv6 header, and ICMP extension structure. In these examples, when generating the echo response message, the destination node, besides encapsulating the IPv6 extension header carrying outbound path information into the ICMP extension structure, also adds a third indication message and its corresponding IOAM data to the second hop-by-hop options header. The third indication message instructs each node on the return path to add IOAM data to the second hop-by-hop options header. The return path is the transmission path from the destination node to the source node for the echo response message.

The third indication information can be encapsulated in the echo response message in the following exemplary manner: the IOAM data field is encapsulated in the second hop-by-hop option header. The third indication information is located within the IOAM data field.

For example, the IOAM data field includes an IOAM trace type field, and the third indication information is represented by the value of the IOAM trace type field. For instance, the third indication information is represented by the most significant and second most significant bits of the IOAM trace type field. In these examples, when the destination node generates an echo response message, it sets the most significant and second most significant bits of the IOAM trace type field to a set value. For example, it sets the most significant and second most significant bits of the IOAM trace type field to 1. Setting the most significant bit of the IOAM trace type field to 1 indicates that hop limits and node identifiers need to be filled in, and setting the second most significant bit of the IOAM trace type field to 1 indicates that ingress and egress interface identifiers need to be added. Furthermore, the remaining bits of the IOAM trace type field can be set to 1 or 0 depending on the actual situation.

In this embodiment, by carrying third indication information in the echo response message, each node on the return path can add its own corresponding IOAM data when forwarding the echo response message, without needing to inform each node to add IOAM data through other devices or other signaling, thus reducing communication overhead. Furthermore, it helps the source node to easily and efficiently obtain both outbound and return path information.

In step S13, the destination node sends an echo response message to the source node.

In some embodiments, the destination node sends an echo response message to the transmission node, and the transmission node forwards the echo response message to the source node. For example, the transmission nodes include transmission node 4 and transmission node 5. The destination node sends an echo response message to transmission node 4, transmission node 4 receives the echo response message and forwards it to transmission node 5, and transmission node 5 receives the echo response message and forwards it to the source node.

In other embodiments, the destination node sends the echo response message directly to the source node.

In this embodiment of the disclosure, the above process enables the IPv6 extension header carrying outbound path information to be returned directly to the source node without the need for a centralized collector or controller, thus simplifying the communication architecture and reducing communication overhead.

Figure 9 is a schematic flowchart of a message processing method according to some embodiments of the present disclosure. As shown in Figure 9, in an IOAM domain, a network environment consisting of 6 devices and two paths is formed. The first path includes nodes R1, R2, R3, and R6, and the second path includes nodes R6, R5, R4, and R1.

Encapsulation node R1 (or source node R1) generates an echo request message.

In some examples, to simulate the path of a specified service flow, the values of fields such as the source node IP address, destination node IP address, and flow identifier in the echo request message are made consistent with those in the specified service flow message.

In some examples, encapsulating node R1 generates the echo request message as follows: It encapsulates an ICMP extension structure carrying first indication information into the echo request message; and it encapsulates a hop-by-hop option header carrying second indication information into the echo request message. The first indication information indicates the IPv6 extension header to be returned, and the second indication information indicates that each node on the outbound path should add IOAM data to the IPv6 extension header to be returned.

In some examples, to facilitate carrying the first and second indication information, the ICMP extension structure and hop-by-hop options header in the echo request message are configured to satisfy the following: the ICMP extension structure includes a first extension header field and a first object field, with the first indication information represented by the object category field in the first object field; the hop-by-hop options header includes an IOAM data field, with the second indication information represented by the IOAM trace type field in the IOAM data field. In these examples, the encapsulating node sets the value of the object category field to Hop by Hop Options header to represent the following first indication information: the IPv6 extension header to be returned is a hop-by-hop options header; the encapsulating node sets the most significant bit and the second most significant bit in the IOAM trace type field to 1 to represent the following second indication information: each node on the outbound path needs to add its corresponding node identifier (node_id), hop limit (Hop_Lim), ingress interface identifier (ingress_if_id), and egress interface identifier (egress_if_id).

In some examples, in addition to encapsulating the first and second indication information, the encapsulation node R1 also selects the outgoing interface based on a hash algorithm and fills in the hop limit, node identifier, and outgoing interface identifier information in the hop-by-hop option header. For example, the encapsulation node R1 assigns the hop limit field a value of 9, assigns its own node identifier R1 to the node identifier field, leaves the ingoing interface identifier field empty, and assigns the outgoing interface identifier field a value of the outgoing interface identifier it selects.

Intermediate nodes R2 and R3 are forwarding nodes on the outbound path. When intermediate nodes R2 and R3 receive and forward echo request messages, they perform IOAM data filling operations. For example, intermediate nodes R2 and R3 fill in the hop limit, node identifier, ingress interface identifier, and egress interface identifier information in the hop-by-hop option header. For instance, intermediate node R2 assigns the hop limit field a value of 8, assigns its own node identifier R2 to the node identifier field, and assigns values to the ingress interface identifier and egress interface identifier fields. Similarly, intermediate node R3 performs similar IOAM data filling processing.

Upon receiving the echo request message, the decapsulation node (i.e., the destination node) R6, based on the second indication information in the echo request message, fills in its corresponding hop limit, node identifier, and ingress interface identifier information into the hop-by-hop option header of the echo request message to obtain a hop-by-hop option header carrying outbound path information. Furthermore, based on the first indication information in the echo request message, the decapsulation node R6 fills in the information from the hop-by-hop option header (i.e., the first hop-by-hop option header) in the second ICMP extension structure of the echo response message, and fills in the third indication information in the hop-by-hop option header (i.e., the second hop-by-hop option header) of the echo response message. The third indication information is used to instruct each node on the return path to add IOAM data to the second hop-by-hop option header.

To facilitate the carrying of the third indication information, the hop-by-hop option header (i.e., the second hop-by-hop option header) in the echo response message is made to satisfy the following: the hop-by-hop option header includes an IOAM data field, and the third indication information is represented by the IOAM trace type field within the IOAM data field. In these examples, the decapsulation node sets the most significant and second-most significant bits of the IOAM trace type field to 1 to represent the following third indication information: each node on the return path needs to add its corresponding node identifier (node_id), hop limit (Hop_Lim), ingress interface identifier (ingress_if_id), and egress interface identifier (egress_if_id).

Intermediate nodes R5 and R4 are forwarding nodes on the return path. When intermediate nodes R5 and R4 receive and forward echo response messages, they perform IOAM data filling operations. For example, when intermediate node R5 receives an echo response message, it fills in the hop limit, its own node identifier R, ingress interface identifier int1, and egress interface identifier int3 in the hop-by-hop options header. Intermediate node R4 performs similar operations on the received echo response messages and then forwards the message to encapsulation node R1.

Encapsulation node R1 obtains the return path information from the hop-by-hop option header in the echo response message and the outbound path information from the ICMP extended structure in the echo response message. Then, the consistency between the outbound and return paths can be checked based on the outbound and return path information.

Figure 10 is a schematic diagram of the structure of a message processing apparatus according to some embodiments of the present disclosure. As shown in Figure 10, the message processing apparatus 100 includes a generation module 101, a sending module 102, and a receiving module 103.

The generation module 101 is configured to generate ICMPv6 echo request messages. The echo request message includes first indication information and second indication information. The first indication information indicates the IPv6 extension header to be returned, and the second indication information indicates that each node on the outbound path adds IOAM data to the IPv6 extension header to be returned. The outbound path is the transmission path from the source node to the destination node for the echo request message.

The sending module 102 is configured to send an echo request message to the destination node.

The receiving module 103 is configured to receive an echo response message from the destination node. The echo response message includes a pending IPv6 extension header carrying IOAM data added by each node on the outbound path.

In this embodiment of the disclosure, the above-described device enables the outbound path information to be directly returned to the source node without the need for a centralized collector or controller, thus simplifying the communication architecture and reducing communication overhead.

Figure 11 is a schematic diagram of a message processing apparatus according to some other embodiments of the present disclosure. As shown in Figure 11, the message processing apparatus 110 includes a receiving module 111, a generating module 112, and a sending module 113.

The receiving module 111 is configured to receive ICMPv6 echo request messages from the source node. The echo request message includes first indication information and second indication information. The first indication information indicates the IPv6 extension header to be returned, and the second indication information indicates that each node on the outbound path adds IOAM data to the IPv6 extension header to be returned. The outbound path is the transmission path from the source node to the destination node for the echo request message.

The generation module 112 is configured to generate an echo response message based on the echo request message. The echo response message includes a pending IPv6 extension header carrying IOAM data added for each node on the outbound path.

Sending module 113 is configured to send an echo response message to the source node.

In this embodiment of the disclosure, the above-described device enables the outbound path information to be directly returned to the source node without the need for a centralized collector or controller, thus simplifying the communication architecture and reducing communication overhead.

Figure 12 is a schematic diagram of a message processing apparatus according to some embodiments of the present disclosure. As shown in Figure 12, the electronic device 120 includes a memory 121 and a processor 122 coupled to the memory 121. The memory 121 is used to store instructions for executing embodiments of the message processing method. The processor 122 is configured to execute the message processing method in any of the embodiments of the present disclosure based on the instructions stored in the memory 121.

Figure 13 is a schematic diagram of the structure of a message processing system according to some embodiments of the present disclosure. As shown in Figure 13, the message processing system 130 includes a source node 131 and a destination node 133.

Source node 131 is used to execute the message processing method shown in Figure 1.

Destination node 133 is used to execute the message processing method shown in Figure 8.

In some embodiments, the message processing system 130 includes at least one transmission node 132 in addition to the source node 131 and the destination node 133. The at least one transmission node 132 includes: at least one first forwarding node, located on the outbound path, for forwarding echo request messages; and at least one second forwarding node, located on the return path, for forwarding echo response messages.

In this embodiment of the disclosure, the above system enables outbound path information to be directly returned to the source node without the need for a centralized collector or controller, thus simplifying the communication architecture and reducing communication overhead.

Figure 14 is a schematic diagram of the structure of a computer system according to some embodiments of the present disclosure. As shown in Figure 14, the computer system 140 can be represented in the form of a general computing device. The computer system 140 includes a memory 141, a processor 142, and a bus 143 connecting different system components.

Memory 141 may include, for example, system memory, non-volatile storage media, etc. System memory may store, for example, an operating system, application programs, a boot loader, and other programs. System memory may include volatile storage media, such as random access memory (RAM) and/or cache memory. Non-volatile storage media may store, for example, instructions for a corresponding embodiment of at least one message processing method being executed. Non-volatile storage media include, but are not limited to, disk storage, optical storage, flash memory, etc.

The processor 142 can be implemented using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete hardware components such as discrete gates or transistors. Accordingly, each module, such as the generation module, the transmission module, and the receiving module, can be implemented by the central processing unit (CPU) running instructions in memory to execute the corresponding steps, or by dedicated circuitry to execute the corresponding steps.

Bus 143 can use any of the various bus architectures. For example, bus architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, and the Peripheral Component Interconnect (PCI) bus.

The computer system 140 can be connected via a bus 143 to interfaces 144, 145, and 146, as well as to memory 141 and processor 142. Input/output interface 144 provides a connection interface for input/output devices such as monitors, mice, and keyboards. Network interface 145 provides a connection interface for various networked devices. Storage interface 146 provides a connection interface for external storage devices such as floppy disks, USB flash drives, and SD cards.

Various aspects of this disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus, and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and/or block diagrams, and combinations thereof, can be implemented by computer-readable program instructions.

These computer-readable program instructions are provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable device to produce a machine, such that execution of the instructions by the processor produces means for implementing the functions specified in one or more boxes of the flowchart and/or block diagram.

These computer-readable program instructions may also be stored in a computer-readable storage medium. These instructions cause a computer to work in a particular manner to produce an article of manufacture, including instructions that implement the functions specified in one or more boxes in a flowchart and/or block diagram.

This disclosure may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

The message processing methods, apparatus, and systems described in the above embodiments enable outbound path information to be directly returned to the source node without the need for a centralized collector or controller, thus simplifying the communication architecture and reducing communication overhead.

The message processing methods, apparatus, and systems according to this disclosure have now been described in detail. To avoid obscuring the concept of this disclosure, some details known in the art have not been described. Those skilled in the art can fully understand how to implement the technical solutions disclosed herein based on the above description.

Claims (28)

A message processing method, executed by the source node, includes: Generate an echo request message for Internet Control Message Protocol version 6 (ICMPv6). The echo request message includes first indication information and second indication information. The first indication information is used to indicate the IPv6 extension header to be returned. The second indication information is used to indicate that each node on the outgoing path adds Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned. The outgoing path is the transmission path from the source node to the destination node for the echo request message. Send the echo request message to the destination node; Receive an echo response message from the destination node, the echo response message including an IPv6 extension header to be returned carrying IOAM data added by each node on the outbound path. According to the message processing method of claim 1, the IPv6 extension header to be returned is the first hop-by-hop option header in the echo request message. According to the message processing method of claim 2, the echo request message further includes an IPv6 header, an Internet Control Message Protocol (ICMP)v6 header, and an ICMP extended structure field; the first indication information is encapsulated in the ICMP extended structure field, and/or the second indication information is encapsulated in the first hop-by-hop option header. According to the message processing method of claim 3, the first hop-by-hop option header includes an IOAM data field, and the second indication information is encapsulated in the IOAM data field. According to the message processing method of claim 4, the IOAM data field includes an IOAM trace type field, and the second indication information is characterized by the value of the IOAM trace type field. According to the message processing method of claim 5, the generation of the echo request message for Internet Control Message Protocol version 6 (ICMPv6) includes: The IOAM trace type field is encapsulated in the first hop-by-hop option header, and the highest and second-highest bits of the IOAM trace type field are set to a set value. According to the message processing method of claim 6, the step of generating an echo request message for Internet Control Message Protocol version 6 (ICMPv6) further includes: Add the IOAM data corresponding to the source node to the first hop-by-hop option header. According to any one of claims 1 to 7, the message processing method further includes IOAM data added to each node on the return path, wherein the return path is the transmission path from the destination node to the source node for the echo response message. The message processing method according to any one of claims 1 to 8 further includes: Based on the IOAM data added to each node on the return path and the IOAM data added to each node on the outbound path in the echo response message, determine the link information traversed by the specified service flow; and/or Path consistency is checked based on the IOAM data added to each node on the return path and the IOAM data added to each node on the outgoing path in the echo response message. According to the message processing method of claim 8 or 9, the echo response message includes an IPv6 header, a second hop-by-hop options header, an Internet Control Message Protocol (ICMP) v6 header, and an ICMP extension structure field; the IOAM data added by each node on the return path is encapsulated in the second hop-by-hop options header, and/or the IPv6 extension header carrying the return message is encapsulated in the ICMP extension structure field of the echo response message. The message processing method according to any one of claims 1 to 10, wherein the IOAM data includes at least one of hop limit, ingress interface identifier, egress interface identifier, and node identifier. A message processing method, executed by the destination node, includes: The system receives an echo request message from the source node in the form of Internet Control Message Protocol Version 6 (ICMPv6). The echo request message includes first indication information and second indication information. The first indication information is used to indicate the IPv6 extension header to be returned. The second indication information is used to indicate that each node on the outgoing path adds Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned. The outgoing path is the transmission path from the source node to the destination node for the echo request message. Based on the echo request message, an echo response message is generated, the echo response message including an IPv6 extension header to be returned carrying IOAM data added to each node on the outbound path; Send the echo response message to the source node. According to the message processing method of claim 12, the IPv6 extension header to be returned is the first hop-by-hop option header in the echo request message. According to the message processing method of claim 13, the step of generating an echo response message based on the echo request message includes: Based on the first indication information, obtain the first hop-by-hop option header from the echo request message; According to the second instruction information, add the IOAM data corresponding to the destination node to the first hop-by-hop option header to obtain the IPv6 extension header to be returned carrying the IOAM data added to each node on the outgoing path; The IPv6 extension header to be returned, carrying the IOAM data added to each node on the outgoing path, is encapsulated into the echo response message. According to the message processing method of claim 13 or 14, the echo response message includes an IPv6 header, an ICMPv6 header, and an ICMP extension structure, wherein the IPv6 extension header to be returned, carrying IOAM data added by each node on the outgoing path, is encapsulated in the ICMP extension structure. According to the message processing method of claim 15, the echo response message further includes a second hop-by-hop option header, the second hop-by-hop option header encapsulating third indication information, the third indication information being used to instruct each node on the return path to add IOAM data to the second hop-by-hop option header, the return path being the transmission path from the destination node to the source node for the echo response message. According to the message processing method of claim 16, the second hop-by-hop option header includes an IOAM data field, and the third indication information is encapsulated in the IOAM data field. According to the message processing method of claim 17, the IOAM data field includes an IOAM trace type field, and the third indication information is characterized by the value of the IOAM trace type field. According to the message processing method of claim 18, the step of generating an echo response message based on the echo request message further includes: The IOAM trace type field is encapsulated in the second hop-by-hop option header, and the highest and second-highest bits of the IOAM trace type field are set to the set values. The message processing method according to any one of claims 16 to 19, wherein generating an echo response message based on the echo request message further includes: Add the IOAM data corresponding to the destination node to the second hop-by-hop option header. The message processing method according to any one of claims 12 to 20, wherein the IOAM data includes at least one of hop limit, ingress interface identifier, egress interface identifier, and node identifier. A message processing apparatus, comprising: The generation module is configured to generate an echo request message for Internet Control Message Protocol version 6 (ICMPv6). The echo request message includes first indication information and second indication information. The first indication information is used to indicate the IPv6 extension header to be returned. The second indication information is used to indicate that each node on the outgoing path adds Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned. The outgoing path is the transmission path from the source node to the destination node for the echo request message. The sending module is configured to send the echo request message to the destination node; The receiving module is configured to receive an echo response message from the destination node, the echo response message including a pending IPv6 extension header carrying IOAM data added by each node on the outbound path. A message processing apparatus, comprising: The receiving module is configured to receive an echo request message from the source node in the Internet Control Message Protocol version 6 (ICMPv6). The echo request message includes first indication information and second indication information. The first indication information is used to indicate the IPv6 extension header to be returned. The second indication information is used to indicate that each node on the outgoing path adds Stream Operation Maintenance and Management (IOAM) data to the IPv6 extension header to be returned. The outgoing path is the transmission path from the source node to the destination node for the echo request message. The generation module is configured to generate an echo response message based on the echo request message, the echo response message including an IPv6 extension header to be returned carrying IOAM data added to each node on the outbound path; The sending module is configured to send the echo response message to the source node. A message processing system, comprising: The source node includes the message processing apparatus as described in claim 22; The destination node includes the message processing apparatus as described in claim 23. The message processing system according to claim 24 further includes: At least one first forwarding node is set on the outbound path for forwarding the echo request message; At least one second forwarding node is set on the backhaul path for forwarding the echo response message. A message processing apparatus, comprising: Memory; and A processor coupled to the memory, the processor being configured to execute the message processing method as described in any one of claims 1 to 21 based on instructions stored in the memory. A computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the message processing method as described in any one of claims 1 to 21. A computer program product having stored computer program instructions that, when executed by a processor, implement the message processing method as described in any one of claims 1 to 21.