Packet processing method, device and system

Abstract

The application provides a message processing method, device and system, and belongs to the technical field of communication. In the scheme provided in the application, the head-end network device further includes an operation indication in the SRH encapsulated in the service message. The operation indication can indicate that the target network device performs a target operation when the SRH needs to be popped out or the additional operation indicated by the additional information in the SRH is not supported. Compared with the target network device directly popping out the SRH or directly ignoring the additional information, the scheme provided in the application indicates the target operation required to be performed by the target network device through the head-end network device, effectively enriches the processing mode of the service message, and improves the flexibility of message processing.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message processing method, apparatus and system. Background Technology

[0002] SRv6 is a segment routing forwarding technology based on Internet Protocol version 6 (IPv6). SRv6's forwarding plane uses the segment routing header (SRH) defined in the IPv6 protocol to forward service packets.

[0003] The SRH includes a segment list and an optional type-length-value (TLV) field. The segment list carries the segment identification (SID) of each node (i.e., network device) in the packet forwarding path. The optional TLV field carries global parameters (also known as irregular additional information), which can be used to instruct nodes in the packet forwarding path to perform specific operations. For example, if the optional TLV field carries in-situ flow information telemetry (iFIT) information, each node in the packet forwarding path can use this iFIT information to detect parameters such as packet loss rate and latency of service packets.

[0004] If a node in the message forwarding path does not support the specific operation indicated by the additional information, that node can ignore the additional information. This results in a relatively simplistic and inflexible approach to processing service messages. Summary of the Invention

[0005] This application provides a message processing method, apparatus, and system that can solve the technical problem of relatively simple and inflexible processing methods for business messages.

[0006] On the one hand, a message processing method is provided, applied to a headend network device. The method includes: encapsulating a first segmented routing header (SRH) in a service message, the first SRH including a segmented list, additional information, and an operation instruction; and forwarding the service message based on the segmented list. The operation instruction is used to instruct the target network device to perform a target operation when the first SRH needs to be popped or when the additional operation indicated by the additional information is not supported. The target network device is a network device in the forwarding path identified by the segmented list.

[0007] Compared to the target network device directly displaying an SRH or ignoring additional information, the method provided in this application allows the head-end network device to instruct the target network device on the target operation to be performed, thereby effectively enriching the processing methods for service packets and improving the flexibility of packet processing.

[0008] Optionally, the target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

[0009] Since the target network device can retain the additional information in the first SRH when it needs to pop up the first SRH, it can ensure that the tail network device in the forwarding path can also obtain the additional information and then perform the additional operations indicated by the additional information.

[0010] Optionally, if the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

[0011] If the network device receiving the service message supports the additional operation indicated by the additional information, it can execute the additional operation and feed back the execution result to the headend network device. Thus, the headend network device can accurately determine the support status of each network device in the forwarding path for the additional operation based on the error response sent by the target network device and / or the execution results sent by the network devices in the forwarding path.

[0012] Optionally, the target operation includes: adding the additional information to the second SRH of the service message before popping the first SRH from the service message; wherein the forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

[0013] By adding the additional information from the first SRH to the second SRH, it can be ensured that network devices located after the sub-paths identified by the segment list in the first SRH in the forwarding path identified by the segment list in the second SRH can also obtain the additional information from the first SRH, and thus perform the additional operations indicated by the additional information.

[0014] Optionally, the first SRH also includes a variable-length field for carrying the additional information and the operation instruction. For example, the type field in the variable-length field can be used to carry the operation instruction, and the variable-length data field in the variable-length field can be used to carry the additional information.

[0015] Since the first SRH can include multiple variable-length fields, the operation instructions carried by these variable-length fields can ensure that the additional information in each variable-length field can be precisely controlled by the corresponding operation instructions, thereby further improving the flexibility of message processing.

[0016] On the other hand, a message processing method is provided, applied to a target network device, the method comprising:

[0017] A service message is received, which encapsulates a first SRH. The first SRH includes a segment list, additional information, and an operation instruction. The target network device is the network device in the forwarding path identified by the segment list. When the first SRH needs to be popped up, or when the additional operation indicated by the additional information is not supported, the target operation is performed based on the operation instruction.

[0018] Optionally, the target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

[0019] Optionally, if the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

[0020] Optionally, the target operation includes: adding the additional information to the second SRH of the service message before popping the first SRH from the service message; wherein the forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

[0021] The technical effects of the packet processing methods applied to the target network device provided above can be found in the relevant descriptions of the packet processing methods applied to the headend network device, which will not be repeated here.

[0022] In another aspect, a message processing apparatus is provided, which can be applied to a headend network device, and the apparatus includes at least one module that can be used to implement the message processing method for a headend network device provided in the above aspects.

[0023] In another aspect, a message processing apparatus is provided, which can be applied to a target network device, and the apparatus includes at least one module that can be used to implement the message processing method for the target network device provided in the above aspects.

[0024] In another aspect, a network device is provided, which may include: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the message processing method provided in any of the preceding aspects.

[0025] In another aspect, a computer-readable storage medium is provided, wherein instructions are stored therein, which are executed by a processor to implement the message processing method provided in any of the preceding aspects.

[0026] In another aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the message processing method provided in any of the above aspects.

[0027] In another aspect, a communication system is provided, which may include: a first network device and a second network device; wherein the first network device includes the means provided above for use in a headend network device, and the second network device includes the means provided above for use in a target network device.

[0028] In summary, this application provides a message processing method, device, and system. In the solution provided by this application, the SRH encapsulated in the service message by the headend network device also includes an operation instruction. This operation instruction can instruct the target network device to perform a target operation when it needs to display an SRH or does not support the additional operation indicated by the additional information in the SRH. Compared to the target network device directly displaying an SRH or directly ignoring the additional information, the solution provided by this application, by instructing the target network device to perform the target operation, effectively enriches the processing methods for service messages and improves the flexibility of message processing. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the structure of a communication system provided in an embodiment of this application;

[0030] Figure 2 This is a schematic diagram of the structure of an IPv6 packet provided in an embodiment of this application;

[0031] Figure 3 This is a flowchart of a message processing method provided in an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of a service message processing flow provided in an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of another service message processing flow provided in an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of another service message processing flow provided in the embodiments of this application;

[0035] Figure 7 This is a schematic diagram of the structure of an optional TLV in an SRH provided in an embodiment of this application;

[0036] Figure 8 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of another message processing device provided in an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. Detailed Implementation

[0039] The message processing method, apparatus, and system provided in the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0040] Figure 1 This is a schematic diagram of the structure of a communication system provided in an embodiment of this application, such as... Figure 1 As shown, the communication system may include multiple network devices 01, and communication connections are established between these multiple network devices 01. Each network device 01 may be a device with packet forwarding capabilities, such as a router or switch.

[0041] In this embodiment of the application, the communication system can be a system that supports SRv6 technology. For a headend network device of a certain end-to-end (E2E) path, it can encapsulate SRH in the IPv6 packet to be sent. Figure 2 This is a schematic diagram of the structure of an IPv6 packet provided in an embodiment of this application, as shown below. Figure 2 As shown, this IPv6 packet may include: an IPv6 header, an SRH (Streaming Host Name), and a payload. The IPv6 header includes the following fields: version, traffic class, flow label, payload length, next header, hop limit, source address (SA), and destination address (DA).

[0042] The SRH includes the following fields: next header, header extension length (Hdr ExtLen), routing type, segment left (SL), last entry, flags, tag, segment list [0] to segment list [n], and optional TLV. n can be an integer greater than or equal to 1.

[0043] In this embodiment, the value of the next header field in the IPv6 header can be 43, indicating that the IPv6 packet contains a routing header. Furthermore, the value of the routing type field in the SRH can be 4, indicating that the routing header is an SRH. The definitions of the main fields in the SRH are as follows:

[0044] When the next header field has a value of 4, it indicates that the payload is IPv4; when it has a value of 41, it indicates that the payload is IPv6; when it has a value of 143, it indicates that the payload is L2 payload; when it has a value of 43, it indicates that the inner header is SRH; and when it has other values, it indicates other IPv6 extension headers.

[0045] The SL field is used to indicate the number of intermediate nodes that need to be visited before reaching the destination node.

[0046] Segment lists [0] to [n] form a segment list, where each segment list in [0] to [n] can be 128 bits long and can be used to carry the SID of a node or link. For example, the SID can be an IPv6 address.

[0047] Optional TLV fields can be used to carry global parameters (i.e., additional information). For example, the optional TLV field defined in Request for Comments (RFC) document number 8754 can be used to carry a hash-based message authentication code (HMAC) and padding bytes. In addition to HMAC and padding bytes, this optional TLV field can also carry network functions virtualization (NFV) metadata, ingress node identifiers, egress node identifiers, network service headers (NSH), iFIT information, and application-aware IPv6 networking (APN6) information.

[0048] SRv6 technology defines three mechanisms for SRH (Penultimate Segment Pop), SRH for Ultimate Segment Pop (Ultimate Segment Pop, USP), and SRH for Ultimate Segment Decapsulation (USD). PSP means that the penultimate hop node in the forwarding path identified by the segment list pops the SRH from the service packet and forwards it to the last hop node. USP means that the last hop node in the forwarding path pops the SRH. USD means that the last hop node in the forwarding path removes the entire IPv6 header (including any extended headers such as the SRH).

[0049] In the first possible scenario, for a system employing the PSP mechanism, after the penultimate hop node in the forwarding path identified by the segment list receives a service packet, if that penultimate hop node does not support the specific operation indicated by the additional information in the SRH, it will pop all SRHs from the service packet. If the service packet contains only one SRH, the service packet after popping the SRH will only contain the remaining parts of the IPv6 header and the payload. This will prevent the tail node (i.e., the destination node) in the forwarding path from obtaining the additional information carried by the optional TLV field in the SRH, and thus from executing the specific operation indicated by that additional information. For example, if the additional information includes iFIT information, the tail node in the forwarding path will not be able to obtain that iFIT information, and therefore will not be able to detect parameters such as packet loss rate and latency of the service packet.

[0050] In the second possible scenario, the specific operation indicated by this additional information could be a probe operation on the forwarding path. If the nodes in the forwarding path identified by the segment list do not support the probe operation and do not respond or process it, the head node of the forwarding path will not be able to accurately know the capabilities of the forwarding path.

[0051] For the problems existing in the first possible scenario mentioned above, the relevant technologies provide the following solutions:

[0052] Solution 1: The system controller provides two modes: "SID routing using PSP flavor" and "SID routing using non-PSP flavor". If there are nodes in the network that do not support the specific operation indicated by this additional information, the operations and maintenance personnel can select the "SID routing using non-PSP flavor" mode on the controller. However, this solution will cause the entire network to change its routing mode, affecting the tunnels of the entire network. If there are tail nodes with poor capabilities that cannot process SRH (i.e., do not have the ability to parse the segment list in the SRH), it will affect the normal processing of service packets. Furthermore, since the PSP mechanism can improve the processing efficiency of service packets, if the proportion of nodes that do not support this specific operation and are the penultimate hop in the forwarding path is small, it will have a significant impact on the processing efficiency of service packets.

[0053] Solution 2: The controller obtains the support status of each node in the network for a specific operation and selects different SID modes based on the node's capabilities. Specifically, nodes report their support status for a specific operation to the controller. When calculating routes, the controller determines which SID mode to use to form the final forwarding path based on whether the penultimate hop node in the forwarding path supports the specific operation. If the penultimate hop node supports the specific operation, its SID is a PSP flavor SID; if it does not support the specific operation, its SID is a non-PSP flavor SID. However, this solution requires nodes to actively report their support status for specific operations, and the controller's route calculation is strongly coupled with the service, which is not conducive to scalability.

[0054] Solution 3: The controller uses "using non-PSP flavor SID for routing" as a constraint condition for routing, adding this constraint to specific tunnels. Specifically, the controller supports setting routing constraints for specific tunnels, where the constraint is either "using PSP flavor SID for routing" or "using non-PSP flavor SID for routing." However, this solution requires users to configure the routing constraints for each tunnel, leading to complex configuration. Furthermore, since users typically cannot accurately predict whether the penultimate hop node supports a specific operation, for some tunnels, only "using non-PSP flavor SID for routing" may be possible as the routing constraint condition. Additionally, some tunnels may not enable the specific operation indicated by the additional information in the optional TLV field when the service is created, but to accommodate future needs, it is necessary to configure "using non-PSP flavor SID for routing" as the routing constraint condition in advance, which may result in unnecessary constraints being added even when the specific operation is not enabled.

[0055] Solution 4: The controller recalculates routes for specific business scenarios. Specifically, the controller first calculates routes using the default "SID routing with PSP flavor" mode. If a service needs to initiate a specific operation, the controller checks whether the penultimate hop node of the service's forwarding path supports that specific operation. If it doesn't support the specific operation, the controller reissues a new forwarding path using the "SID routing with non-PSP flavor" mode to switch the service to this new path. However, this solution is complex, requiring tunnel switching and the controller needing to be aware of the penultimate hop node's support for specific operations. It is tightly coupled with the service and not conducive to scalability.

[0056] It is understood that, in the embodiments of this application, nodes in the packet forwarding path can also be referred to as network devices. For example, the head node (or source node) can be referred to as the head-end network device, and the tail node can be referred to as the tail-end network device.

[0057] This application provides a message processing method, which can be applied to, for example... Figure 1 The system shown can be further improved by this method, which can enrich the processing methods for service messages. For example, the message processing method provided in this application can solve the problem that the tail node cannot obtain the additional information in the optional TLV due to the second-to-last hop node popping an SRH. (See reference...) Figure 3 The method includes:

[0058] Step 101: The headend network device encapsulates a first SRH in the service message. The first SRH includes a segment list, additional information, and operation instructions.

[0059] This segment list identifies the forwarding path of the service packet. For example, the segment list may include the SIDs of various network devices along the forwarding path, where each network device's SID can be its IP address. Following the segment list in the first SRH is an optional TLV, which carries the additional information indicating any additional operations required by the target network device. The target network device is the network device along the forwarding path identified by the segment list.

[0060] The operation instruction in the first SRH can be used to instruct the target network device on the target operation to be performed when the first SRH needs to be popped up, or when the additional operation indicated by the additional information is not supported. For example, the target operation could be to retain the additional information when the first SRH is popped up.

[0061] Step 102: The headend network device forwards the service packet based on the segment list.

[0062] Since this segment list can identify the forwarding path of a service packet, the headend network device can forward the service packet based on this segment list.

[0063] Step 103: When the target network device needs to display the first SRH or does not support the additional operation indicated by the additional information, it performs the target operation based on the operation instruction.

[0064] In this embodiment of the application, after the target network device receives a service packet from the headend network device, if it needs to remove the first SRH from the service packet, or if the target network device does not support the additional operation indicated by the additional information, the target network device can perform the target operation based on the operation indication in the first SRH.

[0065] For example, if the target network device is the penultimate hop network device in the forwarding path identified by the segment list, then upon receiving the service packet, the target network device can determine that the first SRH needs to be removed from the service packet. Accordingly, when removing the first SRH, the target network device can execute the target operation indicated by the operation instruction. For example, the target operation could be to retain the additional information in the first SRH. This ensures that the tail network device in the forwarding path can also obtain the additional information and execute the additional operation indicated by the additional information.

[0066] In summary, this application provides a message processing method. The SRH encapsulated in the service message by the headend network device also includes an operation instruction. This operation instruction can instruct the target network device in the forwarding path to perform a target operation when it needs to pop up the SRH or does not support the additional operation indicated by the additional information in the SRH. Compared to the target network device directly popping up the SRH or directly ignoring the additional information, the method provided by this application, by instructing the target network device to perform the target operation, effectively enriches the processing methods for service messages and improves the flexibility of message processing.

[0067] As an optional implementation, in scenarios where the communication system employs the PSP mechanism, the target network device can be the penultimate hop network device in the forwarding path. Accordingly, the target operation can include: retaining the additional information when the first SRH needs to be popped. Since the target network device can retain the additional information in the first SRH when it needs to be popped, it can ensure that the tail-end network device in the forwarding path can also obtain the additional information, and thus execute the additional operation indicated by the additional information.

[0068] In this application embodiment, the execution method of the target network device when performing the target operation may include: retaining only the additional information in the first SRH and popping out all other information in the first SRH; or, popping out only the segment list in the first SRH and retaining the basic information and the additional information in the first SRH; or, directly retaining the first SRH, that is, not popping out the first SRH.

[0069] The operation instruction in the first SRH can also specify the specific execution method of the target operation. Alternatively, the specific execution method of the target operation can be pre-configured in the target network device. For example, maintenance personnel can directly configure the execution method of the target operation in the target network device via command line. Alternatively, the controller connected to the target network device can issue configuration commands to the target network device to indicate the execution method of the target operation.

[0070] Example, reference Figure 4Suppose the forwarding path of a certain service flow in a communication system is: network device R1 → network device R2 → network device R3 → network device R4. The SID of network device R1 is A:1::1, the SID of network device R2 is B:2::1, the SID of network device R3 is B:3::1, and the SID of network device R4 is B:4::D401. Then, network device R1, as the headend network device, can encapsulate an SRH in the service packet. This SRH includes a segment list, an optional TLV field, and an operation instruction. The segment list records the SIDs of network devices R2 to R4. If this service flow needs to implement iFIT functionality, then... Figure 4 As shown, the additional information carried in this optional TLV field can be iFIT information.

[0071] In the service packet forwarded by network device R1 to network device R2, the SL in the SRH is 2, and the DA in the IPv6 header is the SID of network device R2: B:2::1. After receiving this service packet, network device R2 can update the DA in the IPv6 header to the SID of network device R3: B:3::1 based on the segmentation list in the SRH, and can also update the SL to 1. After receiving the service packet, network device R3 can update the DA in the IPv6 header to the SID of network device R4: B:4::D401 based on the segmentation list in the SRH, and can also update the SL to 0. Since the updated SL = 0, network device R3 can determine that it is the penultimate hop network device in the forwarding path of the service packet, and can remove the SRH from the service packet. Furthermore, since the SRH also includes an operation instruction, network device R3 can retain the iFIT information in the SRH when removing it, based on this operation instruction. For example, refer to... Figure 4 The network device can simply pop up the segment list in the SRH and retain the SRH basic information and the iFIT information in the SRH.

[0072] It is understandable that, in the above implementation, the target network device can retain the additional information based on the operation instruction when it needs to display the first SRH and does not support the additional operation indicated by the additional information. If the target network device supports the additional operation, it can directly retain the additional information when it needs to display the first SRH without the instruction of the operation instruction. That is, if the target network device supports the additional operation, it can retain the additional information when displaying the first SRH even if the first SRH does not carry the operation instruction.

[0073] As an alternative implementation, if the target network device does not support the additional operation indicated by the additional information in the first SRH, the target operation may include at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

[0074] For example, if the target network device does not support this additional operation, it can directly discard the service packet without sending an error response to the headend network device. Alternatively, the target network device can discard the service packet and send an error response to the headend network device. Or, the target network device can ignore the additional information (i.e., the target network device does not discard the service packet and continues to forward it based on the segment list) and send an error response to the headend network device. Still another option is to ignore the additional information and not send an error response to the headend network device. The error response may include an error code, the content of which can be defined according to service requirements.

[0075] In this implementation, the additional operation can be used to probe the tunnel path (i.e., the forwarding path). For example, if a certain probing service needs to probe the tunnel path during the forwarding of a service packet to understand the tunnel path's support capability for a certain service, this additional information can be carried in the optional TLV field of the service packet. If the network device receiving the service packet supports the additional operation indicated by the additional information, it can execute the additional operation and feed back the execution result of the additional operation to the headend network device.

[0076] In this embodiment, since the target network device can ignore the additional information, discard the service packet, and / or send an error response to the headend network device based on the operation instruction when it does not support the additional operation, the headend network device can accurately determine the support status of each network device in the forwarding path for the additional operation based on the error response sent by the target network device and / or the execution results sent by the network devices in the forwarding path, and thus determine the support capability of the forwarding path for the service.

[0077] Example, reference Figure 5 Assuming the service packet to be forwarded is a probe packet, the optional TLV field of the SRH encapsulated in the service packet by the headend network device R1 can carry probe information. If network device R3 does not support the probe operation indicated by this probe information, then network device R3 can send an error response to the headend network device R1 based on the operation indication carried in the SRH. Furthermore, since network device R3 is the penultimate hop network device in the forwarding path, therefore... Figure 5As shown, network device R3 can also pop the SRH from the service packet and forward the service packet after popping the SRH to the tail network device R4.

[0078] As another optional implementation, the target operation may include: adding the additional information to the second SRH of the service message before popping the first SRH from the service message. Here, the forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

[0079] In this embodiment, if the end-to-end path used to carry the service flow is too long, or if the network provides an encapsulated tunnel, the original tunnel may be compressed or encapsulated using a binding-SID (BSID). In this implementation, the service packet may be encapsulated with multiple layers of SRHs. These multiple SRHs may include a first SRH and a second SRH, and the forwarding path identified by the segment list in the first SRH can be a sub-path of the forwarding path identified by the segment list in the second SRH. Correspondingly, the second SRH can also be called the original SRH. Furthermore, the multiple SRHs may include multiple first SRHs, and these multiple first SRHs may use different BSID identifiers.

[0080] Specifically, the last network device or the penultimate network device in the forwarding path identified by the segment list in the first SRH can first add the additional information from the first SRH to the second SRH, and then pop the first SRH. This ensures that other network devices in the forwarding path identified by the segment list in the second SRH, located after the sub-path identified by the segment list in the first SRH, can also obtain the additional information in the first SRH and execute the additional operations indicated by the additional information.

[0081] For example, in this implementation, the additional information can be hop count statistics, and the additional operation can be a packet forwarding hop count statistics operation. Accordingly, by adding the additional information from the first SRH to the second SRH, the target network device can ensure that other network devices after the subpath identified by the segment list in the first SRH can continue to count the packet forwarding hops.

[0082] It is understandable that if the second SRH does not include additional information, the target network device can add an optional TLV field to the second SRH to carry the additional information from the first SRH. If the second SRH already includes additional information, the target network device can replace the additional information in the second SRH with the additional information from the first SRH, that is, overwrite the additional information in the second SRH.

[0083] Example, reference Figure 6 Suppose the forwarding path of a certain service flow is: network device R1 → network device R2 → network device R3 → network device R4 → network device R5 → network device R6. Furthermore, this forwarding path can be divided into a first sub-path and a second sub-path, where the first sub-path is: network device R1 → network device R2 → network device R3, and the second sub-path is: network device R4 → network device R5 → network device R6. Then... Figure 6 As shown, the headend network device R1 can encapsulate a first SRH and a second SRH in the service packet. The first SRH is identified by BSID1 and is therefore also called BSID1 SRH. The segment list 1 in the second SRH can identify the forwarding path R1 to R6, for example, refer to... Figure 6 The segment list 1 may include: BSID1, BSID2, and the SID of network device R6: B:6::D401. Segment list 1-1 in the BSID1 SRH can identify the first subpath. Furthermore, the BSID1 SRH also includes an optional TLV1 for carrying additional information.

[0084] Before popping the BSID1 SRH, the tail-end network device R3 of the first sub-path can add the optional TLV1 from the BSID1 SRH to the second SRH. For example, the optional TLV1 can be used to override the optional TLV in the second SRH. Then, the tail-end network device R3 pops the BSID1 SRH and forwards the service packet containing the popped BSID1 SRH to network device R4. Network device R4, as the head-end network device of the second sub-path, can encapsulate the first SRH identified by BSID2 in the service packet; this can also be called the BSID2 SRH. Figure 6 As shown, the BSID2 SRH includes segment lists 1-2 and optional TLV2, where segment lists 1-2 can identify a second subpath.

[0085] Before popping the BSID2 SRH, the penultimate hop network device R5 can add the optional TLV2 from the BSID2 SRH to the second SRH. For example, the optional TLV2 can override the optional TLV1 in the second SRH. Then, network device R5 pops the BSID2 SRH from the service packet and forwards the service packet with the popped BSID2 SRH to network device R6.

[0086] It is understandable that if a sub-path uses the USP mechanism, and the tail network device of the sub-path is the tail network device in the forwarding path identified by the segment list in the second SRH, then since the tail network device still needs to pop the second SRH, the tail network device can directly pop the first SRH and the second SRH without having to add the additional information in the first SRH to the second SRH.

[0087] For example, combining Figure 6 Network device R6, as the tail network device of the forwarding path identified by segment list 1, can directly pop the BSID2 SRH and the second SRH if the service packet it receives also includes BSID2 SRH, without having to add the optional TLV2 to the second SRH. Furthermore, before popping the two SRHs, network device R6 needs to process the additional information in the optional TLV of each SRH, which will not be elaborated in this embodiment.

[0088] It is also understandable that the several optional implementation methods provided above can be combined as needed. For example, suppose the target network device is the penultimate hop network device in the forwarding path, and the target network device does not support the additional operation indicated by the additional information. Then the target network device can not only retain the additional information when popping the first SRH, but also send an error response to the headend network device (or it can choose not to send an error response).

[0089] Alternatively, suppose the target network device is the tail end of a sub-path in the forwarding path, and the target network device does not support the additional operation indicated by the additional information. Then, the target network device can not only add the additional information to the second SRH before popping the first SRH, but also send an error response to the head end network device (or it can choose not to send an error response).

[0090] Optionally, the first SRH may also include a variable-length field, i.e., an optional TLV field, and the variable-length field may carry the additional information and the operation instruction. Figure 7 This is a schematic diagram of the structure of a variable-length field in an SRH provided in an embodiment of this application, such as... Figure 7 As shown, the variable-length field may include: a type field, a length field, and a variable-length data field.

[0091] The optional TLV fields defined in RFC 8754 can carry optional information, namely the additional information described in the embodiments of this application. This additional information can at least be used by the network device indicated by the DA in the service message. Furthermore, each SRH can encode multiple optional TLVs, each with its own length, format, and semantics. The definitions of each field in the optional TLV fields in RFC 8754 are as follows:

[0092] Type field: An 8-bit code point used to define the format and semantics of additional information. The highest bit (bit 0) of this type field indicates whether the additional information carried in the TLV field can be changed during the transmission of the service message to the destination network device. If the highest bit of this type field is 0, it means that the additional information carried in the TLV field will not change during the forwarding of the service message. If the highest bit of this type field is 1, it means that the additional information carried in the TLV field will change during the forwarding of the service message.

[0093] The length field, which is 8 bits long, is used to indicate the length (in bytes) of this variable-length data field.

[0094] A variable-length data field, whose length can vary, is used to carry this additional information.

[0095] In this embodiment, the operation instruction can be carried in the type field of an optional TLV field. Since the first SRH may include multiple optional TLV fields, carrying the operation instruction in the type field ensures that the additional information in each optional TLV field can be precisely controlled through the operation instruction in the same optional TLV field, thereby effectively improving the flexibility of message processing.

[0096] Optionally, since the value of the highest bit in this type field has been defined, in this embodiment, the second and third highest bits (i.e., the first and second bits) of this type field can be used to carry the operation indication. Furthermore, since the operation indication carried by the second and third highest bits has four selectable values: 00, 01, 10, and 11, four different target operations can be indicated by the four different values ​​of the operation indication.

[0097] For example, when the operation instruction is set to the first value (e.g., 00), it can be used to instruct the target network device to skip (i.e., ignore) the additional information indicated by the additional information in the service message and continue processing the other parts of the service message if it does not support such additional operations. Furthermore, when the operation instruction is set to the first value, it can also instruct the target network device to send an error response to the headend network device or not to send an error response to the headend network device. The target network device can determine whether to send an error response when it detects that the operation instruction is set to the first value based on pre-obtained configuration instructions. These configuration instructions can be configured by maintenance personnel or issued by the controller.

[0098] When the operation instruction takes the second value (e.g., 01), it can be used to instruct the target network device to retain the additional information when the first SRH in the service packet needs to be popped (i.e., force the additional information not to be popped), or it can be used to instruct the additional information to be added to the second SRH of the service packet before popping the first SRH from the service packet. Furthermore, when the operation instruction takes the second value, it can also instruct the target network device to send an error response to the headend network device or not to send an error response to the headend network device. Moreover, the target network device can determine whether to send an error response when it detects that the operation instruction takes the second value, based on pre-acquired configuration instructions.

[0099] For example, in scenarios using the PSP mechanism, this operation instruction can instruct the penultimate hop network device to retain the additional information. Furthermore, this operation instruction does not apply to the trailing network device; that is, if the penultimate hop network device retains the additional information, the trailing network device still needs to display the additional information.

[0100] When the operation instruction is set to the third value (e.g., 10), it can be used to instruct the target network device to discard the service message and not send an error response to the headend network device if it does not support the additional operation indicated by the additional information in the service message.

[0101] When the operation instruction is set to the fourth value (e.g., 11), it can be used to instruct the target network device to discard the service message and send an error response to the headend network device if it does not support the additional operation indicated by the additional information in the service message.

[0102] It is understood that the target operation indicated by the above four values ​​is only one optional implementation method. In the embodiments of this application, the target operation indicated by the operation indication when it is different values ​​can be flexibly adjusted according to the needs of the application scenario. For example, when the operation indication is the first value, it can be used to instruct the target network device to send an error response to the headend network device and continue to forward the service message when it does not support the additional operation indicated by the additional information in the service message.

[0103] In this embodiment, the headend network device can add operation instructions to the first SRH according to the service requirements of the service flow to be forwarded (for example, the value of the type field in the optional TLV can be configured). The headend network device does not need to know the capabilities of each network device in the network, nor does it need to be aware of the routing mode of this tunnel. It only needs to carry the operation instructions in the first SRH to precisely control the additional information carried in the optional TLV field. The above packet processing can be completed automatically by the forwarding plane without linkage with the control plane or rerouting, and it will not affect other tunnel forwarding operations unrelated to the additional information.

[0104] It is also understood that, in this embodiment of the application, in addition to the type field in the optional TLV, the headend network device may also carry the operation instruction through other fields in the first SRH. For example, the operation instruction may also be carried through the routingtype field or the flags field in the first SRH.

[0105] It is also understood that the order of steps in the message processing method provided in this application embodiment can be appropriately adjusted, and steps can be added or removed as needed. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0106] In summary, this application provides a message processing method. The SRH encapsulated in the service message by the headend network device also includes an operation instruction. This operation instruction can instruct the target network device in the forwarding path to perform a target operation when it needs to pop up the SRH or does not support the additional operation indicated by the additional information in the SRH. Compared to the target network device directly popping up the SRH or directly ignoring the additional information, the method provided by this application, by instructing the target network device to perform the target operation, effectively enriches the processing methods for service messages and improves the flexibility of message processing.

[0107] Furthermore, since the headend network devices can guide the target network devices in processing service packets based on operation instructions, it can effectively enhance the service deployment capabilities and compatibility with the existing network of systems using SRv6 policies, and meet the needs of future service expansion.

[0108] Figure 8 This is a schematic diagram of a message processing device provided in an embodiment of this application. This device can be applied to headend network equipment, for example, it can be applied to... Figure 1 Any network device 01 in the system shown, or, can be applied to, such as Figures 4 to 6 Network device R1 in the system. (Reference) Figure 8 The device includes:

[0109] Encapsulation module 201 is used to encapsulate a first SRH in a service packet. The first SRH includes a segmentation list, additional information, and an operation instruction. The operation instruction is used to instruct a target network device to perform a target operation when the first SRH is removed from the service packet or when the additional operation indicated by the additional information is not supported. The target network device is a network device in the forwarding path identified by the segmentation list. The functional implementation of encapsulation module 201 can be referred to the relevant description of step 101 in the above method embodiment.

[0110] The forwarding module 202 is used to forward the service packet based on the segment list. The functionality of the forwarding module 202 can be found in the description of step 102 in the above method embodiment.

[0111] Optionally, the target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

[0112] Optionally, if the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

[0113] Optionally, the target operation includes: adding the additional information to the second SRH of the service message before popping the first SRH from the service message; wherein the forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

[0114] Optionally, the first SRH may also include a variable-length field for carrying the additional information and the operation instruction.

[0115] In summary, this application provides a message processing apparatus that includes an operation instruction within the SRH encapsulated in the service message. This operation instruction can instruct a target network device in the forwarding path to perform a target operation when an SRH needs to be popped or when the additional operation indicated by the additional information in the SRH is not supported. Compared to the target network device directly popping the SRH or directly ignoring the additional information, the apparatus provided in this application can directly instruct the target network device to perform the target operation, thereby effectively enriching the processing methods for service messages and improving the flexibility of message processing.

[0116] Figure 9 This is a schematic diagram of another message processing apparatus provided in an embodiment of this application. This apparatus can be applied to a target network device. For example, it can be applied to... Figure 1 Any network device 01 in the system shown, or, can be applied to, such as Figures 4 to 6 Any network device from R2 to R6 in the network configuration. (Refer to...) Figure 9 The device includes:

[0117] The receiving module 301 is used to receive service packets, which encapsulate a first SRH. The first SRH includes a segmentation list, additional information, and operation instructions. The target network device is a network device in the forwarding path identified by the segmentation list. The functional implementation of the receiving module 301 can be referred to the relevant description of step 102 in the above method embodiment.

[0118] The execution module 302 is used to execute the target operation based on the operation instruction when the first SRH needs to be displayed or when the additional operation does not support the additional information instruction. The functional implementation of the execution module 302 can be referred to the relevant description of step 103 in the above method embodiment.

[0119] Optionally, the target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

[0120] Optionally, if the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

[0121] Optionally, the target operation includes: adding the additional information to the second SRH of the service message before popping the first SRH from the service message; wherein the forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

[0122] In summary, this application provides a message processing apparatus. The SRH (Service Message Heading) encapsulated in the service message received by this apparatus further includes an operation instruction. Based on this operation instruction, the apparatus can perform a target operation when it is necessary to pop up the SRH or when additional operations that do not support the additional information indicated in the SRH are not supported. Compared to directly popping up the SRH or directly ignoring the additional information, the apparatus provided in this application can perform target operations based on the instructions of the headend network device, thereby effectively enriching the processing methods for service messages and improving the flexibility of message processing.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the message processing device and each module described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0124] It should be understood that the message processing apparatus provided in this application embodiment can also be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The message processing method provided in the above method embodiment can also be implemented in software. When the message processing method provided in the above method embodiment is implemented in software, each module in the message processing apparatus can also be a software module.

[0125] Figure 10 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. This network device can be applied to, for example... Figure 1 , Figure 4 , Figure 5 or Figure 6 In the system shown. For example, the network device can be Figure 1 Any network device 01 in the system shown, or can be Figures 4 to 6 Any one of the network devices R1 through R6. For example... Figure 10As shown, the network device may include: a processor 401, a memory 402, a transceiver 403, and a bus 404. The bus 404 connects the processor 401, the memory 402, and the transceiver 403. Communication connections with other devices can be established through the transceiver 403 (which can be wired or wireless). The memory 402 stores computer programs used to implement various application functions. Figure 10 When the various modules in the network device shown are implemented as software modules, the programs corresponding to these software modules can be stored in the network device's memory 402.

[0126] It should be understood that in the embodiments of this application, the processor 401 may be a CPU, but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), GPUs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0127] Memory 402 can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0128] In addition to the data bus, bus 404 may also include a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus 404 in the diagram.

[0129] In this embodiment, the processor 401 in the network device can be used to encapsulate a first SRH in a service packet and forward the service packet. The first SRH includes a segment list, additional information, and an operation instruction. The operation instruction instructs the target network device to perform a target operation when it removes the first SRH from the service packet or does not support the additional operation indicated by the additional information. The target network device is the network device in the forwarding path identified by the segment list. Detailed processing procedures of the processor 401 can be found in the above method embodiments. For example, refer to... Figure 3 The detailed descriptions of steps 101 and 102 in the illustrated embodiment will not be repeated here.

[0130] Alternatively, the processor 401 in the network device can be used to receive service packets, which encapsulate a first SRH (Segmentation Representation Header). The first SRH includes a segmentation list, additional information, and an operation instruction. It can also be used to execute a target operation based on the operation instruction when the first SRH needs to be popped out, or when an additional operation does not support the additional information instruction. Detailed processing procedures of the processor 401 can be found in the above-described method embodiments. For example, refer to... Figure 3 The detailed descriptions of steps 102 and 103 in the illustrated embodiment will not be repeated here.

[0131] This application also provides a computer-readable storage medium storing instructions that are executed by a processor to implement the message processing method performed by a headend network device or a target network device as provided in the above method embodiments.

[0132] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute the message processing method provided in the above method embodiments, either executed by a headend network device or by a target network device.

[0133] This application also provides a communication system, see reference. Figure 1 The communication system may include multiple network devices 01, and communication connections are established between the multiple network devices 01. The multiple network devices 01 may include a first network device and at least one second network device.

[0134] The first network device can be a headend network device in the forwarding path of service packets, and the first network device can include, for example: Figure 8or Figure 10 The message processing device shown.

[0135] The second network device can be a network device other than the headend network device in the forwarding path (i.e., the target network device mentioned above), and the second network device may include, for example: Figure 9 or Figure 10 The message processing device shown.

[0136] The first network device can be used to implement the steps performed by the head-end network device in the above method embodiments, and the second network device can be used to implement the steps performed by the target network device in the above method embodiments.

[0137] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive (SSD).

[0138] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple network devices means two or more network devices. The terms "system" and "network" are often used interchangeably in this document.

[0139] The above description is merely an optional implementation of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A message processing method, characterized in that, Applied to headend network devices, the method includes: A first segmented routing header (SRH) is encapsulated in the service message. The first SRH includes a segment list, additional information, and an operation indication. The segment list is used to represent the forwarding path of the service message. The additional information is information carried in the variable-length field of the first SRH to indicate additional operations that the network devices in the forwarding path need to perform. The operation indication is used to indicate the target operation that the target network device needs to perform when the first SRH needs to be popped or when the additional operation indicated by the additional information is not supported. The target network device is the network device in the forwarding path. The service message is forwarded based on the segment list; The target operation includes at least one of the following: retaining the additional information when the first SRH needs to be popped, discarding the service packet, sending an error response to the headend network device, ignoring the additional information, and adding the additional information to the second SRH of the service packet before popping the first SRH.

2. The method according to claim 1, characterized in that, The target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

3. The method according to claim 1, characterized in that, If the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

4. The method according to any one of claims 1 to 3, characterized in that, The forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

5. The method according to any one of claims 1 to 3, characterized in that, The variable-length field is also used to carry the operation instruction.

6. A message processing method, characterized in that, Applied to a target network device, the method includes: A service message is received, which encapsulates a first segmented routing header (SRH). The first SRH includes a segment list, additional information, and an operation instruction. The segment list is used to indicate the forwarding path of the service message. The additional information is information carried in the variable-length field of the first SRH to indicate additional operations to be performed by network devices in the forwarding path. The target network device is a network device in the forwarding path. When the first SRH needs to be popped, or when an additional operation that does not support the additional information indication is not supported, a target operation is performed based on the operation indication. The target operation includes at least one of the following: retaining the additional information when the first SRH needs to be popped, discarding the service packet, sending an error response to the headend network device, ignoring the additional information, and adding the additional information to the second SRH of the service packet before popping the first SRH.

7. The method according to claim 6, characterized in that, The target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

8. The method according to claim 6, characterized in that, If the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

9. The method according to any one of claims 6 to 8, characterized in that, The forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

10. A message processing apparatus, characterized in that, Applied to headend network equipment, the device includes: An encapsulation module is used to encapsulate a first segmented routing header (SRH) in a service packet. The first SRH includes a segment list, additional information, and an operation indication. The segment list represents the forwarding path of the service packet. The additional information is information carried in the variable-length field of the first SRH to indicate additional operations to be performed by network devices in the forwarding path. The operation indication is used to indicate the target operation to be performed by the target network device when it removes the first SRH from the service packet or does not support the additional operation indicated by the additional information. The target network device is a network device in the forwarding path. The forwarding module is used to forward the service packets based on the segment list; The target operation includes at least one of the following: retaining the additional information when the first SRH needs to be popped, discarding the service packet, sending an error response to the headend network device, ignoring the additional information, and adding the additional information to the second SRH of the service packet before popping the first SRH.

11. The apparatus according to claim 10, characterized in that, The target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

12. The apparatus according to claim 10, characterized in that, If the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

13. The apparatus according to any one of claims 10 to 12, characterized in that, The target operation includes: adding the additional information to the second SRH of the service message before popping the first SRH from the service message; The forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

14. The apparatus according to any one of claims 10 to 12, characterized in that, The variable-length field is also used to carry the operation instruction.

15. A message processing apparatus, characterized in that, Applied to a target network device, the apparatus includes: A receiving module is used to receive service packets, which encapsulate a first segmented routing header (SRH). The first SRH includes a segment list, additional information, and an operation instruction. The segment list is used to indicate the forwarding path of the service packet. The additional information is information carried in the variable-length field of the first SRH to indicate additional operations to be performed by network devices in the forwarding path. The target network device is a network device in the forwarding path. An execution module is configured to perform a target operation based on the operation instruction when the first SRH needs to be popped or when an additional operation that does not support the additional information instruction is required. The target operation includes at least one of the following: retaining the additional information when the first SRH needs to be popped, discarding the service packet, sending an error response to the headend network device, ignoring the additional information, and adding the additional information to the second SRH of the service packet before popping the first SRH.

16. The apparatus according to claim 15, characterized in that, The target network device is the penultimate hop network device in the forwarding path; the target operation includes: retaining the additional information when the first SRH needs to be popped.

17. The apparatus according to claim 15, characterized in that, If the target network device does not support the additional operation indicated by the additional information, the target operation includes at least one of the following operations: discarding the service packet, sending an error response to the headend network device, or ignoring the additional information.

18. The apparatus according to any one of claims 15 to 17, characterized in that, The forwarding path identified by the segment list in the first SRH is a sub-path of the forwarding path identified by the segment list in the second SRH.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that are executed by a processor to implement the method as described in any one of claims 1 to 9.

20. A communication system, characterized in that, The system includes: a first network device and a second network device; The first network device includes the apparatus as described in any one of claims 10 to 14, and the second network device includes the apparatus as described in any one of claims 15 to 18.

Images