Message processing method, device and medium

Abstract

The present application provides a message processing method, a device and a medium. The message processing method comprises: encapsulating a target extension header carrying upper-layer protocol information in an extension header section of a message, to obtain an encapsulated message; and sending the encapsulated message.

Description

Message processing methods, equipment, and media

[0001] Cross-references

[0002] This invention claims priority to a Chinese patent application filed with the Patent Office of China on December 14, 2023, with application number 202311727238.X and invention name “Message Processing Method, Device and Medium”. The entire contents of this application are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a message processing method, device and medium. Background Art

[0004] Internet Protocol Version 6 (IPv6) packets introduce an extension header mechanism. These headers are attached in a linked list format after the IPv6 header and before the upper-layer protocol header. Based on this encapsulation format, the offset length of the IPv6 upper-layer protocol header is calculated as "IPv6 basic header length + IPv6 extension header length." The IPv6 basic header is defined as 40 bytes long, while the IPv6 extension header can exceed 1000 bytes. This causes the IPv6 packet length to exceed the 128-byte processing capability of common network device chips. When the upper-layer protocol header offset exceeds 128 bytes, network devices must process the packet through multiple cycles to read the upper-layer protocol information, severely impacting network throughput and packet latency.

[0005] Under the IPsec mechanism, the message content after the Encapsulating Security Payload (ESP) extension header or the Authentication (AH) extension header will be encrypted and protected, causing the upper-layer protocol information of the IPv6 message to be encrypted as well. This makes it impossible for the device receiving the message to recognize the upper-layer protocol information of the IPv6 message, and thus unable to determine the attributes of the message based on the upper-layer protocol information and perform correct processing actions.

[0006] How to solve the problem that the IPv6 extension header causes the upper-layer protocol information to be excessively offset or encrypted, which in turn makes it impossible for existing network equipment to effectively obtain and process the upper-layer protocol information, resulting in the network equipment being unable to effectively perform security control, operation and maintenance, and congestion avoidance management of IPv6 data packets, is a technical problem that urgently needs to be solved.

[0007] Summary of the Invention

[0008] The embodiments of the present application provide a message processing method, device and medium, which are intended to at least solve the problem that the extended header of IPv6 causes the upper layer protocol information to be excessively offset or encrypted.

[0009] In a first aspect, an embodiment of the present application provides a message processing method, the method comprising: encapsulating a target extended header carrying upper-layer protocol information in an extended header portion of a message to obtain an encapsulated message; and sending the encapsulated message.

[0010] In second aspect, an embodiment of the present application provides a message processing method, which includes: receiving a message; obtaining upper-layer protocol information from a target extension header of the message; determining a forwarding processing rule corresponding to the message based on the upper-layer protocol information; and processing the message according to the forwarding processing rule.

[0011] In a third aspect, an embodiment of the present application provides an electronic device comprising: one or more processors; a memory on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the message processing method described in the first aspect or the second aspect.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the message processing method as described in the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings are used to provide a further understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0014] Figure 1 is a schematic diagram of an IPv6 message format;

[0015] FIG2 is a schematic diagram of the IP message format under two working modes of IPsec;

[0016] FIG3 is a schematic diagram of an implementation environment of a message processing method provided in an embodiment of the present application;

[0017] FIG4 is a flow chart of a message processing method provided in an embodiment of the present application;

[0018] FIG5 is a flow chart of another message processing method provided in an embodiment of the present application;

[0019] FIG6 is a schematic diagram of the format of an upper layer protocol information extension header provided in an embodiment of the present application;

[0020] FIG7 is a schematic diagram of the format of the option data field of the upper layer protocol information extension header provided in an embodiment of the present application;

[0021] FIG8 is a schematic diagram of a message format provided in an embodiment of the present application;

[0022] FIG9 is a schematic diagram of another message format provided in an embodiment of the present application;

[0023] FIG10 is a flow chart of a message processing method provided in an embodiment of the present application;

[0024] FIG11 is a flow chart of a message processing method provided in an embodiment of the present application;

[0025] FIG12 is a schematic diagram of an SRv6 network provided in an embodiment of the present application;

[0026] FIG13 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the technical solution of the present application, the technical solution provided by the present application is described in detail below with reference to the accompanying drawings.

[0028] Example embodiments will be described more fully hereinafter with reference to the accompanying drawings, but the described example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the scope of this application to those skilled in the art.

[0029] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0030] The terms used herein are used only to describe specific embodiments and are not intended to limit this application. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, they specify the presence of features, wholes, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof.

[0031] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0032] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present application, and will not be interpreted as having an idealized or overly formal meaning, unless clearly defined in the examples of the present application.

[0033] To facilitate a better understanding of the solutions of the embodiments of the present application, the relevant technologies are first introduced below.

[0034] With the continuous evolution of the internet and the rapid development of telemedicine, the Internet of Things, industrial interconnection, and autonomous driving, Internet Protocol Version 4 (IPv4) addresses are gradually becoming depleted. The next-generation network protocol, IPv6, not only meets the massive address requirements of future network development but also enables more precise segmented control of emerging network services. Consequently, its deployment and application in commercial networks is rapidly accelerating.

[0035] During the deployment of IPv6, although it fully demonstrated its advantages such as abundant address pools, it also exposed the problem of poor compatibility with existing commercial network equipment.

[0036] Before the advent of IPv6, the processing chips and underlying code logic of various network devices were designed from the outset to fully consider the protocol characteristics of IPv4, which was not an issue for IPv6. With the deployment of IPv6, the position of IPv6 upper-layer protocol information has shifted further relative to IPv4, resulting in the inability of existing network devices to correctly process and forward IPv6 packets.

[0037] Information exchange on a network is carried by packets at the physical transmission layer, and forwarding packets within the network enables information transfer. Based on packet characteristics, network devices perform pre-defined processing actions on packets for purposes such as security control, operational maintenance, and congestion avoidance. These actions may include discarding packets, mirroring packets, modifying packet content, and selecting forwarding routes. Packet characteristics generally refer to the following information carried in a packet: source MAC address, destination MAC address, source IP address, destination IP address, protocol number, source port, and destination port. The protocol number, source port, and destination port are upper-layer protocol information.

[0038] The IPv4 protocol specifies that the IPv4 header length is indicated by the 4-bit IHL (IP Header Length) field, which is a 32-bit unit. Therefore, its theoretical maximum length is 60 bytes. Typically, the IPv4 header does not use the Option field, and the most common IPv4 header length on the Internet is 16 bytes.

[0039] For example, the ASIC / NPU architecture chips commonly found in network equipment can read the first 128 bytes of a message during hard forwarding, extracting the message's characteristics based on the offset, and then executing the pre-set forwarding and processing actions. This mechanism effectively supports the acquisition of upper-layer IPv4 protocol information.

[0040] IPv6 introduces the extension header mechanism. The extension header is attached to the IPv6 packet header and before the upper-layer protocol header in the form of a linked list.

[0041] Please refer to Figure 1, which shows a schematic diagram of the IPv6 message format. As shown in Figure 1, an IPv6 message consists of three parts: the IPv6 basic header, the IPv6 extension header, and the data portion. The data portion consists of the upper-layer protocol header and its payload. The data portion can be an ICMPv6 (Internet Control Message Protocol for IPv6) message, a TCP6 message, or a UDP6 message.

[0042] The IPv6 basic header has eight fields and a fixed size of 40 bytes. Every IPv6 datagram must include a header. The basic header provides essential information for packet forwarding and is parsed by all devices along the forwarding path. The Next Header field in the IPv6 basic header indicates the type of the first extension header (or, if not present, the type of the upper-layer protocol).

[0043] The extension headers defined for IPv6 are:

[0044] (1) Hop-by-Hop Options Extended Header: This type of header has the Next Header field set to 0. This option specifies transmission parameters for each hop along the transmission path. Each intermediate node along the transmission path must read and process this field. The Hop-by-Hop Options header is currently used for three main purposes: for large payloads (payloads exceeding 65,535 bytes); for device prompts, causing the device to check for this option information rather than simply forwarding it; and for resource reservation (RSVP).

[0045] (2) Destination Options: This header has a Next Header field value of 60. The Destination Options header carries some information that only the destination node will process.

[0046] (3) Routing extension header: The Next Header field value of this type of header is 43. This header can be used by IPv6 source nodes to force data packets to pass through a specific device.

[0047] (4) Fragment extension header: This type of header has a Next Header field value of 44. Like IPv4, IPv6 message transmission is also subject to the MTU limit. When the message length exceeds the MTU, it must be fragmented. In IPv6, fragmentation is performed using the Fragment extension header.

[0048] (5) Authentication header (AH): This header has a Next Header field value of 51. This header is used by IPsec to provide authentication, data integrity, and replay protection. It also protects some fields in the IPv6 basic header.

[0049] (6) Encapsulating Security Payload (ESP): This header has a Next Header field value of 50. This header is used by IPsec to provide authentication, data integrity, replay protection, and confidentiality for IPv6 datagrams, similar to the authentication header.

[0050] According to the IPv6 extension header specification, when more than one extension header is used in the same packet, the headers must appear in the following order: IPv6 basic header, hop-by-hop options extension header, destination options extension header, routing extension header, fragmentation extension header, AH extension header, ESP extension header, destination options extension header, and upper-layer protocol data unit.

[0051] Based on the IPv6 message format introduced earlier, the offset length of the IPv6 upper-layer protocol header is "IPv6 basic header length + IPv6 extended header length". Among them, the length of the IPv6 basic header is defined as 40 bytes, while the length of the IPv6 extended header is defined as more than 1000 bytes. This causes the length of the IPv6 message to exceed the chip processing capacity of common network devices - 128 bytes. When the offset length of the upper-layer protocol header exceeds 128 bytes, the network device needs to process it through multiple cycles before it can read the upper-layer protocol information of the IPv6 message, which has a serious impact on the network throughput and message latency. Existing network chips have the following three ways to handle IPv6 messages with upper-layer protocol offset lengths exceeding expectations:

[0052] (1) The protocol number and source and destination ports are searched through a continuous recycle process, which results in a large number of packet losses and severe delays.

[0053] (2) Directly identifying the absence of protocol numbers and source and destination ports, which leads to incorrect processing and routing.

[0054] (3) Discard the message directly.

[0055] RFC9098 addresses this flaw, but it only analyzes the consequences and potential harms, and places the hope on the next generation of network processors to add support for IPv6 protocol features. However, with billions of devices and chips currently in use, it's unrealistic to completely replace or deprecate existing network equipment simply because some IPv6 features aren't supported.

[0056] IPsec is a mechanism for ensuring end-to-end data security within IP communications environments. It operates in two modes: transport mode and tunnel mode. Transport mode protects the IP packet's payload, while tunnel mode protects the entire IP packet. Figure 2 illustrates the IP message format under these two modes. As shown in the example in Figure 2, under IPsec, the message content following the ESP or AH extension header is encrypted and protected, including the upper-layer protocol headers of the IPv6 message. This prevents receiving devices from identifying the upper-layer protocol information in the IPv6 message and, consequently, from determining the message's attributes based on this information and executing the correct processing action.

[0057] How to solve the problem that the IPv6 extension header causes the upper-layer protocol information to be excessively offset or encrypted, which in turn makes it impossible for existing network equipment to effectively obtain and process the upper-layer protocol information, resulting in the network equipment being unable to effectively perform security control, operation and maintenance, and congestion avoidance management of IPv6 data packets, is a technical problem that urgently needs to be solved.

[0058] In order to solve the problem that the extended header of IPv6 causes the upper-layer protocol information to be excessively offset or encrypted, the present application provides a message processing method, an electronic device and a computer-readable storage medium. By encapsulating the upper-layer protocol information in the target extended header of the extended header part of the message, the receiving-side network device can obtain the upper-layer protocol information from the target extended header of the message after receiving the message. Compared with the traditional method of obtaining the upper-layer protocol information from the upper-layer protocol header, the solution of the embodiment of the present application can ensure that the network device efficiently obtains the upper-layer protocol information, thereby enabling the message to be correctly processed and forwarded in the network device.

[0059] The embodiments of the present application can be implemented in a communication system, such as in at least one of the following: Universal Mobile Telecommunications System (UMTS, 3G), High Speed ​​Packet Access (HSPA), fourth generation (4G) access technology based on basic wideband code division multiple access (W-CDMA), such as long term evolution (LTE) access technology; or, the communication system can also support fifth generation (5G) access technology, such as new radio (NR) access technology; and future mobile communication systems (such as 6G communication systems). However, the embodiments are not limited to the systems given as examples, but those skilled in the art can apply the solutions to other communication systems with the necessary properties.

[0060] Please refer to Figure 3, which is a schematic diagram of an implementation environment of a message processing method provided in an embodiment of the present application. As shown in Figure 3, the implementation environment of the embodiment of the present application includes a first device and a second device, wherein the first device and the second device can both be network devices (for example, a switch or a router). The first device can also be referred to as a sending-side network device in the embodiment of the present application. The first device can encapsulate the message and then send the encapsulated message to the second device. The second device can also be referred to as a receiving-side network device in the embodiment of the present application. The second device can receive the message sent by the first device and then parse, process and forward the received message.

[0061] Please refer to FIG4 , which is a flowchart of a message processing method provided in an embodiment of the present application. The execution subject of the method may be the first device shown in FIG3 . As shown in FIG4 , the method includes the following steps:

[0062] Step S110: Encapsulate the target extension header carrying upper layer protocol information in the extension header portion of the message to obtain an encapsulated message.

[0063] Step S120: Send the encapsulated message.

[0064] It should be noted that the message described in the embodiments of the present application may be an IPv6 message or a Segment Routing IPv6 (SRv6) message based on the IPv6 forwarding plane, or a message of another protocol, or a message of a future protocol version. The embodiments of the present application do not limit the specific type of message. The embodiments of the present application will be described using IPv6 messages as an example.

[0065] The embodiment of the present application encapsulates the upper-layer protocol information in the target extension header of the message. The purpose is to enable the receiving-side network device to obtain the upper-layer protocol information from the target extension header of the message after receiving the message. When the offset length of the upper-layer protocol header is too long, this can avoid the receiving-side network device requiring multiple cycles to read the upper-layer protocol information; and when the message adopts the IPsec mechanism, resulting in the upper-layer protocol header being encrypted, it can avoid the receiving-side network device from being unable to obtain the upper-layer protocol information. Overall, compared with the traditional method of obtaining upper-layer protocol information from the upper-layer protocol header, the solution of the embodiment of the present application can ensure that the network device efficiently obtains the upper-layer protocol information, thereby enabling the message to be correctly processed and forwarded in the network device.

[0066] The upper-layer protocol information described in the embodiment of the present application includes at least one of the following information: protocol type information, source port information, destination port information and message type information.

[0067] Please refer to Figure 5, which is a flowchart of another message processing method provided in an embodiment of the present application. As shown in Figure 5, before step S110, the following steps may also be included:

[0068] Step S100: Determine whether the message meets the preset conditions.

[0069] The precondition includes one of the following:

[0070] Condition 1: The offset length of the upper layer protocol header of the message exceeds the preset offset length threshold.

[0071] Condition 2: The upper-layer protocol header of the message is encrypted.

[0072] It is understandable that only one of conditions 1 and 2 needs to be met to confirm that the preset condition is met, and then when the preset condition is met, step S110 is executed, that is: encapsulating the target extended header carrying upper layer protocol information in the extended header part of the message.

[0073] It can be understood that the target extended header needs to be within the above offset length threshold.

[0074] For example, assuming the chip processing capability of the receiving network device is 128 bytes, the offset length threshold in condition 1 can be set to 128 bytes. When the offset length of the upper-layer protocol header exceeds 128 bytes, the transmitting network device executes step S110 to encapsulate the upper-layer protocol information into the target extension header. When the receiving network device receives the message, it can obtain the upper-layer protocol information from the first 128 bytes, eliminating the need to go through multiple processing cycles to obtain the uploaded protocol information, thereby improving the processing efficiency of the upper-layer protocol information.

[0075] It is understandable that when a message includes an ESP extension header or an AH extension header, the target extension header also needs to be located before the ESP extension header or the AH extension header to prevent upper layer protocol information from being encrypted.

[0076] In one embodiment of the present application, the target extension header is an upper layer protocol information extension header (Upper-Layer-Info).

[0077] It is understood that the upper layer protocol information extension header is an extension header defined in the embodiment of the present application. The upper layer protocol information extension header may be located immediately after the basic header of the message or immediately after the hop-by-hop option extension header.

[0078] Please refer to Figure 6, which is a schematic diagram of the format of the upper-layer protocol information extension header provided in an embodiment of the present application.

[0079] As shown in Figure 6, the upper layer protocol information extension header includes:

[0080] Next Header field (Next Header), 8-bit unsigned integer, indicates the protocol type of the next extension header or upper layer protocol;

[0081] The extension header length field (Extension Header Length, Hdr EXT Len), an 8-bit unsigned integer, indicates the length of the upper-layer protocol extension header except the Next Header field, and the unit can be bytes.

[0082] Options field (Options): upper-layer protocol information is located in the options field (Options).

[0083] Please refer to Figure 7, which is a schematic diagram of the format of the option data field of the upper layer protocol information extension header provided in an embodiment of the present application. As shown in Figure 7, the option field of the upper layer protocol information extension header includes:

[0084] Option type field (Option Type, Opt Type); Option data length field (Option Data Length, Opt Data Len); Option data field (Option Data), the upper layer protocol information of the embodiment of the present application can be located in the option data field.

[0085] Specifically, the option data field includes at least one of the following information: protocol type information, source port information, destination port information, message type information, and 16-bit checksum information.

[0086] For example, the protocol type value of the upper-layer protocol information extension header (Upper-Layer-Info) defined in the embodiment of the present application can be 0x46. For the case where the option data field has a checksum (checksum) or no checksum (checksum), the type value of the option (option) can be 0x15 or 0x31.

[0087] If the option data field does not have a checksum, the fields it contains are defined as follows:

[0088] Opt Type: 8-bit unsigned integer, defined in this embodiment as 0b000111, i.e. 0x15; Opt Data Len: 8-bit unsigned integer, indicating the Option Data length in bytes; Option Data: 8-bit upper-layer protocol type and the characteristic field of the protocol, which can be defined as follows: TCP protocol, 0x07 + 16-bit source port + 16-bit destination port; UDP protocol, 0x12 + 16-bit source port + 16-bit destination port; ICMP protocol, 0x3A + 8-bit message type.

[0089] When the option data field contains a checksum, the definitions of the fields it contains are as follows:

[0090] Opt Type: 8-bit unsigned integer; this application defines 0b001111, i.e. 0x31; Opt Data Len: 8-bit unsigned integer, OptionData length, in bytes; Option Data: 9-bit upper-layer protocol type and the characteristic field of the protocol, which can be defined as follows: TCP protocol, 0x07 + 16-bit source port + 16-bit destination port + 16-bit checksum; UDP protocol, 0x12 + 16-bit source port + 16-bit destination port + 16-bit checksum; ICMP protocol, 0x3A + 8-bit message type + 16-bit checksum.

[0091] In one possible embodiment, the target extension header represents an upper-layer protocol information extension header defined in an embodiment of the present application. The extended header portion of the message does not include a hop-by-hop option extension header, the next header of the basic header of the message is an upper-layer protocol information extension header, and the next header field in the basic header of the message has a value corresponding to the upper-layer protocol information extension header.

[0092] Please refer to Figure 8, which is a schematic diagram of a message format provided in an embodiment of the present application. As shown in Figure 8, the message includes a basic header and an extended header, wherein the first header in the extended header is the upper-layer protocol information extended header (Upper-Layer-Info) defined in an embodiment of the present application. Specifically, the value of the next header field (Next Header) of the basic header is 1, indicating that the next header is the upper-layer protocol information extended header (Upper-Layer-Info). The upper-layer protocol information extended header includes a next header field (Next Header), an extended header length field (Hdr EXT Len) and an option field (Options). Among them, the option field (Options) includes an option type field (Opt Type), an option data length field (Opt Data Len) and an option data field (Option Data). In one embodiment, the value of the Option Type field (Opt Type) is 0x15, and the Option Data field (Option Data) includes protocol type information (TCP / UDP protocol type), source port information, and destination port information, or the Option Data field (Option Data) includes protocol type information (ICMP protocol type) and message type information. In another embodiment, the value of the Option Type field (Opt Type) is 0x31, and the Option Data field (Option Data) includes protocol type information (TCP / UDP protocol type), source port information, destination port information, and 16-bit checksum information, or the Option Data field (Option Data) includes protocol type information (ICMP protocol type), message type information, and 16-bit checksum information.

[0093] In one possible embodiment, the target extension header represents an upper-layer protocol information extension header defined in an embodiment of the present application. The extended header portion of the message includes a hop-by-hop options extension header, the next header of the hop-by-hop options extension header is the upper-layer protocol information extension header, and the next header field in the hop-by-hop options extension header has a value corresponding to the upper-layer protocol information extension header.

[0094] Please refer to Figure 9, which is a schematic diagram of another message format provided by an embodiment of the present application. As shown in Figure 9, the message includes a basic header and an extended header, wherein the first header in the extended header is a hop-by-hop option extended header (Hop-by-Hop), and the second header is an upper-layer protocol information extended header (Upper-Layer-Info) defined in an embodiment of the present application. Specifically, the value of the Next Header field (Next Header) of the basic header is 0, indicating that the next header is a hop-by-hop option extended header (Hop-by-Hop). The value of the Next Header field (Next Header) of the Hop-by-Hop option extended header (Hop-by-Hop) is 0x46, indicating that the next header is an upper-layer protocol information extended header (Upper-Layer-Info). The upper-layer protocol information extended header includes a Next Header field (Next Header), an extended header length field (Hdr EXT Len), and an options field (Options). The options field (Options) includes an option type field (Opt Type), an option data length field (Opt Data Len), and an option data field (Option Data). In one embodiment, the value of the option type field (Opt Type) is 0x15, and the option data field (Option Data) includes protocol type information (TCP / UDP protocol type), source port information, and destination port information, or the option data field (Option Data) includes protocol type information (ICMP protocol type) and message type information. In another embodiment, the value of the option type field (Opt Type) is 0x31, and the option data field (Option Data) includes protocol type information (TCP / UDP protocol type), source port information, destination port information, and 16-bit checksum information, or the option data field (Option Data) includes protocol type information (ICMP protocol type), message type information, and 16-bit checksum information.

[0095] In one possible embodiment, the target extension header represents a hop-by-hop options extension header, which includes an options field. Upper-layer protocol information is located in the options field of the hop-by-hop options extension header. In other words, the options field of the hop-by-hop options extension header (Hop-by-Hop) can be used to carry upper-layer protocol information.

[0096] Exemplarily, step S110, encapsulating a target extension header carrying upper layer protocol information in an extension header portion of the message, is specifically implemented as follows:

[0097] Step S111a: Add a target extension header to the extension header part of the message.

[0098] Step S112a: Add the upper layer protocol information to the target extension header.

[0099] Exemplarily, the target extension header carrying upper layer protocol information is encapsulated in the extension header portion of the message, including:

[0100] Step S111b: Add a target extension header to the extension header part of the message.

[0101] Step S112b: encrypt or compress the upper layer protocol information and add it to the target extension header.

[0102] It can be understood that the upper-layer protocol information can be encrypted according to a preset encryption algorithm and then added to the target extension header; after the receiving side network device receives the message, it can decrypt the upper-layer protocol information in the target extension header based on the preset key, and then obtain the upper-layer protocol information.

[0103] It can be understood that the upper-layer protocol information can be compressed based on a preset compression algorithm and then added to the target extension header; after the receiving side network device receives the message, it can decompress the upper-layer protocol information in the target extension header based on a preset decompression algorithm to obtain the upper-layer protocol information.

[0104] An embodiment of the present application provides a message processing method, applied to a sending-side network device, comprising the following steps:

[0105] Step S201: Determine whether the IPv6 message to be forwarded meets one of the following conditions: a. The offset length of the upper layer protocol header exceeds a preset offset length threshold; b. An ESP extension header or an AH extension header exists, so that the upper layer protocol header is encrypted.

[0106] Step S202: If the above condition a or condition b is met, determine whether the IPv6 message to be forwarded contains a Hop-by-Hop option extension header.

[0107] Step S203: If a Hop-by-Hop options extension header exists, the Next Header field of the Hop-by-Hop options extension header is set to the field value representing the Upper-Layer-Info extension header (which can be 0x46), and the Upper-Layer-Info extension header is added after the Hop-by-Hop options extension header. The upper-layer protocol information of the IPv6 packet to be forwarded is encapsulated in the Options field of the Upper-Layer-Info extension header.

[0108] Step S204: If there is no Hop-by-Hop options extension header, set the value of the Next Header field (Next Header) of the basic header to represent the upper-layer protocol information extension header (Upper-Layer-Info) (which can be 1), add the upper-layer protocol information extension header (Upper-Layer-Info) after the basic header, and encapsulate the upper-layer protocol information of the IPv6 packet to be forwarded in the options field (Options) of the upper-layer protocol information extension header (Upper-Layer-Info).

[0109] Step S205: After the entire encapsulation of the message is completed, the encapsulated IPv6 message is sent to the receiving side network device.

[0110] It can be understood that the embodiment of the present application defines: if the message contains a hop-by-hop option extension header (Hop-by-Hop), the upper-layer protocol information extension header (Upper-Layer-Info) immediately follows the hop-by-hop option extension header (Hop-by-Hop); if the message contains a hop-by-Hop option extension header (Hop-by-Hop), the upper-layer protocol information extension header (Upper-Layer-Info) immediately follows the basic header (IPv6 Header).

[0111] It is further understood that if the Next Header field value of the basic IPv6 Header is 0, it indicates that the next header of the basic IPv6 Header is the Hop-by-Hop Options extension header; if the Next Header field value of the basic IPv6 Header is 1, it indicates that the next header of the basic IPv6 Header is the Upper-Layer-Info extension header. Of course, if the Next Header field value of the basic IPv6 Header is 0x46, it can also indicate that the next header of the basic IPv6 Header is the Upper-Layer-Info extension header.

[0112] In an embodiment of the present application, by encapsulating upper-layer protocol information in a target extended header in the extended header part of a message, the receiving-side network device can obtain the upper-layer protocol information from the target extended header of the message after receiving the message. Compared with the traditional method of obtaining upper-layer protocol information from the upper-layer protocol header, the solution of the embodiment of the present application can ensure that the network device efficiently obtains the upper-layer protocol information, thereby enabling the message to be correctly processed and forwarded in the network device.

[0113] Please refer to FIG10, which is a flowchart of a message processing method provided in an embodiment of the present application. The execution subject of the method may be the second device shown in FIG3. As shown in FIG10, the method includes the following steps:

[0114] Step S310: Receive a message.

[0115] Step S320: Obtain upper layer protocol information from the target extension header of the message.

[0116] Step S330: Determine the forwarding processing rule corresponding to the message according to the upper layer protocol information.

[0117] Step S340: Process the message according to the forwarding processing rules.

[0118] The upper layer protocol information includes at least one of the following information: protocol type information; source port information; destination port information; and message type information.

[0119] It can be understood that the embodiment of the present application carries upper-layer protocol information through the target extension header. After receiving the message, the network device can directly obtain the upper-layer protocol information from the target extension header, avoiding problems caused by the upper-layer protocol header offset being too long or being encrypted, ensuring that the network device efficiently obtains the upper-layer protocol information, and thus enables the message to be correctly processed and forwarded in the network device.

[0120] In one embodiment of the present application, the target extension header is an upper layer protocol information extension header (Upper-Layer-Info).

[0121] It is understood that the upper layer protocol information extension header is an extension header defined in the embodiment of the present application. The upper layer protocol information extension header may be located immediately after the basic header of the message or immediately after the hop-by-hop option extension header.

[0122] Please refer to FIG11, which is a flowchart of a message processing method provided in an embodiment of the present application. The execution subject of the method may be the second device shown in FIG3. As shown in FIG11, the method includes the following steps:

[0123] Step S410: Receive a message.

[0124] Step S420: Obtain the value of the Next Header field in the basic header of the message, and determine the position of the upper layer protocol information extension header in the message according to the value of the Next Header field in the basic header.

[0125] Step S430: Acquire upper layer protocol information from an upper layer protocol information extension header according to the determined location.

[0126] Step S440: Determine the forwarding processing rule corresponding to the message according to the upper layer protocol information.

[0127] Step S450: Process the message according to the forwarding processing rules.

[0128] Exemplarily, in step S420, determining the position of the upper layer protocol information extension header in the message according to the value of the next header field in the basic header may specifically include the following steps:

[0129] When the value of the Next Header field in the basic header is the first value (representing the Next Header field value of the Hop-by-Hop Options extension header is "0"), the next header in the basic header is determined to be the Hop-by-Hop Options extension header, and the upper-layer protocol information extension header is determined to be the next header of the Hop-by-Hop Options extension header;

[0130] Alternatively, when the value of the Next Header field in the basic header is the second value (representing the Next Header field value "0x461" or "1" of the upper layer protocol information extension header), the upper layer protocol information extension header is determined to be the next header in the basic header.

[0131] It is understandable that after determining the position of the upper layer protocol information extension header in the message, the upper layer protocol information extension header can be located according to the determined position to extract the upper layer protocol information from the upper layer protocol information extension header.

[0132] Exemplarily, the upper layer protocol information extended header includes a next header field, an extended header length field, and an option field, and the upper layer protocol information is located in the option field.

[0133] That is, when the target extension header is an upper layer protocol information extension header, obtaining the upper layer protocol information from the target extension header of the message specifically includes: obtaining the upper layer protocol information from the option field of the upper layer protocol information extension header.

[0134] In one embodiment of the present application, the target extension header is a hop-by-hop option extension header (Hop-by-Hop), and obtaining upper-layer protocol information from the target extension header of the message includes: obtaining upper-layer protocol information from the option field in the hop-by-hop option extension header.

[0135] It can be understood that the target extended header represents the hop-by-hop options extended header (Hop-by-Hop), the hop-by-hop options extended header (Hop-by-Hop) includes an options field, and the upper-layer protocol information is located in the options field (Options) of the hop-by-hop options extended header (Hop-by-Hop). Therefore, the upper-layer protocol information can be extracted from the options field (Options) of the hop-by-hop options extended header (Hop-by-Hop).

[0136] Exemplarily, determining the forwarding rule corresponding to the message according to the upper layer protocol information may specifically include the following steps: performing matching processing according to the upper layer protocol information and a preset access control list (ACL) to obtain the forwarding processing rule matched by the message.

[0137] Correspondingly, the message is processed according to the forwarding processing rules, including: modifying, discarding or sending the message.

[0138] An embodiment of the present application provides a message processing method, applied to a receiving-side network device, comprising the following steps:

[0139] Step S501: Receive an IPv6 message and confirm the location of the upper-layer protocol information extension header (Upper-Layer-Info).

[0140] Step S502: Parse the upper-layer protocol information from the location of the upper-layer protocol information extension header (Upper-Layer-Info). Specifically, after finding the location of the Upper-Layer-Info extension header, read the option field (option) whose option type field (option type) is 0x15 / 0x31, and then determine the option data field (Option Data) according to the option data length field (Opt Data Len). Parse the upper-layer protocol information such as the upper-layer protocol type, source port information, or destination port information from the option data field (Option Data).

[0141] Step S503: parse the upper layer protocol information and output the parsing result, where the parsing result matches the forwarding processing rule pre-set for the purpose of security control or congestion avoidance.

[0142] Step S504: operate on the IPv6 message according to the forwarding processing rules.

[0143] An embodiment of the present application provides a message processing method, applied to a receiving-side network device, comprising the following steps:

[0144] Step S601: Receive an IPv6 message, where the IPv6 message carries an upper-layer protocol information extension header (Upper-Layer-Info).

[0145] Step S602: Obtain the Next Header field value in the basic header of the IPv6 message.

[0146] Step S603: If the Next Header field value in the basic header is "1", it indicates that the position offset of the upper-layer protocol information extension header (Upper-Layer-Info) relative to the IPv6 message header is 40 bytes. Specifically, the length of the basic header of the IPv6 message is fixed at 40 bytes. If the Next Header field in the basic header is "1", it indicates that the upper-layer protocol information extension header (Upper-Layer-Info) is adjacent to the basic header, starting at the 41st byte.

[0147] Step S604: If the Next Header field value in the basic header is "0", it indicates that the position offset of the Upper-Layer-Info extension header relative to the IPv6 packet header is "40 bytes + the length of the Hop-by-Hop extension header + 2 bytes". Specifically, the length of the basic header of the IPv6 packet is fixed at 40 bytes. If the Next Header field in the basic header is "0", it indicates that the Upper-Layer-Info extension header is immediately adjacent to the Hop-by-Hop extension header, and therefore starts at 40 bytes + the length of the Hop-by-Hop extension header + 1 byte.

[0148] Step S605: Extract the upper-layer protocol information extension header (Upper-Layer-Info) based on the "position offset of the upper-layer protocol information extension header (Upper-Layer-Info) relative to the IPv6 packet header" determined in step S603 or S604. Specifically, the IPv6 packet header can be correctly located by current network devices. Based on the offset, the network device can easily locate the upper-layer protocol information extension header (Upper-Layer-Info). Then, based on the extended header length field (Hdr EXT Len) of the upper-layer protocol information extension header (Upper-Layer-Info), the network device extracts the data content of the upper-layer protocol information extension header (Upper-Layer-Info), that is, the option field (Option) containing the upper-layer protocol information.

[0149] Step S606: Extract the upper-layer protocol information according to the option code of the upper-layer protocol information extension header (Upper-Layer-Info); illustratively, the option field is a typical type-length-value (TLV) information. Remove the one-byte type field and the one-byte length field, and the remaining content is "1-byte upper-layer protocol type + 2-byte source port information + 2-byte destination port information".

[0150] Step S607: parse the upper layer protocol information and output the parsing result. If the parsing result matches a forwarding processing rule preset for security control or congestion avoidance, the message is processed or forwarded according to the rule.

[0151] An embodiment of the present application provides a message processing method, applied to a receiving-side network device, comprising the following steps:

[0152] Step S701: Receive an OSPFv3 protocol message encrypted by ESP under the IPSec tunnel mechanism.

[0153] Specifically, according to the discussion in RFC9099, OSPFv3 protocol packets with non-LLA source IP addresses are generally discarded based on ACL rules. However, because the ESP extension header or AH extension header encryption under the IPSec tunnel mechanism causes the upper-layer protocol information to be encrypted and unrecognizable, the ACL security control becomes ineffective.

[0154] Step S702: parse the upper-layer protocol information from the option field (Option) of the upper-layer protocol information extension header (Upper-Layer-Info).

[0155] Specifically, the receiving-side network device can parse the upper-layer protocol information of the IPv6 message from the extension header that is arranged before the ESP extension header or the AH extension header.

[0156] Step S703: Match the message based on the preset ACL rule.

[0157] Specifically, you can search for ACL rules that match a message based on one or more of the message's source MAC, destination MAC, source IP, destination IP, protocol number, source port, and destination port.

[0158] Step S704: The ACL matches an OSPFv3 message whose source IP address is non-LLA and whose protocol number is 89, and the message is discarded according to the matching result.

[0159] Specifically, the ACL matches OSPFv3 packets whose source IP address is not LLA and whose protocol is 89. In addition, similar RIPng protocol packets also need to be controlled. At this time, the relevant characteristics have been obtained and the matching action can be performed. According to the discussion in RFC9099, routers generally discard such matching OSPFv3 packets.

[0160] An embodiment of the present application provides a message processing method, applied to a receiving-side network device, comprising the following steps:

[0161] Step S801: A non-SR router in an SRv6 domain receives an SRv6 message.

[0162] Specifically, according to the SRv6 mechanism, each new SR node in the path requires a 16-byte SID field to be added to the SegList in the SRH for network programming. In a typical 5G scenario, an end-to-end SRv6 tunnel typically passes through approximately 10 SR nodes, and sometimes up to 15-20 SR nodes. In this case, the SRH extension header in the SRv6 message can reach over 300 bytes in length. Current network chipsets are unable to effectively obtain the upper-layer network information in SRv6 messages at this time.

[0163] Step S802: parse the upper-layer protocol information from the option field of the upper-layer protocol information extension header (Upper-Layer-Info) of the message.

[0164] It can be understood that the solution according to the embodiment of the present application can solve the problem that network devices with insufficient performance are unable to parse the upper layer protocol information of IPv6 packets with too long SRH extension headers.

[0165] Step S803: Use the non-SR routing ACL of the SRv6 domain to match a specific service flow.

[0166] For example, in the SRv6 network shown in Figure 12, a service with a packet destination UDP port of 1025 experiences a fault (packet loss, excessive latency, etc.). Initial diagnosis suggests the fault occurs between non-SR routers BC. Therefore, an ACL is used to match packets with a destination UDP port of 1025 and mirror them to device h3, which is connected to router C for diagnostic purposes.

[0167] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described or described in detail in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. It should be further understood that although operations are described in a specific order in the drawings in the embodiments of the present disclosure, this should not be construed as requiring that these operations be performed in the specific order shown or in a serial order, or that all illustrated operations be performed to obtain the desired results. In certain circumstances, multitasking and parallel processing may be advantageous.

[0168] According to the embodiments of the present application, the cost of correctly parsing message characteristics can be significantly reduced. By introducing an extended header, existing network equipment can correctly parse message characteristics, avoiding the replacement of hundreds of millions of network devices. The negative impact of latency and throughput caused by the correct parsing of message characteristics by existing network equipment can be significantly reduced. In addition, the implementation of the present application will not cause existing equipment to abnormally process messages that meet the requirements of the embodiments of the present application, and can achieve better compatibility with existing commercial networks.

[0169] An embodiment of the present application further provides an electronic device, as shown in FIG13 . The electronic device 1400 includes: one or more processors 1410; and a memory 1420 storing one or more programs. When the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 implement:

[0170] A message processing method applied to a first device; or a message processing method applied to a second device.

[0171] The memory 1420 is a non-transient network system that can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory 1420 may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1420 may optionally include a memory 1420 remotely located relative to the processor 1410, and these remote memories 1420 may be connected to the processor 1410 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0172] The memory 1420 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1420 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1420 and is called by the processor 1410 to execute the methods of the embodiments of this application.

[0173] The processor 1410 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0174] In some embodiments, the electronic device also includes: an input / output interface for realizing information input and output; a communication interface for realizing communication interaction between the device and other devices, which can be realized through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.); a bus for transmitting information between the various components of the device (such as processor 1410, memory 1420, input / output interface and communication interface); wherein the processor 1410, memory 1420, input / output interface and communication interface can realize communication connection with each other within the device through the bus.

[0175] An embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute: a message processing method applied to a first device; or a message processing method applied to a second device.

[0176] An embodiment of the present application further provides a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device performs the following operations:

[0177] A message processing method applied to a first device; or a message processing method applied to a second device.

[0178] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0179] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0180] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0181] The above description of some embodiments of the present application with reference to the accompanying drawings does not limit the scope of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present application shall be within the scope of the present application.

Claims

1. A message processing method, the method comprising: Encapsulating a target extension header carrying upper layer protocol information in an extension header portion of the message to obtain an encapsulated message; Send the encapsulated message.

2. The method according to claim 1, wherein The target extended header is an upper layer protocol information extended header, the upper layer protocol information extended header includes a next header field, an extended header length field and an option field, and the upper layer protocol information is located in the option field.

3. The method according to claim 2, wherein: The option field of the upper layer protocol information extension header includes: an option type field, an option data length field and an option data field, and the upper layer protocol information is located in the option data field; The option data field includes at least one of the following information: protocol type information, source port information, destination port information, message type information and 16-bit checksum information.

4. The method according to claim 2, wherein: The extended header part of the message also includes a hop-by-hop option extended header; the next header of the hop-by-hop option extended header is the upper layer protocol information extended header; the next header field in the hop-by-hop option extended header has a value corresponding to the upper layer protocol information extended header.

5. The method according to claim 2, wherein: The next header of the basic header of the message is the upper layer protocol information extension header, and the next header field in the basic header of the message has a value corresponding to the upper layer protocol information extension header.

6. The method according to claim 1, wherein: The target extended header is a hop-by-hop option extended header, the hop-by-hop option extended header includes an option field, and the upper layer protocol information is located in the option field of the hop-by-hop option extended header.

7. The method according to claim 1, wherein: The target extension header carrying upper layer protocol information is encapsulated in the extension header part of the message, including: If the preset conditions are met, the upper layer protocol is encapsulated in the extended header part of the message. The destination extension header of the protocol information; The preset condition includes one of the following: The offset length of the upper layer protocol header of the message exceeds a preset offset length threshold; The upper layer protocol header of the message is encrypted.

8. The method according to claim 1, wherein: The target extension header carrying upper layer protocol information is encapsulated in the extension header part of the message, including: Adding the target extension header to the extension header part of the message; The upper layer protocol information is added to the target extension header, or the upper layer protocol information is encrypted or compressed before being added to the target extension header.

9. The method according to any one of claims 1 to 8, wherein: The upper layer protocol information includes at least one of the following information: Protocol type information; Source port information; Destination port information; Message type information.

10. A message processing method, the method comprising: Receive messages; Acquire upper layer protocol information from a target extension header of the message; Determine a forwarding processing rule corresponding to the message according to the upper layer protocol information; Process the message according to the forwarding processing rule.

11. The method according to claim 10, wherein: The target extension header is an upper layer protocol information extension header. After the receiving message, the method further includes: Obtaining a value of a next header field in a basic header of the message; The position of the upper layer protocol information extension header in the message is determined according to the value of the next header field in the basic header, so as to obtain the upper layer protocol information from the target extension header of the message according to the position.

12. The method according to claim 11, wherein: The determining the position of the upper layer protocol information extension header in the message according to the value of the next header field in the basic header includes: When the value of the next header field in the basic header is a first value, determining that the next header in the basic header is a hop-by-hop option extension header, and determining that the upper layer protocol information extension header is the next header of the hop-by-hop option extension header; or, When the value of the next header field in the basic header is the second value, it is determined that the upper layer protocol information extension header is the next header in the basic header.

13. The method according to claim 11, wherein: The target extended header is an upper layer protocol information extended header, the upper layer protocol information extended header includes a next header field, an extended header length field and an option field, and the upper layer protocol information is located in the option field; The obtaining upper layer protocol information from the target extension header of the message includes: The upper layer protocol information is acquired from an option field of the upper layer protocol information extension header.

14. The method according to claim 10, wherein: The target extension header is a hop-by-hop option extension header, and obtaining upper layer protocol information from the target extension header of the message includes: The upper layer protocol information is obtained from an option field in the hop-by-hop options extension header.

15. The method according to claim 10, wherein: The determining, according to the upper layer protocol information, a forwarding rule corresponding to the message includes: Perform matching processing according to the upper layer protocol information and the preset access control list ACL to obtain the forwarding processing rule matched by the message; The processing of the message according to the forwarding processing rule includes: modifying, discarding or sending the message.

16. The method according to claim 10, wherein: The upper layer protocol information includes at least one of the following information: Protocol type information; Source port information; Destination port information; Message type information.

17. An electronic device comprising: one or more processors; A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement: The message processing method according to any one of claims 1 to 9; or, A message processing method as described in any one of claims 10-16.

18. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements: The message processing method according to any one of claims 1 to 9; or, A message processing method as described in any one of claims 10-16.

Images