Message sending method, device and storage medium

Abstract

The present application discloses a message transmission method, an apparatus and a storage medium, which includes receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path, causing an extension header of the message to carry a send-to-control-plane identifier for indicating whether the information carried in the message is processed in the control plane or the forwarding plane, and transmitting the message. In addition to supporting traditional hop-by-hop processing functions, the present application can also support the ability to process message information hop-by-hop in the forwarding plane, which can further meet the needs of new technologies such as slicing and in-situ flow detection. The send-to-control-plane identifier can be effectively prevented from being tampered with and used by hackers to cause attacks on network nodes.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is based on and claims priority from a Chinese patent application bearing application number 202110953970.3 and filed on August 19, 2021, the entire contents of which are hereby incorporated by reference into this application. The present application relates to the technical field of communications, and in particular to a message transmission method, device and storage medium. [Background technology]

[0002] The emergence of new technologies such as slicing and in-situ flow information telemetry (iFIT) requires network devices to detect and process certain information hop-by-hop. Figure 1 shows a schematic diagram of slice transmission. Taking slices as an example, as shown in the figure, the message must carry slice ID (identifier) ​​information. This is because network nodes along the transmission path can match the corresponding link resources according to the slice ID information, and then combine it with the corresponding hard slicing technology to ultimately realize end-to-end network slicing functionality.

[0003] A drawback of the prior art is that slice and in situ flow detection techniques have no way of determining how relevant information is carried. Summary of the Invention [Problem to be solved by the invention]

[0004] The technical aspects of the embodiments of the present application provide a message transmission method, device, and storage medium to solve the problem that slice and in-situ flow detection technologies have no way to determine how to carry related information. [Means for solving the problem]

[0005] The present application is directed to receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; carrying in an extension header of said message a control plane forwarding identifier to indicate, for that message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; and transmitting the message.

[0006] In some embodiments, the message is an IPv6 message.

[0007] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0008] In some embodiments, Further comprising carrying the CheckSum in a message extension header.

[0009] In some embodiments, Further included is having the message extension header carry a CheckSumId to indicate the algorithm used in the CheckSum.

[0010] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0011] The present application is directed to receiving a message, the message having an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating whether the information carried in the message is to be processed in the control plane or the forwarding plane; and passing the IPv6 message to a control plane or a forwarding plane for processing according to a send-to-control-plane identifier.

[0012] In some embodiments, the message is an IPv6 message.

[0013] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0014] In some embodiments, Further comprising carrying the first CheckSum in a message extension header.

[0015] In some embodiments, The message extension header may further include carrying a CheckSumId to indicate the algorithm used in the CheckSum.

[0016] In some embodiments, The method further includes comparing a second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0017] In some embodiments, If the calculation content of the CheckSum includes a variable part, after updating the variable part, recalculating a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId, and updating the first CheckSum in the message with the third CheckSum.

[0018] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0019] The present application is directed to Read the program in memory receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; carrying in an extension header of said message a control plane forwarding identifier that indicates, for that message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; a processor for executing the steps of: A first network node is provided, the first network node including a transceiver for transmitting and receiving data under the control of a processor.

[0020] In some embodiments, the message is an IPv6 message.

[0021] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0022] In some embodiments, Further comprising carrying the CheckSum in a message extension header.

[0023] In some embodiments, Further included is having the message extension header carry a CheckSumId to indicate the algorithm used in the CheckSum.

[0024] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0025] The present application is directed to a first node receiving module for receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; a first node identification module for causing an extension header of said message to carry a control plane forwarding identifier, the identifier indicating for said message whether the information carried in the message is to be processed in the control plane or the forwarding plane; a first node transmitting module for transmitting the message.

[0026] In some embodiments, the message is an IPv6 message.

[0027] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0028] In some embodiments, the first node identification module is further used to carry a CheckSum in the message extension header.

[0029] In some embodiments, the first node identification module is further used to cause the message extension header to carry a CheckSumId to indicate the algorithm used in the CheckSum.

[0030] In some embodiments, the first node identification module is further used to update the CheckSum algorithm at preset times.

[0031] The present application is directed to Read the program in memory receiving a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating whether the information carried in the message is to be processed in the control plane or the forwarding plane; a processor for executing a procedure for passing the message to a control plane or a forwarding plane for processing depending on a send-to-control-plane identifier; A second network node is provided that includes a transceiver for transmitting and receiving data under the control of the processor.

[0032] In some embodiments, the message is an IPv6 message.

[0033] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0034] In some embodiments, Further comprising carrying the first CheckSum in a message extension header.

[0035] In some embodiments, The message extension header may further include carrying a CheckSumId to indicate the algorithm used in the CheckSum.

[0036] In some embodiments, The method further includes comparing a second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0037] In some embodiments, If the calculation content of the CheckSum includes a variable part, after updating the variable part, recalculating a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId, and updating the first CheckSum in the message with the third CheckSum.

[0038] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0039] The present application is directed to a second node receiving module for receiving a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating, for the message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; and a second node sending module for passing the message to a control plane or a forwarding plane for processing depending on the control plane send identifier.

[0040] In some embodiments, the message is an IPv6 message.

[0041] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0042] In some embodiments, the second node receiving module is further used to receive a message in which the first CheckSum is carried in a message extension header.

[0043] In some embodiments, the second node receiving module is further used to receive messages that carry a CheckSumId in the message extension header to indicate the algorithm used in the CheckSum.

[0044] In some embodiments, the second node receiving module is further used to compare the second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0045] In some embodiments, if the calculation content of the CheckSum includes a variable part, the second node receiving module is further used to recalculate a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId after updating the variable part, and update the first CheckSum in the message with the third CheckSum.

[0046] In some embodiments, the second node receiving module is further used to update the CheckSum algorithm at preset times.

[0047] An embodiment of the present application provides a computer-readable storage medium storing a computer program for executing the message sending method. [Effects of the Invention]

[0048] The beneficial effects of the present invention are as follows: In a technical aspect according to an embodiment of the present application, the extension header of a message carries a sending identifier to the control plane, which identifier indicates whether the information carried in the message is to be processed in the control plane or the forwarding plane, and all network nodes in the forwarding path must detect and process the information carried in the extension header and determine whether to process the information carried in the extension header in the control plane or the forwarding plane depending on the sending identifier to the control plane carried in the extension header.Therefore, in addition to supporting conventional hop-by-hop processing functions, it is also possible to support the ability to process message information hop-by-hop in the forwarding plane, which can further meet the needs of new technologies such as slicing and in-situ flow detection.

[0049] Furthermore, a CheckSum calculation method is proposed that verifies the integrity of a message and recognizes whether its contents have changed during transmission, while also verifying the authenticity of the message sender. The flexible and variable CheckSum calculation method satisfies the message integrity guarantees of the conventional CheckSum while also adding support for verifying the authenticity of the message sender. This effectively recognizes fraudulent messages forged by hackers and prevents tampering with the identifiers sent to the control plane and their use by hackers to launch attacks on network nodes. [Brief explanation of the drawings]

[0050] The drawings described herein are intended to provide a further understanding of the present application and constitute a part of the present application, and the illustrative embodiments and the description thereof are intended to serve as an aid in interpreting the present application and are not to be construed as undue limitations on the present application. [Figure 1] FIG. 1 is a schematic diagram of slice transfer in the background art. [Figure 2]FIG. 2 is a schematic diagram illustrating a flow of an implementation of a message sending method according to an embodiment of the present application. [Figure 3] FIG. 1 is a schematic diagram illustrating the implementation flow of a second message sending method according to an embodiment of the present application. [Figure 4] FIG. 1 is a schematic diagram of a bit transition procedure in a message transfer procedure in an embodiment of the present application. [Figure 5] 10 is a schematic diagram of a procedure for attacking a network device by sending a large number of messages with forged send identifiers to the control plane from a malicious network device in an embodiment of the present application. [Figure 6] FIG. 2 is a schematic diagram of a message format of a Hop-by-Hop Options Header in an embodiment of the present application. [Figure 7] FIG. 2 is a schematic diagram illustrating the flow of processing an IPv6 message in an embodiment of the present application. [Figure 8] FIG. 2 is a structural schematic diagram of a first network node in an embodiment of the present application; [Figure 9] FIG. 2 is a structural schematic diagram of a second network node in an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0051] The inventors have noticed the following during the invention. That is, information carried in the conventionally defined IPv6 (Internet Protocol Version 6) extension header Hop-by-Hop Options Header (Hop-by-Hop refers to the hop-by-hop routers through which a packet passes) must be detected and processed by all network nodes along the message forwarding path. When slice information and in-situ flow detection information are carried by the extension header, the nodes along the forwarding path will detect and process the carried information.

[0052] Since slicing and in-situ flow detection are new technologies and not yet mature, there is no clear way to carry the relevant information, but carrying it in the IPv6 Hop-by-Hop Options Header is one of the most likely conventional techniques to be used.

[0053] However, carrying slice and in-situ flow detection information in the Hop-by-Hop Options Header has at least one of the following technical problems. Currently, when a network node receives a Hop-by-Hop Options Header, it must send it to the control plane board for processing. If slice information is carried in a service message, the number of messages will be large, and sending all of them to the control plane for processing will place an excessive load on the control plane, making it difficult for the device to process and potentially causing device paralysis. In addition, service messages have transmission delay requirements. If all hop-by-hop nodes send the message to the main control board for processing, it will undoubtedly have a significant impact on the message transmission delay. Therefore, it is basically impossible to carry slice and in-situ flow detection information using the traditional Hop-by-Hop Options Header.

[0054] Regarding the current state of the Hop-by-Hop Options Header, the following is mentioned: That is, some nodes are configured to ignore the Hop-by-Hop Options Header extension header, Some nodes are configured to discard messages carrying the Hop-by-Hop Options Header, Some nodes are configured to rate limit messages carrying the Hop-by-Hop Options Header or process them in a slow queue.

[0055] Specifically, "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path."

[0056] In summary, the conventional Hop-by-Hop Options Header is not suitable for carrying slicing and in-situ flow detection information due to the above problems. For new technologies such as slicing and in-situ flow detection, it is highly desirable for the carried information to be detected and processed by nodes along the forwarding path. Furthermore, this information needs to be processed in the forwarding plane so as not to affect the forwarding latency of the message and not to increase the control plane overhead of the forwarding node.

[0057] Based on this, embodiments of the present application propose an improved aspect of extension headers for messages requiring hop-by-hop processing, which not only realizes traditional hop-by-hop processing functionality but also satisfies the need for hop-by-hop detection and processing of information in the forwarding plane for new technologies such as slicing and in-situ flow detection.

[0058] Specific embodiments of the present invention will be described below with reference to the drawings.

[0059] In the description, the implementation of each node will be described first, and then an example of an implementation in which they are combined will be given to better understand the implementation of the aspects described in the embodiments of the present application. This explanation does not mean that they must be combined or combined, or that they must be implemented independently. In fact, when they are implemented separately, each solves its own problems, but when they are used in combination, a higher technical effect can be obtained.

[0060] FIG. 2 is a schematic diagram of the implementation flow of the message transmission method 1. As shown in the figure, receiving 201 a message to be detected and processed by a hop-by-hop network node in a message forwarding path; a step 202 of causing an extension header of said message to carry a control plane forwarding identifier, the control plane forwarding identifier indicating, for that message, whether the information carried in the message is to be processed in the control plane or in the forwarding plane; and sending 203 the message.

[0061] FIG. 3 is a schematic diagram of the implementation flow of the message transmission method 2. As shown in the figure, receiving 301 a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating, for the message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; and step 302 of passing the message to the control plane or forwarding plane for processing depending on the send-to-control-plane identifier.

[0062] In some embodiments, the message is an IPv6 message.

[0063] In a specific implementation, the extension header of the message is an IPv6 message extension header, Hop-by-Hop Options Header.

[0064] In implementation, an IPv6 message and an extension header, Hop-by-Hop Options Header, can be taken as an example. IPv6 messages are widely applied and representative, and the Hop-by-Hop Options Header is taken as an example because it has the property of being detected and processed by all hop-by-hop network nodes in the message forwarding path. However, other messages and extension headers can be used as long as they satisfy the property of being detected and processed by hop-by-hop network nodes in the message forwarding path. The IPv6 message and extension header, Hop-by-Hop Options Header, are merely used to teach those skilled in the art how to specifically implement technical aspects according to the embodiments of the present application, and do not mean that the present invention is applicable only to IPv6 messages and extension headers. In implementation, corresponding messages and extension headers can be determined according to actual needs.

[0065] A specific embodiment may then be to receive an IPv6 message, cause an IPv6 message extension header, Hop-by-Hop Options Header, to carry a sending identifier to the control plane, the identifier indicating whether the information carried in the Hop-by-Hop Options Header for the message is to be processed in the control plane or the forwarding plane, and transmit the IPv6 message. The receiving side may receive an IPv6 message that is an IPv6 message and that carries a sending identifier to the control plane in its extension header Hop-by-Hop Options Header, where the sending identifier to the control plane is an identifier that indicates whether the information carried in the Hop-by-Hop Options Header for the message is to be processed in the control plane or the forwarding plane, and may pass the IPv6 message to the control plane or the forwarding plane for processing depending on the sending identifier to the control plane.

[0066] This aspect defines a new IPv6 extension header, Hop-by-Hop Options Header, which carries a control plane routing identifier to indicate whether the information carried in the Hop-by-Hop Options Header is processed in the control plane or the forwarding plane.

[0067] In some embodiments, the nodes receiving the message include: It may further include carrying the CheckSum in a message extension header.

[0068] Specifically, the CheckSum is carried in the IPv6 message extension header Hop-by-Hop Options Header.

[0069] Accordingly, the node receiving the message carries the first CheckSum in the IPv6 message extension header Hop-by-Hop Options Header.

[0070] Figure 4 is a schematic diagram of the bit transition procedure in the message transfer procedure. During the message transfer procedure, problems such as those shown in Figure 4 may occur. For example, when transferring a message from user H from router A to router B, a bit transition may occur for some reason, causing the send flag to the control plane to be erroneously set, and the message that should have been processed by the forwarding plane to be erroneously sent to the control plane. If a large number of such messages exist, excessive load may be placed on the control plane, causing router B, a network node, to crash.

[0071] Figure 5 is a schematic diagram of the procedure for attacking network devices by sending a large number of messages with forged send identifiers to the control plane from a malicious network device. If a hacker actively attacks a network node, problems such as those shown in Figure 5 may occur. For example, if a malicious AP_A sends a large number of forged messages carrying a pre-set send processing identifier to the control plane to router C, and router C receives these forged messages and sends all of them to the control plane for processing, router C will be paralyzed, which will affect legitimate message forwarding when normal user H accesses service S, causing a service failure.

[0072] Thus, carrying a CheckSum in the message avoids the two problems mentioned above: it verifies the integrity of the message and checks whether it has been altered during transmission, while also verifying the authenticity of the message sender.

[0073] Accordingly, in some embodiments, the nodes receiving the message include: The method may further include carrying a CheckSumId in the message extension header to indicate the algorithm used in the CheckSum.

[0074] Then, the node receiving the message carries a CheckSumId in the message extension header to indicate the algorithm used in CheckSum.

[0075] Specifically, the IPv6 message extension header Hop-by-Hop Options Header carries a CheckSumId for indicating the algorithm used in CheckSum.

[0076] Then, the node receiving the message carries a CheckSumId in the IPv6 message extension header Hop-by-Hop Options Header to indicate the algorithm used in CheckSum.

[0077] In concrete implementation, The method further includes comparing a second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0078] An example will be given below.

[0079] First, the implementation of the message format will be described.

[0080] Figure 6 is a schematic diagram of the Hop-by-Hop Options Header message format, which includes the following as shown in the figure: Next Header: The type of extension header that follows the Hop-by-Hop Options Header. Hdr Ext Len: The length of the extension header. Flag: An indicator of whether the message needs to be sent to the control plane for processing. For example, if set to 1, the message will be processed in the control plane, and if set to 0, the message will be processed in the forwarding plane. CheckSumId (checksum identifier): An index value for the CheckSum calculation method. CheckSum: The CheckSum is calculated according to the method indicated by CheckSumId. Options: Any number of options may be carried. The definition of an option can be found in at least Section 4.2 of [RFC8200] (RFC: Request For Comments, RFC is a series of memorandums issued by the Internet Engineering Task Force (IETF)).

[0081] The following describes the implementation of the CheckSum calculation.

[0082] The network device is configured in advance with a CheckSum calculation method corresponding to the CheckSumId, and this calculation method includes the CheckSum algorithm, the CheckSum calculation content, etc. For example, the CheckSum algorithm can be set to a parity check, LRC (Longitudinal Redundancy Check), etc. The CheckSum calculation content can be set to a calculation of the Hop-by-Hop Options Header portion excluding the variable portion, a calculation of the entire IPv6 message header excluding the variable portion, or a calculation of the Hop-by-Hop Options Header portion including the variable portion, etc.

[0083] In some embodiments, The method may further include updating the CheckSum algorithm at preset times.

[0084] Specifically, the network device supports configuring multiple CheckSumIds corresponding to multiple different CheckSum calculation methods, and the network device can periodically change the CheckSumId. Even if a hacker eavesdrops on a network message, they cannot know the algorithm corresponding to the CheckSumId or the calculation content of the CheckSum, making it difficult to forge a legitimate message. In addition, the network device periodically changes the CheckSumId, making it even more difficult for a hacker to decipher the content of the CheckSumId.

[0085] The implementation of message processing will now be described.

[0086] FIG. 7 is a schematic diagram showing an implementation flow of IPv6 message processing, which may include the following steps 1 to 6 as shown in the figure. 1. Node A receives a message from user H and encapsulates a Hop-by-Hop Options Header to carry hop-by-hop detection and processing information. If any of the information needs to be sent to the control plane for processing, the flag is set to 1; otherwise, it is set to 0. 2. Node A matches the corresponding CheckSumId for user H's message according to the locally configured CheckSum information, calculates the CheckSum according to the method indicated by the CheckSumId, and carries the CheckSumId and CheckSum information in the Hop-by-Hop Options Header. 3. Node B receives the message from user H forwarded by node A, obtains the local CheckSum calculation method according to the CheckSumId in the Hop-by-Hop Options Header, calculates the CheckSum' of the message, compares the CheckSum' with the CheckSum carried in the message, and If the two are the same, the message is considered to be a valid message and is processed in the control plane or forwarding plane as instructed by the flag; otherwise, the message is considered to be invalid and is processed according to administrator settings, such as by discarding the message. For example, if a malicious node D sends a forged message, it cannot calculate a legitimate CheckSum because it does not know how to calculate the CheckSum. After receiving the fraudulent message, node B calculates a CheckSum' that does not match the CheckSum carried in the message and discards the fraudulent message, thereby avoiding a hacker attack. 5. If the CheckSum calculation contains a variable part, Node B updates the variable part, then recalculates CheckSum2 according to the CheckSum calculation method indicated by CheckSumId, and updates CheckSum in the message with CheckSum2. That is, in some embodiments, If the calculation content of the CheckSum includes a variable part, after updating the variable part, the method may further include recalculating a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId, and updating the first CheckSum in the message with the third CheckSum. 6. After receiving the message from user H, node C processes the message in the same way as node B.

[0087] Based on the same inventive concept, the embodiments of the present application further provide a network node and a computer-readable storage medium, and since the principles of solving the problem of these devices are similar to those of the message transmission method, the implementation of these devices can refer to the implementation of the method, and the overlapping parts will not be repeated.

[0088] When implementing the technical aspects according to the embodiments of the present application, it is possible to implement them in the following forms.

[0089] FIG. 8 is a structural schematic diagram of a first network node. As shown in the figure, the node has: Read the program in memory 820, receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; carrying in an extension header of said message a control plane forwarding identifier that indicates, for that message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; a processor 800 for executing the steps of transmitting the message; and a transceiver 810 for transmitting and receiving data under the control of the processor 800.

[0090] In some embodiments, the message is an IPv6 message.

[0091] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0092] In some embodiments, Further comprising carrying the CheckSum in a message extension header.

[0093] In some embodiments, Further included is having the message extension header carry a CheckSumId to indicate the algorithm used in the CheckSum.

[0094] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0095] In FIG. 8, the bus architecture may include any number of interconnected buses and bridges, specifically connecting various circuits between one or more processors, such as processor 800, and memory, such as memory 820. The bus architecture may also connect various other circuits, such as peripherals, voltage regulators, and power management circuits, which are well known in the art and will not be further described herein. The bus interface provides an interface. The transceiver 810 may be multiple elements, i.e., may include a transmitter and a receiver, and provides a means for communicating with various other devices over a transmission medium. The processor 800 is responsible for managing the bus architecture and general processing, and the memory 820 can store data used by the processor 800 to perform operations.

[0096] The present application is directed to a first node receiving module for receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; a first node identification module for causing an extension header of said message to carry a control plane forwarding identifier, the identifier indicating for said message whether the information carried in the message is to be processed in the control plane or the forwarding plane; and a first node transmitting module for transmitting the message.

[0097] In some embodiments, the message is an IPv6 message.

[0098] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0099] In some embodiments, the first node identification module is further used to carry a CheckSum in the message extension header.

[0100] In some embodiments, the first node identification module is further used to cause the message extension header to carry a CheckSumId to indicate the algorithm used in the CheckSum.

[0101] In some embodiments, the first node identification module is further used to update the CheckSum algorithm at preset times.

[0102] For convenience of description, the above-described devices have been described by dividing them into various modules or units according to their functions. Of course, in implementing this application, the functions of each module or unit may be realized by the same or multiple pieces of software or hardware.

[0103] FIG. 9 is a structural diagram of a second network node. As shown in the figure, the node has: Read the program in memory 920, receiving a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating whether the information carried in the message is to be processed in the control plane or the forwarding plane; a processor 900 for executing a procedure for passing the message to a control plane or a forwarding plane for processing depending on a send-to-control-plane identifier; and a transceiver 910 for transmitting and receiving data under the control of the processor 900.

[0104] In some embodiments, the message is an IPv6 message.

[0105] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0106] In some embodiments, Further comprising carrying the first CheckSum in a message extension header.

[0107] In some embodiments, The message extension header may further include carrying a CheckSumId to indicate the algorithm used in the CheckSum.

[0108] In some embodiments, The method further includes comparing a second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0109] In some embodiments, If the calculation content of the CheckSum includes a variable part, after updating the variable part, recalculating a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId, and updating the first CheckSum in the message with the third CheckSum.

[0110] In some embodiments, The method further includes updating the CheckSum algorithm at a preset time.

[0111] In FIG. 9, the bus architecture may include any number of interconnected buses and bridges, specifically connecting various circuits between one or more processors, such as processor 900, and memory, such as memory 920. The bus architecture may also connect various other circuits, such as peripherals, voltage regulators, and power management circuits, which are well known in the art and will not be further described herein. The bus interface provides an interface. The transceiver 910 may be multiple elements, i.e., may include a transmitter and a receiver, and provides a means for communicating with various other devices over a transmission medium. The processor 900 is responsible for managing the bus architecture and general processing, and the memory 920 can store data used by the processor 900 to perform operations.

[0112] The present application is directed to a second node receiving module for receiving a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating, for the message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; A second network node is further provided, the second network node including a second node sending module for passing the message to a control plane or a forwarding plane for processing depending on the control plane send identifier.

[0113] In some embodiments, the message is an IPv6 message.

[0114] In some embodiments, the message extension header is an IPv6 message extension header, Hop-by-Hop Options Header.

[0115] In some embodiments, the second node receiving module is further used to receive a message in which the first CheckSum is carried in a message extension header.

[0116] In some embodiments, the second node receiving module is further used to receive messages that carry a CheckSumId in the message extension header to indicate the algorithm used in the CheckSum.

[0117] In some embodiments, the second node receiving module is further used to compare the second CheckSum calculated according to the algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

[0118] In some embodiments, if the calculation content of the CheckSum includes a variable part, the second node receiving module is further used to recalculate a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId after updating the variable part, and update the first CheckSum in the message with the third CheckSum.

[0119] In some embodiments, the second node receiving module is further used to update the CheckSum algorithm at preset times.

[0120] For convenience of description, the above-described devices have been described by dividing them into various modules or units according to their functions. Of course, in implementing this application, the functions of each module or unit may be realized by the same or multiple pieces of software or hardware.

[0121] An embodiment of the present application further provides a computer-readable storage medium storing a computer program for executing the message sending method.

[0122] For specific implementation, please refer to the implementation of the message transmission method on each node.

[0123] To summarize the above, in the technical aspect according to the embodiment of the present application, a new message extension header is proposed, and any network node in the forwarding path must detect and process the information carried in the extension header, and determine whether the information carried in the extension header should be processed in the control plane or the forwarding plane according to the send identifier to the control plane carried in the extension header.

[0124] Compared to the Hop-by-Hop Options Header in the prior art, in addition to supporting the traditional Hop-by-Hop Options Header function, a new capability is added to support hop-by-hop processing of message information in the forwarding plane, which can better meet the needs of new technologies such as slicing and in-situ flow detection. The traditional Hop-by-Hop Options Header cannot meet the needs of new technologies such as slicing and in-situ flow detection.

[0125] Furthermore, a CheckSum calculation method is proposed to verify the integrity of the message and recognize whether the content has changed during the transmission procedure, while also verifying the authenticity of the message sender's identity. By periodically changing the CheckSumId, attacks by hackers become more difficult.

[0126] The flexible and variable CheckSum calculation method satisfies the message integrity guarantees of the traditional CheckSum while also adding support for verifying the authenticity of the message sender's identity. It can effectively recognize fraudulent messages forged by hackers. The proposed CheckSum calculation method can effectively prevent identifiers sent to the control plane from being tampered with or used by hackers to launch attacks on network nodes.

[0127] Those skilled in the art will appreciate that the present application may be provided as a method, a system, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product embodied in one or more computer-usable storage media (including, but not limited to, magnetic disk memory, optical memory, etc.) containing computer-usable program code.

[0128] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to form a machine, and the instructions executed by the processor of the computer or other programmable data processing device form an apparatus for implementing the functions specified in one or more flows in the flowcharts and / or one or more blocks in the block diagrams.

[0129] These computer program instructions may be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, with the instructions stored in the computer-readable memory forming an article of manufacture that includes an instruction apparatus that implements the functions specified in one or more flows of the flowcharts and / or one or more blocks of the block diagrams.

[0130] These computer program instructions may be loaded into a computer or other programmable data processing device and cause the computer or other programmable data processing device to perform a series of operational steps to form a computer-implemented process, the instructions executing on the computer or other programmable data processing device providing steps for implementing the functions specified in one or more flows of the flowcharts and / or one or more blocks of the block diagrams.

[0131] Obviously, those skilled in the art can make various modifications and variations to the present application without departing from the spirit and scope of the present application. Therefore, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application also includes these modifications and variations.

Claims

1. receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; carrying in an extension header of said message a control plane forwarding identifier to indicate, for that message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; sending the message; further comprising carrying a checksum in the message extension header; The method of sending a message further comprising having the message extension header carry a CheckSumId for indicating an algorithm used in a CheckSum.

2. The method of claim 1 , wherein the message is an Internet Protocol version 6 (IPv6) message.

3. 3. The method of claim 2, wherein the message extension header is an IPv6 message extension header Hop-by-Hop Options Header.

4. The method of claim 1 , further comprising updating the CheckSum algorithm at preset times.

5. receiving a message, the message having an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating whether the information carried in the message is to be processed in the control plane or the forwarding plane; and passing the message to a control plane or a forwarding plane for processing depending on a send-to-control-plane identifier; carrying the first CheckSum in a message extension header; The method of receiving a message further comprises carrying a CheckSumId in the message extension header to indicate an algorithm used in CheckSum.

6. The method of claim 5 , wherein the message is an IPv6 message.

7. 7. The method of claim 6, wherein the message extension header is an IPv6 message extension header Hop-by-Hop Options Header.

8. 6. The method of claim 5, further comprising: comparing a second CheckSum calculated according to an algorithm indicated by the CheckSumId with the first CheckSum carried in the message to determine whether the message is a valid message.

9. 9. The method of claim 8, further comprising: if the calculation content of the CheckSum includes a variable portion, after updating the variable portion, recalculating a third CheckSum according to the CheckSum calculation method indicated by the CheckSumId, and updating the first CheckSum in the message with the third CheckSum.

10. a first node receiving module for receiving a message to be detected and processed by a hop-by-hop network node in a message forwarding path; a first node identification module for causing an extension header of said message to carry a control plane forwarding identifier, the identifier indicating for said message whether the information carried in the message is to be processed in the control plane or the forwarding plane; a first node transmitting module for transmitting the message; A checksum is carried in the message extension header. The message extension header carries a CheckSumId to indicate the algorithm used in the CheckSum. First network node.

11. a second node receiving module for receiving a message, the message carrying an extension header carrying a send-to-control-plane identifier, the send-to-control-plane identifier being an identifier for indicating, for the message, whether the information carried in the message is to be processed in the control plane or the forwarding plane; a second node processing module for passing the message to a control plane or a forwarding plane for processing in response to a control plane send identifier; The first CheckSum is carried in the message extension header, A second network node, wherein the message extension header carries a CheckSumId for indicating the algorithm used in the CheckSum.

Images