Data processing method and apparatus, and electronic device

Abstract

Embodiments of the present application relate to the technical field of communication, and provide a data processing method and device and electronic equipment. In the embodiments of the present application, a source attribute is added to a BGP-LS prefix NLRI to distinguish a local BGP-LS prefix from an externally introduced external BGP-LS prefix. Thus, when a route reflector RR performs SPF calculation, the source attribute can be used to accurately filter out invalid external BGP-LS prefixes, and only local BGP-LS prefixes are selected to participate in SPF calculation, thereby effectively reducing the amount of data to be processed in SPF calculation, reducing the calculation complexity and memory resource occupation of the route reflector, and further improving the SPF calculation rate and reducing the calculation resource overhead.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to data processing methods, apparatus and electronic equipment. Background Technology

[0002] In large-scale cross-domain or hierarchical networking scenarios, the Border Gateway Protocol - Link State (BGP-LS) protocol is widely used to transmit network topology and reachability information to the controller in the network. Simultaneously, Optimal Route Reflection (ORR) technology is often employed to optimize route reflection. The core of ORR technology lies in using a RouteReflector (RR) within the network to perform Shortest Path First (SPF) calculations from the client's perspective for the connected client groups, selecting the optimal BGP path with the lowest Interior Gateway Protocol (IGP) cost.

[0003] Currently, in practical applications, RR directly relies on all locally collected BGP-LS prefix information when performing the SPF calculation. However, since RR stores both locally collected and external BGP-LS prefixes indiscriminately, this introduces a large number of invalid external BGP-LS prefixes into the SPF calculation process, increasing computational resource overhead and leading to resource waste. Specifically, the local BGP-LS prefix is ​​generated based on the network node's own address information (such as local physical interface address, local loopback address, etc.); the external BGP-LS prefix is ​​generated by the network node based on external routing information (such as address information used by user / service traffic, such as internet segments); and the BGP-LS prefix is ​​used to identify the internet protocol (IP) segments reachable by the network node. Summary of the Invention

[0004] In view of this, this application provides a data processing method, apparatus and electronic device to filter out local BGP-LS prefixes for SPF calculation by utilizing the source attribute of BGP-LS prefixes, thereby avoiding the introduction of external BGP-LS prefixes and increasing the overhead of computing resources.

[0005] This application provides a data processing method applied to a network device, the method comprising: Determine the source attribute of the current BGP-LS prefix Network Layer Reachability Information (NLRI), and advertise the current BGP-LS prefix NLRI and its source attribute to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information of the device or from externally introduced routing information; When this device acts as an ORR route reflector and needs to perform SPF calculation for a specified client, it selects the BGP-LS prefix NLRI whose source attribute indicates the local location for the SPF calculation based on the source attribute of each obtained BGP-LS prefix NLRI.

[0006] This application embodiment also provides a data processing apparatus, which is applied to a network device, and the apparatus includes: The determination module is used to determine the source attribute of the current BGP-LS prefix NLRI; The announcement module is used to announce the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information of the device or externally introduced routing information. The calculation module is used to select the BGP-LS prefix NLRI that indicates the local source attribute for SPF calculation when the device is acting as an ORR route reflector and needs to perform SPF calculation for a specified client, based on the source attribute of each BGP-LS prefix NLRI that has been obtained.

[0007] This application also provides an electronic device, which includes: Processor; and A computer-readable storage medium storing computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method described above.

[0008] This application also provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the above method.

[0009] As can be seen from the above technical solutions, in this embodiment of the application, by adding a source attribute to the BGP-LS prefix NLRI to distinguish between the local BGP-LS prefix and the externally introduced BGP-LS prefix, invalid external BGP-LS prefixes can be accurately filtered out based on this source attribute when the route reflector (RR) performs SPF calculation. Only the local BGP-LS prefix is ​​selected to participate in the SPF calculation, thereby effectively reducing the amount of data that needs to be processed for SPF calculation, reducing the computational complexity and memory resource consumption of the route reflector, thereby improving the SPF calculation rate and reducing computational resource overhead.

[0010] Furthermore, in this embodiment, by adding the source attribute of the BGP-LS prefix NLRI when announcing the BGP-LS prefix NLRI, the controller in the network can clearly construct a network infrastructure topology map based on the local BGP-LS prefix route that marks the location of network nodes, according to the source attribute of the received BGP-LS prefix NLRI. This avoids irrelevant information such as external BGP-LS prefixes interfering with network topology modeling, thereby improving the accuracy and reliability of the entire network topology identification and making applications such as traffic engineering and fault delimitation more accurate and efficient. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 This is a flowchart illustrating a data processing method provided in an embodiment of this application.

[0013] Figure 2 This is a schematic diagram of the message structure of a BGP update message provided in an embodiment of this application.

[0014] Figure 3 This is a schematic diagram illustrating the implementation of the newly added prefix source TLV field provided in the embodiments of this application.

[0015] Figure 4 This is a schematic diagram illustrating the implementation of the networking architecture provided in the embodiments of this application.

[0016] Figure 5 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application.

[0017] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, and to make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0019] See Figure 1 , Figure 1 This is a flowchart illustrating a method provided in an embodiment of this application. In this embodiment, the method can be applied to network devices in a BGP network. Figure 1 As shown, the process may include the following steps: Step 101: Determine the source attribute of the current BGP-LS prefix NLRI, and advertise the current BGP-LS prefix NLRI and its source attribute to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information of the device or from externally introduced routing information.

[0020] In this embodiment, the current BGP-LS prefix NLRI can be used to indicate the IP network segment reachable by this device. As described above, the local BGP-LS prefix NLRI is generated based on the local physical interface address or local loopback address of this device, that is, its source attribute can be determined as follows: the current BGP-LS prefix NLRI originates from local address information (e.g., it can be denoted as local LOCAL); the external BGP-LS prefix NLRI is generated based on the routing information of external routes, that is, its source attribute can be determined as follows: the current BGP-LS prefix NLRI originates from externally introduced routing information (e.g., it can be denoted as externally introduced EXTERNAL).

[0021] Based on this, this embodiment can determine the source attribute of the BGP-LS prefix NLRI when generating the BGP-LS prefix NLRI. Specifically, as an embodiment, determining the source attribute of the current BGP-LS prefix NLRI in this step may include, for example, first determining whether the routing prefix corresponding to the current BGP-LS prefix NLRI belongs to the local physical interface address or local loopback address of this device; then, if so, determining the source attribute of the current BGP-LS prefix NLRI as originating from local address information; if not, indicating that the BGP-LS prefix NLRI may be originating from externally introduced routing information.

[0022] The local physical interface address can be understood as the IP address assigned to the local physical interface. The local loopback address can be understood as a special virtual IP address that does not correspond to any physical port, but is used to implement local network communication on the same device.

[0023] In this embodiment, routing information can be advertised via BGP update messages in the BGP protocol. Based on this, as an example, this step advertises the current BGP-LS prefix NLRI and its source attributes to the BGP-LS peers. Specifically, this can be implemented by sending a first BGP update message to the BGP-LS peers configured on this device. The first BGP update message carries at least the current BGP-LS prefix NLRI and its source attributes to achieve information advertising to the BGP-LS peers.

[0024] As for how to specifically carry the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI in the first BGP update message, examples will be provided below, and will not be elaborated here.

[0025] Step 102: When this device acts as an ORR route reflector and needs to perform SPF calculation for a specified client, select the BGP-LS prefix NLRI whose source attribute indicates the local location for the SPF calculation based on the source attribute of each obtained BGP-LS prefix NLRI.

[0026] In this embodiment, as one example, after generating the BGP-LS prefix NLRI, the device can locally store the BGP-LS prefix NLRI and its corresponding source attributes, or, after receiving the BGP-LS prefix NLRI and its corresponding source attributes announced by other network devices, it can locally store the received BGP-LS prefix NLRI and its corresponding source attributes, so that they can be used for SPF calculation later.

[0027] Based on this, when this device acts as an ORR route reflector and needs to perform SPF calculation for a specified client, it can filter the BGP-LS prefix NLRIs based on the source attributes of each obtained BGP-LS prefix NLRI (i.e., the BGP-LS prefix NLRIs stored locally). This filters out BGP-LS prefix NLRIs whose source attributes indicate external EXTERNAL (i.e., external BGP-LS prefix NLRIs), and only selects BGP-LS prefix NLRIs whose source attributes indicate local LOCAL (i.e., local BGP-LS prefix NLRIs) for the above SPF calculation. This avoids interference from external BGP-LS prefix NLRIs, reduces the overhead of SPF calculation resources, and improves the SPF calculation rate.

[0028] In this embodiment, the ORR route reflector can be understood as a route reflector that enables the ORR function. The specified client can refer to the client that this device interfaces with in the network, for example, it can be obtained through the client configuration information of this device.

[0029] Optionally, in this embodiment, the triggering time for performing SPF calculation for a specified client is not specifically limited and can be flexibly set based on actual application needs; for example, SPF calculation for a specified client can be triggered when a specified change occurs in the link state information database used for ORR function in the ORR route reflector. As for how to specifically perform SPF calculation for a specified client, please refer to the description of related technologies, which are not specifically limited here.

[0030] This concludes the process. Figure 1 The process is shown below.

[0031] pass Figure 1 As can be seen from the process shown, in this embodiment of the application, by adding a source attribute to the BGP-LS prefix NLRI to distinguish between the local BGP-LS prefix and the externally introduced BGP-LS prefix, invalid external BGP-LS prefixes can be accurately filtered out based on this source attribute when the route reflector (RR) performs SPF calculation. Only the local BGP-LS prefix is ​​selected to participate in the SPF calculation, thereby effectively reducing the amount of data that needs to be traversed and processed for SPF calculation, reducing the computational complexity and memory resource consumption of the route reflector, and thus improving the SPF calculation speed and reducing computational resource overhead.

[0032] Furthermore, in this embodiment, by adding the source attribute of the BGP-LS prefix NLRI when announcing the BGP-LS prefix NLRI, the controller in the network can clearly construct a network infrastructure topology map based on the local BGP-LS prefix route that marks the location of network nodes, according to the source attribute of the received BGP-LS prefix NLRI. This avoids irrelevant information such as external BGP-LS prefixes interfering with network topology modeling, thereby improving the accuracy and reliability of the entire network topology identification and making applications such as traffic engineering and fault delimitation more accurate and efficient.

[0033] Before describing how the current BGP-LS prefix NLRI and its source attribute are carried in the first BGP update message in step 101 above, the message structure of the BGP update message will be described with an example: In this embodiment, as an example, the message structure of the BGP update message (also known as the BGP update message) is as follows: Figure 2As shown, it includes: a message header, a BGP path attribute field, and an NLRI field. The BGP path attribute field can contain various path attributes such as community attributes and BGP-LS attributes. The NLRI field can contain various NLRIs, such as the BGP-LS prefix NLRI.

[0034] Optionally, in this embodiment, the source attribute of the current BGP-LS prefix NLRI is added to the BGP update message only by the originating device of the current BGP-LS prefix NLRI (i.e., the network device that generated the current BGP-LS prefix NLRI). For example, the source attribute of the current BGP-LS prefix NLRI can be encapsulated in the BGP-LS attribute or community attribute of the BGP update message. Subsequently, during the forwarding of the BGP update message, the source attribute carried in the BGP update message can be encapsulated in different positions as needed, i.e., it can be encapsulated in both the BGP-LS attribute and community attribute of the BGP update message as needed. However, it should be noted that it cannot be encapsulated in both the BGP-LS attribute and community attribute of the BGP update message simultaneously.

[0035] Based on the above description, the following example illustrates how the current BGP-LS prefix NLRI and its source attribute are carried in the first BGP update message: In this embodiment, it should first be noted that the aforementioned BGP-LS attributes are optional non-transitive attributes, while community attributes are optional transitive attributes. "Optional" can be understood as meaning that it can be carried or not. "Non-transitive" can be understood as meaning that by default, it is not allowed to be transmitted across Autonomous System (AS) domains; that is, when transmitting across AS domains, non-transitive attributes such as the aforementioned BGP-LS attributes in the BGP update message will be discarded (except for special policy configurations). Correspondingly, "transitive" can be understood as meaning that it is allowed to be transmitted across AS domains; that is, when transmitting across AS domains, transitive attributes such as the aforementioned community attributes in the BGP update message will not be discarded by default.

[0036] Based on this, in this embodiment, as one example, the first BGP update message carries the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI. In specific implementations, this may include, for example, the following: First, check whether this device and its corresponding BGP-LS peer belong to the same AS.

[0037] For example, during the process of establishing a BGP connection with the corresponding BGP-LS peer, this device obtains and records the AS number (used to identify the AS domain of the BGP-LS peer) advertised by the BGP-LS peer. Based on this, when checking whether this device and the corresponding BGP-LS peer belong to the same AS, it can check whether the AS number corresponding to the BGP-LS peer recorded locally by this device is the same as the AS number configured on this device (used to identify the AS domain of this device). If they are the same, it is determined that this device and the corresponding BGP-LS peer belong to the same AS; if they are different, it is determined that this device and the corresponding BGP-LS peer do not belong to the same AS.

[0038] Subsequently, if this device and its corresponding BGP-LS peer belong to the same AS, then cross-AS domain transmission is not involved. In this case, the source attribute of the current BGP-LS prefix NLRI can be encapsulated into the newly added Type-Length-Value (TLV) field in the BGP-LS attributes of the first BGP update message (as described above). Figure 2 As shown, the newly added prefix source TLV field in the BGP-LS attributes, that is, the source attribute of the current BGP-LS prefix NLRI is located in the newly added TLV field in the BGP-LS attributes of the first BGP update message; or, the source attribute of the current BGP-LS prefix NLRI can be encapsulated into the newly added community attribute of the first BGP update message, that is, the source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message.

[0039] If this device and its corresponding BGP-LS peer do not belong to the same AS, then cross-AS domain transmission is involved. In this case, in order to avoid the loss of source attributes, the source attributes of the current BGP-LS prefix NLRI can only be encapsulated into the newly added community attributes of the first BGP update message.

[0040] Optionally, in this embodiment, the above-mentioned encapsulation of the source attribute of the current BGP-LS prefix NLRI into the newly added community attribute of the first BGP update message may, in specific implementations, include: When the source attribute of the current BGP-LS prefix NLRI indicates local (LOCAL), the source attribute of the current BGP-LS prefix NLRI is encapsulated into the newly added community attribute of the first BGP update message. When the source attribute of the current BGP-LS prefix NLRI indicates externally introduced (EXTERNAL), no processing is required. In this way, if the newly added community attribute and the BGP-LS attribute are not found in the first BGP update message, it indicates that the current BGP-LS prefix NLRI is externally introduced (i.e., the source attribute is externally introduced (EXTERNAL)).

[0041] Alternatively, when the source attribute of the current BGP-LS prefix NLRI indicates local (LOCAL), the source attribute of the current BGP-LS prefix NLRI is encapsulated into the newly added community attribute of the first BGP update message, and represented by the first community attribute value in the newly added community attribute. When the source attribute of the current BGP-LS prefix NLRI indicates externally introduced (EXTERNAL), the source attribute of the current BGP-LS prefix NLRI is encapsulated into the newly added community attribute of the first BGP update message, and represented by the second community attribute value in the newly added community attribute. The first community attribute value is different from the second community attribute value.

[0042] For example, when the BGP-LS attribute of the first BGP update message carries the source attribute of the current BGP-LS prefix NLRI, a prefix source TLV field can be added to the BGP-LS attribute to record the source attribute of the current BGP-LS prefix NLRI. The specific format of this newly added prefix source TLV field is as follows: Figure 3 As shown: Type code: Requires a new code point assigned by the Internet Assigned Numbers Authority (IANA), which occupies 2 bytes, such as TBD0 (this is just an example).

[0043] Length: The actual length of the value, fixed at 1, occupying 2 bytes.

[0044] Value: The value used to characterize the source attribute of the current BGP-LS prefix NLRI, occupying 1 byte, and the value range can be 0~255; for example, 0 and 255 are reserved values, 1 indicates that it comes from the local device (i.e., LOCAL), and 2 indicates that it is introduced from outside the device (i.e., EXTERNAL).

[0045] As another example, when the community attribute of the first BGP update message carries the source attribute of the current BGP-LS prefix NLRI, a well-known community attribute (such as the BGP-LS local prefix community attribute) can be added to the community attribute to characterize the source attribute of the current BGP-LS prefix NLRI.

[0046] The newly added well-known community attribute can be temporarily labeled as TBD1, with a length of 4 bytes. Based on this, if the first BGP update message contains this newly added well-known community attribute in its community attributes, it indicates that the current BGP-LS prefix NLRI originates from the device's local address information (i.e., the source attribute is local LOCAL); conversely, if the first BGP update message does not contain this newly added well-known community attribute and also does not contain the BGP-LS attribute, it indicates that the BGP-LS prefix NLRI originates from externally introduced routing information (i.e., the source attribute is externally introduced EXTERNAL).

[0047] Based on the above description, in this embodiment, as one example, the above data processing method further includes: When it is necessary to forward the received second BGP update message to a BGP-LS peer, in order to avoid the loss of the source attribute of the BGP-LS prefix NLRI during the forwarding process, it is advisable to first check whether the device and the corresponding BGP-LS peer belong to the same AS.

[0048] If so, then forward the second BGP update message directly.

[0049] If not, when the source attribute of the BGP-LS prefix NLRI is carried in the BGP-LS attribute of the second BGP update message, the source attribute is encapsulated into the new community attribute of the second BGP update message, and the source attribute in the encapsulated BGP-LS attribute of the second BGP update message is deleted before forwarding it (that is, after deleting the source attribute in the BGP-LS attribute of the encapsulated second BGP update message, the second UDP message is forwarded).

[0050] To facilitate understanding of the specific implementation process of the above data processing method, specific examples are provided below.

[0051] In practical applications, the BGP-LS protocol does not provide any mechanism to identify the source attribute of the BGP-LS prefix NLRI. This leads to the following technical shortcomings for network devices such as route reflectors (RR) and controllers running the BGP-LS protocol: (1) Resource waste: The route reflector (RR) stores local BGP-LS prefixes and a large number of externally introduced BGP-LS prefixes indiscriminately. When the route reflector performs SPF calculation for each client, it cannot effectively filter out useless external BGP-LS prefixes. This not only increases the complexity of SPF calculation, but also leads to excessive memory consumption and increased computing resource overhead.

[0052] (2) Information ambiguity: For the upper-layer controller, it is impossible to distinguish whether the received BGP-LS prefix NLRI belongs to the infrastructure prefix that represents the location of the network node (which can be used for network modeling) or the ordinary service route that carries traffic (such as Internet route), thus affecting the accuracy of network modeling and the accuracy of policy application.

[0053] Based on this, in order to solve the above-mentioned technical problems, this embodiment provides a data processing method that can complete the source differentiation of prefix NLRI during the BGP-LS prefix NLRI generation stage, so that the RR deploying ORR can filter invalid information such as external BGP-LS prefixes to save computing resources, while enabling the upper-layer controller to obtain a more semantic network view.

[0054] For example, as an embodiment, the data processing method provided in this embodiment can be applied to a BGP ORR scenario, specifically to network devices such as route reflectors that act as BGP-LS speakers and enable ORR functionality. The specific implementation process is as follows: 1. Source Labeling: When generating the BGP-LS prefix NLRI, determine its source attribute. Specifically, if the prefix originates from the local physical interface address or local loopback address of this device, its source attribute can be labeled as local (LOCAL); if the prefix is ​​generated based on routing information imported from an external routing domain using BGP or other routing protocols, its source attribute can be labeled as externally imported (EXTERNAL).

[0055] 2. Information Advertisement: When advertising the prefix NLRI to BGP-LS peers (such as Software-Defined Network (SDN) controllers or ORR route reflectors), the source attribute indicating LOCAL or EXTERNAL can be encapsulated in the BGP attributes of the BGP update message (such as a newly defined prefix attribute TLV in the BGP-LS attributes, such as the prefix source TLV, or a well-known community attribute added in the community attributes to characterize the prefix source) and sent together.

[0056] 3. ORR Optimization: When this device acts as an ORR route reflector and performs SPF calculation for the specified client group it is connected to, it can filter out the BGP-LS prefix NLRI with the source attribute indicating EXTERNAL (that is, filter out useless external BGP-LS prefix NLRI) based on the source attribute parsed from the BGP attributes, and only select the BGP-LS prefix NLRI with the source attribute indicating LOCAL for SPF calculation, so as to effectively reduce the consumption of computing resources and improve the SPF calculation rate.

[0057] For example, see Figure 4 The cross-domain network shown comprises three Autonomous Systems (AS): AS 200, AS 100, and AS 300. PE-1 (Carrier Edge Router 1), PE-2 (Carrier Edge Router 2), PE-3 (Carrier Edge Router 3), PE-4 (Carrier Edge Router 4), and RR-5 are located in AS 100; ASBR-6 (Autonomous System Border Router-6) is located in AS 200; and ASBR-7 (Autonomous System Border Router-7) is located in AS 300. AS 100 is divided into three IGP domains (such as ISIS or OSPF): Area 1, Area 2, and Area 3. RR-5 acts as an ORR route reflector, and PE-1, PE-2, PE-3, and PE-4 are the clients that RR-5 interfaces with.

[0058] In this context, PE stands for Provider Edge, ASBR for Autonomous System Boundary Router, ISIS for Intermediate System to Intermediate System, and OSPF for Open Shortest Path First.

[0059] Based on the above description, taking the PE-1 device as an example, the PE-1 device adds a LOCAL tag to the BGP-LS prefix NLRI generated based on the local interface IP address prefix (which includes the physical interface IP address + loopback address) (i.e., marks its source attribute as local LOCAL), and adds an EXTERNALL tag to the BGP-LS prefix NLRI generated based on the IP prefix introduced from the ASBR-6 device (i.e., marks its source attribute as externally introduced EXTERNALL). When PE-1 sends the BGP-LS prefix NLRI to RR-5, it also encapsulates the tag indicating LOCAL or EXTERNALL in the BGP attributes of the BGP update message. It is understood that other devices (such as PE-2, PE-3, and PE-4) can also perform similar operations as PE-1.

[0060] RR-5 receives all BGP-LS prefix NLRIs. When the ORR function component of RR-5 needs to obtain reachability information from BGP-LS prefix routes, it only obtains BGP-LS prefix routes carrying the LOCAL label, excluding BGP-LS prefix routes carrying the EXTERNAL label. Based on this, the ORR function component of RR-5 can perform SPF calculation based solely on reachability information carrying the LOCAL label (i.e., BGP-LS prefix routes carrying the LOCAL label), avoiding the consumption of computing resources by useless reachability information.

[0061] This concludes the description of the method provided in the embodiments of this application. The apparatus provided in the embodiments of this application will now be described: As an example, this embodiment also provides a routing device applied to BGP ORR. For example, see... Figure 5 , Figure 5 This is a schematic diagram of a routing device applied to BGP ORR, provided as an embodiment of this application. The device corresponds to... Figure 1 The process is shown below. Figure 5 As shown, the routing device 500 for BGP ORR is applied to a network device, and the routing device 500 for BGP ORR includes: Module 501 is used to determine the source attribute of the current BGP-LS prefix NLRI; The announcement module 502 is used to announce the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information of the device or externally introduced routing information. The calculation module 503 is used to select the BGP-LS prefix NLRI whose source attribute indicates the local location for the SPF calculation when the device is acting as an ORR route reflector and needs to perform SPF calculation for a specified client, based on the source attribute of each BGP-LS prefix NLRI that has been obtained.

[0062] As an example, when the notification module 502 announces the current BGP-LS prefix NLRI and its source attributes to the BGP-LS peers, it is specifically used for: Send a first BGP update message to the BGP-LS peer, wherein the first BGP update message carries at least the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI.

[0063] As an example, if this device and the BGP-LS peer belong to the same AS, then: The source attribute of the current BGP-LS prefix NLRI is located in the newly added TLV field of the BGP-LS attribute of the first BGP update message; or, the source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message.

[0064] As an example, if this device and the BGP-LS peer belong to different ASs, then: The source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message.

[0065] As an example, the determining module 501, when performing the determination of the source attribute of the current BGP-LS prefix NLRI, is specifically used for: Determine whether the routing prefix corresponding to the current BGP-LS prefix NLRI belongs to the local physical interface address or local loopback address of this device; If so, the source attribute of the current BGP-LS prefix NLRI is determined to be local address information. If not, the source attribute of the current BGP-LS prefix NLRI will be determined as the current BGP-LS prefix NLRI originating from externally introduced routing information.

[0066] As one embodiment, the device further includes: The forwarding module is used to check whether the device and the BGP-LS peer belong to the same AS when it needs to forward the received second BGP update message to the BGP-LS peer. If not, when the source attribute of the BGP-LS prefix NLRI is carried in the BGP-LS attribute of the second BGP update message, the source attribute is encapsulated into the new community attribute of the second BGP update message, and the source attribute in the encapsulated BGP-LS attribute of the second BGP update message is deleted before forwarding.

[0067] This concludes the process. Figure 5 Structural description of the device shown.

[0068] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0069] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0070] Please see Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided as an exemplary embodiment of this application. The electronic device includes a processor and a computer-readable storage medium; the computer-readable storage medium stores a plurality of computer program instructions, which, when executed by the processor, implement the method disclosed in the above example of this application. Depending on the actual function of the electronic device, other hardware may also be included, which will not be elaborated further.

[0071] Based on the same concept as the above method, this application also provides a computer-readable storage medium storing a plurality of computer program instructions, which, when executed by a processor, can implement the method disclosed in the above examples of this application.

[0072] For example, the aforementioned computer-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, messages, etc. For instance, computer-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0073] The above are merely preferred embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, This method is applied to network devices, and the method includes: Determine the source attribute of the current BGP-LS prefix network reachability information (NLRI) and announce the current BGP-LS prefix NLRI and its source attribute to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information or externally introduced routing information. When this device acts as an optimal route reflection (ORR) route reflector and needs to perform shortest path first (SPF) calculation for a specified client, it selects the BGP-LS prefix NLRI whose source attribute indicates the local location for the SPF calculation based on the obtained source attributes of each BGP-LS prefix NLRI.

2. The method according to claim 1, characterized in that, The step of announcing the current BGP-LS prefix NLRI and its source attributes to BGP-LS peers includes: Send a first BGP update message to the BGP-LS peer, wherein the first BGP update message carries at least the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI.

3. The method according to claim 2, characterized in that, If this device and the BGP-LS peer belong to the same Autonomous System (AS), then: The source attribute of the current BGP-LS prefix NLRI is located in the newly added Type-Length-Value (TLV) field of the BGP-LS attributes of the first BGP update message; or, The source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message.

4. The method according to claim 2, characterized in that, If this device and the BGP-LS peer belong to different ASs, then the source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message.

5. The method according to claim 1, characterized in that, The source attributes for determining the current Border Gateway Protocol Link State (BGP-LS) prefix network reachability information (NLRI) include: Determine whether the routing prefix corresponding to the current BGP-LS prefix NLRI belongs to the local physical interface address or local loopback address of this device; If so, the source attribute of the current BGP-LS prefix NLRI is determined to be local address information. If not, the source attribute of the current BGP-LS prefix NLRI will be determined as the current BGP-LS prefix NLRI originating from externally introduced routing information.

6. The method according to claim 1, characterized in that, The method further includes: When it is necessary to forward the received second BGP update message to the BGP-LS peer, check whether this device and the BGP-LS peer belong to the same AS. If not, when the source attribute of the BGP-LS prefix NLRI is carried in the BGP-LS attribute of the second BGP update message, the source attribute is encapsulated into the new community attribute of the second BGP update message, and the source attribute in the encapsulated BGP-LS attribute of the second BGP update message is deleted before forwarding.

7. A data processing apparatus, characterized in that, This device is used in network equipment and includes: The determination module is used to determine the source attribute of the current Border Gateway Protocol Link State (BGP-LS) prefix network reachability information (NLRI). The announcement module is used to announce the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI to the BGP-LS peers; wherein, the source attribute is used to indicate whether the current BGP-LS prefix NLRI originates from local address information of the device or externally introduced routing information. The calculation module is used to select the BGP-LS prefix NLRI whose source attribute indicates the local location for the SPF calculation when the device is acting as an optimal route reflection ORR route reflector and needs to perform shortest path first SPF calculation for a specified client, based on the source attribute of each obtained BGP-LS prefix NLRI.

8. The apparatus according to claim 7, characterized in that, The notification module is specifically used for: Send a first BGP update message to the BGP-LS peer, wherein the first BGP update message carries at least the current BGP-LS prefix NLRI and the source attribute of the current BGP-LS prefix NLRI; And / or, If this device and the BGP-LS peer belong to the same Autonomous System (AS), then: The source attribute of the current BGP-LS prefix NLRI is located in the newly added Type-Length-Value (TLV) field of the BGP-LS attributes of the first BGP update message; or, the source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message. If this device and the BGP-LS peer belong to different ASs, then: The source attribute of the current BGP-LS prefix NLRI is located in the newly added community attribute of the first BGP update message; And / or, The determining module is specifically used for: Determine whether the routing prefix corresponding to the current BGP-LS prefix NLRI belongs to the local physical interface address or local loopback address of this device; If so, the source attribute of the current BGP-LS prefix NLRI is determined to be local address information. If not, the source attribute of the current BGP-LS prefix NLRI will be determined as the current BGP-LS prefix NLRI originating from externally introduced routing information; And / or, The device further includes: The forwarding module is used to check whether the device and the BGP-LS peer belong to the same AS when it needs to forward the received second BGP update message to the BGP-LS peer. If not, when the source attribute of the BGP-LS prefix NLRI is carried in the BGP-LS attribute of the second BGP update message, the source attribute is encapsulated into the new community attribute of the second BGP update message, and the source attribute in the encapsulated BGP-LS attribute of the second BGP update message is deleted before forwarding.

9. An electronic device, characterized in that, The electronic device includes: Processor; and A computer-readable storage medium storing computer program instructions that, when executed by the processor, cause the processor to perform the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

Images