PATH DATA DELETION METHOD, MESSAGE FORWARDING METHOD, AND APPARATUS

Abstract

Embodiments of this application disclose a path data deletion method, a message forwarding method, and related apparatus. A controller disclosed in this application may obtain an identifier of an invalid path from a network node located on the invalid path, and determine, based on the identifier of the invalid path and a first network node providing the identifier of the invalid path, at least a second network node located on the invalid path. The controller is configured to send a path deletion message to the second network node to assist in cleaning invalid path data remaining in a network node, so that it is possible to disable periodic path data synchronization of a network node in a RSVP-TE mechanism. In addition, because path data of an invalid path is cleaned, abnormal data forwarding can be avoided and system stability can be improved.

Claims

1. A path data deletion method, applied to a network in which a resource reservation protocol-traffic engineering (RSVP-TE) is deployed, wherein the network comprises a controller and a plurality of network nodes, the plurality of network nodes comprises a first network node and a second network node, and the method comprises: obtaining, by the controller, an identifier of an invalid path from the first network node, wherein the first network node is a network node on the invalid path; determining, by the controller, the second network node based on the identifier of the invalid path, wherein the second network node is a network node on the invalid path; and sending, by the controller, a path deletion message to the second network node, wherein the path deletion message is used to instruct to delete path data related to the invalid path.

2. The method according to claim 1, wherein the path deletion message is a path computation update PCUpd message, the PCUpd message comprises a path field and a label switched path LSP object field, the path field is set to be optional, the LSP object field comprises a flag bit, and the flag bit is used to identify whether a network node receiving the PCUpd message is a network node other than an initial network node in a forwarding direction of a path.

3. A path data deletion controller, applied to a network in which a resource reservation protocol-traffic engineering (RSVP-TE) is deployed, wherein the network comprises the controller and a plurality of network nodes, the plurality of network nodes comprises a first network node and a second network node, and the controller comprises an obtaining unit, a determining unit, and a sending unit, wherein the obtaining unit is configured to obtain an identifier of an invalid path from the first network node, wherein the first network node is a network node on the invalid path; the determining unit is configured to determine the second network node based on the identifier of the invalid path, wherein the second network node is a network node on the invalid path; and the sending unit is configured to send a path deletion message to the second network node, wherein the path deletion message is used to instruct to delete path data related to the invalid path.

4. The controller according to claim 3, wherein the second network node is a network node adjacent to the first network node on the invalid path.

5. The controller according to claim 3, wherein the first network node is an initial network node in a forwarding direction of the invalid path, and the obtaining unit is further configured to obtain a path report message sent by the first network node, wherein the path report message is used to indicate that the invalid path needs to be deleted, and the path report message comprises the identifier of the invalid path.

6. The controller according to claim 3, wherein the controller further comprises a judging unit, wherein the judging unit is configured to: determine whether the second network node is a last network node in the forwarding direction of the invalid path, and if the second network node is not the last network node, trigger the determining unit; and the determining unit is configured to: determine an identifier of a third network node based on a topology structure of the invalid path, wherein the third network node is a next network node of the second network node in the forwarding direction of the invalid path; and use the third network node as the second network node, and trigger the judging unit.

7. The controller according to claim 3, wherein the determining unit is further configured to: determine the topology structure of the invalid path based on the identifier of the invalid path; determine an identifier of the second network node based on the topology structure, wherein the second network node is a next network node of the first network node in the forwarding direction of the invalid path; and determine an address of the second network node based on the identifier of the second network node; and the sending unit is further configured to send the path deletion message to the second network node based on the address of the second network node.

8. The controller according to claim 3, wherein the determining unit is further configured to search for addresses of the plurality of network nodes in the network; and the sending unit is further configured to send the path deletion message to the plurality of network nodes based on the addresses of the plurality of network nodes.

9. The controller according to claim 3, wherein the first network node is a network node other than an initial network node in a forwarding direction of the invalid path, and the obtaining unit is further configured to obtain a path report message sent by the first network node, wherein the path report message is used to indicate that the invalid path needs to be deleted, and the path report message comprises the identifier of the invalid path.

10. The controller according to claim 9, wherein the obtaining unit is further configured to: if a fault occurs on a path between the second network node and the first network node on the invalid path, obtain the path report message sent by the first network node.

11. The controller according to claim 9, wherein the controller further comprises a judging unit, wherein the obtaining unit is further configured to obtain a delegation message sent by a fourth network node, wherein the delegation message comprises an address of the fourth network node and path data of a path on which the fourth network node is located, and the fourth network node is a network node other than the initial network node in the forwarding direction of the invalid path; the judging unit is configured to: determine, based on the path data of the path on which the fourth network node is located, whether the fourth network node comprises the path data of the invalid path; and if the fourth network node comprises the path data of the invalid path, trigger the sending unit; and the sending unit is further configured to send the path deletion message to the fourth network node.

12. The controller according to claim 11, wherein the obtaining unit obtains the delegation message after obtaining the path report message.

13. The controller according to claim 9, wherein a fifth network node is the initial network node in the forwarding direction of the invalid path, and the controller further comprises a comparison unit, wherein the obtaining unit is further configured to obtain a path change message sent by the fifth network node, wherein the path change message comprises a topology structure of a changed path, the changed path is obtained by changing the invalid path, and an identifier of the changed path is the same as the identifier of the invalid path; the comparison unit is configured to: determine, through comparison, a distinctive part of the invalid path different from the changed path; and determine a network node located on the distinctive part; and the sending unit is further configured to send the path deletion message to the network node located on the distinctive part.

14. A message forwarding controller, applied to a network in which a resource reservation protocol-traffic engineering (RSVP-TE) is deployed, wherein the network comprises the controller and a plurality of network nodes, the plurality of network nodes comprises a first network node and a second network node, and the controller comprises an obtaining unit and a forwarding unit, wherein the obtaining unit is configured to obtain, from the first network node, a transfer message carrying an identifier of the second network node, wherein the first network node and the second network node are network nodes on a same path; and the forwarding unit is configured to forward the transfer message to the second network node based on the identifier of the second network node.

15. The controller according to claim 14, wherein the forwarding unit is further configured to: determine an address of the second network node based on the identifier of the second network node; and forward the transfer message to the address of the second network node.

16. The controller according to claim 14, wherein the transfer message is sent by the first network node when the path becomes an invalid path.

17. The controller according to claim 16, wherein the transfer message is sent when a path deletion message sent by the first network node to the second network node is lost.

18. The controller according to claim 14, wherein the controller further comprises an obtaining unit, wherein the obtaining unit is configured to: obtain an acknowledgement message returned by the second network node, wherein the acknowledgement message is used to identify that the second network node has received the transfer message, and the acknowledgement message carries an identifier of the first network node.

19. The controller according to claim 18, wherein the controller further comprises a sending unit, wherein the sending unit is configured to: send the acknowledgement message to the first network node based on the identifier of the first network node.

20. The controller according to claim 14, wherein the transfer message or the acknowledgement message is a path computation notify with data (PCNtf with Data) message, an optional type length value field in the PCNtf with Data message comprises a destination address field and an opaque data field, the destination address field is used to carry an identifier of a network node receiving the PCNtf with Data message, and the opaque data field is used to carry a message that needs to be received by the network node receiving the PCNtf with Data message.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0117] FIG. 1a is a schematic diagram of connections between a controller and network nodes according to an embodiment of this application;

[0118] FIG. 1 is a method flowchart of a path data deletion method according to an embodiment of this application;

[0119] FIG. 2 is a schematic diagram of a PCUpd message format and a PCUpd message format that is provided in an embodiment of this application;

[0120] FIG. 3A and FIG. 3B are a schematic diagram of an LSP object field format and an LSP object field format that is provided in an embodiment of this application;

[0121] FIG. 4 is a schematic diagram of a PCRpt message format and a PCRpt message format that is provided in an embodiment of this application;

[0122] FIG. 5 is a schematic diagram of connections between a controller and network nodes according to an embodiment of this application;

[0123] FIG. 6 is a method flowchart of determining a second network node according to an embodiment of this application;

[0124] FIG. 7 is a schematic diagram of connections between a controller and network nodes in an application scenario according to an embodiment of this application;

[0125] FIG. 8 is a signaling diagram between a controller and network nodes in an application scenario according to an embodiment of this application;

[0126] FIG. 9 is a schematic diagram of connections between a controller and network nodes according to an embodiment of this application;

[0127] FIG. 10 is a method flowchart of sending a path deletion message to an intermediate node according to an embodiment of this application;

[0128] FIG. 11a is a signaling diagram between a controller and network nodes in an application scenario according to an embodiment of this application;

[0129] FIG. 11b is a signaling diagram between a controller and network nodes in an application scenario according to a second embodiment of this application;

[0130] FIG. 11c is a signaling diagram between a controller and network nodes in an application scenario according to a third embodiment of this application;

[0131] FIG. 12 is a method flowchart of sending a path deletion message by comparing path topologies according to an embodiment of this application;

[0132] FIG. 13 is a schematic diagram of connections between a controller and network nodes in an application scenario according to an embodiment of this application;

[0133] FIG. 14 is a method flowchart of a message forwarding method according to an embodiment of this application;

[0134] FIG. 15a is a schematic diagram of a PCNtf with Data message format according to an embodiment of this application;

[0135] FIG. 15b is a schematic diagram of a destination address field format according to an embodiment of this application;

[0136] FIG. 15c is a schematic diagram of a destination address field format according to an embodiment of this application;

[0137] FIG. 16 is a schematic diagram of connections between a controller and network nodes according to an embodiment of this application;

[0138] FIG. 17 is a schematic diagram of connections between a controller and network nodes in an application scenario according to an embodiment of this application;

[0139] FIG. 18 is a signaling diagram between a controller and network nodes in an application scenario according to an embodiment of this application;

[0140] FIG. 19 is an apparatus structural diagram of a path data deletion apparatus according to an embodiment of this application;

[0141] FIG. 20 is an apparatus structural diagram of a message forwarding apparatus according to an embodiment of this application;

[0142] FIG. 21 is a schematic hardware structural diagram of a controller according to an embodiment of this application; and

[0143] FIG. 22 is a schematic hardware structural diagram of a controller according to an embodiment of this application.

DESCRIPTION OF EMBODIMENTS

[0144] The following describes the embodiments of this application with reference to the accompanying drawings.

[0145] In a mechanism of a conventional RSVP-TE, a network node needs to periodically synchronize path-related data with an adjacent network node of the network node based on a network connection architecture. When a network is of a relatively large scale, a network node in the network has many adjacent network nodes. If the conventional RSVP-TE is deployed in the network, a network node in the network needs to consume a large amount of system resources to periodically synchronize path data, evidently affecting the network node in providing normal services at least in a data synchronization process. It can be learned that the conventional RSVP-TE is not suitable for networks of a relatively large scale.

[0146] However, if the mechanism of periodically synchronizing path data in the RSVP-TE is disabled, path data stored in a network node cannot be updated. For example, if a path has been deleted (down), and some network nodes on the path may not know the status due to a link failure, the network nodes continue to store path data of the path, that is, the path data that is already invalid, and the remaining path data evidently wastes storage space of the network nodes. In addition, the path data remaining in the network nodes may further cause function abnormality of the network nodes. For example, a network node stores path data of an invalid path, and a correspondence is established between an identifier of the invalid path and a new path. The new path may be obtained by changing the original invalid path. Then, when the network node obtains, from a path whose identifier is the identifier of the invalid path and data that needs to be forwarded, the network node may forward the data by using the path data of the invalid path. As a result, the data is forwarded to an incorrect network node, reducing system stability.

[0147] If the problem caused due to remaining invalid path data is not resolved, the mechanism of periodically synchronizing path data in the RSVP-TE cannot be disabled. If the mechanism of periodically synchronizing path data in the RSVP-TE is not disabled, the applicable scope of the RSVP-TE is limited. It can be learned that after the mechanism of periodically synchronizing path data in the RSVP-TE is disabled, how to delete remaining invalid path data in a network node is a technical problem that urgently needs to be resolved.

[0148] The embodiments of this application provide a path data deletion method and a message forwarding method. The path data deletion method and the message forwarding method are applied to a network in which the RSVP-TE is deployed. The RSVP-TE is improved in the embodiments of this application. A mechanism in which a network node needs to periodically synchronize path data with an adjacent network node is disabled, and a mechanism in which a controller in the network assists a network node in deleting stored path data of an invalid path is introduced.

[0149] In the embodiments of this application, the network in which the RSVP-TE provided in the embodiments of this application is deployed may be an IP core network or a generalized multiprotocol label switching (GMPLS) network. A quantity of network nodes included in the network is not limited. In other words, the RSVP-TE provided in the embodiments of this application may be deployed in a large-scale network. The network node may be a collective name of a processing device and a forwarding device used in the network, and may be a server, a router, a switch, or the like.

[0150] The network to which the embodiments of this application are applied further includes a controller. One controller may be connected to at least one network node in the network, and is configured to control the connected network node. A connection relationship between the controller and the at least one network node may be shown in FIG. 1a. In the embodiments of this application, if the at least one network node includes an initial network node that is located on a path and that is in a forwarding direction of the path, a path computation element communication protocol (PCEP) path may be established between the controller and the network node, for example, a PCEP path established between the controller and a node A in FIG. 1a. According to an improvement solution provided in the embodiments of this application, the controller may assist a network node in deleting path data that is of an invalid path and that is stored in the network node. The path in the embodiments of this application may include types such as a data link and a tunnel, and for example, may include a label switched path (LSP). One path may include at least two network nodes. For example, a path 1 may connect a network node a, a network node b, and a network node c, and a forwarding direction is from the network node a, to the network node b, and then to the network node c. The network node a, the network node b, and the network node c are network nodes located on the path, and each network node located on the path 1 may store path data of the path. For example, the network node b may store data related to the path such as a path identifier and inbound and outbound interface information of the path in the network node b.

[0151] The invalid path may be a path that no longer uses a forwarding function or that no longer has a forwarding function, for example, a deleted path, an expired path, or a path on which a fault occurs. For example, after the path 1 is deleted, the path 1 becomes an invalid path. If the network node b still stores the path data of the path 1, the path data may be considered as path data related to an invalid path. When the path 1 has become the invalid path, if the network node b still stores the path data, because the path data no longer has an actual function and it is equivalent to that the path data of the path 1 remains, that the network node b continues to store the path data that does not have an actual function is equivalent to that the network node b wastes storage space of the network node b, and the path data needs to be deleted under an instruction. In the embodiments of this application, the controller may instruct the network node b to delete the path data.

Embodiment 1

[0152] With reference to the accompanying drawings, the following describes a path data deletion method provided in this embodiment of this application. A network to which the method is applied includes a plurality of network nodes, for example, a first network node and a second network node. The network to which the method is applied further includes a controller.

[0153] FIG. 1 is a method flowchart of the path data deletion method according to this embodiment of this application. The method includes the following steps.

[0154] 101. The controller obtains an identifier of an invalid path from the first network node.

[0155] This application does not limit a manner in which the controller obtains the identifier of the invalid path, and specifies only that the identifier of the invalid path is obtained from a network node on the invalid path, that is, the first network node. The identifier of the invalid path may have a function of uniquely identifying the invalid path. For example, when the invalid path is an LSP, the identifier of the invalid path may be an ID of the LSP.

[0156] The first network node may be a network node on the invalid path, and which specific network node on the invalid path is the first network node may depend on a connection relationship between a network node on the invalid path and the controller and a specific application scenario. This part is to be described in detail in the following embodiment. When the controller obtains the identifier of the invalid path from the first network node, it means that the path identified by the identifier has become an invalid path. Alternatively, when a path becomes an invalid path, the controller obtains an identifier of the invalid path from the first network node. It should be noted that because the identifier of the invalid path is provided by the first network node for the controller, and it is equivalent to that the first network node has specified that the identifier provided for the controller is used to identify an invalid path. Generally, it is assumed that the first network node has deleted path data that is related to the invalid path and that is stored in the first network node.

[0157] 102. The controller determines the second network node based on the identifier of the invalid path.

[0158] Because the second network node is also located on the invalid path as the first network node, it is possible that the second network node still stores the path data of the invalid path. In consideration of this possibility, to avoid a waste of storage space of the second network node, the controller needs to instruct the second network node to delete the path data of the invalid path. Alternatively the controller needs to determine that the second network node has deleted the path data of the invalid path.

[0159] This embodiment of this application does not limit a position relationship between the second network node and the first network node on the invalid path, and each of the second network node and the first network node may be any network node on the invalid path. In an optional case, the second network node is a network node adjacent to the first network node. The adjacent position relationship may include at least two possibilities. In a first possibility, the second network node is a next hop (Hop) of the first network node in a forwarding direction of the invalid path, that is, the second network node is a next network node configured to receive data forwarded by the first network node. Then, the first network node and the second network node may be adjacent network nodes. Alternatively, in a second possibility, the first network node is a next hop of the second network node in a forwarding direction of the invalid path, that is, the first network node is a network node configured to receive data forwarded by the second network node. Then, the first network node and the second network node may be also adjacent network nodes.

[0160] The controller may clearly determine an address of a network node on the invalid path or a topology structure such as a record route object (RRO) of the invalid path by using the identifier of the invalid path, to determine the second network node adjacent to the first network node on the invalid path.

[0161] In addition to the second network node, in some application scenarios, the controller may further determine another network node located on the invalid path, that is, can determine at least a third network node based on the identifier of the invalid path.

[0162] 103. The controller sends a path deletion message to the second network node.

[0163] The controller may send the path deletion message to the second network node based on an address of the second network node. The address of the second network node may identify a specific position of the second network node in the network. If another network device such as the controller can learn of the address of the second network node, a message sent to the address of the second network node may be obtained by the second network node. An address of a network node may be an IP address of the network node, or may be a session address (Session ID) of the network node. The session address may be an address of a peer end of a PCEP session established between the controller such as a path computation element (PCE) and a network node such as a path computation client (PCC). A TCP connection is established between the PCE and the PCC. Session addresses of both a local end and a peer end of the connection may be represented by using IP addresses, which are similar to peer addresses in a border gateway protocol (BGP).

[0164] The RSVP-TE is improved, so that the controller can send, to the second network node, the path deletion message used to instruct to delete the path data related to the invalid path. The path deletion message may be a message of an original type in the RSVP-TE. Alternatively, the path deletion message may be obtained by improving a message of an original type of the RSVP-TE. Alternatively, the path deletion message may be of a new message type generated by improving the RSVP-TE.

[0165] This embodiment of this application provides an optional manner. The RSVP-TE is improved, to improve a message of an original type: a path computation update (PCUpd) message, to obtain the path deletion message used to instruct a network node to delete path data of an invalid path.

[0166] A format of a PCUpd message in the conventional RSVP-TE is shown in the left part of FIG. 2, and a format of an improved PCUpd message is shown in the right part of FIG. 2. The conventional PCUpd message is extended, to modify a path field <path> into an optional field [<path>]. The field herein may be in a format of a type length value (Type-length-value, TLV). When an LSP object field <LSP> carries an R flag bit, it identifies that the PCUpd message is used to indicate deletion (Remove). Because the path field <path> is an optional field, the path field may not need to be carried in the PCUpd message.

[0167] In addition, a new flag bit may be added to the LSP object field <LSP>, to identify whether a network node receiving the PCUpd message is a network node other than an initial network node in a forwarding direction of a path. For example, when a particular character is set in the new flag bit, it may be determined that the network node receiving the PCUpd message, for example, the second network node, is a network node other than the initial network node in the forwarding direction of the invalid path, namely, an intermediate node. When no character is set in the new flag bit, it may be determined that the network node receiving the PCUpd message, for example, the second network node, is the initial network node in the forwarding direction of the invalid path, namely, a head node. For modification of the LSP object field, refer to FIG. 3A and FIG. 3B. FIG. 3A shows a format of an LSP object field in the conventional RSVP-TE, and FIG. 3B shows a format of an improved LSP object field. It can be learned that a T flag bit is added to the right side of the LSP object field.

[0168] It should be noted that one network node may be located on a plurality of paths. For example, a network node A may be located on a path 1: A.fwdarw.B.fwdarw.C, and may be also located on a path 2: D.fwdarw.A.fwdarw.E. When the controller sends the path deletion message to the second network node, the second network node needs to know the specific path whose path data needs to be deleted. Therefore, the path deletion message may include the identifier of the invalid path, so that when the second network node obtains the path deletion message, the second network node can decide that path data related to an invalid path, such as the path 2 in path data stored in the second network node needs to be deleted. Certainly, in addition to sending the path deletion message to the second network node, the controller may further send the path deletion message to another network node that is on the invalid path and that is determined in step 102. The path deletion message may be sequentially sent, or may be simultaneously sent. This is related to a specific mechanism of determining a network node in step 102, or may be related to an application scenario. Details are not described herein.

[0169] It can be learned that to avoid the problem that in a mechanism of the RSVP-TE, invalid path data may remain in a network node because the network node periodically synchronizes path data, the controller may obtain the identifier of the invalid path from the network node located on the invalid path, and may determine, based on the identifier of the invalid path and the first network node providing the identifier of the invalid path, the second network node located on the invalid path, and the controller may send the path deletion message to the second network node, so that the second network node deletes the originally stored path data related to the invalid path. Therefore, the following case is avoided: the second network node wastes storage space in storing invalid path data. The controller may assist in cleaning invalid path data remaining in a network node, so that it is possible to disable periodic path data synchronization of the network node in the mechanism of the RSVP-TE. Therefore, the network node in the network in which the RSVP-TE is deployed does not need to consume resources to periodically synchronize path data with a neighboring network node, and with assistance of the controller, does not waste storage space in storing the path data of the invalid path. There is no obstacle for deploying the RSVP-TE in a large-scale network. Also the applicable range of the RSVP-TE is extended. In addition, because path data that is of an invalid path and that may remain in a network node is cleaned, abnormal data forwarding that may occur is avoided, and system stability is improved.

[0170] The following describes in detail the first network node in step 101 with reference to a connection relationship between a network node on the invalid path and the controller and a specific application scenario.

[0171] This embodiment of this application provides at least two scenarios of the position of the first network node on the invalid path. In a first case, the first network node is a head node on the invalid path. In a second case, the first network node is an intermediate node on the invalid path. The head node may be an initial network node in a forwarding direction of a path, and the intermediate node may be a network node other than the head node on the path. For example, on a path 1 A.fwdarw.B.fwdarw.C, a head node is a network node A, and an intermediate node may be a network node B or a network node C.

[0172] The RSVP-TE is improved. Therefore, when the first network node is the head node, the first network node may send a path report message carrying the identifier of the invalid path to the controller; or when the first network node is the intermediate node, the first network node may send a delegation message carrying the identifier of the invalid path or a path report message carrying the identifier of the invalid path to the controller.

[0173] The path report message or the delegation message may be a message of an original type in the RSVP-TE. Alternatively, the path report message or the delegation message may be obtained by improving a message of an original type by improving the RSVP-TE. Alternatively, the path report message or the delegation message may be a new message type generated by the improved RSVP-TE.

[0174] This embodiment of this application provides an optional manner. The improved RSVP-TE modifies a message of an original type: a path computation report (PCRpt) message is improved, to obtain the path report message or the delegation message.

[0175] A format of a PCRpt message in the conventional RSVP-TE is shown in the left part of FIG. 4, and a format of an improved PCRpt message is shown in the right part of FIG. 4. The conventional PCRpt message is extended, to modify the content carried in a path field <path> into optional [<intended_path> <actual_attribute_list> <actual_path> <intended_attribute_list>]. The field herein may be in a format of a type length value (Type-length-value, TLV). Because the path field <path> is an optional field, when the first network node is the intermediate node, the path report message or the delegation message sent to the controller may carry only an <actual_path> part in the path field <path>, and does not need to carry the other three parts. When the LSP object field <LSP> carries an R flag bit, it identifies that the PCRpt message is used to indicate deletion (Remove).

[0176] In addition, a new flag bit T may be further added to the LSP object field, and the flag bit is used to identify whether a network node sending the PCRpt message is an initial network node (a head node) in a forwarding direction of a path or a network node (an intermediate node) other than the initial network node in the forwarding direction of the path. For example, a character T may be filled in the flag bit to identify that the network node sending the PCRpt message is the intermediate node on the path; or no character is filled in the flag bit to identify that the network node sending the PCRpt message is the head node on the path.

[0177] The following describes a case in which the first network node is the head node on the invalid path.

[0178] In this case, for step 101, optionally, the controller may obtain the path report message sent by the first network node, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path.

[0179] There may be a plurality of scenarios in which the controller obtains, from the first network node, the path report message carrying the identifier of the invalid path. The following describes a relatively common scenario.

[0180] In this scenario, when the invalid path is still valid (referred to as the path 1), a data connection is established between the first network node and the controller, and the controller may collect related data of the path 1 by using the data connection. The connection relationship may be shown in FIG. 5. A path in a particular protocol, for example, a PCEP path, is established between the controller and a network node A (Node A) serving as the first network node. When the path 1 is deleted (referred to as an invalid path), the network node A may send a path report message to the controller, to notify the controller that the path 1 has currently become the invalid path. Before obtaining the path report message from the network node A, the controller may not need to learn whether a network node B (Node B) and a network node C (Node C) are located on the path 1. Or the controller at most obtains information such as node identifiers of the network node B and the network node C by using an interior gateway protocol (IGP). Therefore, the controller cannot directly obtain addresses of nodes (for example, the network node B and the network node C) other than the head node on the invalid path by using the path report message reported by the network node A.

[0181] In this scenario, because the controller does not know the addresses of the network nodes included on the path 1 other than the first network node (the head node), when the controller receives the path report message sent by the first network node, the controller needs to determine the address of the second network node in a specific querying manner. Two manners are described in this embodiment of this application.

[0182] In a first manner of determining the second network node:

[0183] Optionally, FIG. 6 shows a procedure that may be included in step 102.

[0184] 601. The controller determines a topology structure of the invalid path based on the identifier of the invalid path.

[0185] The topology structure of the invalid path may indicate a connection relationship and the forwarding direction of the invalid path, and may be, for example, an RRO corresponding to the invalid path. The controller may search, based on the identifier of the invalid path, an LSP DB stored in the controller for the RRO of the invalid path.

[0186] 602. The controller determines an identifier of the second network node based on the topology structure.

[0187] After the RRO of the invalid path is determined, a forwarding direction and a sequence of network nodes on the invalid path may be determined. For example, when the invalid path is: A.fwdarw.B.fwdarw.C, a network node B receives data forwarded by a network node A, a network node C receives the data forwarded by the network node B, and the network node B is equivalent to a next-hop network node of the network node A on the invalid path.

[0188] Because the controller obtains the path report message from the first network node, and the first network node is the head node on the invalid path, the controller may first determine the next-hop network node of the first network node on the invalid path from the RRO, in order to determine the second network node, where the second network node is a next network node of the first network node in the forwarding direction of the invalid path.

[0189] Subsequently, the controller may determine, based on the second network node obtained from the RRO, the identifier of the second network node such as a node IP of the second network node from a TE DB stored in the controller.

[0190] 603. The controller determines an address of the second network node based on the identifier of the second network node.

[0191] The controller determines, based on the identifier of the second network node, the address of the second network node from a session (session) DB stored in the controller.

[0192] After obtaining the address of the second network node, the controller has a capability of sending a message to the second network node. Therefore, for step 103, the controller may send the path deletion message to the second network node based on the address of the second network node.

[0193] After sending the path deletion message to the second network node, the controller may determine whether the second network node is a last network node in the forwarding direction of the invalid path. If the second network node is the last network node, it means that all network nodes on the invalid path are instructed to delete the path data of the invalid path. If the second network node is not the last network node, it means that there is another network node following the second network node in the forwarding direction of the invalid path. Therefore, after the controller sends the path deletion message to the second network node based on the address of the second network node, the method further includes:

[0194] determining, by the controller, whether the second network node is the last network node in the forwarding direction of the invalid path, and if the second network node is not the last network node, determining an identifier of a third network node based on the topology structure of the invalid path, where the third network node is a next network node of the second network node in the forwarding direction of the invalid path; and

[0195] using the third network node as the second network node, and continuing to perform step 602 and step 603 until it is determined that the second network node is the last network node in the forwarding direction of the invalid path.

[0196] It should be noted that in the embodiment described above the controller determines whether the second network node is the last network node in the forwarding direction of the invalid path is implemented only based on the embodiment corresponding to FIG. 6. But the disclosure is not limited in this embodiment of this application. The determining step may alternatively be implemented in another searching manner.

[0197] In a second manner of determining the second network node:

[0198] This determining manner is applicable to a network having a relatively small network scale. Because the identifier of the invalid path uniquely identifies the invalid path, the path deletion message carrying the identifier of the invalid path may be sent to the entire network, for example, sent to a plurality of network nodes or all network nodes in the entire network. When the path deletion message is sent to the plurality of network nodes, a scenario in which the second network node is determined inevitably occurs. In other words, the plurality of network nodes found by the controller from the network may include the second network node. When the path deletion message is sent to all the network nodes, the network nodes may inevitably include the second network node.

[0199] Therefore, in this manner, the controller searches for addresses of the plurality of network nodes in the network, and may obtain the addresses from a session DB stored in the controller. For step 103, optionally, the controller sends the path deletion message to the plurality of network nodes based on the addresses of the plurality of network nodes.

[0200] With reference to specific application scenarios, the following further describes the case in which the first network node is the head node on the invalid path.

[0201] In a first application scenario:

[0202] Refer to FIG. 7 for a connection relationship between each network node and a controller and for path-related data in the scenario. As shown in FIG. 7, the content of each database (Database, DB) stored in the controller may be shown in Table 1:

TABLE-US-00001 TABLE 1 LSP DB TE DB (topology) Session (session) DB LSP 1: Node A: 1.1.1.1 Session 1 1.1.1.1; LSP ID: 1 link: 12.0.0.1 Session 2 2.2.2.2; RRO (Current path): Node B: 2.2.2.2 Session 3 3.3.3.3; 12.0.0.1; 12.0.0.2; link: 12.0.0.2 23.0.0.1 Session 4 4.4.4.4 2.2.2.2; 23.0.0.1; Node C: 3.3.3.3 23.0.0.2; 3.3.3.3 link: 23.0.0.2 Node D: 4.4.4.4 link: 14.0.0.2

[0203] It can be learned from the LSP DB in the controller that a current path (Current path) of an established (Up) path 1 may be 12.0.0.1.fwdarw.12.0.0.2.fwdarw.2.2.2.2.fwdarw.23.0.0.1.fwdarw.23.0.0.2.fwdarw.3.3.3.3. In other words, a path A.fwdarw.B.fwdarw.C in FIG. 5 is denoted as an LSP 1.

[0204] When the controller obtains a path report message from a network node A (the first network node), the controller determines that the LSP 1 has been deleted and has become invalid. The controller determines an RRO of the LSP 1 from the LSP DB based on an identifier of the LSP 1, determines, based on next hop information of the RRO, that a next-hop network node of the network node A on the invalid path is a network node B (the second network node), determines, from a TE DB, that an identifier of the network node B is 2.2.2.2, and determines, from a session DB, that an address of the network node B is 2.2.2.2. In this way the controller can send a path deletion message to the address, to instruct the network node B to delete path data related to the LSP 1 (the invalid path). Subsequently, the controller may continue to determine a next-hop network node of the network node B, for example, a network node C, from the RRO of the LSP 1, and continue the foregoing process of determining an identifier and an address of a network node, to send the path deletion message to the network node C.

[0205] Therefore, after the LSP 1 is deleted, the path data that is related to the LSP 1 and that may remain in the network node B and the network node C is deleted with assistance of the controller.

[0206] In a second application scenario:

[0207] In the RSVP-TE, when a path becomes invalid, network nodes may exchange a path tear message and a resv tear message to instruct an adjacent network node to delete path data related to the invalid path. However, it is still necessary for a network node A to send a path report message to the controller. A reason is as follows: First, the controller needs to synchronize, for the invalid path, related data stored in the controller; and second, because a fault may occur on a part of a path, a network node or some network nodes may not learn that the path has become invalid, and the network node or the network nodes still stores or store path data of the path.

[0208] Description is provided by using an example in which a fault may occur on a part of an invalid path. A path is an LSP 1: A.fwdarw.B.fwdarw.C.fwdarw.D, and a fault occurs on a path from a network node B to a network node C. When the path 1 becomes an invalid path, a path tear message sent by the network node B to the network node C is lost. As a result, the network node C does not learn that the LSP 1 has become invalid.

[0209] Refer to FIG. 8 for processing process. After the LSP 1 is established (Up), the controller may obtain path data of the LSP 1 from a network node A. Then, a user may delete the LSP 1, and the LSP 1 becomes an invalid path. The network node A serving as a head node, namely, the first network node, may delete path data that is of the LSP 1 and that is stored in the network node A, and send an RSVP path tear (LSP 1) message to the network node B, to notify the network node B that the LSP 1 has been deleted. The network node B may delete path data related to the LSP 1, and the network node B continues to send the RSVP path tear (LSP 1) message to the network node C. However, because the fault occurs on the path B.fwdarw.C, the RSVP path tear (LSP 1) message sent by the network node B is lost, and cannot be sent to the network node C. As a result, the network node C and a network node D cannot learn that the LSP 1 has been deleted. Consequently, the network node C and the network node D still store the path data of the LSP 1.

[0210] When the network node A deletes the path data of the LSP 1, the network node A may further send a path report message, namely, a PCRpt message in FIG. 8, to the controller. The message carries an identifier of the LSP 1 and a flag bit (R) that indicates deletion of the LSP 1. When obtaining the PCRpt message, the controller decides that the LSP 1 has become an invalid path, and may determine, based on the identifier of the LSP 1, that the network node B, the network node C, and the network node D are located on the invalid path. Therefore, the controller may separately send a deletion message to the network node B, the network node C, and the network node D, to instruct the three network nodes to delete the path data that is related to the LSP 1 and that is stored in the three network nodes. The deletion message may be a message of a type (Delete LSP 1) shown in FIG. 8, or may be a message of another type, for example, the foregoing PCUpd message. After receiving the deletion message sent by the controller, the network node B, the network node C, and the network node D may determine, based on the deletion message, that the path data of the LSP 1 needs to be deleted.

[0211] Therefore, the path data that is related to the LSP 1 and that would have remained in the network node C and the network node D is deleted with assistance of the controller, to improve storage efficiency of the two network nodes.

[0212] After the case in which the first network node is the head node on the invalid path is described, the following describes a case in which the first network node is the intermediate node on the invalid path.

[0213] In this scenario, before the invalid path becomes invalid (referred to as the path 1), a data connection is established between the controller and each network node on the path 1. Therefore, the controller may collect related data of the path 1. The connection relationship may be shown in FIG. 9. A path in a particular protocol, for example, a PCEP path, is established between the controller and each of a network node A (Node A), a network node B (Node B), and a network node C (Node C) on the path 1. The interaction between the controller and the network node A serving as the head node on the path 1 and data transmitted to the controller are similar to the interaction between the network node A and the controller in the embodiment corresponding to FIG. 5, and details are not described herein again. Each of the network node B and the network node C serving as intermediate nodes may implement delegation (Delegation) to the controller by using a path to the controller. The delegation means that a network node such as a PCC sends a tunnel of the network node to the controller such as a PCE for management. The tunnel has many attributes. The PCE generally can manage only a status of the tunnel, i.e., whether it is up or down. When a path of a tunnel is invalid (Down), the PCE may request the PCC delegating the tunnel to delete path data of the tunnel. For delegation to the controller, the intermediate node mainly delegates the path-related data. For example, the network node B delegates inbound and outbound interface information of the network node B on the path 1 and an identifier of the network node B to the controller. It should be noted that because one network node may be located on a plurality of paths, for example, the network node B may be located on the path 1: A.fwdarw.B.fwdarw.C, and may be also located on a path 2: B.fwdarw.C.fwdarw.D, delegation of the intermediate node to the controller may be path specific. In other words, the network node B may perform delegation to the controller for the path 1, and delegated content is related to the path 1; and the network node B may further perform delegation to the controller for the path 2, and delegated content is related to the path 2.

[0214] Because the controller obtains delegation permission of the intermediate node on the path, the controller may learn of network nodes included on the path corresponding to the path identifier. From the perspective of the network node, because a path in a particular protocol is established between each network node on the path and the controller, each network node on the path can actively send a message, for example, a delegation message or a path report message, to the controller.

[0215] When the first network node is the intermediate node on the invalid path, for how to determine the second network node, refer to a related description when the first network node is the head node on the invalid path. However, it should be noted that a difference from the case in which the first network node is the head node is that in this scenario, a connection in a particular protocol is established between the controller and each network node on the path. Therefore, a manner of determining the second network node is not as complex as the two manners of determining the second network node in the embodiment corresponding to FIG. 5. For example, because the controller has learned of information that is related to the path and that is of the intermediate nodes, the controller may not need to determine the address of the second network node by using a TE DB. The controller may directly determine the address of the second network node by using a PCEP session.

[0216] For how to send the path deletion message to the determined second network node when the first network node is the intermediate node on the invalid path, refer to a related description when the first network node is the head node on the invalid path, and details are not described herein again.

[0217] With reference to specific application scenarios, the following further describes the case in which the first network node is the intermediate node on the invalid path.

[0218] In a first application scenario:

[0219] This scenario mainly focuses on a case of processing performed by the controller when a fourth network node sends a delegation message to the controller. The fourth network node is an intermediate node on the invalid path, and may be same as or may be different from the first network node.

[0220] In this case, a processing process may be shown in FIG. 10.

[0221] 1001. The controller obtains a delegation message sent by the fourth network node, where the delegation message includes an address of the fourth network node and path data of a path on which the fourth network node is located.

[0222] 1002. The controller determines, based on the path data of the path on which the fourth network node is located, whether the fourth network node includes the path data of the invalid path, and performs 1003 if the fourth network node includes the path data of the invalid path.

[0223] The controller may perform the determining step 1002 based on the obtained identifier of the invalid path; and if finding that a delegation path of the fourth network node is an invalid path, instruct, by using step 1003, the fourth network node to delete the path data related to the path.

[0224] The controller may obtain the identifier of the invalid path by using another network node. For example:

[0225] The controller may obtain the path report message sent by the first network node, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path. Alternatively, the controller may obtain a path report message sent by the initial network node (the head node) in the forwarding direction of the invalid path, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path.

[0226] 1003. The controller sends a path deletion message to the first network node.

[0227] If it can be determined in step 1002 that the first network node includes the path data of the invalid path, the controller may send the path deletion message to the first network node, to assist the first network node in deleting the path data that is of the invalid path and that remains in the first network node.

[0228] That when the first network node performs delegation to the controller, the controller finds that the first network node stores the path data of the invalid path may occur in many cases. For example, because a fault occurs on a path between the first network node and another network node on the invalid path, or the first network node is offline, the first network node has not received a path tear message sent by another network node for the invalid path, and consequently, the first network node cannot know a status of the invalid path and continues to maintain the path data of the invalid path. For another example, a fault occurs on a part of the invalid path, and a network node finds the fault and notifies the controller of the fault. In this case, the first network node does not know the fault, and another network node does not send a path tear message for the invalid path. As a result, the first network node still reserves the path data of the invalid path. Examples of other cases are not listed herein one by one.

[0229] In a second application scenario:

[0230] This scenario mainly focuses on a case of processing performed by the controller when the first network node sends the path report message to the controller.

[0231] Although the first network node on the invalid path (it is assumed that the invalid path is the path 1 before the path is invalid) is the intermediate node, because the first network node has delegated the path 1 to the controller, the first network node may send the path report message to the controller when permitted, to indicate to the controller that the path 1 has been deleted.

[0232] Therefore, in step 101, the controller may obtain the identifier of the invalid path by obtaining the path report message sent by the first network node, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path.

[0233] The first network node may be enabled to send the path report message to the controller under a certain condition. For example, a fault occurs on a path between the first network node and the second network node on the invalid path (or the path 1 that is still valid). As a result, the path 1 cannot normally provide a service, and needs to be deleted. In other words, the path 1 becomes the invalid path. The fault on the path between the first network node and the second network node may be found by the first network node. For example, when the first network node finds that a packet forwarded to the second network node is lost or there is no acknowledgement reply, the first network node may determine that the fault occurs on the path between the first network node and the second network node on the path 1.

[0234] When the first network node finds that the path 1 cannot normally provide a service, the first network node may consider that the path 1 has become invalid, and may send the path report message to controller, to notify the controller that the path 1 has become invalid.

[0235] The following provides descriptions with reference to two specific scenarios.

[0236] In a scenario a, an established path is an LSP 1: A.fwdarw.B.fwdarw.C.fwdarw.D, and a fault occurs on a path from a network node B to a network node C. When the LSP 1 becomes an invalid path, a path tear message sent by the network node B to the network node C is lost. As a result, the network node C does not learn that the LSP 1 has been invalid. The first network node is the network node B.

[0237] Refer to FIG. 11a for a processing process. After the LSP 1 is established (Up), the controller may obtain path data of the LSP 1 from the network node A. Then, a user may delete the LSP 1, and the LSP 1 becomes the invalid path. The network node A serving as a head node may delete the path data that is of the LSP 1 and that is stored in the network node A, and send an RSVP path tear (LSP 1) message to the network node B, namely, the first network node, to notify the network node B that the LSP 1 has been deleted. The network node B may delete path data related to the LSP 1, and the network node B continues to send the RSVP path tear (LSP 1) message to the network node C. However, because a fault occurs on a path B.fwdarw.C, the RSVP path tear (LSP 1) message sent by the network node B is lost, and cannot be sent to the network node C. As a result, the network node C and the network node D cannot learn that the LSP 1 has been deleted. Consequently, the network node C and the network node D still store the path data of the LSP 1.

[0238] Because the network node B does not obtain an acknowledgement message returned by the network node C, the network node B may decide that the RSVP path tear (LSP 1) message sent by the network node B is lost due to the fault on the path B.fwdarw.C. The network node B sends a path report message (a PCEP: PCRpt (LSP 1, R) message sent by the network node B to the controller in FIG. 11a) to the controller. The message carries an identifier of the LSP 1 and a flag bit (R) that indicates deletion of the LSP 1, to notify the controller that the LSP 1 has become the invalid path.

[0239] When obtaining the PCRpt message, the controller decides that the LSP 1 has become invalid; and may determine, based on the identifier of the LSP 1, that the network node C and the network node D are located on the invalid path, and both the two network nodes delegate related information of the LSP 1 to the controller. Therefore, the controller may consider that the network node C and the network node D still store the path data of the LSP 1, and path data remaining in a downstream network device on the invalid path may be understood as downstream residues. The controller may separately send a deletion message to the network node C and the network node D, to instruct the two network nodes to delete the path data that is related to the LSP 1 and that is still stored in the two network nodes. The deletion message may be a path deletion message PCEP: PCUpd (LSP 1, R) of a type shown in FIG. 11a. After receiving the path deletion message sent by the controller, the network node C and the network node D determine that the path data of the LSP 1 needs to be deleted.

[0240] Therefore, the path data that is related to the LSP 1 and that originally may remain in the network node C and the network node D is deleted with assistance of the controller, to improve storage efficiency of the two network nodes.

[0241] In a scenario b, an established path is an LSP 1: A.fwdarw.B.fwdarw.C.fwdarw.D, and a fault occurs on a path from a network node B to a network node A. When the LSP 1 becomes an invalid path, a resv tear message sent by the network node B to the network node A is lost. As a result, the network node A does not learn that the LSP 1 has been invalid. The first network node is the network node B.

[0242] Refer to FIG. 11b for a processing process. After the LSP 1 is established (Up), the controller may obtain path data of the LSP 1 from the network node A. Then, the network node B detects that the fault occurs on the path B.fwdarw.A from the network node B to the network node A, and the network node B determines that the LSP 1 has become the invalid path.

[0243] The network node B may delete path data that is related to the LSP 1 and that is stored in the network node B, and send the resv tear message to the network node A. However, the resv tear message is lost due to the fault on B.fwdarw.A. The network node B may further send the RSVP path tear (LSP 1) message to a network node C. Therefore, the network node C may delete path data that is related to the LSP 1 and that is stored in the network node C, and the network node C may continue to send the RSVP path tear (LSP 1) message to a network node D. Therefore, the network node D may delete path data that is related to the LSP 1 and that is stored in the network node D.

[0244] The network node B may further send a path report message (a PCEP: PCRpt (LSP 1, R) message sent by the network node B to the controller in FIG. 11b) to the controller when finding that the fault occurs on B.fwdarw.A. The message carries an identifier of the LSP 1 and a flag bit (R) that indicates deletion of the LSP 1, to notify the controller that the LSP 1 has become the invalid path.

[0245] When obtaining the PCRpt message, the controller decides that the LSP 1 has become the invalid path, and may determine, based on the identifier of the LSP 1, that the network node A is located on the invalid path. The network node A does not notify the controller that the path data of the LSP 1 has been deleted. Therefore, the controller may consider that the network node A still stores the path data of the LSP 1, and path data remaining in an upstream network device on the invalid path may be understood as upstream residues. The controller may send a deletion message to the network node A, to instruct the network node A to delete the path data that is related to the LSP 1 and that is stored in the network node A. The deletion message may be a path deletion message PCEP: PCUpd (LSP 1, R) of a type shown in FIG. 11b. After receiving the path deletion message sent by the controller, the network node A determines that the path data of the LSP 1 needs to be deleted.

[0246] Therefore, the path data that is related to the LSP 1 and that originally may remain in the network node A is deleted with assistance of the controller, to improve storage efficiency of the network node A.

[0247] In a scenario c, an established path is an LSP 1: A.fwdarw.B.fwdarw.C.fwdarw.D, and a fault occurs on a path from a network node B to the controller. As a result, a path deletion message sent by the controller to the network node B is lost. If the network node B does not obtain an RSVP path tear (LSP 1) message sent by another network node for the LSP 1, path data of the LSP 1 remains in the network node B. The first network node is the network node B.

[0248] Refer to FIG. 11c for a processing process. The controller has learned that the LSP 1 has been invalid, and sends a path deletion message to a network node on the LSP 1. However, a fault occurs on a path from the controller to the network node B. As a result, the path deletion message sent by the controller to the network node B is lost.

[0249] Then, after the path from the network node B to the controller is restored, the network node B may perform delegation to the controller again, or synchronize, with the controller, the path data stored in the network node B again. For example, the network node B may send a PECP: PCRpt (LSP, S) message in FIG. 11c to the controller, to synchronize, with the controller, related information of all LSPs that is currently stored in the network node B.

[0250] If the network node B does not obtain the RSVP path tear (LSP 1) message sent by another network node for the LSP 1, and the path data of the LSP 1 remains in the network node B, the controller learns, by using the foregoing data synchronization process, that the network node B still stores the path data of the LSP 1 that has become an invalid path. The controller sends a PCEP PCUpd (LSP 1, R) message to the network node B, to instruct the network node B to delete the path data of the LSP 1.

[0251] Therefore, the path data that is related to the LSP 1 and that originally may remain in the network node B is deleted with assistance of the controller, to improve storage efficiency of the network node B.

[0252] In a third application scenario:

[0253] This scenario mainly focuses on how the controller processes, when the first network node is the intermediate node on the invalid path, a path change message sent by a head node on the invalid path, namely, a fourth network node.

[0254] Referring to FIG. 12, based on the embodiment corresponding to FIG. 9, the method may further include the following steps:

[0255] 1201. The controller obtains a path change message sent by the fourth network node, where the path change message includes a topology structure of a changed path, the changed path is obtained by changing the invalid path, and an identifier of the changed path is the same as the identifier of the invalid path.

[0256] Because the identifier of the path before and after the change does not change, this change status may be understood as a change based on an original path, and little content is changed. The path identifier of the original path is still used. For example, the invalid path is A.fwdarw.B.fwdarw.C.fwdarw.D. The invalid path is changed to obtain the changed path: A.fwdarw.B.fwdarw.C.fwdarw.E. It can be learned that only a last network node on the path is changed. Therefore, the changed path still uses the identifier of the path before the change.

[0257] 1202. The controller determines, through comparison, a distinctive part of the invalid path that is different from the changed path.

[0258] 1203. The controller determines a network node located on the distinctive part.

[0259] 1204. The controller sends a path deletion message to the network node located on the distinctive part.

[0260] The controller may determine the RRO of the invalid path from the LSP DB based on the path identifier, by comparing the RRO with a topology structure that is of the changed path and that is carried in the path change message in order to determine a difference between the two. For example, in the foregoing example, the invalid path is A.fwdarw.B.fwdarw.C.fwdarw.D, and the changed path is A.fwdarw.B.fwdarw.C.fwdarw.E. Then, the distinctive part is the network node D. The controller may send the path deletion message to the network node D, to instruct the network node D to delete path data that is related to the invalid path and that is stored in the network node D.

[0261] It can be learned that for a path that is relatively slightly changed, because most of the changed path still uses related data of the original path, the changed part may be determined through comparison, and the path deletion message is sent only to the network node or nodes on the changed part, to improve path data deletion efficiency.

[0262] In a fourth application scenario:

[0263] This scenario is mainly described by combining cases that may occur in the foregoing three application scenarios.

[0264] Referring to FIG. 13, content of each database stored in the controller according to FIG. 13 may be shown in Table 2:

TABLE-US-00002 TABLE 2 LSP DB (topology) PCEP Session PCEP1: Session 1 1.1.1.2; LSP ID: 1 Session 2 2.2.2.3; RRO (Current path): 12.0.0.1; 12.0.0.2; 2.2.2.2; Session 3 3.3.3.4; 23.0.0.1; 23.0.0.2; 3.3.3.3 Session 4 4.4.4.5 PCEP2: LSP ID: 1 HOP: 12.0.0.2; 2.2.2.2; 23.0.0.1 PCEP3: LSP ID: 1 HOP: 23.0.0.2; 3.3.3.3

[0265] It can be learned from the LSP DB in the controller that a current path (Current path) of an established (Up) path 1 may be 12.0.0.1.fwdarw.12.0.0.2.fwdarw.2.2.2.2.fwdarw.23.0.0.1.fwdarw.23.0.0.2.fwdarw.3.3.3.3. In other words, a path A.fwdarw.B.fwdarw.C in FIG. 13 is denoted as an LSP 1. In this application scenario, descriptions may be provided with reference to the following three scenarios. In the following scenarios, the first network node is a network node B.

[0266] Scenario a: This scenario mainly focuses on a processing process of the controller when an LSP is deleted.

[0267] When the controller obtains a path report message from the network node B (an intermediate network node), the controller determines that the LSP 1 has been deleted and has become an invalid path. The controller determines an RRO of the LSP 1 from the LSP DB based on an identifier of the LSP 1, determines, based on next hop information of the RRO, that a next-hop network node of the network node B on the invalid path is a network node C (the second network node), determines, from a TE DB, that an identifier of the network node C is 3.3.3.3, and determines, from a session DB, that an address of the network node C is 3.3.3.3, so that the controller can send a path deletion message to the address to instruct the network node C to delete path data related to the LSP 1 (the invalid path).

[0268] Alternatively, in a small-scale network, the controller may further traverse all stored PCEP sessions, and send the path deletion message to all addresses, to instruct a receiver (a network node) to delete path data related to the LSP 1.

[0269] Therefore, after the LSP 1 is deleted, the path data that is related to the LSP 1 and that would have remained in the network node C is deleted with assistance of the controller.

[0270] Scenario b: This scenario mainly focuses on a processing process of the controller when an RRO changes.

[0271] The controller may obtain a path change message from a network node A (the fourth network node), to notify that the LSP 1 has changed and an RRO of a new LSP is changed into: 14.0.0.1; 14.0.0.2; 4.4.4.4; 34.0.0.2; 34.0.0.1; and 3.3.3.3 (that is, a new path is A.fwdarw.D.fwdarw.C).

[0272] The controller may determine, by using an identifier of the LSP 1, that an RRO of the original LSP 1 is A.fwdarw.B.fwdarw.C, determine, by comparing new and old topology information, that a distinctive part includes a network node B, and find that an address of the network node B is a PCEP 2 in the LSP DB, to send a path deletion message to the network node B, to instruct the network node B to delete path data related to the LSP 1.

[0273] Therefore, after the RRO of the LSP 1 changes, the path data that is related to the LSP 1 and that would have remained in the network node B is deleted with assistance of the controller.

[0274] Scenario c: This scenario mainly focuses on a processing process of the controller when an intermediate node, for example, the first network node: the network node B, delegates the LSP 1 to the controller.

[0275] The network node B sends, to the controller, a delegation message used to delegate the LSP 1. When receiving the delegation message, the controller may determine, based on an identifier of the LSP 1, whether the LSP 1 is an invalid path, and if the LSP 1 is the invalid path, the controller may further determine whether the network node B stores path data of the LSP 1. If the network node B stores the path data of the LSP 1, the controller may send a path deletion message to the network node B, to instruct the network node B to delete the path data related to the LSP 1.

[0276] Therefore, after the LSP 1 is deleted, the path data that is related to the LSP 1 and that may remain in the network node B is deleted with assistance of the controller.

Embodiment 2

[0277] This embodiment of this application further provides a message forwarding method. The method is also applied to a network in which an RSVP-TE is deployed. The network includes a controller and a plurality of network nodes. The plurality of network nodes includes a first network node and a second network node. The controller in the method mainly has a function of forwarding, to the second network node, a transfer message received from the first network node. Therefore, the method is not limited to being applied only to an application scenario of cleaning path data remaining in a network node. Because a manner of forwarding performed by the controller can be used to improve reliability of sending content carried in a transfer message to the second network node, the method may be further applied to another scenario in which a message needs to be forwarded by using the controller or a scenario in which message sending reliability needs to be improved.

[0278] FIG. 14 is a method flowchart of the message forwarding method according to this embodiment of this application. The method includes the following steps:

[0279] 1401. The controller obtains, from the first network node, a transfer message carrying an identifier of the second network node.

[0280] 1402. The controller forwards the transfer message to the second network node based on the identifier of the second network node.

[0281] Both the first network node and the second network node may be network nodes on a same path. To more reliably send content carried in the transfer message to the second network node, the first network node may send the transfer message to the controller, and the controller forwards the transfer message. Because the transfer message carries the identifier of the second network node, when receiving the transfer message, the controller may determine, based on the carried identifier of the network node, a specific network node to which the transfer message needs to be forwarded. The identifier of the second network node may be a destination address of the second network node, or may be an ID used to identify the second network node.

[0282] It should be noted that in step 1402, the controller possibly cannot directly determine an actual address of the second network node, that is, an address used to receive messages, based on the identifier of the second network node and that is carried in the transfer message. Therefore, the controller needs to search a database such as a TE DB based on the identifier, to obtain the address of the second network node before it can forward the transfer message to the address.

[0283] The RSVP-TE is improved, so that the first network node can send, to the controller, the transfer message used to instruct the controller to forward the transfer message to the second network node. The transfer message may be a message of an original type in the RSVP-TE. Alternatively, the transfer message may be obtained by modifying a message of an original type to improve the RSVP-TE. Alternatively, the transfer message may be of a new message type generated to improve the RSVP-TE.

[0284] This embodiment of this application provides an optional manner. The RSVP-TE is improved, to improve a message of an original type: a path computation notify with data (Path Computation Notify with Data, PCNtf with data) message. The improved PCNtf with Data message may have a function of instructing the controller to perform forwarding to a specified network node (the second network node).

[0285] A format of the PCNtf with Data message may be shown in FIG. 15a. An improved part related to this application mainly includes a message type (NT) field, a report message value (NV) field, and an optional type length value (Optional TLVs) field.

[0286] The NT field is used to identify a notification type of the PCNtf with Data message. For example, a value of the NV field may be set to 209 to identify that the PCNtf with Data message is a notification message carrying additional data. Therefore, when receiving the PCNtf with Data message, the controller may recognize, by using a value of the NT field, that the PCNtf with Data message is a message that needs to be forwarded to another network node.

[0287] The NV field is used to identify a quantity of PCNtf with Data messages sent by the first network node, or to identify a quantity of PCNtf with Data messages that are sent by the first network node and that need to be forwarded to the second network node. For example, the first network node sends a first PCNtf with Data message that needs to be forwarded to the second network node, for example, a notification message 1, and a value of an NV field in the notification message 1 may be 1. Then, the first network node sends a second PCNtf with Data message that needs to be forwarded to the second network node, for example, a notification message 2, and a value of an NV field in the notification message 2 may be obtained by adding 1 to the value of the NV field in the notification message 1. Therefore, the value of the NV field in the notification message 2 is 2. The value of the NV field may have a function of ensuring a time sequence, so that when receiving a PCNtf with Data message, the second network node may determine a processing sequence based on the value of the NV field. For example, due to network latency, the second network node first obtains, from the controller, the PCNtf with Data message in which the value of the NV field is 2, and then obtains the PCNtf with Data message in which the value of the NV field is 1. If no NV field has a function of identifying a time sequence, the second network node may first process the first obtained PCNtf with Data message, and then process the latter obtained PCNtf with Data message. This could cause data abnormality. Relying on the identification function of the NV field, the second network node may first process the PCNtf with Data message in which the value of the NV field is 1, and then process the PCNtf with Data message in which the value of the NV field is 2, so that the processing sequence is consistent with the sending sequence of the first network node. Therefore, the following case is avoided: Data of the second network node is abnormal because the sequence of processing the PCNtf with Data messages is incorrect.

[0288] The optional TLVs field includes a destination address (DESTINATION-HOP TLV) field and an opaque data (OPAQUE-DATA TLV) field.

[0289] The destination address field is used to carry an address of a network node receiving the PCNtf with Data message, for example, the identifier of the second network node. A type (Type) part may occupy two bytes, and a length (Length) part may occupy two bytes. It should be noted that a value (Value) part of the destination address field may be in different formats for different application scenarios. For example, a format shown in FIG. 15b is for the Internet protocol version 4 (Internet Protocol version 4, IPv4), and a format shown in FIG. 15c is for the Internet protocol version 6 (Internet Protocol version 6, IPv6). Correspondingly, for the type part of the destination address field, when the value part is in the format shown in FIG. 15b, a value of the type part may be 30; or when the value part is in the format shown in FIG. 15c, a value of the type part may be 31.

[0290] The opaque data field is used to carry data that needs to be sent to a network node receiving the PCNtf with Data message. A type part may occupy two bytes, and a length part may occupy two bytes. A value of the type part may be 35, a value of the length part is an actual length of the packet, and a value part may store the data that needs to be sent to the network node receiving the PCNtf with Data message.

[0291] When the transfer message is the PCNtf with Data message, the PCNtf with Data message needs to be improved, and network nodes further need to be improved, so that the network nodes have a capability of sending the PCNtf with Data message, for example, a notify with data (Notify with Data) capability. Correspondingly, a connection relationship between the network node and the controller may be shown in FIG. 16. A PECP connection is established between the controller and each of a network node A, a network node B, and a network node C, and the PCNtf with Data message may be received or sent by using the connections.

[0292] The following describes an opportunity that the first network node sends the transfer message to the controller.

[0293] When a message needs to be sent to the second network node, the first network node may send, to the controller by using a process in the embodiment corresponding to FIG. 14, the transfer message carrying the message that needs to be obtained by the second network node, to ensure reliability of obtaining the message by the second network node.

[0294] In some particular application scenarios, for example, when a path on which the first network node and the second network node are located becomes an invalid path, the first network node sends the transfer message to the controller. Here the transfer message carries a path deletion message used to instruct the second network node to delete path data of the invalid path, to ensure that the second network node can receive the path deletion message, and delete, as instructed by the path deletion message, the path data that is of the invalid path and that is stored in the second network node.

[0295] In some particular application scenarios, for example, when a path on which the first network node and the second network node are located becomes an invalid path, and the first network node finds that a path deletion message directly sent to the second network node is lost, the first network node may send the transfer message to the controller. The transfer message carries the path deletion message used to instruct the second network node to delete the path data of the invalid path, to ensure that the second network node can receive the path deletion message, and delete, as instructed by the path deletion message, the path data that is of the invalid path and that is stored in the second network node.

[0296] It should be noted that after the controller forwards the transfer message to the second network node, the controller may further obtain an acknowledgement message returned by the second network node, where the acknowledgement message is used to identify that the second network node has received the transfer message, and the acknowledgement message carries an identifier of the first network node. The acknowledgement message is also a message that needs to be forwarded by the controller. Therefore, after receiving the acknowledgement message, the controller may forward the acknowledgment message to the first network node based on the identifier that is of the first network node and that is carried in the acknowledgement message, to notify the first network node that the second network node has received the transfer message.

[0297] Because the acknowledgment message is also a transfer message that needs to be forwarded by the controller, another opportunity of sending the transfer message may be as follows: After a network node receives a transfer message that is sent by another network node b and that is forwarded by the controller, an acknowledgment reply for the transfer message may be forwarded by the controller to the network node b in the form of a transfer message.

[0298] With reference to specific application scenarios, the following further describes the message forwarding method provided in this embodiment of this application.

[0299] In a first application scenario:

[0300] Refer to FIG. 17 for a connection relationship between each network node and a controller and for path-related data in the scenario. As shown in FIG. 17, content of each database (Database, DB) stored in the controller may be shown in Table 3:

TABLE-US-00003 TABLE 3 TE DB (topology) Session DB Node1: 1.1.1.1 Session 1 1.1.1.1; link: 12.0.0.1 Session 2 2.2.2.2; Node2: 2.2.2.2 Session 3 3.3.3.3; link: 12.0.0.2 23.0.0.1 Session 4 4.4.4.4 Node3: 3.3.3.3 link: 23.0.0.2 Node3: 4.4.4.4 link: 14.0.0.2

[0301] The first network node may be a network node A, the second network node may be a network node B, and the network node A and the network node B are located on a same path. It is assumed that the path becomes an invalid path. If a path deletion message (Path Tear) sent by the network node A to the network node B fails, the network node A may send a transfer message such as a PCNtf with Data message to the controller. The transfer message carries an identifier of the network node B and the path deletion message that needs to be sent to the network node B.

[0302] When obtaining the transfer message, the controller may determine, from a TE DB by using the carried identifier of the network node B, that a node IP of the network node B is 2.2.2.2; then search a session DB based on the node IP of the network node B, to find that an address of the network node B is 2.2.2.2; and then forward the PCNtf with Data message to the address of the network node B.

[0303] After obtaining the PCNtf with Data message, the network node B may determine, based on the carried path deletion message, that path data that is of the invalid path and that is stored in the network node B needs to be deleted.

[0304] In a second application scenario:

[0305] An established path is an LSP 1: A.fwdarw.B.fwdarw.C.fwdarw.D, and a fault occurs on a path from a network node B to a network node C. When the LSP 1 becomes an invalid path, a path tear message sent by the network node B to the network node C is lost. As a result, the network node C does not learn that the LSP 1 has become invalid. The first network node is the network node B, and the second network node is the network node C.

[0306] A processing process may be shown in FIG. 18. After the LSP 1 is established (Up), the controller may obtain path data of the LSP 1 from the network node A. Then, a user may delete the LSP 1. The LSP 1 becomes invalid. The network node A serving as a head node may delete the path data that is of the LSP 1 and that is stored in the network node A, and send an RSVP path tear (LSP 1) message to the network node B, namely, the first network node, to notify the network node B that the LSP 1 has been deleted. The network node B may delete path data related to the LSP 1, and the network node B continues to send the RSVP path tear (LSP 1) message to the network node C. However, because the fault occurs on the path B.fwdarw.C, the RSVP path tear (LSP 1) message sent by the network node B is lost, and cannot be sent to the network node C. As a result, the network node C and the network node D cannot learn that the LSP 1 has been deleted. Consequently, the network node C and the network node D still store path data of the LSP 1.

[0307] Because the network node B does not obtain an acknowledgement message returned by the network node C, the network node B may decide that the RSVP path tear (LSP 1) message sent by the network node B is lost due to a fault on the path B.fwdarw.C. The network node B sends a PCNtf with Data message to the controller, where a destination address is the network node C, and additional data is a path tear message for the invalid path.

[0308] After determining the address of the network node C based on the PCNtf with Data message, the controller forwards the PCNtf with Data message to the network node C. After obtaining the PCNtf with Data message, the network node C may determine, based on the additional path tear message, that the path data that is of the invalid path and that is stored in the network node C needs to be deleted.

[0309] In addition, the network node C may further send a PCNtf with Data message to the controller. The message's destination address is the network node B, and includes additional data that is an acknowledgement (ACK) message (equivalent to an acknowledgement message sent by the second network node) indicating that the path tear message for the invalid path has been received.

[0310] If the controller receives the PCNtf with Data message, the controller may decide, based on the destination address of the PCNtf with Data message, that the PCNtf with Data message needs to be forwarded to the network node B. Therefore, the controller may forward the PCNtf with Data message to the network node B. When receiving the PCNtf with Data message, the network node B may determine that the network node C has received the previously sent PCNtf with Data message that carries the path tear message.

Embodiment 3

[0311] This embodiment is an apparatus embodiment corresponding to Embodiment 1. For related descriptions of features, refer to the descriptions in Embodiment 1. Details are not described herein again.

[0312] FIG. 19 is an apparatus structural diagram of a path data deletion controller according to an embodiment of this application. The path data deletion controller is applied to a network in which an RSVP-TE is deployed. The network includes a controller 1900 and a plurality of network nodes. The plurality of network nodes includes a first network node and a second network node. The controller 1900 includes an obtaining unit 1901, a determining unit 1902, and a sending unit 1903.

[0313] The obtaining unit 1901 is configured to obtain an identifier of an invalid path from the first network node, where the first network node is a network node on the invalid path.

[0314] The determining unit 1902 is configured to determine the second network node based on the identifier of the invalid path, where the second network node is a network node on the invalid path.

[0315] The sending unit 1903 is configured to send a path deletion message to the second network node, where the path deletion message is used to instruct to delete path data related to the invalid path.

[0316] Optionally, the second network node is a network node adjacent to the first network node on the invalid path.

[0317] Optionally, the first network node is an initial network node in a forwarding direction of the invalid path, and the obtaining unit is further configured to obtain a path report message sent by the first network node, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path.

[0318] Optionally, the controller further includes a judging unit.

[0319] The judging unit is configured to: determine whether the second network node is a last network node in the forwarding direction of the invalid path, and if the second network node is not the last network node, trigger the determining unit.

[0320] The determining unit is configured to: determine an identifier of a third network node based on a topology structure of the invalid path, where the third network node is a next network node of the second network node in the forwarding direction of the invalid path; and use the third network node as the second network node, and trigger the judging unit.

[0321] Optionally, the determining unit is further configured to: determine the topology structure of the invalid path based on the identifier of the invalid path; determine an identifier of the second network node based on the topology structure, where the second network node is a next network node of the first network node in the forwarding direction of the invalid path; and determine an address of the second network node based on the identifier of the second network node.

[0322] The sending unit is further configured to send the path deletion message to the second network node based on the address of the second network node.

[0323] Optionally, the determining unit is further configured to search for addresses of the plurality of network nodes in the network.

[0324] The sending unit is further configured to send the path deletion message to the plurality of network nodes based on the addresses of the plurality of network nodes.

[0325] Optionally, the first network node is a network node other than an initial network node in a forwarding direction of the invalid path, and the obtaining unit is further configured to obtain a path report message sent by the first network node, where the path report message is used to indicate that the invalid path needs to be deleted, and the path report message includes the identifier of the invalid path.

[0326] Optionally, the obtaining unit is further configured to: if a fault occurs on a path between the second network node and the first network node on the invalid path, obtain the path report message sent by the first network node.

[0327] The obtaining unit is further configured to obtain a delegation message sent by a fourth network node, where the delegation message includes an address of the fourth network node and path data of a path on which the fourth network node is located, and the fourth network node is a network node other than the initial network node in the forwarding direction of the invalid path.

[0328] Optionally, the controller further includes a judging unit.

[0329] The judging unit is configured to: determine, based on the path data of the path on which the fourth network node is located, whether the fourth network node includes the path data of the invalid path; and if the fourth network node includes the path data of the invalid path, trigger the sending unit.

[0330] The sending unit is further configured to send the path deletion message to the fourth network node.

[0331] Optionally, the obtaining unit obtains the delegation message after obtaining the path report message.

[0332] Optionally, a fifth network node is the initial network node in the forwarding direction of the invalid path, and the controller further includes a comparison unit.

[0333] The obtaining unit is further configured to obtain a path change message sent by the fifth network node, where the path change message includes a topology structure of a changed path, the changed path is obtained by changing the invalid path, and an identifier of the changed path is the same as the identifier of the invalid path.

[0334] The comparison unit is configured to: determine, through comparison, a distinctive part of the invalid path different from the changed path; and determine a network node located on the distinctive part.

[0335] The sending unit is further configured to send the path deletion message to the network node located on the distinctive part.

[0336] Optionally, the path report message or the delegation message is a PCRpt message, the PCRpt message includes a path field and an LSP object field, the path field is set to be optional, and a flag bit is added to the LSP object field to identify whether a network node sending the PCRpt message is a network node other than an initial network node in a forwarding direction of a path.

[0337] Optionally, the path deletion message is a PCUpd message, the PCUpd message includes a path field and an LSP object field. The path field is set to be optional, and a flag bit is added to the LSP object field to identify whether a network node receiving the PCUpd message is a network node other than an initial network node in a forwarding direction of a path.

Embodiment 4

[0338] This embodiment is an apparatus embodiment corresponding to Embodiment 2. For related descriptions of features, refer to the descriptions in Embodiment 2. Details are not described herein again.

[0339] FIG. 20 is an apparatus structural diagram of a message forwarding controller according to an embodiment of this application. The message forwarding controller is applied to a network in which an RSVP-TE is deployed. The network includes a controller 2000 and a plurality of network nodes. The plurality of network nodes includes a first network node and a second network node. The controller 2000 includes an obtaining unit 2001 and a forwarding unit 2002.

[0340] The obtaining unit 2001 is configured to obtain, from the first network node, a transfer message carrying an identifier of the second network node, where the first network node and the second network node are network nodes on a same path.

[0341] The forwarding unit 2002 is configured to forward the transfer message to the second network node based on the identifier of the second network node.

[0342] Optionally, the forwarding unit is further configured to: determine an address of the second network node based on the identifier of the second network node, and forward the transfer message to the address of the second network node.

[0343] Optionally, the transfer message is sent by the first network node when the path becomes an invalid path.

[0344] Optionally, the transfer message is sent when a path deletion message sent by the first network node to the second network node is lost.

[0345] Optionally, the obtaining unit is further configured to obtain an acknowledgement message returned by the second network node, where the acknowledgement message is used to identify that the second network node has received the transfer message, and the acknowledgement message carries an identifier of the first network node.

[0346] Optionally, the forwarding unit is further configured to send the acknowledgement message to the first network node based on the identifier of the first network node.

[0347] Optionally, the transfer message or the acknowledgement message is a PCNtf with Data message. An optional type length value field in the PCNtf with Data message includes a destination address field and an opaque data field. The destination address field is used to carry an identifier of a network node receiving the PCNtf with Data message, and the opaque data field is used to carry a message that needs to be received by the network node receiving the PCNtf with Data message.

Embodiment 5

[0348] FIG. 21 is a schematic hardware structural diagram of a controller according to an embodiment of this application. The controller is located in a network in which an RSVP-TE is deployed. The network includes a plurality of network nodes. The plurality of network nodes include a first network node and a second network node. A controller 2100 includes a memory 2101, a receiver 2102, a transmitter 2103, and a processor 2104. The processor 2104 is separately connected to the memory 2101, the receiver 2102, and the transmitter 2103. The memory 2101 is configured to store a group of program instructions. The processor 2104 is configured to invoke the program instructions stored in the memory 2101, to perform the following operations:

[0349] triggering the receiver 2102 to obtain an identifier of an invalid path from the first network node, where the first network node is a network node on the invalid path;

[0350] determining the second network node based on the identifier of the invalid path, where the second network node is a network node on the invalid path; and

[0351] triggering the transmitter 2103 to send a path deletion message to the second network node, where the path deletion message is used to instruct to delete path data related to the invalid path.

[0352] Optionally, the processor 2104 may be a central processing unit (Central Processing Unit, CPU), the memory 2101 may be an internal memory of a random access memory (Random Access Memory, RAM) type, the receiver 2102 and the transmitter 2103 may include a common physical interface, and the physical interface may be an Ethernet (Ethernet) interface or an asynchronous transfer mode (Asynchronous Transfer Mode, ATM) interface. The processor 2104, the transmitter 2103, the receiver 2102, and the memory 2101 may be integrated into one or more independent circuits or hardware, for example, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC).

Embodiment 6

[0353] FIG. 22 is a schematic hardware structural diagram of a controller according to an embodiment of this application. The controller is located in a network in which an RSVP-TE is deployed. The network includes a plurality of network nodes. The plurality of network nodes includes a first network node and a second network node. A controller 2200 includes a memory 2201, a receiver 2202, a transmitter 2203, and a processor 2204. The processor 2204 is separately connected to the memory 2201, the receiver 2202, and the transmitter 2203. The memory 2201 is configured to store a group of program instructions. The processor 2204 is configured to invoke the program instructions stored in the memory 2201, to perform the following operations:

[0354] triggering the receiver 2202 to obtain, from the first network node, a transfer message carrying an identifier of the second network node, where the first network node and the second network node are network nodes on a same path; and

[0355] triggering the transmitter 2203 to forward the transfer message to the second network node based on the identifier of the second network node.

[0356] Optionally, the processor 2204 may be a CPU, the memory 2201 may be an internal memory of a RAM type, the receiver 2202 and the transmitter 2203 may include a common physical interface, and the physical interface may be an Ethernet interface or an ATM interface. The processor 2204, the transmitter 2203, the receiver 2202, and the memory 2201 may be integrated into one or more independent circuits or hardware, for example, an ASIC.

[0357] It may be clearly understood by a person skilled in the art that, for the purpose of convenient and brief description, reference may be made to a corresponding process in the foregoing method embodiments for a detailed working process of the foregoing system, apparatus, and unit, and details are not described herein again.

[0358] In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely an example. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0359] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

[0360] In addition, functional units in the embodiments of this application may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in a form of hardware, or may be implemented in a form of a software functional unit.

[0361] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of this application essentially, or the part contributing to the prior art, or all or some of the technical solutions may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or some of the steps of the methods described in the embodiments of this application. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk, or an optical disc.

[0362] The foregoing descriptions are merely specific implementations of the present invention, but are not intended to limit the protection scope of the present invention. Any variation or replacement readily figured out by a person skilled in the art within the technical scope disclosed in the present invention shall fall within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.