Message processing method, apparatus and system

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, device and system

[0001] Cross-reference to Related Applications

[0002] This application is based on and claims priority to the CN application No. 202410645311.7, filed on May 23, 2024, the disclosure of which is incorporated herein in its entirety. TECHNICAL FIELD

[0003] The present disclosure relates to the technical field of data communication, and particularly relates to a message processing method, device and system. BACKGROUND

[0004] The sixth version of Internet Control Message Protocol (ICMPv6) is an important component of the TCP / IP protocol stack. ICMPv6 messages mainly include two types of messages: error messages and information messages. Among them, the information messages include echo request and echo reply. Information messages are widely used in connectivity detection of IP networks, for example, in the Packet Internet Groper (PING) command. The PING command is used to detect the bidirectional connectivity between two nodes, which requires the source node to send an echo request to the destination node, and the destination node to send an echo response to the source node.

[0005] ICMPv6 messages are encapsulated in IPv6 messages. In addition to including an IPv6 header (also known as an IPv6 basic header), IPv6 messages can also carry IPv6 extension headers. The IPv6 extension header includes hop-by-hop options header and destination options header, etc., which has been defined for in-stream measurement and collection of path trace information. After that, the information collected by the IPv6 extension header is reported to a centralized collector or controller, which is further processed by the centralized collector or controller. SUMMARY

[0006] The present disclosure provides a message processing method, device and system.

[0007] According to a first aspect of the present disclosure, a packet processing method is provided, which comprises: generating an echo request packet of Internet Control Message Protocol version 6 (ICMPv6), the echo request packet comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, and the second indication information being used to indicate that each node on a forward path adds in-situ operations, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the forward path being a transmission path of the echo request packet from a source node to a destination node; sending the echo request packet to the destination node; and receiving an echo response packet from the destination node, the echo response packet comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the forward path.

[0008] In some embodiments, the to-be-returned IPv6 extension header is a first hop-by-hop option header in the echo request packet.

[0009] In some embodiments, the echo request packet further comprises an IPv6 header, an Internet Control Message Protocol (ICMP) version 6 (ICMPv6) 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.

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

[0011] In some embodiments, the IOAM data field comprises an IOAM trace type field, and the second indication information is represented by a value of the IOAM trace type field.

[0012] In some embodiments, the generating the echo request packet of Internet Control Message Protocol version 6 (ICMPv6) comprises: encapsulating the IOAM trace type field into a first hop-by-hop option header, and setting a highest bit and a second highest bit in the value of the IOAM trace type field to a set value.

[0013] In some embodiments, the generating the echo request packet of Internet Control Message Protocol version 6 (ICMPv6) further comprises: adding IOAM data corresponding to the source node into the first hop-by-hop option header.

[0014] In some embodiments, the echo response packet further comprises IOAM data added by each node on a backward path, the backward path being a transmission path of the echo response packet from the destination node to the source node.

[0015] In some embodiments, the packet processing method further comprises: determining link information through which the service flow passes according to the IOAM data added by each node on the backhaul path in the echo response packet and the IOAM data added by each node on the front path; and / or performing path consistency detection according to the IOAM data added by each node on the backhaul path in the echo response packet and the IOAM data added by each node on the front path.

[0016] In some embodiments, the echo response packet comprises an IPv6 header, a second hop-by-hop option header, an Internet Control Message Protocol (ICMPv6) header, and an ICMP extension structure field; the IOAM data added by each node on the backhaul path is encapsulated in the second hop-by-hop option header, and / or the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the front path is encapsulated in the ICMP extension structure field in the echo response packet.

[0017] In some embodiments, the IOAM data comprises at least one of hop limit, ingress interface identifier, egress interface identifier, and node identifier.

[0018] According to a second aspect of the present disclosure, a packet processing method is provided, which is performed by a destination node and comprises: receiving a sixth version of Internet Control Message Protocol (ICMPv6) echo request packet from a source node, the echo request packet comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned sixth version of Internet Protocol (IPv6) extension header, and the second indication information being used to indicate that each node on a front path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the front path being a transmission path of the echo request packet transmitted from the source node to the destination node; generating an echo response packet according to the echo request packet, the echo response packet comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the front path; and sending the echo response packet to the source node.

[0019] In some embodiments, the to-be-returned IPv6 extension header is a first hop-by-hop option header in the echo request packet.

[0020] In some embodiments, the generating the echo response packet according to the echo request packet comprises: obtaining a first hop-by-hop option header from the echo request packet according to the first indication information; adding IOAM data corresponding to the destination node in 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 by each node on a to-path; and encapsulating the IPv6 extension header to be returned carrying IOAM data added by each node on the to-path into the echo response packet.

[0021] In some embodiments, the echo response packet comprises an IPv6 header, an ICMPv6 header, and an ICMP extension structure, and the IPv6 extension header carrying IOAM data added by each node on the to-path is encapsulated in the ICMP extension structure.

[0022] In some embodiments, the echo response packet further comprises a second hop-by-hop option header, and the second hop-by-hop option header encapsulates third indication information indicating that each node on a backhaul path adds IOAM data in the second hop-by-hop option header, the backhaul path being a transmission path of the echo response packet transmitted from the destination node to the source node.

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

[0024] In some embodiments, the IOAM data field comprises an IOAM trace type field, and the third indication information is represented by a value of the IOAM trace type field.

[0025] In some embodiments, the generating the echo response packet according to the echo request packet further comprises: encapsulating the IOAM trace type field into the second hop-by-hop option header, and setting the highest bit and the second highest bit in the value of the IOAM trace type field to a set value.

[0026] In some embodiments, the generating the echo response packet according to the echo request packet further comprises: adding the IOAM data corresponding to the destination node into the second hop-by-hop option header.

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

[0028] According to a third aspect of the present disclosure, a packet processing apparatus is provided, comprising: a generating module configured to generate an echo request packet of Internet Control Message Protocol version 6 (ICMPv6), the echo request packet comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, and the second indication information being used to indicate that each node on a forward path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the forward path being a transmission path of the echo request packet from a source node to a destination node; a sending module configured to send the echo request packet to the destination node; and a receiving module configured to receive an echo response packet from the destination node, the echo response packet comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the forward path.

[0029] According to a fourth aspect of the present disclosure, a packet processing apparatus is provided, comprising: a receiving module configured to receive an echo request packet of Internet Control Message Protocol version 6 (ICMPv6) from a source node, the echo request packet comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, and the second indication information being used to indicate that each node on a forward path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the forward path being a transmission path of the echo request packet from the source node to a destination node; a generating module configured to generate an echo response packet according to the echo request packet, the echo response packet comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the forward path; and a sending module configured to send the echo response packet to the source node.

[0030] According to a fifth aspect of the present disclosure, a packet processing system is provided, comprising: a source node comprising the packet processing apparatus as described above; and a destination node comprising the packet processing apparatus as described above.

[0031] In some embodiments, the packet processing system further comprises: at least one first forwarding node arranged on the forward path and configured to forward the echo request packet; and at least one second forwarding node arranged on a backward path and configured to forward the echo response packet.

[0032] According to a sixth aspect of the present disclosure, a packet processing apparatus is provided, comprising: a memory; and a processor coupled to the memory, the processor being configured to execute the packet processing method as described above based on instructions stored in the memory.

[0033] According to a seventh aspect of the present disclosure, a computer readable storage medium is provided, having stored thereon computer program instructions which, when executed by a processor, implement the packet processing method as described above.

[0034] According to an eighth aspect of the present disclosure, a computer program product is provided, having stored thereon computer program instructions which, when executed by a processor, implement the packet processing method as described above.

[0035] Other features and advantages of the present disclosure will become apparent from the following detailed description of exemplary embodiments of the present disclosure with reference to the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings, which form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0037] The present disclosure can be more clearly understood with reference to the following detailed description of exemplary embodiments thereof in connection with the accompanying drawings.

[0038] FIG. 1 is a flowchart of a packet processing method according to some embodiments of the present disclosure;

[0039] FIG. 2 is a format diagram of an echo request packet according to some embodiments of the present disclosure;

[0040] FIG. 3 is a format diagram of an ICMP header in an echo request packet according to some embodiments of the present disclosure;

[0041] FIG. 4 is a format diagram of a first ICMP extension structure according to some embodiments of the present disclosure;

[0042] FIG. 5 is a format diagram of an echo response packet according to some embodiments of the present disclosure;

[0043] FIG. 6 is a format diagram of an ICMP header in an echo response packet according to some embodiments of the present disclosure;

[0044] FIG. 7 is a format diagram of a second ICMP extension structure according to some embodiments of the present disclosure;

[0045] FIG. 8 is a flowchart of a packet processing method according to some other embodiments of the present disclosure;

[0046] FIG. 9 is a flowchart of a packet processing method according to some further embodiments of the present disclosure;

[0047] FIG. 10 is a block diagram of a packet processing apparatus according to some embodiments of the present disclosure;

[0048] FIG. 11 is a block diagram of a packet processing apparatus according to some other embodiments of the present disclosure;

[0049] FIG. 12 is a structural schematic diagram of a packet processing device according to some embodiments of the present disclosure;

[0050] FIG. 13 is a structural schematic diagram of a packet processing system according to some embodiments of the present disclosure;

[0051] FIG. 14 is a structural schematic diagram of a computer system according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0052] Various exemplary embodiments of the present disclosure will now be described in detail below with reference to the drawings. Note that the relative arrangement, numerical expressions, and numerical values of components and steps set forth in these embodiments are not limiting to the scope of the present disclosure unless specifically stated otherwise.

[0053] Meanwhile, it should be understood that the sizes of the various portions shown in the drawings are not drawn to scale for the sake of convenience in description.

[0054] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way limiting to the scope of the disclosure and its applications or uses.

[0055] Techniques, methods, and apparatus known to those of ordinary skill in the relevant art can not be discussed in detail herein, but should be considered part of the specification as appropriate.

[0056] In all examples shown and discussed herein, any specific values should be interpreted as merely illustrative and not as a limitation. Thus, other examples of the exemplary embodiments can have different values.

[0057] Note that similar reference numerals and letters refer to like items in the following drawings, and thus, once an item is defined in one drawing, it need not be discussed further in subsequent drawings.

[0058] In order to make the purposes, technical solutions, and advantages of the present disclosure clearer, the present disclosure is further described in detail below with reference to specific embodiments and with reference to the drawings.

[0059] In many application scenarios, a source node (source node) needs to know the forwarding of a packet in a network. In the related art, the source node needs to be supported by a centralized collector or controller to obtain operation administration and maintenance (OAM) data carried by an IPv6 extension header, which has a complex architecture and large communication overhead.

[0060] In view of this, the present disclosure provides a packet processing method, device and system, which can make the information of the upstream path directly return to the source node, without the support of the centralized collector or controller, simplifying the communication architecture and reducing the communication overhead.

[0061] FIG. 1 is a flow diagram of a packet processing method according to some embodiments of the present disclosure. As shown in FIG. 1, the packet processing method includes steps S1-S3.

[0062] In step S1, the source node generates an ICMPv6 echo request packet.

[0063] The source node (also referred to as an encapsulation node) can be, for example, a network device. For example, the source node is a router or other network device. Alternatively, the source node can be a host device. For example, the source node is a personal computer (PC) or a server, etc. In some examples, the packet processing device described below is provided in the source node, and the packet processing method is performed by the packet processing device.

[0064] The echo request packet encapsulates first indication information and second indication information. The first indication information is used to indicate an IPv6 extension header to be returned. The second indication information is used to indicate that each node on the upstream path adds IOAM data in the IPv6 extension header to be returned. The upstream path is the transmission path of the echo request packet from the source node to the destination node.

[0065] The first indication information can include, for example, type indication information, which is used to indicate the type of the IPv6 extension header to be returned. For example, the first indication information includes: 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. Alternatively, the first indication information includes: type = Destination Options header. This indication information indicates that the IPv6 extension header to be returned is a Destination Options header. In addition, in specific implementations, the first indication information can also include other extension header types.

[0066] In some examples, in order to carry the first indication information, the format of the echo request packet in the related art is modified. The modified echo request packet satisfies: the echo request packet includes an ICMPv6 header and an ICMP extension structure field, and the first indication information is encapsulated in the ICMP extension structure field.

[0067] The second indication information can be used to indicate which IOAM data needs to be added by each node. For example, the second indication information indicates that each node needs to add an identifier of the node itself. For another example, the second indication information indicates that each node needs to add at least one of hop limit, ingress interface, and egress interface, and the identifier of the node itself.

[0068] In the embodiments of the present disclosure, the first indication information is carried in the echo request packet, so that the destination node can determine the IPv6 extension header to be returned according to the echo request packet, without the need to additionally inform the destination node of the indication information of the IPv6 extension header to be returned through other devices or other signaling, thereby reducing communication overhead. The second indication information is carried in the echo request packet, so that each node on the upstream path can add the corresponding IOAM data of the node itself when forwarding the echo request packet, without the need to additionally inform each node of the IOAM data to be added through other devices or other signaling, thereby reducing communication overhead.

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

[0070] In some examples, the ICMP extension structure in the echo request packet includes an object field, and the first hop-by-hop option header in the echo request packet 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.

[0071] In some embodiments, when generating the echo request packet, the source node, in addition to encapsulating the first indication information and the second indication information into the echo request packet, also includes: adding the IOAM data corresponding to the source node into the first hop-by-hop option header in the echo request packet. For example, the source node adds the identifier of the source node, the ingress interface of the echo request packet, and the egress interface of the echo request packet into the first hop-by-hop option header.

[0072] In step S2, the source node sends the echo request packet to the destination node.

[0073] In some examples, the source node sends the echo request packet to a transmission node, and the transmission node (also referred to as an intermediate node) forwards the echo request packet to the destination node. For example, the transmission nodes include a transmission node 1, a transmission node 2, and a transmission node 3. The source node sends the echo request packet to the transmission node 1, the transmission node 1 receives the echo request packet and forwards it to the transmission node 2, the transmission node 2 receives the echo request packet and forwards it to the transmission node 3, the transmission node 3 receives the echo request packet and forwards it to the destination node. In addition, each transmission node adds its own IOAM data to the echo request packet when forwarding the echo request packet.

[0074] In other examples, the source node sends the echo request packet directly to the destination node.

[0075] The destination node generates an echo response packet after receiving the echo request packet, and then sends the echo response packet to the source node. Subsequently, step S3 is performed.

[0076] In step S3, the source node receives the echo response packet from the destination node.

[0077] The echo response packet includes a to-be-returned IPv6 extension header carrying the IOAM data added by each node on the upstream path.

[0078] For example, the to-be-returned IPv6 extension header is the first hop-by-hop option header in the echo request packet. The echo response packet includes the first hop-by-hop option header carrying the IOAM data added by each node on the upstream path.

[0079] In some embodiments, after step S3, the packet processing method further includes: determining, by the source node, link information through which the specified service flow passes, according to the IOAM data (referred to as upstream path information) added by each node on the upstream path in the echo response packet.

[0080] In some embodiments, the echo response packet further includes IOAM data (referred to as return path information) added by each node on a return path. The return path refers to a transmission path of the echo response packet from the destination node to the source node. By allowing the echo response packet to carry not only the upstream path information but also the return path information, the sending node can easily and efficiently obtain the bidirectional path information of the packet.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 specified 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.

[0086] The first hop-by-hop option header encapsulates the second indication information. In some examples, the first hop-by-hop option header includes IOAM data fields, and the second indication information is encapsulated in the IOAM data fields.

[0087] The IOAM data fields can include an IOAM trace type field, and the second indication information is represented by a 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 in the value of the IOAM trace type field. In these examples, the source node encapsulates the IOAM trace type field into the first hop-by-hop option header when generating the echo request packet, and sets the most significant bit and the second most significant bit in the value of the IOAM trace type field to a set value. For example, the most significant bit and the second most significant bit in the value of the IOAM trace type field are set to 1. Wherein, setting the most significant bit in the value of the IOAM trace type field to 1 indicates that the hop limit and the node identifier need to be filled, and setting the second most significant bit in the value of the IOAM trace type field to 1 indicates that the ingress interface identifier and the egress interface identifier need to be added. In addition, the remaining bits in the value of the IOAM trace type field can be set to 1 or 0 according to actual conditions.

[0088] In the embodiments of the present disclosure, by encapsulating the IOAM data field in the hop-by-hop option header in the echo request packet, the second indication information is facilitated to be carried, which helps to indicate each node on the upstream path to add its corresponding IOAM data into the hop-by-hop option header concisely and efficiently, and further helps to improve the processing effect of the entire packet processing process.

[0089] The ICMPv6 header includes the following fields as shown in FIG. 3: a type field (Type), a code field (Code), a checksum field (Checksum), an identifier field (Identifier), and a sequence number field (Sequence Number). Among them, the type field is used to indicate the message type (or packet type); the code field is used to indicate the more subdivided type of the packet type; the checksum field is used to check the ICMPv6 packet; the identifier field is used to indicate an identifier matching the echo request and echo response packets; and the sequence number is used to indicate an identifier matching the echo request and echo response packets.

[0090] The first ICMP extension structure encapsulates the first indication information. In some examples, as shown in FIG. 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 in the first object field.

[0091] In some examples, the first extension header field includes a version number field (Version), a reserved field (Reserved), and a checksum field (Checksum). The size of the version number field, the reserved field, and the checksum field in the first extension header field can be set in the following exemplary manner: for example, the version number field is 4 bits in size, used to indicate the version number of the packet; the reserved field is 12 bits in size, with all bits set to 0; and the checksum field is 16 bits in size.

[0092] In some examples, the first object field includes a length field, an object class field, and an object sub-class field. The length field can be denoted by Length, used to identify the length of the object; the object class field can be denoted by Class-Num, used to represent the first indication information; and the object sub-class field can be denoted by C-Type, also referred to as the object sub-type field, used to define the detailed type of the object. The object sub-class field can be used as a reserved field, so as to subsequently extend the function of the packet according to actual needs.

[0093] In some examples, the first object field includes a length field, an object class field, and an object sub-class field, but does not include an object payload field.

[0094] In the embodiments of the present disclosure, the echo request packet includes the first ICMP extension structure field, so as to facilitate carrying the first indication information. In addition, the first ICMP extension structure field does not include the object payload field, so that the echo request packet is more concise, and the communication overhead required for transmitting the ICMPv6 packet between the source node and the destination node is reduced.

[0095] FIG. 5 is a format diagram of an echo response packet according to some embodiments of the present disclosure. As shown in FIG. 5, the echo response packet in some embodiments of the present disclosure includes an IPv6 header, a second hop-by-hop option header, an ICMPv6 header, and a second ICMP extension structure.

[0096] The IPv6 header includes the IP address of the source node, the IP address of the destination node, a flow label (Flow Label), and the like.

[0097] The second hop-by-hop option header encapsulates the third indication information. In some examples, the second hop-by-hop option header includes IOAM data fields, and the third indication information is encapsulated in the IOAM data fields.

[0098] The IOAM data field includes an IOAM trace type (Trace Type) field, and the third indication information is represented by a value of the IOAM trace type field. For example, the IOAM trace type field has the highest bit and the second highest bit both being 1, which indicates that each node on the backhaul path needs to add the following IOAM data: hop limit, node representation, incoming interface identifier, and outgoing interface identifier.

[0099] In the embodiments of the present disclosure, the IOAM data field is encapsulated in the hop-by-hop option header in the echo response message, so as to facilitate carrying the third indication information, which helps to indicate that each node on the backhaul path adds its corresponding IOAM data to the hop-by-hop option header, and further helps to improve the processing effect of the entire message processing flow.

[0100] The ICMPv6 header includes the following fields as shown in FIG. 6: a type field (Type), a code field (Code), a checksum field (Checksum), an identifier field (Identifier), and a sequence number field (Sequence Number). The type field is used to indicate the message type (or message type). The code field is used to indicate a more specific type of the message type. The checksum field is used to check the ICMPv6 message. The identifier field is used to indicate an identifier matching the echo request and echo response messages. The sequence number is used to indicate an identifier matching the echo request and echo response messages.

[0101] The second ICMP extension structure encapsulates the IPv6 extension header carrying the information of the upstream path to be returned. In some examples, as shown in FIG. 7, the second ICMP extension structure includes a second extension header field and at least one second object field. The IPv6 extension header carrying the information of the upstream path to be returned is encapsulated in the second object field.

[0102] In some examples, the second object field includes a length field, an object class field, an object sub-class field, and an object payload field. The length field can be represented by Length, which is used to identify the object length. The object class field can be represented by Class-Num. The object sub-class field can be represented by C-Type. The object payload field can be represented by Object payload, which is used to encapsulate the IPv6 extension header carrying the information of the upstream path to be returned.

[0103] In implementation, the size of each field in the second object field can be flexibly set. For example, the size of the length field can be set to 16 bits, the size of the object class field can be set to 8 bits, the size of the object sub-class field can be set to 8 bits, and the size of the object payload field can be set to n*32 bits.

[0104] In the embodiments of the present disclosure, the second extension structure field is carried in the echo response message, so as to carry the to-be-returned IPv6 extension header, thereby enabling the source node to easily obtain the in-path information in the to-be-returned IPv6 extension header. Moreover, the third indication information is carried in the second hop-by-hop option header in the echo response message, so as to simply and efficiently indicate each node on the backhaul path to add the IOAM data corresponding to the node, thereby enabling the source node to simply and efficiently obtain the backhaul path information.

[0105] FIG. 8 is a flow diagram of a packet processing method according to some embodiments of the present disclosure. As shown in FIG. 8, the packet processing method includes steps S11-S13.

[0106] In step S11, the destination node receives the ICMPv6 echo request message from the source node.

[0107] The destination node (also referred to as a decapsulating node) can be a network device. For example, the destination node is a router or other network device. Alternatively, the destination node can be a host device. For example, the destination node is a host device such as a personal computer (PC) or a server. In some examples, the packet processing apparatus described below is provided in the destination node and performs the packet processing method.

[0108] The echo request message encapsulates the first indication information and the second indication information. The first indication information is used to indicate the to-be-returned IPv6 extension header. The second indication information is used to indicate each node on the in-path to add the IOAM data in the to-be-returned IPv6 extension header. The in-path is the transmission path of the echo request message from the source node to the destination node. For the format of the echo request message, refer to the related content described above.

[0109] In step S12, the destination node generates an echo response message according to the echo request message.

[0110] The echo response message includes the to-be-returned IPv6 extension header information carrying the IOAM data added by each node on the in-path. In some examples, the to-be-returned IPv6 extension header is the first hop-by-hop option header in the echo request message. In some examples, the IOAM data added by each node on the in-path and carried by the to-be-returned IPv6 extension header includes the node identifier corresponding to each node on the in-path, the hop limit, the ingress interface identifier, and the egress interface identifier.

[0111] In some embodiments, the destination node generates the echo response packet according to the following manner: according to the first indication information, obtaining the first hop-by-hop option header from the echo request packet; according to the second indication information, adding the IOAM data corresponding to the destination node in the first hop-by-hop option header to obtain the IPv6 extension header to be returned carrying the in-path path information; and encapsulating the IPv6 extension header to be returned carrying the in-path path information into the echo response packet.

[0112] In some examples, the echo response packet comprises an IPv6 header, an ICMPv6 header, and an ICMP extension structure. In these examples, when generating the echo response packet, the destination node encapsulates the IPv6 extension header to be returned carrying the in-path path information into the ICMP extension structure.

[0113] In other examples, the echo response packet comprises an IPv6 header, an ICMPv6 header, an ICMP extension structure, and a second hop-by-hop option header. In these examples, when generating the echo response packet, the destination node encapsulates the IPv6 extension header to be returned carrying the in-path path information into the ICMP extension structure, and adds the third indication information and the IOAM data corresponding to the destination node into the second hop-by-hop option header. The third indication information is used to indicate that each node on the backhaul path adds IOAM data in the second hop-by-hop option header. The backhaul path is the transmission path of the echo response packet from the destination node to the source node.

[0114] In these examples, the third indication information is encapsulated in the echo response packet in the following exemplary manner: encapsulating the IOAM data field in the second hop-by-hop option header. The third indication information is located in the IOAM data field.

[0115] For example, the IOAM data field comprises an IOAM trace type field, and the third indication information is represented by the value of the IOAM trace type field. For example, the third indication information is represented by the most significant bit and the second most significant bit of the value of the IOAM trace type field. In these examples, when generating the echo response packet, the destination node sets the most significant bit and the second most significant bit of the value of the IOAM trace type field to a set value. For example, the most significant bit and the second most significant bit of the value of the IOAM trace type field are set to 1. Setting the most significant bit of the value of the IOAM trace type field to 1 indicates that the hop limit and the node identifier need to be filled in, and setting the second most significant bit of the value of the IOAM trace type field to 1 indicates that the ingress interface identifier and the egress interface identifier need to be added. In addition, the remaining bits of the value of the IOAM trace type field can be set to 1 or 0 according to actual conditions.

[0116] In the embodiments of the present disclosure, the echo response message carries the third indication information, so that each node on the backhaul path can add its corresponding IOAM data when forwarding the echo response message, without the need for additional devices or other signaling to inform each node to add IOAM data, thereby reducing communication overhead. Moreover, it helps the source node to obtain the backhaul path information simply and efficiently while obtaining the forward path information simply and efficiently.

[0117] In step S13, the destination node sends the echo response message to the source node.

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

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

[0120] In the embodiments of the present disclosure, the above process can enable the IPv6 extension header carrying the forward path information to be returned directly to the source node without the support of a centralized collector or a controller, thereby simplifying the communication architecture and reducing communication overhead.

[0121] FIG. 9 is a flow diagram of a message processing method according to still other embodiments of the present disclosure. As shown in FIG. 9, in an IOAM domain, six devices form a networking environment including two paths. The first path includes nodes R1, R2, R3, and R6, and the second path includes nodes R6, R5, R4, and R1.

[0122] The encapsulation node R1 (or source node R1) generates an echo request message.

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

[0124] In some examples, the encapsulation node R1 generates the echo request message in the following manner: encapsulates an ICMP extension structure carrying first indication information into the echo request message; and encapsulates a hop-by-hop option header carrying second indication information into the echo request message. The first indication information is used to indicate the IPv6 extension header to be returned, and the second indication information is used to indicate that each node on the forward path adds IOAM data in the IPv6 extension header to be returned.

[0125] In some examples, in order to facilitate carrying the first indication information and the second indication information, the ICMP extension structure and the hop-by-hop option header in the echo request packet meet: the ICMP extension structure includes a first extension header field and a first object field, and the first indication information is represented by an object category field in the first object field; the hop-by-hop option header includes an IOAM data field, and the second indication information is represented by an IOAM trace type field in the IOAM data field. In these examples, the encapsulation 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 the hop-by-hop option header; and the encapsulation node sets the highest bit and the second highest bit in the IOAM trace type field value to 1 to represent the following second indication information: each node on the egress path needs to add the node identifier (node_id), hop limit (Hop_Lim), ingress interface identifier (ingress_if_id), and egress interface identifier (egress_if_id) corresponding to the node.

[0126] In some examples, in addition to encapsulating the first indication information and the second indication information, the encapsulation node R1 also selects an egress interface based on a hash algorithm and fills in the hop limit, node identifier, and egress 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 the node identifier field a value of its own node identifier R1, sets the value of the ingress interface identifier field to empty, and assigns the egress interface identifier field a value of the egress interface identifier selected by itself.

[0127] The intermediate nodes R2 and R3 are forwarding nodes on the egress path. When the intermediate nodes R2 and R3 receive and forward the echo request packet, they perform IOAM data filling operations. For example, the 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 example, the intermediate node R2 assigns the hop limit field a value of 8, assigns the node identifier field a value of its own node identifier R2, and assigns values to the ingress interface identifier field and the egress interface identifier field. Similarly, the intermediate node R3 also performs similar IOAM data filling processing.

[0128] The decapsulating node (i.e., the destination node) R6 fills in the hop-by-hop option header of the echo request packet with the hop limit, the node identifier, and the ingress interface identifier corresponding to the decapsulating node R6 according to the second indication information in the echo request packet, to obtain the hop-by-hop option header carrying the information of the upstream path. Further, the decapsulating node R6 fills the information of the hop-by-hop option header (i.e., the first hop-by-hop option header) in the echo request packet into the second ICMP extension structure in the echo response packet, and fills the third indication information into the hop-by-hop option header (i.e., the second hop-by-hop option header) in the echo response packet. The third indication information is used to instruct each node on the downstream path to add IOAM data in the second hop-by-hop option header.

[0129] To facilitate carrying the third indication information, the hop-by-hop option header (i.e., the second hop-by-hop option header) in the echo response packet satisfies that the hop-by-hop option header includes an IOAM data field, and the third indication information is represented by an IOAM trace type field in the IOAM data field. In these examples, the decapsulating node sets the highest bit and the second highest bit in the value of the IOAM trace type field to 1, to represent the following third indication information: each node on the downstream path needs to add the node identifier (node_id), the hop limit (Hop_Lim), the ingress interface identifier (ingress_if_id), and the egress interface identifier (egress_if_id) corresponding to the node.

[0130] The intermediate nodes R5 and R4 are forwarding nodes on the downstream path. When the intermediate nodes R5 and R4 receive and forward the echo response packet, the IOAM data filling operation is performed. For example, when the intermediate node R5 receives the echo response packet, the hop limit, the node identifier R of the intermediate node R5, the ingress interface identifier int1, and the egress interface identifier int3 are filled in the hop-by-hop option header. The intermediate node R4 performs similar operations on the received echo response packet, and then forwards the packet to the encapsulating node R1.

[0131] The encapsulating node R1 obtains the information of the downstream path from the hop-by-hop option header in the echo response packet, and obtains the information of the upstream path from the ICMP extension structure in the echo response packet. Then, the consistency of the upstream path and the downstream path can be detected according to the information of the upstream path and the information of the downstream path.

[0132] FIG. 10 is a structural schematic diagram of a packet processing apparatus according to some embodiments of the present disclosure. As shown in FIG. 10, the packet processing apparatus 100 includes a generating module 101, a sending module 102, and a receiving module 103.

[0133] The generating module 101 is configured to generate an ICMPv6 echo request packet. The echo request packet includes first indication information and second indication information. The first indication information is used to indicate an IPv6 extension header to be returned, and the second indication information is used to indicate that each node on an in-path adds IOAM data in the IPv6 extension header to be returned. The in-path is a transmission path of the echo request packet from a source node to a destination node.

[0134] The sending module 102 is configured to send the echo request packet to the destination node.

[0135] The receiving module 103 is configured to receive an echo response packet from the destination node. The echo response packet includes the IPv6 extension header to be returned carrying the IOAM data added by each node on the in-path.

[0136] In the embodiments of the present disclosure, the above apparatus can make the in-path information directly returned to the source node without the support of the centralized collector or the controller, simplifies the communication architecture, and reduces the communication overhead.

[0137] FIG. 11 is a structural schematic diagram of a packet processing apparatus according to some other embodiments of the present disclosure. As shown in FIG. 11, the packet processing apparatus 110 includes a receiving module 111, a generating module 112, and a sending module 113.

[0138] The receiving module 111 is configured to receive an ICMPv6 echo request packet from a source node. The echo request packet includes first indication information and second indication information. The first indication information is used to indicate an IPv6 extension header to be returned, and the second indication information is used to indicate that each node on an in-path adds IOAM data in the IPv6 extension header to be returned. The in-path is a transmission path of the echo request packet from the source node to a destination node.

[0139] The generating module 112 is configured to generate an echo response packet according to the echo request packet. The echo response packet includes the IPv6 extension header to be returned carrying the IOAM data added by each node on the in-path.

[0140] The sending module 113 is configured to send the echo response packet to the source node.

[0141] In the embodiments of the present disclosure, the above apparatus can make the in-path information directly returned to the source node without the support of the centralized collector or the controller, simplifies the communication architecture, and reduces the communication overhead.

[0142] FIG. 12 is a structural schematic diagram of a packet processing apparatus according to some embodiments of the present disclosure. As shown in FIG. 12, the electronic device 120 includes a memory 121 and a processor 122 coupled to the memory 121. The memory 121 is configured to store instructions for implementing embodiments of the packet processing method. The processor 122 is configured to execute the packet processing method according to any of the embodiments of the present disclosure based on the instructions stored in the memory 121.

[0143] FIG. 13 is a structural schematic diagram of a packet processing system according to some embodiments of the present disclosure. As shown in FIG. 13, the packet processing system 130 includes a source node 131 and a destination node 133.

[0144] The source node 131 is configured to execute the packet processing method as shown in FIG. 1.

[0145] The destination node 133 is configured to execute the packet processing method as shown in FIG. 8.

[0146] In some embodiments, the packet 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 disposed on the access path and configured to forward the echo request packet, and at least one second forwarding node disposed on the backhaul path and configured to forward the echo response packet.

[0147] In the embodiments of the present disclosure, the above system enables the access path information to be directly returned to the source node without the support of a centralized collector or controller, thereby simplifying the communication architecture and reducing the communication overhead.

[0148] FIG. 14 is a structural schematic diagram of a computer system according to some embodiments of the present disclosure. As shown in FIG. 14, the computer system 140 can be in the form of a general-purpose computing device. The computer system 140 includes a memory 141, a processor 142, and a bus 143 connecting different system components.

[0149] The memory 141 can include, for example, system memory, non-volatile storage media, and the like. The system memory, for example, stores an operating system, application programs, a boot loader, and other programs. The system memory can include volatile storage media such as random access memory (RAM) and / or cache memory. The non-volatile storage media, for example, stores instructions for implementing at least one of the packet processing methods being executed. The non-volatile storage media includes, but is not limited to, magnetic storage media, optical storage media, flash memory, and the like.

[0150] The processor 142 can be implemented with 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 device, discrete gate or transistor logic, etc. discrete hardware component. Accordingly, each module such as a generation module, a sending module and a receiving module can be implemented by a central processing unit (CPU) running instructions in a memory to perform corresponding steps, or by a dedicated circuit to perform corresponding steps.

[0151] The bus 143 can use any of a variety of bus structures. For example, the bus structure includes but is not limited to an industry standard architecture (ISA) bus, a micro channel architecture (MCA) bus, a peripheral component interconnect (PCI) bus.

[0152] The computer system 140 can be connected between the interfaces 144, 145, 146 and the memory 141 and the processor 142 through the bus 143. The input / output interface 144 can provide a connection interface for display, mouse, keyboard and other input / output devices. The network interface 145 provides a connection interface for various networking devices. The storage interface 146 provides a connection interface for external storage devices such as floppy disks, U disks, SD cards, etc.

[0153] Here, various aspects of the present disclosure are described with reference to flowcharts and / or block diagrams of methods, apparatuses and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowchart and / or block diagram can be implemented by computer readable program instructions.

[0154] These computer readable program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable device to generate a machine, so that the instructions executed by the processor generate an apparatus that implements the functions specified in one or more blocks of the flowchart and / or block diagram.

[0155] These computer readable program instructions can also be stored in a computer readable memory, which makes the computer work in a specific way, so as to generate a product, including instructions that implement the functions specified in one or more blocks of the flowchart and / or block diagram.

[0156] The present disclosure can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects.

[0157] Through the packet processing method, device and system in the above embodiments, the upstream path information can be directly returned to the source node without the support of the centralized collector or the controller, which simplifies the communication architecture and reduces the communication overhead.

[0158] So far, the packet processing method, device and system according to the present disclosure have been described in detail. In order to avoid obscuring the concept of the present disclosure, some details known in the art are not described. Those skilled in the art can fully understand how to implement the technical solutions disclosed herein according to the above description.

Claims

1. A method for processing a packet, performed by a source node, comprising: generating an echo request packet of Internet Control Message Protocol version 6 (ICMPv6), the echo request packet comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, the second indication information being used to indicate that each node on a forward path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the forward path being a transmission path of the echo request packet transmitted from the source node to a destination node; sending the echo request packet to the destination node; receiving an echo response packet from the destination node, the echo response packet comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the forward path.

2. The packet processing method of claim 1, wherein, The to-be-returned IPv6 extension header is a first hop-by-hop option header in the echo request packet.

3. The packet processing method of claim 2, wherein, The echo request packet further comprises an IPv6 header, an Internet Control Message Protocol (ICMP) version 6 (ICMPv6) 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.

4. The packet processing method of claim 3, wherein, The first hop-by-hop option header comprises an IOAM data field, and the second indication information is encapsulated in the IOAM data field.

5. The packet processing method of claim 4, wherein, The IOAM data field comprises an IOAM trace type field, and the second indication information is represented by a value of the IOAM trace type field.

6. The packet processing method of claim 5, wherein, The generating of the echo request packet of ICMPv6 comprises: encapsulating the IOAM trace type field into the first hop-by-hop option header, and setting a most significant bit and a second most significant bit in the value of the IOAM trace type field to a set value.

7. The packet processing method of claim 6, wherein, The generating of the echo request packet of ICMPv6 further comprises: adding IOAM data corresponding to the source node into the first hop-by-hop option header.

8. The packet processing method according to any one of claims 1 to 7, wherein The echo response packet further comprises IOAM data added by each node on a backward path, the backward path being a transmission path of the echo response packet transmitted from the destination node to the source node. 9.The method of any one of claims 1 to 8, further comprising: determining link information through which a specified service flow passes, according to the IOAM data added by each node on the backward path in the echo response packet and the IOAM data added by each node on the forward path; and / or performing path consistency detection according to the IOAM data added by each node on the backward path in the echo response packet and the IOAM data added by each node on the forward path. ​ 10. The packet processing method of claim 8 or 9, wherein, The echo response message comprises an IPv6 header, a second hop-by-hop option header, an Internet Control Message Protocol (ICMPv6) header, and an ICMP extension structure field; IOAM data added by each node on a backhaul path is encapsulated in the second hop-by-hop option header, and / or the IPv6 extension header carrying the to-be-returned data is encapsulated in the ICMP extension structure field in the echo response message.

11. The packet processing method according to any one of claims 1 to 10, wherein The IOAM data comprises at least one of a hop limit, an ingress interface identifier, an egress interface identifier, and a node identifier.

12. A packet processing method, performed by a destination node, comprising: receiving a sixth version of an Internet Control Message Protocol (ICMPv6) echo request message from a source node, the echo request message comprising first indication information and second indication information, the first indication information being used to indicate a sixth version of an Internet Protocol (IPv6) extension header to be returned, and the second indication information being used to indicate that each node on a forward path adds in-flow operation, administration and maintenance (IOAM) data in the IPv6 extension header to be returned, the forward path being a transmission path of the echo request message from the source node to the destination node; generating an echo response message according to the echo request message, the echo response message comprising the IPv6 extension header to be returned carrying the IOAM data added by each node on the forward path; sending the echo response message to the source node.

13. The packet processing method of claim 12, wherein, The IPv6 extension header to be returned is a first hop-by-hop option header in the echo request message.

14. The packet processing method of claim 13, wherein, The generating the echo response message according to the echo request message comprises: obtaining a first hop-by-hop option header from the echo request message according to the first indication information; adding, in the first hop-by-hop option header, IOAM data corresponding to the destination node according to the second indication information, to obtain the IPv6 extension header to be returned carrying the IOAM data added by each node on the forward path; encapsulating the IPv6 extension header to be returned carrying the IOAM data added by each node on the forward path into the echo response message.

15. The packet processing method of claim 13 or 14, wherein, The echo response message comprises an IPv6 header, an ICMPv6 header, and an ICMP extension structure, and the IPv6 extension header to be returned carrying the IOAM data added by each node on the forward path is encapsulated in the ICMP extension structure.

16. The packet processing method of claim 15, wherein, The echo response message further comprises a second hop-by-hop option header, and the second hop-by-hop option header encapsulates third indication information, the third indication information being used to indicate that each node on a backhaul path adds IOAM data in the second hop-by-hop option header, the backhaul path being a transmission path of the echo response message from the destination node to the source node.

17. The packet processing method of claim 16, wherein, The second hop-by-hop option header comprises an IOAM data field, and the third indication information is encapsulated in the IOAM data field.

18. The packet processing method of claim 17, wherein, The IOAM data field comprises an IOAM trace type field, and the third indication information is represented by a value of the IOAM trace type field.

19. The packet processing method of claim 18, wherein, The generating the echo response message according to the echo request message further comprises: encapsulate the IOAM trace type field into a second hop-by-hop option header, and set a most significant bit and a second most significant bit in a value of the IOAM trace type field to a set value.

20. The packet processing method of any of claims 16 to 19, wherein, The generating, according to the echo request message, an echo response message further includes: adding the IOAM data corresponding to the destination node into the second hop-by-hop option header.

21. The packet processing method of any 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.

22. A packet processing apparatus, comprising: a generating module configured to generate an echo request message of Internet Control Message Protocol version 6 (ICMPv6), the echo request message comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, and the second indication information being used to indicate that each node on a to-path path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the to-path path being a transmission path of the echo request message transmitted by a source node to a destination node; a sending module configured to send the echo request message to the destination node; a receiving module configured to receive an echo response message from the destination node, the echo response message comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the to-path path.

23. A packet processing apparatus, 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 comprising first indication information and second indication information, the first indication information being used to indicate a to-be-returned Internet Protocol version 6 (IPv6) extension header, and the second indication information being used to indicate that each node on a to-path path adds in-flow operation, administration and maintenance (IOAM) data in the to-be-returned IPv6 extension header, the to-path path being a transmission path of the echo request message transmitted by the source node to a destination node; a generating module configured to generate, according to the echo request message, an echo response message, the echo response message comprising the to-be-returned IPv6 extension header carrying the IOAM data added by each node on the to-path path; a sending module configured to send the echo response message to the source node.

24. A packet processing system, comprising: a source node comprising the packet processing apparatus of claim 22; a destination node comprising the packet processing apparatus of claim 23.

25. The packet processing system of claim 24, further comprising: at least one first forwarding node disposed on a to-path path, configured to forward the echo request message; and at least one second forwarding node disposed on a to-back path, configured to forward the echo response message.

26. A packet processing apparatus, comprising: a memory; and a processor coupled to the memory, the processor configured to execute the packet processing method of any one of claims 1 to 21 based on instructions stored in the memory.

27. A computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the packet processing method according to any one of claims 1 to 21.

28. A computer program product having stored thereon computer program instructions which, when executed by a processor, implement the packet processing method according to any one of claims 1 to 21.

Images