A service processing method and network device

Abstract

A service processing method and network device, the method comprising: a first network device determining a second network device on a forwarding path of a packet according to service requirement; the first network device sending a first message to the second network device to establish a first connection with the second network device; the first network device sending a second message to the second network device by using the first connection, the second message being used to request the second network device to assist in determining information related to the forwarding path. In the scheme, when the first network device determines that the second network device needs to assist in determining the information related to the forwarding path of the packet according to the service requirement, the first network device initiatively establishes a connection with the second network device, and requests the second network device to assist in determining the information related to the forwarding path by using the established connection, thereby realizing on-demand establishment of the connection, avoiding generation of a large number of idle session connections, and saving resource cost.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service processing method and network equipment. Background Technology

[0002] A Path Computation Element (PCE) is a computational unit in a path computation architecture that enables centralized path computation based on various constraints. A Path Computation Client (PCC) is a client in this architecture that sends route request messages to the PCE and establishes a path connection upon receiving a response with the route calculation results. The PCE receives route request messages from the PCC, performs path computation based on the request messages, and returns the computation results to the PCC.

[0003] In some situations, the PCE (Planetary Element Entity) is often unable to independently determine the forwarding path of a packet. In such cases, the PCE needs to send messages to other PCCs (Planets and Components) along the forwarding path to request their assistance in determining the forwarding path. Since communication between the PCC and PCE requires a dedicated Path Computation Element Communication Protocol (PCEP), to ensure the PCE can successfully complete path calculation, it is typically necessary for network devices that may act as PCCs to proactively establish a PCEP session connection with the PCE beforehand.

[0004] However, in some network scenarios, all network devices in the network may act as PCCs. In these scenarios, all network devices need to establish PCEP session connections with the PCE, which can easily generate a large number of idle session connections, resulting in high resource overhead. Summary of the Invention

[0005] This application provides a service processing method and a network device. When a first network device determines, based on service requirements, that it needs the assistance of a second network device to determine the relevant information of a packet forwarding path, the first network device sends a first message to the second network device to establish a connection with the second network device. The first network device then uses the established connection to request the assistance of the second network device to determine the relevant information of the forwarding path. This achieves on-demand connection establishment, avoids generating a large number of idle session connections, and saves resource overhead.

[0006] This application provides a service processing method, comprising: a first network device determining a second network device on a packet forwarding path according to service requirements, wherein the packet belongs to the service, and the first network device may be a device with path calculation capabilities, such as a controller in the network or a network device participating in packet forwarding in the network. The first network device sends a first message to the second network device to establish a first connection with the second network device, the first connection being, for example, a PECP session connection; the first network device uses the first connection to send a second message to the second network device, the second message being used to request the second network device to assist in determining information related to the forwarding path.

[0007] In this solution, when the first network device determines, based on service requirements, that it needs the assistance of the second network device to determine the forwarding path of a packet, it proactively establishes a connection with the second network device and uses the established connection to request the assistance of the second network device to determine the relevant information of the forwarding path. This achieves on-demand connection establishment, avoids generating a large number of idle session connections, and saves resource overhead.

[0008] Optionally, in one possible implementation, the method further includes: the first network device receiving a third message sent by the second network device, the third message including information related to the forwarding path. By receiving the forwarding path-related information from the second network device, the first network device can determine the forwarding path of the packet based on the second network device.

[0009] Optionally, in one possible implementation, the first network device determines the second network device on the forwarding path of the packet according to service requirements, including: the first network device determines, according to the service requirements, that it cannot determine information related to the forwarding path of the packet; the first network device determines the second network device, which is used to assist in determining the information related to the forwarding path.

[0010] In other words, during the process of determining the forwarding path of a packet, the first network device determines that it needs a second network device to assist it in calculating the forwarding path. This second network device can be a network device along the forwarding path. For example, in a scenario where adhesive labels are needed to represent the forwarding path, the first network device can determine that it needs a second network device to allocate the corresponding adhesive labels. As another example, in a scenario where packets are forwarded across regions, the first network device may be unable to calculate the forwarding path of the packet in that other region due to a lack of topology information. In such cases, the first network device can determine that it needs a second network device to calculate the forwarding path of the packet in that other region.

[0011] Optionally, in one possible implementation, the information associated with the forwarding path includes an adhesion label and / or a path label for indicating the forwarding path.

[0012] Optionally, in one possible implementation, the first network device determines the second network device on the packet forwarding path according to service requirements, including: the first network device determines the packet forwarding path according to the service requirements; the first network device determines the second network device as a sticky node according to the packet forwarding path, and the second network device is used to allocate sticky tags; the first network device sends a second message to the second network device using the first connection, including: the first network device sends a second message to the second network device using the first connection, the second message including tag stack information, and the second message is used to request the second network device to allocate sticky tags corresponding to the tag stack information.

[0013] Optionally, in one possible implementation, the first network device determines the second network device as a sticky node based on the forwarding path of the packet, including: the first network device determining, based on the forwarding path of the packet, that the number of tags required to indicate the forwarding path is greater than the maximum number of tags that the tag stack can carry; the first network device determining the second network device based on the forwarding path, wherein the second network device is a network device on the forwarding path of the packet. For example, when the number of nodes or links traversed by the forwarding path determined by the first network device is greater than the maximum number of tags that the tag stack can carry, the tag stack used to indicate the forwarding path cannot completely carry all the tags corresponding to the forwarding path. In this case, the first network device can determine that sticky tags need to be used to indicate the forwarding of the packet.

[0014] Optionally, in one possible implementation, the first network device determines the second network device on the packet forwarding path according to service requirements, including: the first network device determines, according to the service requirements, that the first network device cannot calculate the packet forwarding path; the first network device determines the second network device according to the network topology, the second network device being a network device on the packet forwarding path, and the second network device assisting the first network device in calculating the first path to the destination device.

[0015] In this scheme, when the first network device is unable to calculate the forwarding path of a packet, the first network device requests the second network device to assist it in calculating the path to the destination device, thereby improving the availability and flexibility of path calculation.

[0016] Optionally, in one possible implementation, the first network device determines, based on the service requirements, that it cannot calculate the forwarding path of the packet, including: the first network device determining, based on the service requirements, that the destination device of the packet is not located in a first area, where the first area is the area where the first network device is located; and the first network device determining, based on the topology of the first area, a second network device, where the second network device is a boundary device between the first and second areas, and the second area is the area where the destination device is located, or the second area is the area through which the forwarding path to the destination device must pass.

[0017] Optionally, in one possible implementation, the first network device uses the first connection to send a second message to the second network device to request the second network device to calculate a first path to the destination device. A third message sent by the second network device to the first network device includes indication information of the first path.

[0018] Optionally, in one possible implementation, the method further includes: the first network device determining a third network device based on the network topology, the third network device being a boundary device between the first area and the second area; the first network device establishing a second connection with the third network device; the first network device sending a fourth message to the third network device using the second connection, the fourth message being used to request the third network device to calculate a second path to the destination device; the first network device receiving a fifth message sent by the third network device, the fifth message including indication information of the second path; and the first network device determining part or all of the forwarding path of the packet based on the third message and the fifth message.

[0019] In other words, if the first network device determines that both the second and third network devices are boundary devices of the first and second areas respectively, the first network device can establish a PECP session connection with the second and third network devices to request the calculation of the path to the destination device. After the first network device obtains the path indication information returned by the second and third network devices respectively, the first network device combines the path indication information returned by the two network devices to determine the forwarding path of the packet, thereby achieving a better path selection.

[0020] Optionally, in one possible implementation, the first network device sending a first message to the second network device to establish a first connection includes: the first network device establishing a Transmission Control Protocol (TCP) connection with the second network device; and using the TCP connection, the first network device sending the first message to the second network device to negotiate the establishment of the first connection with the second network device.

[0021] Optionally, in one possible implementation, the first network device can be a head node device or a controller on the forwarding path of the packet. For example, the first network device is a network head node or ingress node traversed on the end-to-end forwarding path of the packet, specifically an endpoint device of a tunnel or a boundary node of a network domain, etc. Alternatively, in some possible application scenarios, the first network device is a controller with network management functions.

[0022] Optionally, in one possible implementation, both the first network device and the second network device are path calculation client (PCC) devices on the forwarding path.

[0023] Optionally, in one possible implementation, the packet forwarding path includes one or more of the following: Segment Routing Policy (SR policy) path, Segment Routing Internet Protocol version 4 (SRV4) path, SRV6 path, Segment Routing Traffic Engineering (SR-TE) path, and Multi-protocol Label Switching Traffic Engineering (MPLS-TE) path.

[0024] A second aspect of this application provides a network device, which is a first network device, comprising: a processing unit and a transceiver unit; the processing unit is configured to determine a second network device on a forwarding path of a packet according to service requirements, wherein the packet belongs to the service; the transceiver unit is configured to send a first message to the second network device to establish a first connection with the second network device; the transceiver unit is further configured to use the first connection to send a second message to the second network device, wherein the second message is used to request the second network device to assist in determining information related to the forwarding path.

[0025] Optionally, in one possible implementation, the transceiver unit is further configured to receive a third message sent by the second network device, the third message including information related to the forwarding path.

[0026] Optionally, in one possible implementation, the processing unit is specifically configured to: determine, based on the service requirements, that the first network device cannot determine information related to the forwarding path of the packet; and determine a second network device, wherein the second network device is used to assist in determining information related to the forwarding path.

[0027] Optionally, in one possible implementation, the information associated with the forwarding path includes an adhesion label and / or a path label for indicating the forwarding path.

[0028] Optionally, in one possible implementation, the processing unit is specifically configured to: determine the forwarding path of the packet according to the service requirements; determine the second network device as a sticky node according to the forwarding path of the packet, and the second network device is used to allocate sticky tags; the transceiver unit is specifically configured to send a second message to the second network device using the first connection, the second message including tag stack information, and the second message is used to request the second network device to allocate sticky tags corresponding to the tag stack information.

[0029] Optionally, in one possible implementation, the processing unit is specifically configured to: determine, based on the forwarding path of the packet, that the number of tags required to indicate the forwarding path is greater than the maximum number of tags that the tag stack can support; and determine, based on the forwarding path, the second network device, which is a network device on the forwarding path of the packet.

[0030] Optionally, in one possible implementation, the processing unit is specifically configured to: determine, based on the service requirements, that the first network device cannot calculate the forwarding path of the packet; determine, based on the network topology, that the second network device is a network device on the forwarding path of the packet, and that the second network device is used to assist the first network device in calculating the first path to the destination device.

[0031] Optionally, in one possible implementation, the processing unit is specifically configured to: determine, based on the service requirements, that the destination device of the packet is not located in the first region, where the first region is the region where the first network device is located; and, based on the topology of the first region, determine the second network device, where the second network device is the boundary device between the first region and the second region, and the second region is the region where the destination device is located, or the second region is the region through which the forwarding path to the destination device must pass.

[0032] Optionally, in one possible implementation, the first network device uses the first connection to send a second message to the second network device to request the second network device to calculate a first path to the destination device, and the third message includes indication information of the first path.

[0033] Optionally, in one possible implementation, the processing unit is specifically configured to: determine a third network device based on the network topology, wherein the third network device is a boundary device between the first area and the second area; the transceiver unit is specifically configured to: establish a second connection with the third network device; send a fourth message to the third network device using the second connection, wherein the fourth message is used to request the third network device to calculate a second path to the destination device; receive a fifth message sent by the third network device, wherein the fifth message includes indication information of the second path; the processing unit is further configured to determine part or all of the forwarding path of the packet based on the third message and the fifth message.

[0034] Optionally, in one possible implementation, the first connection includes a path calculation unit communication protocol PCEP connection.

[0035] Optionally, in one possible implementation, the transceiver unit is specifically used to establish a Transmission Control Protocol (TCP) connection with the second network device; and to use the TCP connection to send the first message to the second network device to negotiate the establishment of the first connection with the second network device.

[0036] Optionally, in one possible implementation, the first network device is a head node device on the forwarding path of the packet. Alternatively, in certain possible scenarios, the first network device may also be a controller.

[0037] Optionally, in one possible implementation, both the first network device and the second network device are path calculation client (PCC) devices on the forwarding path.

[0038] Optionally, in one possible implementation, the message forwarding path includes one or more of the following: SR policy path, SRV4-based path, SRV6 path, SR-TE path, and MPLS-TE path.

[0039] A third aspect of this application provides a network device comprising: a processor configured to cause the network device to implement the methods described in any possible implementation of the first aspect. The device may further include a memory coupled to the processor, wherein when the processor executes instructions stored in the memory, it causes the network device to implement the methods described in any possible implementation of the first aspect. The device may also include a communication interface for communicating with other devices; exemplaryly, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0040] In this application, the instructions in the memory can be pre-stored or downloaded from the Internet when using the network device and then stored. This application does not specifically limit the source of the instructions in the memory. The coupling in this application is an indirect coupling or connection between devices, units, or modules, which can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules.

[0041] A fourth aspect of this application provides a computer storage medium that may be non-volatile; the computer storage medium stores computer-readable instructions that, when executed by a processor, implement the method of any one of the first aspects.

[0042] The fifth aspect of this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the method as described in any of the first aspects.

[0043] The sixth aspect of this application provides a network system comprising a network device as described in any of the implementations of the second or third aspect above, and one or more other network devices for cooperating with the network device to calculate or obtain forwarding path related information.

[0044] A seventh aspect of this application provides a chip including a processor. Part or all of the processor is used to read and execute a computer program stored in a memory to perform the method in any possible implementation of any of the above aspects. Optionally, the chip includes a memory, which is connected to the processor via a circuit or wire. Further optionally, the chip also includes a communication interface, to which the processor is connected. The communication interface is used to receive data and / or information to be processed, the processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing result through the communication interface. The communication interface can be an input / output interface. The method provided in this application can be implemented by a single chip or by multiple chips working together.

[0045] The solutions provided in the second to seventh aspects above are used to implement or cooperate with the methods provided in the first aspect above, and therefore can achieve the same or corresponding beneficial effects as the first aspect, which will not be elaborated here. Attached Figure Description

[0046] Figure 1 This application provides a schematic diagram of a network architecture.

[0047] Figure 2 A flowchart illustrating a business processing method 200 provided in an embodiment of this application;

[0048] Figure 3 A flowchart illustrating a business processing method 300 provided in an embodiment of this application;

[0049] Figure 4(a) is a flowchart illustrating a message forwarding method 400 provided in an embodiment of this application;

[0050] Figure 4(b) is a schematic diagram of the application network architecture of a message forwarding method 400 provided in an embodiment of this application;

[0051] Figure 5(a) is a flowchart illustrating a message forwarding method 500 provided in an embodiment of this application;

[0052] Figure 5(b) is a schematic diagram of the application network architecture of a message forwarding method 500 provided in an embodiment of this application;

[0053] Figure 6 A flowchart illustrating a business processing method 600 provided in an embodiment of this application;

[0054] Figure 7(a) is a flowchart illustrating a method 700 for determining a message forwarding path according to an embodiment of this application;

[0055] Figure 7(b) is a schematic diagram of the application network architecture of a method 700 for determining the forwarding path of a message provided in an embodiment of this application;

[0056] Figure 8(a) is a flowchart illustrating a method 800 for determining the forwarding path of a message according to an embodiment of this application;

[0057] Figure 8(b) is a schematic diagram of the application network architecture of a method 800 for determining the forwarding path of a message provided in an embodiment of this application;

[0058] Figure 9 A schematic diagram of the structure of a network device 900 provided in an embodiment of this application;

[0059] Figure 10 This is a schematic diagram of the structure of a network device 1000 provided in an embodiment of this application;

[0060] Figure 11 This is a schematic diagram of the structure of a network system 1100 provided in an embodiment of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0062] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved. The division of units in this application is a logical division. In practical applications, there may be other division methods. For example, multiple units may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the shown or discussed mutual coupling, direct coupling, or communication connection may be through some interface, and the indirect coupling or communication connection between units may be electrical or other similar forms, none of which are limited in this application. Furthermore, the units or sub-units described as separate components may or may not be physically separated, may or may not be physical units, or may be distributed among multiple circuit units. Some or all of the units can be selected to achieve the purpose of the solution in this application according to actual needs.

[0063] PCEP is a path calculation communication protocol used for information exchange between PCE and PCC. PCC can send a path calculation request message to PCE based on a PCEP session connection; after receiving the path calculation request message, PCE performs path calculation according to the path calculation request message and returns the path calculation result to PCC based on the PCEP session connection.

[0064] In some situations, such as when sticky labels are needed to represent paths, the PCE often cannot independently determine the forwarding path information of a packet. In this case, the PCE needs to send messages to other PCCs on the forwarding path to request their assistance in determining the packet forwarding path information. In the above scenario, the PCE can be understood as the controller, while the PCCs can be understood as network devices that interact with the controller for packet forwarding. As the controller, the PCE typically needs to establish pre-established communication connections with all the PCCs it manages and controls to implement various possible functions, including path calculation. For example, this can be done through the PCEP protocol; otherwise, some functions of the controller may not function properly.

[0065] However, in some network scenarios, all network devices may act as PCCs. In these scenarios, all network devices need to establish PCEP session connections with the PCE, which can easily lead to a large number of idle session connections and high resource overhead. (See also...) Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 1As shown, the network architecture includes a controller, network device A, network device B, network device C, and network device D. The controller is a PCE (Physical Electronic Device), and network device A is a PCC (Physical Electronic Device). Network device A can initiate a PEEP (Physical Electronic Protocol) session connection with the controller beforehand. Thus, when network device A needs to determine the forwarding path of an acquired packet, it can send a path calculation request to the controller via the PCEP session connection, requesting the controller to calculate the packet's forwarding path. During the controller's calculation of the packet's forwarding path, the controller may need assistance from other network devices in the network to determine relevant information about the packet's forwarding path. For example, the controller may need assistance from network devices B, C, or D. Since the controller needs to interact with other network devices based on the PCEP session connection, to ensure the controller can successfully complete the packet forwarding path calculation, network devices B, C, and D all need to initiate a PCEP session connection with the controller beforehand. However, in practice, the controller may only need to establish a PCEP session connection with network device B. Therefore, all network devices in the network establish PCEP session connections with PCE, which easily generates a large number of idle session connections, resulting in high resource overhead.

[0066] In view of this, the present application provides a service processing method in which, when the network device responsible for routing determines that it needs the assistance of another network device for routing, the network device responsible for routing initiates a request to establish a connection with the other network device, so as to realize the on-demand establishment of connections, avoid generating a large number of idle session connections, and save resource overhead.

[0067] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a business processing method 200 provided in an embodiment of this application. This business processing method 200 can be applied to... Figure 1 In the network structure shown.

[0068] like Figure 2 As shown, the message processing method 200 includes at least the following steps.

[0069] Step 201: The first network device determines the second network device on the forwarding path of the packet according to the service requirements, wherein the packet belongs to the service.

[0070] In this embodiment, the first network device can be a device with path calculation capabilities, such as a network device involved in packet forwarding or a controller in the network. In actual deployment, the controller can be independent of the network device or can be located inside a network device. This controller can also be called a network management device.

[0071] When the first network device is a network device participating in packet forwarding in the network, the first network device may be, for example, a network device on the packet forwarding path. The packet forwarding path may be a partial path on a complete end-to-end packet forwarding path, such as a packet forwarding path determined by the first network device that starts from the first network device and passes through the second network device. That is, the first network device is also a device on the packet forwarding path, and the packet arrives at the first network device before reaching the second network device. As a possible example, the first network device may be a head node or ingress node, specifically a tunnel end node or a boundary node of a network domain on the forwarding path through which the packet passes. In other possible scenarios, the first network device may also be a node at other locations on the packet forwarding path, but it needs to request assistance from other nodes on the path to provide information related to the forwarding path using method 200. The second network device is a network device between the first network device and the destination device of the packet. The first network device may obtain service requirements by receiving packets to be forwarded. These service requirements may, for example, be forwarding the packet to be forwarded to the destination address specified by the packet.

[0072] When the first network device is a controller, the first network device may obtain service requirements by receiving path calculation request messages sent by other network devices connected to it. This service requirement may, for example, be calculating the forwarding path of a message from one network device to another.

[0073] In other words, regardless of whether the first network device is a controller or a network device involved in packet forwarding in the network, the first network device needs to determine the packet forwarding path based on the obtained service requirements.

[0074] In one possible embodiment, a first network device may determine, based on the service requirements, that it cannot determine information related to the forwarding path of the packet; the first network device then determines a second network device, which assists in determining the information related to the forwarding path. The information related to the forwarding path may include adhesion tags and / or path tags used to indicate the forwarding path.

[0075] In other words, during the process of determining the forwarding path of a packet, the first network device determines that it needs a second network device to assist it in calculating the forwarding path. This second network device can be a network device along the forwarding path. For example, in scenarios where adhesive tags are needed to represent the forwarding path, the first network device may determine that it needs the second network device to allocate the corresponding adhesive tags. As another example, in scenarios involving cross-region packet forwarding, the first network device may be unable to calculate the forwarding path of the packet in the other region due to a lack of topology information; in such cases, the first network device may determine that it needs the second network device to calculate the forwarding path. Alternatively, the first network device may also instruct the second network device to send other information related to the forwarding path.

[0076] In one possible embodiment, the packet forwarding path may include one or more of the following: a Segment Routing Policy (SR policy) path, a Segment Routing Internet Protocol version 4 (SRV4) path, an SRV6 path, a Segment Routing Traffic Engineering (SR-TE) path, and a Multi-Protocol Label Switching (MPLS-TE) path. In other words, the method provided in this embodiment can be applied to calculate one or more of the following: an SR policy path, an SRV4 path, an SRV6 path, an SR-TE path, and an MPLS-TE path.

[0077] Step 202: The first network device sends a first message to the second network device to establish a first connection with the second network device.

[0078] In this embodiment, after the first network device determines that it needs the second network device to determine information related to the forwarding path of the packet, the first network device may send a first message to the second network device, which is used to request the establishment of a first connection with the second network device.

[0079] The first connection can be a connection used to implement information related to interactive path calculation. For example, the first connection can be a PCEP session connection. After the first network device and the second network device establish the first connection, the first network device and the second network device can interact with information related to path calculation; that is, the first network device can send a request message to the second network device to request the second network device to determine information related to the forwarding path of the packet.

[0080] Understandably, when the first network device is a network device on the packet forwarding path, it has a corresponding network topology and is reachable from other network devices in the network, allowing it to directly establish a first connection with the second network device. However, when the first network device is a controller, it is necessary to ensure that the controller is reachable from other network devices during deployment to guarantee its ability to establish a first connection with the second network device.

[0081] Step 203: The first network device sends a second message to the second network device using the first connection. The second message is used to request the second network device to assist in determining information related to the forwarding path.

[0082] In the case that the first connection is a PCEP connection, the second message may be, for example, a PCEP Path Computation Request (PCReq) message, which can be used to request the second network device to assist in determining information related to the forwarding path.

[0083] Step 204: The first network device receives a third message sent by the second network device, the third message including information related to the forwarding path.

[0084] After the second network device receives the second message sent by the first network device, the second network device can determine information related to the forwarding path based on the second message and send a third message to the first network device, which includes the information related to the forwarding path determined by the second network device.

[0085] In the case that the first connection is a PCEP connection, the third message can be, for example, a path calculation response (PCEPPath Computation Reply, PCRep) message, which can provide feedback on information related to the forwarding path.

[0086] In this embodiment, when the first network device responsible for routing determines that it needs the assistance of the second network device to determine the relevant information of the packet forwarding path, the first network device initiates a connection establishment request to the second network device. This enables the first network device to request the assistance of the second network device to determine the relevant information of the packet forwarding path, thereby realizing on-demand connection establishment, avoiding the generation of a large number of idle session connections, and saving resource overhead.

[0087] The above describes the process by which the first network device initiates a request to the second network device to establish a first connection based on service requirements, so as to realize the exchange of relevant information about the forwarding path. For ease of understanding, the process of the first network device and the second network device establishing a first connection will be described in detail below.

[0088] The following example uses a PCEP session connection as an example. The process of establishing a first connection between the first network device and the second network device is as follows:

[0089] 1. The first network device, acting as the initiator, establishes a Transmission Control Protocol (TCP) connection with the second network device through a three-way handshake.

[0090] 2. The first network device and the second network device exchange Open messages to negotiate and establish a PECP session connection.

[0091] 3. The first network device and the second network device exchange keepalive messages to maintain the PECP session connection.

[0092] In process 1, the three-way handshake includes: the first network device, acting as the initiator, sends a connection request message to the second network device to request the establishment of a TCP connection. Upon receiving the connection request message, the second network device sends an acknowledgement (ack) message to the first network device and allocates the necessary resources to establish the TCP connection. After receiving the ack message from the second network device, the first network device also sends an ack message to the second network device and allocates the necessary resources to establish the TCP connection. Through this three-way handshake process, the first network device can establish a TCP connection with the second network device.

[0093] For example, the connection request message sent by the first network device to the second network device can be a TCP message, and the message format of the TCP message can be as follows:

[0094]

[0095]

[0096] The explanations of the various fields in a TCP message are as follows:

[0097] Source Port: The source port number.

[0098] Destination Port: Destination port number.

[0099] Sequence Number: Serial number.

[0100] Acknowledgment Number: Confirmation number.

[0101] Data Offset: Header length.

[0102] Reserved: Reserved bit.

[0103] URG: Emergency pointer is valid.

[0104] ACK: Confirmation that the sequence number is valid.

[0105] PSH: The receiver should deliver this segment to the application layer as soon as possible.

[0106] RST: Rebuild connection.

[0107] SYN: Synchronization sequence number, used to initiate a connection.

[0108] FIN: The sending end has completed the sending task.

[0109] Window: Window size.

[0110] Checksum: Validation sum.

[0111] Urgent Pointer: An urgent pointer.

[0112] Options: Optional.

[0113] Data: Data.

[0114] Destination Port: Destination port number.

[0115] In this case, the port number of the PECO session connection is 4189. The first network device can establish a TCP connection with the second network device through a three-way handshake by sending a TCP message with the destination port number 4189 to the second network device.

[0116] In Process 2, after the first network device establishes a TCP connection with the second network device, the first network device and the second network device can negotiate to establish a PECP session connection by sending Open messages to each other. Among them, the Open message can be, for example, the first message mentioned above.

[0117] Among them, the format of the Open message can be as follows:

[0118] <Open Message(Open message)> ::= <Common Header(Common header)>

[0119] <open>

[0120] The Common Header field represents the general header, and the OPEN object represents the specific Open message content.

[0121] The format of a general header can be as follows:

[0122]

[0123]

[0124] The explanations of the fields in the general header are as follows:

[0125] Ver (Version): PCEP version number, the current version number is 1.

[0126] Flags: Reserved flags, not yet located, set to all 0s.

[0127] Message-Type: PCEP message type, used for the type of the current PECP message.

[0128] Message-Length: Total length of the PCEP message, in bytes.

[0129] The meanings of the different values ​​for the Message-Type field are as follows:

[0130] 1 Open

[0131] 2 Keepalive

[0132] 3. Path Computation Request (PCReq)

[0133] 4. Path Computation Reply (PCRep)

[0134] 5. Notification

[0135] 6. Error

[0136] 7. Close

[0137] 10. Path Computation LSP State Report (PCRpt)

[0138] 11. Path Computation LSP Update Request (PCUpd)

[0139] 12. Path Calculation Initialization Request (PCEP Initiate Request, PCInitiate)

[0140] The format of an OPEN object can be as follows:

[0141]

[0142] The explanations of the fields in the OPEN object are as follows:

[0143] Ver: PCEP version number, the current version number is 1.

[0144] Flags: Reserved flags, not yet defined, set to all 0s.

[0145] Keepalive: The maximum interval between two consecutive PCEP message transmissions, in seconds.

[0146] DeadTimer: The timeout period between two PCEP neighbors, typically 4 times Keepalive.

[0147] SID (PCEP session ID): A sequence number that identifies a PCEP session.

[0148] Optional TLVs: Optional type length values ​​(TLVs) in an OPEN object.

[0149] The above describes the process of the first network device establishing a first connection with the second network device. The following will describe in detail, with reference to the accompanying drawings, the process by which the first network device requests the second network device to assist in determining information related to the forwarding path in different scenarios.

[0150] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating a business processing method 300 provided in an embodiment of this application. Figure 3 As shown, this business processing method 300 is a method for scenarios that require the use of adhesive tags to represent forwarding paths, and includes the following steps.

[0151] Step 301: The first network device determines the forwarding path of the packet according to the service requirements.

[0152] In this embodiment, the first network device determines the forwarding path of the packet based on the acquired service requirements. For example, when the first network device is a controller, it can use the network device that sent the service requirements to it as the starting device and calculate the forwarding path from the starting device to the destination device of the packet. When the first network device is a network device participating in packet forwarding in the network, it can use itself as the starting device to calculate the forwarding path from itself to the destination device of the packet based on the received packet.

[0153] Step 302: The first network device determines the second network device as an adhesion node based on the forwarding path of the packet, and the second network device is used to assign adhesion tags.

[0154] Understandably, in networks that use labels to represent forwarding paths, such as Multi-protocol Label Switching (MPLS-TE) networks or Segment Routing-MPLS (SR-MPLS) networks, network devices represent nodes or links on the forwarding path by carrying multiple labels in a label stack. Each label in the label stack can represent a node or link traversed on the forwarding path. However, the label stack depth supported by network devices is limited, meaning the number of labels the label stack can carry is limited. For example, in some network devices, the maximum number of labels the label stack can carry can be 10, 18, or 28 layers.

[0155] Therefore, when the number of nodes or links traversed by the forwarding path determined by the network device exceeds the maximum number of tags that the label stack can carry, the label stack used to indicate the forwarding path cannot carry all the tags corresponding to the forwarding path. In this case, stuck labels can be used to indicate the forwarding of packets.

[0156] In other words, the first network device can determine, based on the forwarding path of the packet, that the number of tags required to indicate the forwarding path is greater than the maximum number of tags that the tag stack can support. Then, the first network device determines the second network device based on the forwarding path. The second network device is the network device on the forwarding path of the packet, and this second network device can serve as an adhesion node for allocating adhesion tags.

[0157] There are several ways for the first network device to determine the second network device based on the forwarding path. For example, after determining the forwarding path, the first network device can obtain the label stack 1 corresponding to that path. The first network device can use the maximum number of labels that the label stack on the forwarding plane can carry as a benchmark. In label stack 1, count N labels from the bottom to the top, and designate the network device to which the Nth label belongs as the second network device. N is the maximum number of labels that the label stack can carry. For example, assuming the maximum number of labels that the label stack on the first network device's forwarding plane can carry is 10, the first network device can count 10 labels from the bottom to the top in the generated label stack 1, and designate the network device to which the 10th label belongs as the second network device.

[0158] In addition, the first network device can also be based on the maximum number of tags that the label stack on the forwarding plane can carry. In this label stack 1, count N tags from the top of the stack to the bottom of the stack, and the network device to which the Nth tag belongs is the second network device. N is the maximum number of tags that the label stack can carry.

[0159] The first network device can also be determined by other means, such as determining the network device located at the midpoint between the destination device and the originating network device as the second network device, as long as it is ensured that in the label stack generated by the first network device, the number of labels corresponding to the second network device from the top of the stack to the bottom of the stack is not greater than the maximum number of labels that the forwarding plane can support.

[0160] Step 303: The first network device sends a first message to the second network device to establish a first connection with the second network device.

[0161] Step 303 is similar to step 203 above, and the details can be found in the description of step 203, which will not be repeated here.

[0162] Step 304: The first network device sends a second message to the second network device using the first connection. The second message includes tag stack information and is used to request the second network device to allocate adhesive tags corresponding to the tag stack information.

[0163] In this embodiment, after the first network device and the second network device establish a first connection, the first network device can send a request message to the second network device to request the second network device to allocate adhesive tags. This request message includes tag stack information, which corresponds to the adhesive tags requested to be allocated by the second network device.

[0164] Step 305: The first network device receives a third message sent by the second network device, the third message including an adhesive tag corresponding to the tag stack information.

[0165] In this embodiment, after receiving the second message from the first network device, the second network device can dynamically request an adhesive tag from the tag pool and establish a correspondence between the adhesive tag and the tag stack information. This allows the second network device to replace the adhesive tag with the tag stack information when it receives a message carrying the adhesive tag. Then, the second network device can send the requested adhesive tag to the first network device via a third message, enabling the first network device to receive a third message containing the adhesive tag corresponding to the tag stack information.

[0166] For example, refer to Figures 4(a) and 4(b). Figure 4(a) is a flowchart illustrating a packet forwarding method 400 provided in an embodiment of this application; Figure 4(b) is an architecture diagram of an application network for the packet forwarding method 400 provided in an embodiment of this application. As shown in Figure 4(b), the first network device may refer to network device 1 in Figure 4(b). The packet forwarding method 400 includes the following steps.

[0167] Step 401: Network device 1 calculates the forwarding path of the packet and determines network device 2 based on the forwarding path.

[0168] When the first network device is network device 1, network device 1 can receive a message from the external network. Based on the destination address of the message, network device 1 can calculate the path from network device 1 to network device 12 as "network device 1-network device 2-network device 3-network device 4-network device 5-network device 6-network device 7-network device 8-network device 9-network device 10-network device 11-network device 12".

[0169] Assume the label stack supports a maximum of 10 layers of labels. If the forwarding path calculated by network device 1 is the path described above, and the labels in the label stack represent nodes on the forwarding path, then the label stack needs to carry 11 layers of labels: {Network Device 2-Network Device 3-Network Device 4-Network Device 5-Network Device 6-Network Device 7-Network Device 8-Network Device 9-Network Device 10-Network Device 11-Network Device 12}. If the labels in the label stack represent links on the forwarding path, then the label stack needs to carry 11 layers of labels: {1001-1002-1003-1004-1005-1006-1007-1008-1009-1010-1011}. In other words, the number of labels needed in the label stack indicating the forwarding path is greater than the maximum number of labels the label stack can actually support. Therefore, network device 1 can identify a specific network device on the forwarding path as a sticky node and request that network device to allocate sticky labels.

[0170] In this embodiment, since the tag stack supports a maximum of 10 layers of tags, network device 1 counts 10 tags from the bottom to the top of the 11-layer tag stack, and the network device to which the 10th tag (i.e., tag 1002) belongs is the sticking node. Then, network device 1 can determine that tag 1002 comes from network device 2 based on the Traffic Engineering Database (TEDB), thereby determining that network device 2 is the sticking node.

[0171] Alternatively, network device 1 can count 10 tags from top to bottom in the tag stack that includes 11 layers of tags, and use the network device to which the 10th tag (i.e., tag 1010) belongs as the sticky node. Then, network device 1 can determine that tag 1010 comes from network device 11 based on TEDB, thereby determining network device 11 as the sticky node.

[0172] It is understandable that, in addition to determining the sticky nodes through the methods described above, other methods can also be used to determine the sticky nodes. For example, network device 1 determines any network device between network device 1 and network device 12 that meets the following condition: ensuring that the label corresponding to the network device that is a sticky node has no more than 10 layers in the label stack including the 11 layers of labels, from the top label to the bottom label. For example, network device 5 or network device 6 can be determined as sticky nodes.

[0173] Step 402, network device 1 sends request message 1 to network device 2, which requests network device 2 to allocate adhesive tags.

[0174] It is understood that before network device 1 sends request message 1 to network device 2, network device 1 needs to initiate a PECP session connection with network device 2. The process of establishing a PECP session connection between network device 1 and network device 2 can be referred to the description in the above embodiments, and will not be repeated here.

[0175] In the request message 1 sent by network device 1 to network device 2, there is tag stack information specified by network device 1 that needs to establish a correspondence with the attached tag. This tag stack information can be, for example, 10 layers of tags counted from the last layer to the first layer of tags mentioned above by network device 1, that is, the tag stack information can include {1002-1003-1004-1005-1006-1007-1008-1009-1010-1011}, a total of 10 layers of tags.

[0176] Step 403: Network device 2 applies for adhesive tags and establishes the correspondence between adhesive tags and tag stack information.

[0177] After receiving a request message from network device 1, network device 2 can dynamically request a sticky tag from the tag pool. This sticky tag can be, for example, sticky tag 100. Network device 2 can also establish a correspondence between sticky tag 100 and tag stack information based on the tag stack information in the request message. For example, network device 2 can generate a forwarding table entry in which sticky tag 100 corresponds to tag stack information {1002-1003-1004-1005-1006-1007-1008-1009-1010-1011}. When network device 2 looks up the table based on sticky tag 100 in this forwarding table entry, it can find the corresponding 10 layers of tag stack information.

[0178] Step 404: Network device 2 sends an adhesion tag to network device 1.

[0179] Step 405, network device 1 sends a message to network device 2, the message carrying an adhesive tag.

[0180] After receiving the adhesive tag 100 sent by network device 2, network device 1 can replace the aforementioned 10-layer tag stack information with the adhesive tag 100, that is, network device 1 generates a tag stack {1001, 100}. Therefore, when forwarding a packet, network device 1 can forward the packet to network device 2 based on the indication of the tag stack {1001, 100}. Furthermore, before forwarding the packet, network device 1 removes tag 1001 from the tag stack, so that the tag stack of the packet forwarded by network device 1 to network device 2 only includes the adhesive tag 100.

[0181] Step 406: Network device 2 replaces the sticky tags in the message with the corresponding tag stack and forwards the message to network device 3.

[0182] After receiving a packet forwarded by network device 1, network device 2 can determine the 10-layer tag stack information corresponding to the attached tag 100 based on the forwarding table entries. It then replaces the attached tag 100 in the packet with the tag stack {1002-1003-1004-1005-1006-1007-1008-1009-1010-1011}. Similarly, network device 2 can determine to forward the packet to network device 3 based on the replaced tag stack. Before forwarding the packet, it removes the top tag (i.e., tag 1002) from the tag stack, ensuring that the tag stack of the packet forwarded to network device 3 includes {1003-1004-1005-1006-1007-1008-1009-1010-1011}, guiding subsequent network devices in forwarding the packet.

[0183] The above description uses network device 1 as an example to illustrate the packet forwarding process. In practice, the first network device can also be a controller. The following description will use the first network device as a controller to illustrate the packet forwarding process in detail.

[0184] For example, refer to Figures 5(a) and 5(b). Figure 5(a) is a flowchart illustrating a packet forwarding method 500 provided in an embodiment of this application; Figure 5(b) is an architecture diagram of an application network for a packet forwarding method 500 provided in an embodiment of this application. As shown in Figure 5(b), the first network device may refer to the controller in Figure 5(b), and the packet forwarding method 500 includes the following steps.

[0185] Step 501: Network device 1 sends a routing request to the controller.

[0186] When network device 1 receives a message that needs to be forwarded to network device 12, network device 1 sends a routing request to the controller. The routing request carries the address of network device 12 and requests the controller to calculate the forwarding path from network device 1 to network device 12.

[0187] Step 502: The controller calculates the forwarding path of the packet and determines network device 2 based on the forwarding path.

[0188] In this embodiment, step 502 is similar to step 401 described above. For details, please refer to step 401 described above. It will not be repeated here.

[0189] Step 503: The controller sends a request message 2 to the network device 2, which requests the network device 2 to assign an adhesive tag.

[0190] It is understandable that before the controller sends request message 2 to network device 2, the controller needs to actively establish a PECP session connection with network device 2 as the initiator. The process of the controller establishing a PECP session connection with network device 2 can be referred to the description in the above embodiment, and will not be repeated here.

[0191] In this embodiment, step 503 is similar to step 402 described above. For details, please refer to step 402 described above, and it will not be repeated here.

[0192] Step 504: Network device 2 applies for adhesive tags and establishes a correspondence between adhesive tags and tag stack information.

[0193] Step 505: Network device 2 sends an adhesive tag to the controller.

[0194] In this embodiment, steps 504-505 are similar to steps 403-404 described above. For details, please refer to steps 403-404 described above. They will not be repeated here.

[0195] Step 506: The controller sends a tag stack to network device 1, which includes the adhesive tag.

[0196] After the controller receives the sticky tag returned by network device 2, it can generate a tag stack {1001, 100} indicating the forwarding path based on the sticky tag. That is, it carries a tag indicating the link between network device 1 and network device 2, as well as the sticky tag 100. Then, the controller sends the tag stack to network device 1 so that the network device can forward packets based on the tag stack.

[0197] Step 507: Network device 1 sends a message to network device 2, the message carrying an adhesive tag.

[0198] Step 508: Network device 2 replaces the sticky tags in the message with the corresponding tag stack and forwards the message to network device 3.

[0199] In this embodiment, steps 507-508 are similar to steps 405-406 described above. For details, please refer to steps 405-406 described above. They will not be repeated here.

[0200] The above describes the process by which a first network device requests a second network device to assign an adhesive label in a scenario where an adhesive label is needed to represent a forwarding path. The following will describe the process by which a first network device requests a second network device to assist in calculating a forwarding path in other scenarios.

[0201] Please refer to Figure 6 , Figure 6 This is a flowchart illustrating a business processing method 600 provided in an embodiment of this application. Figure 6 As shown, the business processing method 600 can be, for example, a method for cross-domain scenarios, including the following steps.

[0202] Step 601: The first network device determines, based on the service requirements, that it cannot calculate the forwarding path of the packet.

[0203] In this embodiment, the first network device can be a controller or a network device participating in packet forwarding within the network. When the first network device is a controller, it can receive a request to calculate the forwarding path of a packet. This service requirement can be to calculate the forwarding path to the destination device or a designated device for the packet. When the first network device is a network device participating in packet forwarding within the network, it can receive a packet to be forwarded. This service requirement can be to forward the packet to the destination device or a designated device. In other words, the first network device needs to calculate the forwarding path of the packet according to the service requirement.

[0204] In this scenario, the first network device, based on service requirements, can determine that it cannot independently calculate the forwarding path of a packet. For example, if the first network device does not store the network topology related to the destination device of the packet, it cannot calculate the forwarding path. Similarly, if the packet has certain forwarding constraints, such as Service Level Agreement (SLA) requirements, and the first network device cannot obtain the SLAs corresponding to all or part of the links in the network topology, it may also be unable to calculate the forwarding path.

[0205] Step 602: The first network device determines the second network device according to the network topology. The second network device is a network device on the forwarding path of the packet. The second network device is used to assist the first network device in calculating the first path to the destination device.

[0206] In this embodiment, the first network device may store a global network topology or a local network topology between the first network device and the destination device of the message. Based on the global network topology or the local network topology, the first network device may determine that it needs the assistance of the second network device to calculate a first path to the destination device.

[0207] For example, if the first network device only stores the aforementioned local network topology, it cannot calculate the complete forwarding path to the destination device. The first network device can determine a partial forwarding path to the destination device, and if the second network device on that partial forwarding path can calculate the remaining forwarding path, the first network device can determine the second network device as the one assisting it in calculating the remaining path to the destination device, i.e., the forwarding path from the second network device to the destination device.

[0208] For example, if a message has certain forwarding constraints, such as Service Level Agreement (SLA) requirements, and the first network device cannot obtain the SLAs corresponding to all or part of the links in the network topology, the first network device can determine that it needs the assistance of a second network device to calculate the forwarding path to the destination device. The second network device can obtain the SLAs corresponding to all or part of the links in the network topology.

[0209] In one possible embodiment, the first network device may determine, based on the service requirements, that the destination device of the packet is not located in the first region, where the first network device is located, and the first network device can only obtain the topology of the first region. Based on the topology of the first region, the first network device determines the second network device, which is the boundary device between the first and second regions. The second region is either the region where the destination device is located, or the region through which the forwarding path to the destination device must pass.

[0210] In other words, when packet forwarding requires crossing regions, the first network device may not be able to obtain the topology of other regions, and therefore cannot calculate the complete packet forwarding path. In this case, the first network device can determine a boundary device for that region based on its own topology to assist in calculating the path to the destination device. This boundary device may be located not only in the region where the first network device is located, but also in the region where the destination device is located, or in a region that the forwarding path to the destination device must traverse. In this way, the boundary device can obtain the topology of regions outside the region where the first network device is located, thereby calculating the packet forwarding path.

[0211] In other possible application scenarios, the first network device may also need the second network device to help it determine information related to the forwarding path for other reasons.

[0212] Step 603: The first network device sends a first message to the second network device to establish a first connection with the second network device.

[0213] Step 604: The first network device sends a second message to the second network device using the first connection.

[0214] In this embodiment, the two messages can be used to request the second network device to calculate a first path to the destination device. The second message may include, for example, the addresses of the two endpoint devices of the first path (i.e., the address of the second network device and the address of the destination device of the message).

[0215] Step 605: The first network device receives a third message sent by the second network device, the third message including indication information of the first path.

[0216] The indication information of the first path returned by the third message can be used to indicate the complete path from the second network device to the destination device, or it can indicate a part of the complete path.

[0217] In one possible implementation, after the second network device receives the second message sent by the first network device, the second network device can determine a first path to the destination device and send the indication information corresponding to the first path to the first network device via a third message. For example, when the second network device and the destination device of the message are located in the same area, the second network device can calculate the path from itself to the destination device of the message based on the topology of that area, and send the calculated tag stack information indicating the path as the path indication information to the first network device via a third message.

[0218] In another possible implementation, the second network device may determine the topology of the area the packet needs to traverse and send this topology to the first network device via a third message. For example, when the second network device and the destination device of the packet are located in the same area, the second network device can determine that the packet needs to pass through that area to reach the destination device. Therefore, the second network device can send the topology of that area as path indication information to the first network device via a third message. In this way, the first network device can obtain the topology of the area where the destination device is located and calculate the path to the destination device based on that topology.

[0219] In one possible embodiment, the first network device may also be a plurality of network devices that assist it in calculating the path to the destination device, and establish a connection with the plurality of network devices to request the plurality of network devices to assist in calculating the path to the destination device.

[0220] For example, the message forwarding method 600 may further include:

[0221] The first network device determines a third network device based on the network topology. The third network device is a boundary device between the aforementioned first and second regions, meaning the region where the third network device is located is the same as the region where the second network device is located. The first network device establishes a second connection with the third network device, which may be, for example, a PECP session connection. The first network device uses the second connection to send a fourth message to the third network device, requesting the third network device to calculate a second path to the destination device. The first network device receives a fifth message from the third network device, which includes indication information for the second path. Based on the third and fifth messages, the first network device determines part or all of the forwarding path for the packet. For example, the first network device can select one of the paths returned by the second and third network devices based on a preset path selection strategy to determine the packet forwarding path.

[0222] In other words, if the first network device determines that both the second and third network devices are boundary devices of the first and second areas, the first network device can establish a PECP session connection with the second and third network devices to request the calculation of the path to the destination device. After obtaining the path indication information returned by the second and third network devices, the first network device combines the path indication information returned by the two network devices to determine the forwarding path of the packet.

[0223] To facilitate understanding, the process of determining the forwarding path of a packet in a cross-domain scenario will be described in detail below with specific examples. Refer to Figures 7(a) and 7(b). Figure 7(a) is a flowchart illustrating a method 700 for determining the forwarding path of a packet according to an embodiment of this application; Figure 7(b) is a schematic diagram of the network architecture of the application of the method 700 for determining the forwarding path of a packet according to an embodiment of this application. As shown in Figure 7(b), network device 1, network device 2, and network device 3 are located in region 1; network device 2 and network device 3 are also located in region 2; and network device 4, network device 5, and network device 6 are located in region 2.

[0224] The method 700 for determining the forwarding path of a message includes the following steps.

[0225] Step 701: Network device 1 determines the forwarding path of the packet that it cannot calculate based on the business requirements.

[0226] The service requirement could be to forward packets to network device 6. Since network device 6 is located in area 2, while network device 1 is located in area 1, and network device 1 does not have the topology of area 2, network device 1 can determine that it cannot calculate a path to network device 6. Network device 6 may or may not be the destination device of the packet, but it may be connected to a destination device.

[0227] Step 702: Network device 1 determines network device 2 and network device 3 based on the topology of area 1.

[0228] Based on the topology of region 1, network device 1 can determine that network devices 2 and 3 are boundary devices of region 1, and that network devices 2 and 3 may have the topology of region 2. Therefore, network device 1 can determine the forwarding path for packets to be calculated with the assistance of network devices 2 and 3.

[0229] Step 703, Network device 1 sends message 1 to network device 2 to establish a PECP session connection 1 with network device 2.

[0230] Step 704: Network device 1 sends message 2 to network device 3 to establish a PECP session connection 2 with network device 3.

[0231] The process of establishing a PECP session connection between network device 1, network device 2, and network device 3 can be referred to the above embodiments, and will not be repeated here.

[0232] Step 705, network device 1 sends message 3 to network device 2 using PECP session connection 1. Message 3 is used to request network device 2 to calculate path 1 to network device 6.

[0233] Here, path 1 leading to network device 6 can refer to the path from network device 2 to network device 6.

[0234] Step 706: Network device 1 sends message 4 to network device 3 using PECP session connection 2. Message 4 is used to request network device 3 to calculate path 2 to network device 6.

[0235] Here, the path 2 leading to network device 6 can refer to the path from network device 3 to network device 6.

[0236] Step 707: Network device 2 determines the indication information 1 for path 1 based on message 3.

[0237] Since network device 2 is a boundary device of region 2, network device 2 can obtain the topology of region 2. Therefore, network device 2 can determine path 1 from itself to network device 6 based on the topology of region 2. In this way, network device 2 can determine indication information 1 based on path 1 from itself to network device 6. This indication information 1 may include, for example, label stack information indicating path 1.

[0238] Step 708: Network device 2 sends instruction information 1 to network device 1.

[0239] Step 709: Network device 3 determines the indication information 2 for path 2 based on message 4.

[0240] Similarly, since network device 3 is the boundary device of region 2, network device 3 can also obtain the topology of region 2 and determine the path 2 from itself to network device 6 based on the topology of region 2. In this way, network device 3 can determine indication information 2 based on the path 2 from itself to network device 6, which may include, for example, label stack information indicating path 2.

[0241] Step 710: Network device 3 sends instruction information 2 to network device 1.

[0242] Step 711: Network device 1 determines the path to network device 6 based on instruction information 1 and instruction information 2.

[0243] After receiving indication information 1 corresponding to path 1 and indication information 2 corresponding to path 2, network device 1 can obtain path 1 from network device 2 to network device 6 and path 2 from network device 3 to network device 6. Network device 1 can select one path from path 1 and path 2 based on a preset path selection strategy to determine the path to network device 6. For example, if network device 1 selects path 1 from path 1 and path 2, the network device can generate a path from network device 1 to network device 2, and then from network device 2 to network device 6.

[0244] The above describes the process of determining the forwarding path of a packet when the forwarding path crosses a single domain. The following will describe in detail the process of determining the forwarding path of a packet when the forwarding path crosses multiple domains, using specific examples.

[0245] Please refer to Figures 8(a) and 8(b). Figure 8(a) is a flowchart illustrating a method 800 for determining a packet forwarding path according to an embodiment of this application. Figure 8(b) is a schematic diagram of the architecture of an application network for a method 800 for determining a packet forwarding path according to an embodiment of this application.

[0246] As shown in Figure 8(b), network devices 1, 2 and 3 are in region 1, network devices 2, 3, 4, 5 and 6 are in region 2, and network devices 6, 7, 8 and 9 are in region 3.

[0247] The method 800 for determining the forwarding path of a message includes the following steps.

[0248] Step 801: Network device 1 determines the forwarding path of packets that it cannot calculate based on business requirements.

[0249] The service requirement could be to forward packets to network device 9. Since network device 9 is located in area 3, while network device 1 is located in area 1, and network device 1 does not have the topology of area 3, network device 1 can determine that it cannot calculate the path to network device 9.

[0250] Step 802: Network device 1 determines network device 2 based on the topology of area 1.

[0251] Based on the topology of region 1, network device 1 can determine that network device 2 is a boundary device of region 1, and network device 2 may have the topology of region 3. Therefore, network device 1 can determine that network device 2 will assist it in calculating the forwarding path of packets.

[0252] Step 803: Network device 1 sends message 5 to network device 2 to establish a PECP session connection 3 with network device 2.

[0253] In step 804, network device 1 sends message 6 to network device 2 using PECP session connection 3. Message 6 is used to request network device 2 to calculate path 3 to network device 9.

[0254] Here, the path 3 leading to network device 9 can refer to the path from network device 2 to network device 9.

[0255] In step 805, network device 2 sends message 7 to network device 6, which requests network device 6 to calculate path 4 to network device 9.

[0256] Since network device 9 is located in region 3, and network device 2 does not have the topology of region 3, network device 2 can determine that it cannot calculate a path to network device 9. At this point, network device 2 can determine that network device 6 is a boundary device of region 2 based on the topology of region 2, meaning that network device 6 may have the topology of region 3. Therefore, network device 2 can determine that network device 6 should assist it in calculating the packet forwarding path, and thus sends message 7 to network device 6. This message 7 requests network device 6 to calculate path 4 to network device 9, which can be a path from network device 6 to network device 9.

[0257] Step 806: Network device 6 determines the indication information 3 corresponding to path 4 based on message 7.

[0258] Since network device 6 is a boundary device of region 3, network device 6 can obtain the topology of region 3. Therefore, network device 6 can determine the path 4 from itself to network device 9 based on the topology of region 3. In this way, network device 6 can determine the indication information 3 based on the path 4 from itself to network device 9. The indication information 3 may include, for example, the label stack information indicating the path 4.

[0259] Step 807: Network device 6 sends indication information 3 corresponding to path 4 to network device 2.

[0260] It is understood that, in addition to sending the indication information 3 corresponding to path 4 to network device 2, network device 6 can also send the indication information 3 directly to network device 1. This embodiment does not make any specific limitations.

[0261] Step 808: Network device 2 determines the indication information 4 corresponding to path 3 based on indication message 3.

[0262] After receiving the instruction information 3, network device 2 can obtain the path 3 from itself to network device 9 based on its own path to network device 6 and the path from network device 6 to network device 9 indicated by the instruction information 3, thereby determining the instruction information 4 corresponding to the path.

[0263] Step 809: Send indication information 4 corresponding to path 3 to network device 1.

[0264] Step 810: Network device 1 determines the path to network device 9 based on instruction information 4.

[0265] Similarly, after receiving the instruction information 4, network device 1 can determine the path from itself to network device 9 based on the path from itself to network device 2 and the path 3 indicated by the instruction information 4.

[0266] The above embodiments are provided as examples to illustrate the scenarios in which the service processing methods provided in this application are applied. It is understood that the service processing methods provided in this application can also be applied to network scenarios where controllers and repeaters are deployed, and the type of controller deployed in the network to which this application is applied is not exclusively limited.

[0267] To implement the above embodiments, this application also provides a network device. See also... Figure 9 , Figure 9 This is a schematic diagram of the structure of a network device 900 provided in an embodiment of this application.

[0268] Figure 9 Although the network device 900 shown has certain specific features, those skilled in the art will realize from the embodiments of this application that, for the sake of brevity, Figure 9 Various other features are not shown to avoid obscuring more relevant aspects of the implementation methods disclosed in this application. Therefore, as an example, in some implementations, the network device 900 includes one or more processors 901, a network interface 902, a programming interface 903, a memory 904, and one or more communication buses 909 for interconnecting various components. In other implementations, the network device 900 may omit or add some functional components or units based on the above examples.

[0269] In some implementations, network interface 902 is used, among other purposes, to connect to one or more other network devices / servers in a network system. In some implementations, communication bus 909 includes circuitry for interconnecting and controlling communication between system components. Memory 904 may include non-volatile memory, such as 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. Memory 904 may also include volatile memory, which may be random access memory (RAM) used as an external cache.

[0270] In some implementations, memory 904 or a non-transitory computer-readable storage medium of memory 904 stores the following programs, modules and data structures, or subsets thereof, specifically including transceiver units (not shown) and processing units 9041.

[0271] In one possible embodiment, the network device 900 may be, for example, the first network device described in the above embodiments. The network device 900 may include, for example, a transceiver unit and a processing unit 9041;

[0272] In one possible embodiment, the network device 900 may have any of the functions of the first network device in method 200 or method 300 described above. The network device 900 may, for example, include a transceiver unit and a processing unit 9041; the transceiver unit is used to execute steps 202, 203, 204, 303, 304, or 305 described above; the processing unit 9041 is used to execute steps 201, 301, or 302 described above.

[0273] It is understood that the functions of the transceiver unit described above can be implemented by the processor calling program code in the memory and cooperating with the network interface 902 when needed; or the data transmission and reception operations can be completed by the network interface 902 on the network device 900.

[0274] In various implementations, the network device 900 is used to execute the service processing method provided in the embodiments of this application, such as executing the above-described method. Figures 2 to 8(b) The business processing method corresponding to the embodiment shown.

[0275] Corresponding to the method embodiments and virtual device embodiments provided in this application, this application also provides a network device, and the hardware structure of the network device is described below.

[0276] Please refer to Figure 10 , Figure 10 This is a schematic diagram of the structure of a network device 1000 provided in an embodiment of this application. The network device 1000 can be configured as the first network device in the above method embodiment.

[0277] Network device 1000 corresponds to the first network device in the above method embodiments. The various hardware components, modules, and other operations and / or functions in network device 1000 are respectively for implementing the various steps and methods performed by the first network device in the method embodiments. For detailed information on how network device 1000 forwards packets, please refer to the above method embodiments; for brevity, they will not be repeated here. The steps of method 200 or method 300 are completed through integrated logic circuits in the hardware of the network device 1000 processor or through software instructions. The steps of the methods disclosed in this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above methods. To avoid repetition, detailed descriptions are not provided here.

[0278] Network device 1000 corresponds to network device 900 in the above virtual device embodiment. Each functional module in network device 900 is implemented using software from network device 1000. In other words, the functional modules included in network device 900 are generated by the processor of network device 1000 after reading the program code stored in memory.

[0279] Network device 1000 includes: main control board 1010 and interface board 1030.

[0280] The main control board 1010, also known as the main processing unit (MPU) or route processor card, controls and manages the various components in the network device 1000, including route calculation, device management, device maintenance, and protocol processing functions. The main control board 1010 includes a central processing unit 1011 and a memory 1012.

[0281] Interface board 1030 is also known as a line processing unit (LPU), linecard, or service board. Interface board 1030 provides various service interfaces and implements packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces, POS (Packet over SONET / SDH) interfaces, etc., with Ethernet interfaces such as Flexible Ethernet Clients (FlexE Clients). Interface board 1030 includes: a central processing unit 1031, a network processor 1032, a forwarding table entry memory 1034, and a physical interface card (PIC) 1033.

[0282] The central processing unit 1031 on the interface board 1030 is used to control and manage the interface board 1030 and communicate with the central processing unit 1011 on the main control board 1010.

[0283] The network processor 1032 is used to implement packet forwarding processing. The network processor 1032 can be in the form of a forwarding chip. Specifically, uplink packet processing includes: packet ingress interface processing, forwarding table lookup; downlink packet processing includes: forwarding table lookup, etc.

[0284] Physical interface card 1033 is used to implement physical layer interfacing functions. Raw traffic enters interface board 1030 through this card, and processed packets are sent out from the physical interface card 1033. Physical interface card 1033 includes at least one physical interface, also called a physical port. Physical interface card 1033 corresponds to FlexE physical interface 204 in system architecture 200. Physical interface card 1033, also called a daughter card, can be installed on interface board 1030 and is responsible for converting photoelectric signals into packets, performing validity checks on the packets, and forwarding them to network processor 1032 for processing. In some embodiments, the central processing unit 1031 of interface board 1003 can also perform the functions of network processor 1032, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for network processor 1032 in physical interface card 1033.

[0285] Optionally, the network device 1000 includes multiple interface boards. For example, the network device 1000 also includes an interface board 1040, which includes a central processing unit 1041, a network processor 1042, a forwarding table entry memory 1044, and a physical interface card 1043.

[0286] Optionally, the network device 1000 also includes a switching fabric board 1020. The switching fabric board 1020 can also be referred to as a switch fabric unit (SFU). In cases where the network device has multiple interface boards 1030, the switching fabric board 1020 is used to complete data exchange between the interface boards. For example, interface boards 1030 and 1040 can communicate via the switching fabric board 1020.

[0287] The main control board 1010 and the interface board 1030 are coupled. For example, the main control board 1010, interface boards 1030 and 1040, and the switching network board 1020 are interconnected via a system bus and connected to the system backplane. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 1010 and the interface board 1030, and the main control board 1010 and the interface board 1030 communicate with each other through the IPC channel.

[0288] Logically, network device 1000 includes a control plane and a forwarding plane. The control plane includes a main control board 1010 and a central processing unit 1031, while the forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 1034, a physical interface card 1033, and a network processor 1032. The control plane performs functions such as router operation, generating forwarding tables, processing signaling and protocol messages, and configuring and maintaining the device's status. The control plane distributes the generated forwarding tables to the forwarding plane. In the forwarding plane, the network processor 1032 uses the forwarding tables distributed by the control plane to look up and forward messages received by the physical interface card 1033. The forwarding tables distributed by the control plane can be stored in the forwarding table entry memory 1034. In some embodiments, the control plane and the forwarding plane can be completely separated and not on the same device.

[0289] If network device 1000 is configured as the first network device in method 200, central processing unit 1011 acquires a message; adds first indication information and second indication information to the message to obtain an updated message. Network processor 1032 triggers physical interface card 1033 to send the updated message to the second network device.

[0290] If network device 1000 is configured as the first network device in method 300, the central processing unit 1011 determines the second network device on the packet forwarding path according to service requirements. The network processor 1032 triggers the physical interface card 1033 to send a first message and a second message to the second network device.

[0291] It should be understood that the transceiver unit in network device 900 is equivalent to physical interface card 1033 or physical interface card 1043 in network device 1000; the acquisition module 901 and processing unit 902 in network device 900 can be equivalent to central processing unit 1011 or central processing unit 1031 in network device 1000.

[0292] It should be understood that the operation on interface board 1040 in this embodiment is consistent with the operation on interface board 1030, and will not be described again for the sake of simplicity. It should be understood that the network device 1000 in this embodiment can correspond to the first network device or the second network device in the above-described method embodiments. The main control board 1010, interface board 1030 and / or interface board 1040 in the network device 1000 can implement the functions and / or various steps implemented by the first network device or the second network device in the above-described method embodiments, and will not be described again for the sake of simplicity.

[0293] It's worth noting that a network device may have one or more main control boards, including a primary and a backup main control board. It may also have one or more interface boards; the more powerful the network device's data processing capabilities, the more interface boards it provides. Each interface board may also have one or more physical interface cards. A switching board may or may not exist; multiple boards can share the load and provide redundancy. In a centralized forwarding architecture, the network device may not need a switching board, as the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the network device can have at least one switching board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture network device are greater than those of a centralized architecture device. Alternatively, the network device can also be a single board, without a switching board. The functions of the interface board and the main control board are integrated on this one board. In this case, the central processing unit (CPU) on the interface board and the CPU on the main control board can be combined into a single CPU to perform the combined functions. This type of device has lower data exchange and processing capabilities (e.g., low-end switches or routers). The specific architecture used depends on the specific network deployment scenario, and no restrictions are imposed here.

[0294] In some possible embodiments, the first or second network device described above can be implemented as a virtualized device. For example, a virtualized device can be a virtual machine (VM) running a program for sending messages, and the VM is deployed on a hardware device (e.g., a physical server). A virtual machine refers to a complete computer system with full hardware system functionality simulated by software, running in a completely isolated environment. The virtual machine can be configured as the first or second network device. For example, the first or second network device can be implemented based on a general-purpose physical server combined with Network Functions Virtualization (NFV) technology. The first or second network device can be a virtual host, a virtual router, or a virtual switch. Those skilled in the art can virtualize the first or second network device with the above-mentioned functions on a general-purpose physical server by combining NFV technology by reading this application. Further details are omitted here.

[0295] It should be understood that the network devices of the various product forms described above each have any of the functions of the first network device or the second network device in the above method embodiments, which will not be elaborated here.

[0296] This application provides a computer program product that, when run on a network device, causes the network device to execute the method executed by the first network device in method 200 or method 300 described above.

[0297] See Figure 11 This application provides a network system 1100, which includes network device 1101 and network device 1102. Optionally, network device 1101 can be the first network device in method 200, network device 900, or network device 1000, and network device 1101 is the head node in the network; network device 1102 can be the first network device in method 300, network device 900, or network device 1000, and network device 1102 is an intermediate node in the network. Optionally, system 1100 may further include network device 1103, which can be the network device 900 or network device 1000, and network device 1103 is the tail node in the network.

[0298] This application also provides a chip, including a processor and an interface circuit. The interface circuit is used to receive instructions and transmit them to the processor. The processor is coupled to a memory, which stores programs or instructions. When the processor executes the programs or instructions, the chip system implements the methods described in any of the above method embodiments.

[0299] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0300] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0301] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0302] The embodiments of this application have been described in detail above. The steps in the method of the embodiments of this application can be scheduled, merged or deleted in sequence according to actual needs; the modules in the device of the embodiments of this application can be divided, merged or deleted according to actual needs.

[0303] It should be understood that the phrase "an embodiment" or "one embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "one embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence number of the above-described processes does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0304] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0305] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0306] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0307] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0308] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0309] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0310] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0311] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device / server, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.< / open>

Claims

1. A service processing method characterized by, Comprising: The first network device determines a second network device on a forwarding path of a packet according to a service requirement, the packet belonging to the service; When it is determined based on the service requirement that the second network device is needed to assist the first network device in determining information related to the forwarding path of the packet, the first network device sends a first message to the second network device to establish a first connection with the second network device; The first network device sends a second message to the second network device through the first connection, the second message being used to request the second network device to assist in determining the information related to the forwarding path.

2. The service processing method according to claim 1, characterized by, The method further comprises: The first network device receives a third message sent by the second network device, the third message comprising the information related to the forwarding path.

3. The service processing method according to claim 1 or 2, characterized by, The first network device determines a second network device on a forwarding path of a packet according to a service requirement, comprising: The first network device determines, according to the service requirement, that the first network device cannot determine information related to the forwarding path of the packet; The first network device determines the second network device for assisting in determining the information related to the forwarding path.

4. The service processing method according to claim 1 or 2, characterized by, The information related to the forwarding path comprises a stick label and / or a path label used to indicate the forwarding path.

5. The service processing method of claim 1, wherein The first network device determines a second network device on a forwarding path of a packet according to a service requirement, comprising: The first network device determines the forwarding path of the packet according to the service requirement; The first network device determines, according to the forwarding path of the packet, that the second network device is a stick node for allocating a stick label; The first network device sends a second message to the second network device through the first connection, comprising: The first network device sends a second message to the second network device through the first connection, the second message comprising label stack information, the second message being used to request the second network device to allocate a stick label corresponding to the label stack information.

6. The service processing method according to claim 5, characterized by, The first network device determines, according to the forwarding path of the packet, that the second network device is a stick node, comprising: The first network device determines, according to the forwarding path of the packet, that the number of labels to be used for indicating the forwarding path is greater than the maximum number of labels that a label stack can carry; The first network device determines, according to the forwarding path, the second network device as a network device on the forwarding path of the packet.

7. The service processing method of claim 2, wherein, The first network device determines a second network device on a forwarding path of a packet according to a service requirement, comprising: The first network device determines, according to the service requirement, that the first network device cannot calculate the forwarding path of the packet; The first network device determines, according to a network topology, the second network device as a network device on the forwarding path of the packet, the second network device being used to assist the first network device in calculating a first path to a destination device.

8. The service processing method according to claim 7, characterized by, The first network device determines, according to the service requirement, that the first network device is unable to calculate a forwarding path of the packet, including: The first network device determines, according to the service requirement, that a destination device of the packet is not located in a first region, the first region being a region where the first network device is located; The first network device determines, according to a topology of the first region, a second network device, the second network device being a border device of the first region and a second region, the second region being a region where the destination device is located or the second region being a region that needs to be passed through by the forwarding path to the destination device.

9. The service processing method according to claim 7 or 8, characterized by, The first network device sends, to the second network device, a second message through the first connection, the second message being used to request the second network device to calculate a first path to the destination device, the third message including indication information of the first path.

10. The service processing method according to claim 9, characterized by, The method further includes: The first network device determines, according to the network topology, a third network device, the third network device being a border device of the first region and the second region; The first network device establishes a second connection with the third network device; The first network device sends, to the third network device, a fourth message through the second connection, the fourth message being used to request the third network device to calculate a second path to the destination device; The first network device receives a fifth message sent by the third network device, the fifth message including indication information of the second path; The first network device determines part or all of the forwarding path of the packet according to the third message and the fifth message.

11. The transaction processing method according to any one of claims 1 to 2, characterized by, The first connection includes a path computation element communication protocol (PCEP) connection.

12. The transaction processing method of claim 11, wherein, The first network device sends, to the second network device, a first message to establish a first connection with the second network device, including: The first network device establishes a transmission control protocol (TCP) connection with the second network device; The first network device sends, to the second network device, the first message through the TCP connection to negotiate with the second network device to establish the first connection.

13. The service processing method according to any one of claims 1 to 2, characterized in that: The first network device is a head node device on the forwarding path of the packet.

14. The service processing method according to claim 13, characterized in that: The first network device and the second network device are both path computation client (PCC) devices on the forwarding path.

15. The transaction processing method according to any one of claims 1 to 2, wherein The forwarding path of the packet includes one or more of a segment routing policy (SR) path, an internet protocol version 4-based segment routing (SRV4) path, an internet protocol version 6-based segment routing (SRV6) path, a segment routing-traffic engineering (SR-TE) path, and a multiprotocol label switching-traffic engineering (MPLS-TE) path.

16. A network device, comprising: including: a processor and a memory; the memory is used to store instructions; The processor is configured to execute instructions in the memory, so that the network device performs the method according to any one of claims 1 to 15.

17. A computer readable storage medium characterized by: The computer readable storage medium stores computer readable instructions, and when the computer readable instructions are executed by the processor, the method according to any one of claims 1 to 15 is implemented.

Images