Method, device and storage medium for processing notification information

Abstract

The present application discloses a method for processing notification information, comprising: a first node receiving, in a first IGP process, first notification information sent by a second node, including a destination address of the second node and a first identifier indicating a first elastic algorithm in the first IGP process; determining whether the first identifier indicates an elastic algorithm identical to the first elastic algorithm in the second IGP process; and if not: publishing, in the second IGP process, second notification information including the destination address and a second identifier indicating a second elastic algorithm in the second IGP process, or not publishing third notification information including the destination address. In this method, the first elastic algorithm in the first IGP process is mapped to the second elastic algorithm in the second IGP process, thereby resolving the problem that notification information introduced across processes does not work properly when different elastic algorithms are deployed in different IGP processes.

Description

[0001] This application is a divisional application of the application submitted to the China Intellectual Property Office with an application date of May 26, 2020, application number 202010453838.1, and invention name “A method, device and storage medium for processing notification information”. Technical Field

[0002] The present invention relates to the field of communication technology, and in particular to a method, device and storage medium for processing notification information. Background Art

[0003] The flexible algorithm (Flex-Algo) feature is an inherent component of the segment routing-traffic engineering (SR-TE) architecture. Flex-Algo typically includes the link cost type used in path calculation (currently including IGP, TE, and link latency), algorithm priority, and link constraints involved in path calculation. It provides a strategy that enables the IGP to calculate the shortest path with constraints.

[0004] Nodes within the same IGP process will deploy the same Flex-Algo. When running different IGP processes simultaneously on a node, the node can import the Flex-Algo from one IGP process into other IGP processes. However, the imported Flex-Algo may not function properly in the other IGP processes, causing forwarding path parameters to not meet customer requirements and degrading network performance. Summary of the Invention

[0005] The embodiment of the present application provides a method for processing notification information, which can solve the problem that when different IGP processes deploy different elasticity algorithms, the notification information introduced across processes cannot work properly.

[0006] In order to achieve the above objectives, this application provides the following technical solutions:

[0007] In a first aspect, the present application provides a method for processing notification information, which is applied to a first node in a network, wherein the first node simultaneously runs a first internal gateway protocol (IGP) process and a second IGP process, and the network further includes a second node and a third node, wherein the second node runs the first IGP process and the third node runs the second IGP process. The method comprises: the first node receives first notification information sent by the second node, including a destination address of the second node and a first identifier, wherein the first identifier is used to indicate a first resilience algorithm in the first IGP process. The first node is capable of obtaining relevant information about the resilience algorithm on each IGP process it runs, and after receiving the first notification information, the first node determines whether the first identifier is used in the second IGP process to indicate the same resilience algorithm as the first resilience algorithm indicated in the first IGP process. When the first node determines that the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process: the first node publishes second notification information including the destination address and the second identifier to the third node in the second IGP process, the second identifier is different from the first identifier, the second identifier is used to indicate the second elastic algorithm in the second IGP process, the second elastic algorithm can be the same as the first elastic algorithm or different from the first elastic algorithm, the second notification information is used by the third node to generate first routing information to the destination address, the third node can also publish the second notification information to other nodes, and the other nodes generate first routing information to the destination address based on the second notification information; or, when the first node determines that the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, it can also choose not to publish the third notification information including the destination address in the second IGP process.

[0008] From the first aspect above, it can be seen that in the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If not, the first node can carry the identifier of the elastic algorithm supported by the IGP process to be introduced in the notification information for publication, or choose not to publish the notification information in the IGP process to be introduced, thereby solving the problem that the notification information introduced across processes cannot work normally when the elastic algorithms deployed by the two IGP processes are different.

[0009] In conjunction with the first aspect described above, in a first possible implementation of the first aspect, the first identifier is not used in the second IGP process to indicate an elastic algorithm that is the same as the first elastic algorithm, including two situations: the first situation is that the first identifier exists in the second IGP process, but the third elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm. The second situation is that the first identifier does not exist in the second IGP process.

[0010] In conjunction with the above-mentioned first aspect or the first possible implementation of the first aspect, in the second possible implementation of the first aspect, before the first node publishes the second notification information to the third node in the second IGP process, the method further includes: the first node determines the second elastic algorithm based on the first elastic algorithm, and the second elastic algorithm satisfies a preset condition. Specifically, when the first node determines that the first identifier is not used to indicate an elastic algorithm that is the same as the first elastic algorithm in the second IGP process, the first node may determine the first elastic algorithm based on the first identifier in the first IGP process, and then determine the second elastic algorithm that satisfies the preset condition in the second IGP process based on the definition of the first elastic algorithm.

[0011] From the second possible implementation method of the first aspect above, it can be seen that when the elasticity algorithms deployed in the two IGP processes are different, the elasticity algorithm indicated by the introduced algorithm identifier in the first IGP process can be used to determine the elasticity algorithm that meets the preset conditions in the second IGP process to be introduced, thereby meeting customer needs and ensuring network performance while ensuring that the notification information introduced across processes can work normally.

[0012] In combination with the second possible implementation of the first aspect above, in the third possible implementation of the first aspect, the preset conditions include one or more of the following: the first is that the similarity between the second elastic algorithm and the first elastic algorithm meets the first threshold, and the second is that the priority of the second elastic algorithm meets the second threshold. The similarity meeting the first threshold includes two situations: the definitions of the second elastic algorithm and the first elastic algorithm are exactly the same and partially the same. For example, the first elastic algorithm includes specific definitions: link cost type A during path calculation, algorithm priority B, and link constraint condition C participating in path calculation. This situation where the definitions are the same may refer to the definition of the elastic algorithm meeting the link cost type A during path calculation, the algorithm priority B, and the link constraint condition C participating in path calculation. The situation where the definitions are partially the same may refer to the definition of the elastic algorithm meeting the link cost type A during path calculation and the algorithm priority B, which is deemed to meet the first threshold. The second elastic algorithm's priority meeting the second threshold may mean that the elastic algorithms deployed in the second IGP process are configured with a priority order. When the first node determines that the second IGP process contains a first identifier, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the second elastic algorithm whose priority meets the second threshold may be selected based on a pre-set priority order. The preset condition may also mean that the similarity between the second elastic algorithm and the first elastic algorithm meets the first threshold, and the priority of the second elastic algorithm meets the second threshold.

[0013] In combination with the above-mentioned first aspect and any one of the first to third possible implementation methods of the first aspect, in the fourth possible implementation method of the first aspect, after the first node receives the first notification information sent by the second node, it also includes: the first node generates second routing information to the destination address based on the first notification information in the first IGP process; the first node generates second notification information based on the second routing information in the second IGP process.

[0014] In combination with the above-mentioned first aspect and any possible implementation method of the first to fourth aspects, in the fifth possible implementation method of the first aspect, the method also includes: when the first identifier is used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process: the first node publishes fourth notification information to the third node in the second IGP process, the fourth notification information includes the destination address and the first identifier, and the fourth notification information is used to generate third routing information to the destination address.

[0015] From the fifth possible implementation method of the first aspect above, it can be seen that in the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If so, it can be directly introduced and published, thereby supporting the cross-process information introduction of notification information in scenarios where the same elastic algorithm is deployed in two IGP processes.

[0016] In combination with the fifth possible implementation of the first aspect above, in the sixth possible implementation of the first aspect, after the first node receives the first notification information sent by the second node, it also includes: the first node generates fourth routing information to the destination address based on the first notification information in the first IGP process; the first node generates fourth notification information based on the fourth routing information in the second IGP process.

[0017] In combination with the above-mentioned first aspect and any one of the first to sixth possible implementations of the first aspect, in the seventh possible implementation of the first aspect, when the method is applied to a segmented routing SRv6 network based on the IPv6 data plane, the first identifier is included in the type-length-value TLV field of the location information locator. The destination address contained in the first notification information may refer to the locator configured by the second node. In the route publishing phase, after configuring the locator, the second node needs to publish the information of the locator to other nodes in the first IGP process. The locator carries a first identifier of the first resilience algorithm. For example, the first identifier is 128. The first identifier can be included in the TLV field of the locator.

[0018] In combination with the above-mentioned first aspect and any one of the first to sixth possible implementation methods of the first aspect, in the eighth possible implementation method of the first aspect, when the method is applied to a multi-protocol label switching MPLS network, the destination address contained in the first notification information may refer to the prefix-SID configured by the second node. In the route publishing stage, after the second node configures the prefix-SID carrying the first identifier of the first elastic algorithm, it needs to publish the information of the prefix-SID to other nodes in the first IGP process. The first identifier can be included in the TLV field of the prefix-SID. The second node will publish the prefix-SID information to other nodes (including the first node) in the first IGP process in the form of a prefix-SID TLV, and the other nodes can calculate the routing information to reach the prefix-SID based on the first elastic algorithm indicated by the first identifier carried in the first notification information.

[0019] According to a second aspect of the present application, a device for processing notification information is provided. The device is a first node in a network, the first node running a first Interior Gateway Protocol (IGP) process and a second IGP process. The network further includes a second node and a third node, the second node running the first IGP process and the third node running the second IGP process. The device includes: a receiving module configured to receive first notification information sent by the second node, the first notification information including a destination address of the second node and a first identifier, the first identifier being used to indicate a first resilience algorithm in the first IGP process; a determining module configured to determine whether the first identifier in the first notification information received by the receiving module is used to indicate a resilience algorithm identical to the first resilience algorithm in the second IGP process; and a publishing module configured to, when the determining module determines that the first identifier is not used to indicate a resilience algorithm identical to the first resilience algorithm in the second IGP process: publish second notification information to the third node in the second IGP process, the second notification information including a destination address and a second identifier, the second identifier being used to indicate a second resilience algorithm in the second IGP process, the second notification information being used to generate first routing information to the destination address; or, not publish third notification information in the second IGP process, the third notification information including the destination address.

[0020] In combination with the above-mentioned second aspect, in a first possible implementation method of the second aspect, the first identifier is not used to indicate an elastic algorithm that is the same as the first elastic algorithm in the second IGP process, including: the first identifier exists in the second IGP process, and the third elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm; or, the first identifier does not exist in the second IGP process.

[0021] In combination with the above-mentioned second aspect or the first possible implementation method of the second aspect, in the second possible implementation method of the second aspect, the processing device also includes: a determination module, used to determine the second elasticity algorithm based on the first elasticity algorithm before the publishing module publishes the second notification information to the third node in the second IGP process, and the second elasticity algorithm meets the preset conditions.

[0022] In combination with the second possible implementation method of the second aspect above, in the third possible implementation method of the second aspect, the preset conditions include one or more of the following: the similarity between the second elastic algorithm and the first elastic algorithm meets the first threshold, and the priority of the second elastic algorithm meets the second threshold.

[0023] In combination with the above-mentioned second aspect and any one of the first to third possible implementation methods of the second aspect, in a fourth possible implementation method of the second aspect, the processing device also includes: a generation module, which is used to generate second routing information to the destination address according to the first notification information in the first IGP process after the receiving module receives the first notification information sent by the second node; and generate second notification information according to the second routing information in the second IGP process.

[0024] In combination with the above-mentioned second aspect and any one of the first to fourth possible implementation methods of the second aspect, in the fifth possible implementation method of the second aspect, the publishing module is also used to publish fourth notification information to the third node in the second IGP process when the judgment module determines that the first identifier is used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, and the fourth notification information includes the destination address and the first identifier, and the fourth notification information is used to generate third routing information to the destination address.

[0025] In combination with the fifth possible implementation method of the second aspect above, in the sixth possible implementation method of the second aspect, the generation module is further used to generate fourth routing information to the destination address based on the first notification information in the first IGP process after the receiving module receives the first notification information sent by the second node; and generate fourth notification information based on the fourth routing information in the second IGP process.

[0026] In combination with the above-mentioned second aspect and any one of the first to sixth possible implementation methods of the second aspect, in the seventh possible implementation method of the second aspect, when the processing device is applied to a segmented routing SRv6 network based on the IPv6 data plane, the first identifier is included in the type-length-value TLV field of the location information locator.

[0027] In combination with the above-mentioned second aspect and any one of the first to sixth possible implementation methods of the second aspect, in the eighth possible implementation method of the second aspect, when the processing device is applied to a multi-protocol label switching MPLS network, the first identifier is included in the type-length-value TLV field of the prefix segment identifier prefix-SID.

[0028] A third aspect of the present application provides a network device comprising a processor and a memory. The memory is used to store computer-readable instructions (or computer programs), and the processor is used to read the computer-readable instructions to implement the method provided by the first aspect and any implementation thereof.

[0029] In some implementations, the network device further includes a transceiver for receiving and sending data.

[0030] In a fourth aspect, the present application provides a computer storage medium, which may be non-volatile, storing computer-readable instructions that, when executed by a processor, implement the method of the first aspect or any possible implementation of the first aspect.

[0031] An embodiment of the present invention adopts a method for processing notification information. In the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If not, the first node can carry the identifier of the elastic algorithm supported by the IGP process to be introduced in the notification information for publication, or can choose not to publish the notification information in the IGP process to be introduced, thereby solving the problem that the notification information introduced across processes cannot work normally when the elastic algorithms deployed by the two IGP processes are different. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a schematic diagram of a communication system architecture provided by an embodiment of the present application;

[0033] Figure 2 This is a schematic diagram of an embodiment of a method for processing notification information provided in an embodiment of the present application;

[0034] Figure 3 This is a schematic diagram of another embodiment of the method for processing notification information provided in an embodiment of the present application;

[0035] Figure 4 This is a schematic diagram of the structure of the network device provided in the embodiment of the present application;

[0036] Figure 5 It is a structural diagram of the notification information processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present invention, rather than all the embodiments. It is known to those skilled in the art that with the emergence of new application scenarios, the technical solutions provided by the embodiments of the present invention are also applicable to similar technical problems.

[0038] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules clearly listed, but may include other steps or modules that are not clearly listed or that are inherent to these processes, methods, products or devices. The naming or numbering of steps in this application does not mean that the steps in the method flow must be executed in the time / logical sequence indicated by the naming or numbering. The process steps that have been named or numbered can be changed in the execution order according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved. The division of modules in this application is a logical division. In actual application, there may be other division methods. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection between modules can be electrical or other similar forms, which are not limited in this application. Moreover, the modules or submodules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed into multiple circuit modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application.

[0039] Segment routing (SR) is a tunneling technology based on the source routing forwarding mode. SR divides the network path into segments and assigns segment identifiers (SIDs) to these segments and forwarding nodes in the network. By arranging the segments and network nodes in an orderly manner (segment list), a forwarding path can be obtained. SR encodes the sequence of segments representing the forwarding path in the packet header and transmits it with the packet. SR based on multi-protocol label switching (MPLS) is abbreviated as SR-MPLS. SR based on IPv6 is called Internet Protocol version 6 segment routing (IPv6SR) or segment routing over IPv6 data plane (SRv6).

[0040] Specifically, in an SR-MPLS network, the SID is encoded as an MPLS label or an index within an MPLS label, and the SR path is encoded as an MPLS label stack within the MPLS packet. A prefix segment is used to identify a destination address prefix within the network. It is propagated to other nodes within the network via the Interior Gateway Protocol (IGP) and is globally visible. Prefix segments are identified by prefix-SID. SRv6 networks insert a segment routing header (SRH) into IPv6 packets. The SRH carries a SID list, which specifies the IP addresses of each node along the forwarding path. Intermediate nodes can continuously update the destination address and offset address stack based on this SID list to complete hop-by-hop forwarding. The terms SID list and segment list are synonymous. In an SRv6 network, a SID is a 128-bit IPv6 address. A SID consists of three parts: a locator, a function, and an argument. The locator field is typically used for addressing (related to routing) and indicates the destination address corresponding to a node. During route advertisement, it can be propagated to other nodes in the network via the IGP protocol, making it globally visible. The function field indicates the function associated with the SID (such as topology or service). The argument field is optional and indicates the parameters used to execute the function. For more information about SRv6 and SR-MPLS, please refer to the relevant standard technical documentation in the existing technology and will not be elaborated here.

[0041] Commonly used IGP protocols include the Routing Information Protocol (RIP), the Open Shortest Path First (OSPF) protocol, and the Intermediate System to Intermediate System (IS-IS) protocol. Traditional IGPs use certain parameters to calculate the shortest path for data packets. For example, the OSPF protocol uses a cost value to calculate the shortest path. However, if all packets choose the shortest path, many problems will arise. Segment routing-traffic engineering (SR-TE) can add additional constraints to the traditional IGP path calculation, allowing packets in the network to take paths other than the shortest path. The flexible algorithm (Flex-Algo) function is an inherent component of SR-TE and can provide a strategy that enables the IGP to calculate the shortest path with constraints. The Internet Assigned Numbers Authority (IANA) defines the type values ​​of different IGP algorithms. Algorithms 0 to 127 are reserved for standardization by the Institute of Electrical and Electronics Engineers (IEFE). Currently, two standard algorithm identifiers are defined in Request for Comments (RFC) 8402: Algorithm 0 (SPF algorithm based on IGP link metrics) and Algorithm 1 (Strict SPF algorithm based on IGP link metrics). Algorithms 128-255 can be customized by the operator, which is Flex-Algo, also known as the SR IGP resiliency algorithm. Flex-Algo usually includes the link cost type during path calculation (currently including IGP, TE, link delay, etc.), algorithm priority, and link constraints involved in path calculation. Among them, link constraints refer to the restrictions that must be followed in calculating the path to each locator or prefix-SID carrying Flex-Algo.

[0042] Taking an SRv6 network as an example, during the route advertisement phase in a Flex-Algo scenario, SRv6 must be enabled on each node in the SRv6 network and locators must be configured. Each locator can carry a Flex-Algo. After configuring a locator, the node propagates this locator information to other nodes in the SRv6 network via the IGP protocol in the form of a locator TLV. When other nodes need to find routes contained in this locator, they use the Flex-Algo carried by the locator to calculate the path to the routes contained in this locator. Locator information in one IGP process can be imported into other IGP processes across processes. However, the current implementation of cross-process import of locator information does not account for the possibility that the Flex-Algos deployed in two IGP processes may differ. As a result, cross-process imported locator information may not work in the imported IGP process, resulting in forwarding path parameters that do not meet customer requirements and degrading network performance. To avoid the aforementioned situation, embodiments of the present application provide a method for processing notification information. This method addresses the cross-process import of locator information or prefix-SIDs when different Flex-Algos are deployed in two IGP processes. This method ensures that even when different Flex-Algos are deployed in two IGP processes, the locator information or prefix-SID information remains functional after being imported across processes. This application also provides a corresponding apparatus. These methods are described below.

[0043] First, the network architecture of the embodiment of the present application is introduced. Figure 1 A schematic diagram of the network architecture provided for an embodiment of the present application. Figure 1 The network 10 shown in the figure adopts segment routing (SR) technology, which can be an SRv6 network or an SR-MPLS network, and the embodiment of the present application is not limited to this.

[0044] like Figure 1 As shown, the network 10 may include multiple nodes, and an IGP protocol process (abbreviated as: IGP process) is run on each node. The IGP process in the embodiment of the present application may be: RIP process, OSPF process or IS-IS process. Figure 1Figure 1 shows two IGP processes. A first IGP process includes nodes 1, 2, and 3, meaning nodes 1, 2, and 3 are running the first IGP process. A second IGP process includes nodes 1, 4, and 5, meaning nodes 1, 4, and 5 are running the second IGP process. It should be understood that network 10 may include more IGP processes, and each IGP process may include more nodes and have different connection relationships. Figure 1 The illustrated scenario uses only two IGP processes and nodes 1, 2, 3, 4, and 5 as examples and should not be construed as limiting the present application. For example, in addition to running the first and second IGP processes, node 1 may also run other IGP processes. In addition to running the first IGP process, node 2 or node 3 may also run other IGP processes, such as a third IGP process. Taking the first and second IGP processes included in network 10 as an example, the first IGP process may be any one of an RTP process, an OSPF process, and an IS-IS process, and the second IGP process may also be any one of an RTP process, an OSPF process, and an IS-IS process. The first and second IGP processes may be the same or different IGP protocol processes. For example, the first IGP process may be an IS-IS process, while the second IGP process may be an OSPF process. This is not a limitation of the present embodiment.

[0045] In an embodiment of the present application, one or more elastic algorithms can be deployed on both the first IGP process and the second IGP process, and each elastic algorithm corresponds to a specific algorithm ID and includes a specific definition. The number of elastic algorithms deployed in the first IGP process and the second IGP process can be the same or different. If elastic algorithms with the same algorithm ID are deployed in the first IGP process and the second IGP process, the definition of the elastic algorithm indicated by the algorithm ID in the first IGP process and the definition of the elastic algorithm indicated by the algorithm ID in the second IGP process can be the same or different. This embodiment of the present application does not limit this. For example, the first IGP process deploys three elastic algorithms with algorithm IDs 128, 129 and 130, and the second IGP process deploys two elastic algorithms with algorithm IDs 128 and 136. ID 128 indicates the first elastic algorithm in the first IGP process, and the first elastic algorithm includes specific definitions: link cost type A during path calculation, algorithm priority B, and link constraint conditions C participating in path calculation. The second IGP process also deploys 128, which also indicates the first elastic algorithm. Specifically, it defines the elastic algorithm as follows: link cost type A during path calculation, algorithm priority B, and link constraint C for path calculation. Alternatively, 128 in the second IGP process may indicate a second elastic algorithm, different from the first elastic algorithm definition, that includes the following: link cost type A during path calculation, algorithm priority D, and link constraint F for path calculation.

[0046] Based on the above network 10, the embodiment of the present application provides a method for processing notification information, such as Figure 2 shown.

[0047] Figure 2 A schematic diagram of an embodiment of a method for processing communication information provided in an embodiment of the present application.

[0048] See Figure 2 An embodiment of the method for processing notification information provided in the embodiments of the present application may include:

[0049] 201. A first node receives first notification information sent by a second node in a first IGP process. The first notification information includes a destination address and a first identifier of the second node. The first identifier is used to indicate a first resilience algorithm in the first IGP process.

[0050] In the embodiment of the present application, the first node and the second node both run the first IGP process. The first node is a node that runs multiple IGP processes at the same time. For example, the first node can be Figure 1 Node 1 in the example runs both the first IGP process and the second IGP process.

[0051] In the first IGP process, the second node first sends first notification information to the first node through the IGP protocol. The first notification information includes the destination address of the second node and a first identifier. The first identifier is used to indicate a first resilience algorithm in the first IGP process.

[0052] Optionally, in an SRv6 network, the destination address contained in the first notification information in an embodiment of the present application may refer to the locator configured by the second node. In the route publishing phase, after configuring the locator, the second node needs to publish the locator information to other nodes in the first IGP process. The locator carries a first identifier of a first elastic algorithm. For example, the first identifier is 128, and the first identifier can be included in the TLV field of the locator. The second node will publish the locator information to other nodes (including the first node) in the first IGP process in the form of a locator TLV, and other nodes can calculate the routing information to reach the locator based on the first elastic algorithm indicated by the first identifier carried in the first notification information.

[0053] Optionally, in an SR-MPLS network, the destination address contained in the first notification information in the embodiment of the present application may refer to the prefix-SID configured by the second node. In the route publishing phase, after the second node configures the prefix-SID carrying the first identifier of the first elastic algorithm, it needs to publish the information of the prefix-SID to other nodes in the first IGP process. The first identifier can be included in the TLV field of the prefix-SID. The second node will publish the prefix-SID information to other nodes (including the first node) in the first IGP process in the form of a prefix-SID TLV, and other nodes can calculate the routing information to reach the prefix-SID based on the first elastic algorithm indicated by the first identifier carried in the first notification information.

[0054] It should be noted that, in the embodiment of the present application, the first notification information may include other information in addition to the destination address of the second node and the first identifier. The embodiment of the present application does not limit whether the first notification information includes other information, the specific content of the other information, or the specific form of the first notification information.

[0055] 202. The first node determines whether the first identifier is used to indicate an elastic algorithm that is the same as the first elastic algorithm in the second IGP process.

[0056] In an embodiment of the present application, the first node can obtain information about all elastic algorithms deployed in all IGP processes it runs locally. In an embodiment of the present application, after the first node receives the first notification information sent by the second node in the first IGP process, it will first determine whether the first identifier is used in the second IGP process to indicate the same elastic algorithm as the first elastic algorithm. Specifically, in an embodiment of the present application, whether the first identifier is used in the second IGP process to indicate the same elastic algorithm as the first elastic algorithm includes the following two situations:

[0057] Case 1: The elastic algorithm deployed in the second IGP process contains a first identifier, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm indicated by the first identifier in the first IGP process. Specifically, the definitions of the two algorithms are different. For example, the elastic algorithm with algorithm ID "128" is deployed in both the first and second IGP processes. However, "128" in the first IGP process indicates the first elastic algorithm, which is specifically defined as: link cost type A during path calculation, algorithm priority B, and link constraint condition C for participating in path calculation. The elastic algorithm "128" in the second IGP process has a different definition from the first elastic algorithm, specifically including: link cost type A during path calculation, algorithm priority C, and link constraint condition F for participating in path calculation.

[0058] Case 2: The elastic algorithm deployed in the second IGP process does not contain the first identifier. For example, the first elastic algorithm with algorithm ID "128" is deployed in the first IGP process, but there is no elastic algorithm with algorithm ID "128" in the second IGP process.

[0059] In an embodiment of the present application, after the first node receives the first notification information sent by the second node in the first IGP process, it determines whether the second IGP process satisfies the above two conditions. Specifically, the first node may first determine whether the first identifier exists in the second IGP process. If not, it is the second condition mentioned above. If so, it is further determined whether the elastic algorithm indicated by the first identifier in the second IGP process is the same as the first elastic algorithm. If they are not the same, it is the first condition mentioned above.

[0060] 203. When the first identifier is not used to indicate an elastic algorithm that is the same as the first elastic algorithm in the second IGP process, the first node publishes second notification information to the third node in the second IGP process. The second notification information includes the destination address and the second identifier. The second identifier is used to indicate the second elastic algorithm in the second IGP process. The second notification information is used to generate first routing information to the second node. Alternatively, when the first identifier is not used to indicate an elastic algorithm that is the same as the first elastic algorithm in the second IGP process, the first node does not publish third notification information including the destination address in the second IGP process.

[0061] In an embodiment of the present application, when the first node determines that the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, that is, the elastic algorithm deployed in the second IGP process meets the first or second situation in step 202, the first node can choose to publish a second notification information to the third node in the second IGP process, and the second notification information includes the destination address and the second identifier of the second node, and the second identifier indicates the second elastic algorithm in the second IGP process.

[0062] Specifically, in an embodiment of the present application, after the first node determines that the first identifier is not used to indicate an elastic algorithm identical to the first elastic algorithm in the second IGP process, it may first determine a second elastic algorithm from one or more elastic algorithms deployed in the second IGP process, then generate a second notification message carrying a second identifier of the second elastic algorithm, and finally publish the second notification message to a third node in the second IGP process. It should be noted that in an embodiment of the present application, the second identifier is an identifier different from the first identifier, and the second elastic algorithm may be the same algorithm as the first elastic algorithm or an algorithm different from the first elastic algorithm, which is not limited in this embodiment of the present application. Furthermore, when the first identifier exists in the second IGP process, the second elastic algorithm may also be the elastic algorithm indicated by the first identifier in the second IGP process, which is not excluded in this embodiment of the present application. The embodiment of the present application also does not specifically limit the method for determining the second elastic algorithm. In an embodiment of the present application, the third node may be any node in the second IGP process. Based on the second notification message published by the first node, the third node may use the second elastic algorithm indicated by the second identifier carried in the second notification message to generate first routing information to the second node.

[0063] Alternatively, in an embodiment of the present application, when the first node determines that the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, that is, the elastic algorithm deployed in the second IGP process meets the first or second case in step 202, the first node may also choose not to publish the third advertisement information including the destination address of the second node. In other words, in both cases, the first node may choose not to introduce the destination address of the second node from the first IGP process into the second IGP process.

[0064] In an embodiment of the present application, in the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If not, the first node can carry the identifier of the elastic algorithm supported by the IGP process to be introduced in the notification information for publication, or can choose not to publish the notification information in the IGP process to be introduced, thereby solving the problem that the notification information introduced across processes cannot work normally when the elastic algorithms deployed by the two IGP processes are different.

[0065] Figure 3 A schematic diagram of another embodiment of the method for processing notification information provided in an embodiment of the present application.

[0066] See Figure 3 Another embodiment of the method for processing notification information provided in the embodiment of the present application may include:

[0067] 301. A first node receives first notification information sent by a second node in a first IGP process. The first notification information includes a destination address and a first identifier of the second node. The first identifier is used to indicate a first resilience algorithm in the first IGP process.

[0068] The embodiments of this application can be found in Figure 2 Step 201 in FIG. 1 is understood for simplicity and will not be described in detail here.

[0069] 302. The first node generates first routing information from the first node to the destination address according to the first advertisement information in the first IGP process.

[0070] In the embodiment of the present application, after receiving the first notification information sent by the second node in the first IGP process, the first node uses the first elastic algorithm to calculate and generate first routing information to the destination address.

[0071] For example, in an SRv6 network, when the destination address of the second node in the first notification information is the locator configured by the second node, the first node uses the first identifier contained in the TLV field of the locator to indicate the first elastic algorithm in the first IGP process to calculate the first routing information reaching the locator.

[0072] For example, in an SR-MPLS network, when the destination address of the second node in the first notification information is the prefix-SID configured by the second node, the first node uses the first elastic algorithm indicated by the first identifier contained in the TLV field of the prefix-SID in the first IGP process to calculate the first routing information to reach the prefix-SID.

[0073] 303. The first node determines whether the first identifier exists in the second IGP process.

[0074] In this embodiment of the present application, after receiving the first notification information sent by the second node, the first node determines whether the first identifier exists in the second IGP process. For example, if the first identifier included in the first notification information is the algorithm ID "128," the first node determines whether the elastic algorithm with the algorithm ID "128" exists in the second IGP process after receiving the first notification information sent by the second node.

[0075] The embodiments of this application can also be referred to Figure 2 The relevant contents in step 202 have been understood and will not be repeated here.

[0076] It should be noted that the embodiment of the present application does not limit the order of step 302 and step 303.

[0077] 304. If so, the first node determines whether the first identifier indicates the same elastic algorithm as the first elastic algorithm in the second IGP process.

[0078] In the embodiment of the present application, when the first node determines that the first identifier exists in the second IGP process, the first node further determines whether the first identifier indicates an elastic algorithm that is the same as the first elastic algorithm in the second IGP process.

[0079] The embodiments of this application can be found in Figure 2 The relevant contents of the first case in step 202 have been understood and will not be repeated here.

[0080] 305. If the first identifier exists in the second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the first node publishes a second notification message to the third node in the second IGP process, and the second notification message includes the destination address and the second identifier of the second node. The second identifier is used to indicate the second elastic algorithm in the second IGP process, the second elastic algorithm meets the preset conditions, and the second notification message is used to generate second routing information to the destination address.

[0081] In an embodiment of the present application, when a first node determines that a first identifier exists in a second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the first node may choose to publish a second notification message to a third node in the second IGP process, wherein the second notification message includes the destination address and the second identifier of the second node, the second identifier indicates a second elastic algorithm in the second IGP process, and the second elastic algorithm satisfies a preset condition. It should be noted that the preset conditions in the embodiment of the present application include one or more of the following conditions: the similarity between the second elastic algorithm and the first elastic algorithm satisfies a first threshold; the priority of the second elastic algorithm satisfies a second threshold.

[0082] Optionally, in this embodiment of the present application, the second elastic algorithm satisfying the preset condition may mean that the similarity between the second elastic algorithm and the first elastic algorithm satisfies a first threshold. In this embodiment of the present application, the similarity between the second elastic algorithm and the first elastic algorithm satisfying the first threshold includes both the cases where the definitions of the first elastic algorithm and the second elastic algorithm are completely identical and partially identical.

[0083] If satisfying the first threshold means that the definition of the second elastic algorithm is exactly the same as that of the first elastic algorithm, then when the first node determines that the first identifier exists in the second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the first node can determine whether there is a second elastic algorithm that is exactly the same as the definition of the first elastic algorithm from one or more elastic algorithms deployed in the second IGP process based on the definition of the first elastic algorithm. If it is determined that there is a second elastic algorithm, the first node generates a second notification message carrying the second identifier of the second elastic algorithm and publishes it in the second IGP process.

[0084] If satisfying the first threshold means that the third elastic algorithm and the first elastic algorithm have the same definition, then when the first node determines that the first identifier exists in the second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the first node can determine whether the second elastic algorithm exists based on the specific rule of similarity meeting the first threshold specified in the pre-set condition. For example, the first elastic algorithm includes specific definitions: link cost type A during path calculation, algorithm priority B, and link constraint C for participating in path calculation. The similarity meeting the first threshold means that the elastic algorithm definition satisfies the link cost type A and algorithm priority B during path calculation. The first node can then determine whether the second elastic algorithm meeting these conditions exists among the elastic algorithms deployed in the second IGP process. If it is determined that the second elastic algorithm exists, the first node generates a second notification message carrying the second identifier of the second elastic algorithm and publishes it in the second IGP process. It should be noted that other rules can be used to determine whether the similarity meets the first threshold, and this embodiment of the present application does not limit this.

[0085] Optionally, in an embodiment of the present application, the second elastic algorithm satisfying the preset condition may refer to the priority of the second elastic algorithm satisfying a second threshold. For example, the elastic algorithms deployed in the second IGP process are set with a priority order. When the first node determines that a first identifier exists in the second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the first node may also select a second elastic algorithm that satisfies the priority of the second threshold based on the preset priority order, and then generate a second notification message carrying the second identifier of the second elastic algorithm and publish it in the second IGP process.

[0086] Optionally, in the embodiment of the present application, the second elastic algorithm meeting the preset condition may also mean that the similarity between the second elastic algorithm and the first elastic algorithm meets the first threshold, and the priority of the second elastic algorithm meets the second threshold.

[0087] It should be noted that the pre-set conditions in the embodiment of the present application can also be other rules, and the second elastic algorithm can be associated with the first elastic algorithm or can be unrelated to the first elastic algorithm, and the embodiment of the present application does not limit this. For example, one or more elastic algorithms are set according to customer needs. When the first node determines that there is a first identifier in the second IGP process, but the elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm, or the first identifier does not exist in the second IGP process, the second elastic algorithm is determined according to customer needs, and then a second notification message carrying the second identifier of the second elastic algorithm is generated and published in the second IGP process.

[0088] Alternatively, in an embodiment of the present application, if the first node determines that there is a first identifier in the second IGP process, but the elasticity algorithm indicated by the first identifier in the second IGP process is different from the first elasticity algorithm, or the first identifier does not exist in the second IGP process, the first node may also choose not to publish the third notification information including the destination address of the second node in the second IGP process.

[0089] The embodiments of this application can be found in Figure 2 The relevant contents in step 203 in FIG. 1 can be understood for reference only and will not be repeated here.

[0090] It should be noted that, in the embodiment of the present application, the second notification information may be generated based on the first routing information generated by the first node in step 302. After determining the second resilience algorithm that meets the preset conditions, the first node generates the second notification information carrying the second identifier of the second resilience algorithm based on the first routing information from the first node to the destination address generated in the first IGP process.

[0091] 306. If the first identifier exists in the second IGP process, and the first identifier indicates the same elastic algorithm as the first elastic algorithm in the second IGP process, the first node publishes a fourth notification information to the third node in the second IGP process, and the fourth notification information includes the destination address and the first identifier of the second node. The fourth notification information is used to generate third routing information to the second node.

[0092] In an embodiment of the present application, when a first node determines that a second IGP process includes a first identifier, and the first identifier indicates a resiliency algorithm that is the same as the first resiliency algorithm in the second IGP process, the first node will issue a fourth notification message to a third node in the second IGP process, where the fourth notification message carries the destination address of the second node and the first identifier. The third node may calculate third routing information to the destination address based on the first resiliency algorithm.

[0093] It should be noted that, in the embodiment of the present application, the fourth announcement information may be generated based on the first routing information generated by the first node in step 302. After determining the first resilience algorithm indicated by the first identifier in the first IGP process and the resilience algorithm indicated by the first identifier in the second IGP process that is the same as the first resilience algorithm, the first node generates second announcement information carrying the first identifier based on the first routing information from the first node to the destination address generated in the first IGP process.

[0094] In an embodiment of the present application, in the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If yes, it can be directly introduced and published. If not, the first node can carry the identifier of the elastic algorithm supported by the IGP process to be introduced in the notification information for publication, or choose not to publish the notification information in the IGP process to be introduced, thereby solving the problem that the notification information introduced across processes cannot work normally when the elastic algorithms deployed by the two IGP processes are different.

[0095] The above is a detailed introduction to the method for processing notification information provided by the embodiment of the present application. Next, the device for processing notification information provided by the embodiment of the present application will be introduced. Figure 4 .

[0096] It is understandable that, in order to realize the above functions, the above-mentioned first node includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the modules and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0097] From the perspective of hardware structure, the first node can be implemented by one physical device, or by multiple physical devices, or it can be a logical function module within a physical device. The embodiments of the present application do not make specific limitations on this.

[0098] For example, the above Figures 2 to 3 The first node in Figure 4 The network device 400 is implemented as described above. The network device 400 may be a first node in a network, where the first node runs a first Interior Gateway Protocol (IGP) process and a second IGP process. The network also includes a second node and a third node, where the second node runs the first IGP process and the third node runs the second IGP process. The network device 400 includes a processor 410, a memory 420, and a transceiver 430. The transceiver 430 is configured to communicate with other devices or a communication network.

[0099] The processor 410 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (server IC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0100] The memory 420 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 420 may exist independently and be connected to the processor 410. The memory 420 may also be integrated with the processor 410.

[0101] The memory 420 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 410. The processor 410 is used to execute the computer-executable instructions stored in the memory 420, thereby implementing the notification information processing method provided in the embodiment of the present application.

[0102] Specifically, when the network device 400 is Figure 2-Figure 3 When the first node in the process is detected, the processor 410 is specifically configured to:

[0103] Receive the first notification information sent by the second node, the first notification information includes the destination address and the first identifier of the second node, the first identifier is used to indicate the first elastic algorithm in the first IGP process; determine whether the first identifier is used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process; when the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process: publish the second notification information to the third node in the second IGP process, the second notification information includes the destination address and the second identifier, the second identifier is used to indicate the second elastic algorithm in the second IGP process, and the second notification information is used to generate the first routing information to the destination address; or, do not publish the third notification information in the second IGP process, and the third notification information includes the destination address. For specific implementation, please refer to Figure 2 In the embodiment shown, steps 201 to 203, and Figure 3 The detailed description of steps 301 to 306 in the illustrated embodiment will not be repeated here.

[0104] Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

[0105] The embodiments of the present application can divide the functional modules of the network device according to the above method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0106] For example, when the functional modules are divided in an integrated manner, Figure 5 A schematic diagram of the structure of a notification information processing device 500 is shown. The processing device 500 corresponds to Figure 2-Figure 3 The first node in the embodiment.

[0107] See Figure 5 The notification information processing device 500 provided in the embodiment of the present application may include:

[0108] The receiving module 501 is configured to receive first notification information sent by the second node, the first notification information including the destination address and the first identifier of the second node, the first identifier being used to indicate the first resilience algorithm in the first IGP process. Figure 2 A detailed description of step 201 in the illustrated embodiment, and Figure 3The detailed description of step 301 in the illustrated embodiment will not be repeated here.

[0109] The judging module 502 is configured to judge whether the first identifier in the first notification information received by the receiving module 501 is used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process. Figure 2 A detailed description of step 202 in the illustrated embodiment, and Figure 3 The detailed description of step 303 and step 304 in the illustrated embodiment will not be repeated here.

[0110] Publishing module 503 is configured to, when judging module 502 judges that the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process: publish second notification information to the third node in the second IGP process, the second notification information including the destination address of the second node and the second identifier, the second identifier being used to indicate the second elastic algorithm in the second IGP process, and the second notification information being used to generate first routing information to the destination address; or not publish third notification information including the destination address in the second IGP process. For specific implementation methods, please refer to Figure 2 A detailed description of step 203 in the illustrated embodiment, and Figure 3 The detailed description of step 305 in the illustrated embodiment will not be repeated here.

[0111] In an embodiment of the present application, in the process of introducing notification information across processes, the first node can first determine whether the identifier of the elastic algorithm carried by the introduced notification information indicates the same elastic algorithm in the IGP process to be introduced. If not, the first node can carry the identifier of the elastic algorithm supported by the IGP process to be introduced in the notification information for publication, or can choose not to publish the notification information in the IGP process to be introduced, thereby solving the problem that the notification information introduced across processes cannot work normally when the elastic algorithms deployed by the two IGP processes are different.

[0112] Optionally, as an embodiment, the first identifier is not used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, including: the first identifier exists in the second IGP process, and the third elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm; or the first identifier does not exist in the second IGP process. For specific implementation methods, please refer to Figure 2 A detailed description of step 202 in the illustrated embodiment, and Figure 3 The detailed description of step 303 and step 304 in the illustrated embodiment will not be repeated here.

[0113] Optionally, as an embodiment, the processing device 500 further includes: a determining module 504 configured to determine the second elastic algorithm according to the first elastic algorithm before the publishing module 503 publishes the second notification information to the third node in the second IGP process, and the second elastic algorithm satisfies a preset condition. For specific implementation methods, please refer to Figure 3 The detailed description of step 305 in the illustrated embodiment will not be repeated here.

[0114] Optionally, as an embodiment, the preset conditions include one or more of the following: the similarity between the second elastic algorithm and the first elastic algorithm meets a first threshold, and the priority of the second elastic algorithm meets a second threshold. Figure 3 The detailed description of step 305 in the illustrated embodiment will not be repeated here.

[0115] Optionally, as an embodiment, the processing device 500 further includes: a generating module 505, configured to generate, in the first IGP process, second routing information to the destination address based on the first routing information after the receiving module 501 receives the first notification information sent by the second node; and generate the second notification information based on the second routing information in the second IGP process. For specific implementation methods, please refer to Figure 3 The detailed description of step 302 and step 305 in the illustrated embodiment will not be repeated here.

[0116] Optionally, as an embodiment, the publishing module 503 is further configured to publish fourth notification information to the third node in the second IGP process when the judging module 502 judges that the first identifier is used to indicate the same elastic algorithm as the first elastic algorithm in the second IGP process, wherein the fourth notification information includes the destination address and the first identifier, and the fourth notification information is used to generate third routing information to the destination address. For specific implementation methods, please refer to Figure 3 The detailed description of step 306 in the illustrated embodiment will not be repeated here.

[0117] Optionally, as an embodiment, the generating module 505 is further configured to generate, in the first IGP process, fourth routing information to the destination address based on the first routing information after the receiving module 501 receives the first notification information sent by the second node; and generate the fourth notification information based on the fourth routing information in the second IGP process. For specific implementation methods, please refer to Figure 3 The detailed description of step 302 and step 306 in the illustrated embodiment will not be repeated here.

[0118] Optionally, as an embodiment, when the processing device 500 is applied to a segment routing SRv6 network based on an IPv6 data plane, the first identifier is included in the type-length-value TLV field of the location information locator. For specific implementation methods, please refer to Figure 2 A detailed description of step 201 in the illustrated embodiment, and Figure 3 The detailed description of step 301 in the illustrated embodiment will not be repeated here.

[0119] Optionally, as an embodiment, when the processing device 500 is applied to a multi-protocol label switching MPLS network, the first identifier is included in a type-length-value TLV field of a prefix segment identifier prefix-SID. Figure 2 A detailed description of step 201 in the illustrated embodiment, and Figure 3 The detailed description of step 301 in the illustrated embodiment will not be repeated here.

[0120] It should be understood that the judgment module 502, determination module 504 and generation module 505 in the above embodiment can be implemented by a processor or processor-related circuit components, and the receiving module 501 and publishing module 503 in the above embodiment can be implemented by a transceiver or transceiver-related circuit components.

[0121] In addition, the judgment module 502, the determination module 504 and the generation module 505 can be software functional units, that is, the kinetic energy steps of these units described above are implemented by software. In this case, these software units can be stored in Figure 4 In the embodiment shown, the software code in the memory 420 is executed when the processor 410 reads the software code in the memory 420. Figure 4 The functions of the processor in the embodiment shown are shown in FIG. Figure 4 The detailed description of the processor 410 in FIG. 4 is omitted here.

[0122] Optionally, an embodiment of the present application provides a chip system, which includes a processor for supporting a terminal device to implement the above-mentioned data processing method. In one possible design, the chip system also includes a memory. The memory is used to store program instructions and data necessary for the terminal device. The chip system can be composed of a chip, or it can include a chip and other discrete devices, which is not specifically limited in the embodiment of the present application. For the specific implementation process, please refer to Figure 2 A detailed description of steps 201 to 203 in the illustrated embodiment, and Figure 3 The detailed description of steps 301 to 306 in the illustrated embodiment will not be repeated here.

[0123] It should be understood that the processor mentioned in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0124] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) is integrated into the processor.

[0125] It should also be understood that the memory mentioned in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0126] It should be noted that the memory described herein is intended to include, but not be limited to, these and any other suitable types of memory.

[0127] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0128] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0129] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a server, or a data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode to another website, a computer, a server, or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium can be a magnetic medium, (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive Solid State Disk (SSD)), etc.

[0130] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0131] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0132] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0133] The above is a detailed introduction to the processing method, device and storage medium for notification information provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for processing notification information, characterized in that: The method is applied to a first node in a network, where the first node runs a first Interior Gateway Protocol (IGP) process and a second IGP process. The network further includes a second node and a third node, where the second node runs the first IGP process and the third node runs the second IGP process. The method includes: The first node receives first advertisement information sent by the second node, where the first advertisement information includes location information (locator) and a first identifier of the second node in a segment routing (SRv6) network based on an Internet Protocol version 6 (IPv6) data plane, where the first identifier is used to indicate a first resilience algorithm in the first IGP process; The first node publishes second notification information to the third node in the second IGP process, where the second notification information includes the locator and a second identifier, where the second identifier is used to indicate a second resilience algorithm in the second IGP process, and the second notification information is used to generate first routing information to the locator; or The first node does not publish a notification message including the locator in the second IGP process; or, In a case where the first identifier is used in the second IGP process to indicate a resiliency algorithm that is the same as the first resiliency algorithm, the first node publishes fourth notification information to the third node in the second IGP process, the fourth notification information including the locator and the first identifier, and the fourth notification information is used to generate third routing information to the locator.

2. The method according to claim 1, characterized in that The first identifier is different from the second identifier.

3. The method according to claim 1 or 2, characterized in that The first elasticity algorithm is different from the second elasticity algorithm.

4. The method according to any one of claims 1 to 3, characterized in that The first identifier exists in the second IGP process, and the third elastic algorithm indicated by the first identifier in the second IGP process is different from the first elastic algorithm; or, The first identifier does not exist in the second IGP process.

5. The method according to any one of claims 1 to 4, characterized in that Before the first node issues the second notification information to the third node in the second IGP process, the method further includes: The first node determines the second elastic algorithm according to the first elastic algorithm, and the second elastic algorithm meets a preset condition.

6. The method according to claim 5, characterized in that The pre-conditions include one or more of the following: The similarity between the second elastic algorithm and the first elastic algorithm meets a first threshold; the priority of the second elastic algorithm meets a second threshold.

7. The method according to any one of claims 1 to 6, characterized in that After the first node receives the first notification information sent by the second node, the method further includes: The first node generates, in the first IGP process, second routing information to the locator according to the first advertisement information; The first node generates the second advertisement information according to the second routing information in the second IGP process.

8. The method according to any one of claims 1 to 7, characterized in that The first identifier is included in a type-length-value TLV field.

9. A network device, characterized in that: include: processor and memory; The memory is used to store computer-readable instructions or computer programs, and the processor is used to read the computer-readable instructions to implement the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The method comprises computer program instructions which, when executed on a computer, cause the computer to perform the method according to any one of claims 1 to 8.

11. A network system comprising a first node, a second node, and a third node, wherein the first node runs a first Interior Gateway Protocol (IGP) process and a second IGP process, the second node runs the first IGP process, and the third node runs the second IGP process, wherein: The first node is configured to execute the method according to any one of claims 1 to 8.

Images