Methods for receiving BGP-intent routes and advertising BGP-intent routes

Abstract

An embodiment of the present disclosure provides a method for receiving a BGP-intent route and a method for advertising a BGP-intent route, the method for receiving a BGP-intent route includes a step of receiving a BGP-intent route advertised from a BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

Description

Technical Field

[0001] This disclosure claims the priority of a Chinese patent application filed with the China National Intellectual Property Administration on October 25, 2021, with an application number of 202111243804.0 and an invention title of "Method for Receiving BGP-intent Routes and Method for Advertising BGP-intent Routes", and all of its contents are incorporated herein by reference.

[0002] This disclosure relates to the field of data communication, and specifically to a method for receiving BGP-intent routes and a method for advertising BGP-intent routes.

Background Art

[0003] In large networks spanning multiple domains, the Border Gateway Protocol (BGP) is commonly used to provide end-to-end intent-based routing. Intent-based routing refers to the selection of lower-layer transmission paths based on a clear intent when a BGP route repeats its next hop, meaning that intent information must be carried when BGP routes are advertised. Since the lower-layer transmission paths are traffic engineering paths established based on a specific intent, in networks providing transmission services, intent may also be called traffic engineering goals. Currently, there are multiple ways in which intent is carried when BGP routes are advertised. For example, draft-kaliraj-idr-bgp-classful-transport-planes-12 carries intent information by defining a "Classful Transport" SAFI NLRI and a "Transport Class" Route Target extended community, draft-dskc-bess-bgp-car-02 carries intent information by defining a BGP CAR SAFI NLRI, and draft-zhou-idr-inter-domain-lcu-02 carries intent information using a Color extended community directly. In this specification, such BGP routes are collectively referred to as BGP-intent routes.

[0004] Generally, a node receiving a BGP-intent route advertisement message decodes the intent locally based on intent-template information and either establishes a transmission path or selects an existing transmission path to the message advertiser that satisfies the intent. Intent-template information includes a set of constraints, such as the amount of link bandwidth that must be provided in the path, minimum and maximum delay limits, delay jitter limits, packet loss rate limits, inclusion or exclusion of specific nodes or links, and restrictions on calculating routes within a specific virtual network. Ingress PE nodes in the network (i.e., nodes responsible for service access) select BGP-intent routes to Egress PEs that can meet service demands based on the service level agreement (SLA). In other words, intent-template information at Ingress PE nodes generally matches the service SLA, but this does not mean that intent-template information at intermediate nodes also matches the service SLA. For example, when observing the forwarding of BGP routes across multiple domains, the service's SLA must satisfy the condition that "provide one route with a maximum latency of 100ms from Ingress PE to Egress PE." Clearly, the 100ms latency refers to the end-to-end cumulative latency limit, not the cumulative latency of a route in an intermediate segment during BGP route forwarding. This means that each BGP speaker in the middle of the route cannot use the 100ms latency as an indicator to establish a transmission route to the next BGP speaker or select an existing transmission route to the next BGP speaker. One way to solve this problem is to include different latency indicators (or called latency credits) in intent-templates configured on different BGP speakers within the route. However, this static configuration method has an obvious flaw, as an intent-template may not necessarily be bound to a specific end-to-end route and may serve multiple routes.

[0005] Regarding the problem of low efficiency in establishing BGP-intent route transmission paths due to the content included in BGP-intent routes in related technologies, no effective solution has yet been proposed.

[0006] Therefore, it is necessary to improve the related technologies in order to overcome their shortcomings. [Overview of the project] [Problems that the invention aims to solve]

[0007] The embodiments of this disclosure provide a method for receiving BGP-intent routes and a method for advertising BGP-intent routes that at least solve the problem in related technologies of low efficiency in establishing transmission paths for BGP-intent routes due to the content contained in the BGP-intent routes. [Means for solving the problem]

[0008] According to one embodiment of the present disclosure, a method for receiving a BGP-intent route is provided, which includes the step of receiving a BGP-intent route advertised by a BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0009] According to another embodiment of the present disclosure, a method for advertising a BGP-intent route is provided, comprising the step of advertising the BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0010] According to another embodiment of the present disclosure, a BGP-intent route receiving device is provided, which includes a receiving module configured to receive BGP-intent routes advertised by a BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0011] According to another embodiment of the present disclosure, a BGP-intent route advertising device is provided, which includes an advertising module configured to advertise a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route includes an advertising module that includes at least one of a metric type, a metric, and metric credit information.

[0012] According to another embodiment of the present disclosure, a computer-readable storage medium is provided in which a computer program is stored, the computer program is configured to perform any of the above methods when executed.

[0013] According to another embodiment of the present disclosure, an electronic device is provided which further includes memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor performs any of the above methods by means of the computer program. [Effects of the Invention]

[0014] According to this disclosure, a BGP-intent route advertised by a BGP speaker is received, and the BGP-intent route includes at least one of the metric type, metric, and metric credit information, thereby solving the problem of low efficiency in establishing route transmission paths in related technologies and improving the efficiency of establishing transmission paths.

[0015] (Brief explanation of the drawing) The drawings described herein are for further understanding of the Disclosure and constitute part of the Disclosure. The exemplary embodiments and descriptions thereof are to be used in interpreting the Disclosure and do not unduly limit the Disclosure. [Brief explanation of the drawing]

[0016] [Figure 1] This is a block diagram showing the hardware configuration of a computer terminal for a BGP-intent route receiving method according to an embodiment of the present disclosure. [Figure 2] This is a flowchart of the method for receiving BGP-intent routes according to an embodiment of the present disclosure. [Figure 3] This is a flowchart of the BGP-intent route advertisement method according to the embodiment of this disclosure. [Figure 4] This is a schematic diagram of the metric-credit attribute format according to an embodiment of the present disclosure. [Figure 5] This is a schematic diagram of different intent transmission paths between the same source and sink according to embodiments of the present disclosure. [Figure 6] This is a schematic diagram of the same-intended transmission path between a multipair source and a sink according to an embodiment of the present disclosure. [Figure 7] This is a block diagram of a BGP-intent route receiving device according to an embodiment of the present disclosure. [Figure 8] This is a block diagram of a BGP-intent route advertisement device according to an embodiment of the present disclosure. [Modes for carrying out the invention]

[0017] Hereinafter, the technical solutions in the embodiments of this disclosure will be clearly and completely described with reference to the drawings in the embodiments of this disclosure, so that those skilled in the art may better understand the solutions of this disclosure. Clearly, the embodiments described are only a part of, and not all, of, the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure, without any creative work on their part, should all fall within the scope of this disclosure.

[0018] Furthermore, terms such as “First,” “Second,” etc., in the specification, claims, and drawings of this disclosure are not used to describe a specific order or sequence, but rather to distinguish similar subjects. It should be understood that data used in this manner are appropriately interchangeable so that the embodiments of this disclosure described herein may be carried out in an order other than those illustrated or described herein. Also, the terms “includes” and “has” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units may include other steps or units that are not explicitly shown or are specific to those processes, methods, products, or apparatus, and are not limited to the steps or units explicitly shown.

[0019] Examples of the method according to embodiments of the present disclosure can be executed on a computer terminal or a similar computing device. Taking operation on a computer terminal as an example, FIG. 1 is a block diagram showing the hardware configuration of a computer terminal for a method of receiving a BGP-intent route according to embodiments of the present disclosure. As shown in FIG. 1, the computer terminal may include one or more (only one is shown in FIG. 1) processors 102 (the processor 102 includes, but is not limited to, a microprocessor (abbreviated as Microprocessor Unit, MPU) or a programmable logic device (abbreviated as Programmable logic device, PLD)), and a memory 104 configured to store data. In an exemplary embodiment, the computer terminal may further include a transmission device 106 and an input / output device 108 for communication functions. As can be understood by those skilled in the art, the structure shown in FIG. 1 is merely schematic and does not limit the structure of the computer terminal. For example, the computer terminal may include more or fewer components than those shown in FIG. 1, or may have a different configuration with functions equivalent to those shown in FIG. 1 or more functions than those shown in FIG. 1.

[0020] Memory 104 may be configured to store software programs and modules of application software, for example, a computer program corresponding to the method for receiving BGP-intent routes in an embodiment of the present disclosure. The processor 102 may execute the computer program stored in the memory 104 to perform various functional applications and data processing, that is, to implement the above method. Memory 104 may include high-speed random access memory, and may further include non-volatile memory such as, for example, one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some embodiments, memory 104 may further include a memory that is remotely installed with respect to processor 102, and these remote memories may be connected to the computer terminal via a network. Examples of the above network include, but are not limited to, the Internet, enterprise intranet, local area network, mobile communication network, and combinations thereof.

[0021] The transmission device 106 is configured to transmit and receive data via one network. Specific examples of the above network may include a wireless network provided by a communication carrier of the computer terminal. In one embodiment, the transmission device 106 includes a network adapter (abbreviated as NIC) that is connected to other network devices by a base station and can communicate with the Internet. In one embodiment, the transmission device 106 may be a radio frequency (RF) module configured to communicate with the Internet in a wireless manner.

[0022] FIG. 2 is a flowchart of a method for receiving BGP-intent routes according to an embodiment of the present disclosure. As shown in FIG. 2, the method includes the following step S202.

[0023] In step S202, a BGP-intent route advertised by a BGP speaker is received, and the BGP-intent route includes at least one of the following: metric type, metric, and metric credit information.

[0024] The above steps allow the system to receive BGP-intent routes advertised by a BGP speaker, and the BGP-intent route includes at least one of the following: metric type, metric, and metric credit information. This solves the problem in related technologies where the content included in BGP-intent routes results in low efficiency in establishing transmission paths for BGP-intent routes, and further improves the efficiency of establishing transmission paths by including metric type, metric, and metric credit information in BGP-intent routes.

[0025] Furthermore, in one embodiment, the metric type includes IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics, the metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces, and the metric credit information includes only one piece of information regardless of the specific source, or includes multiple pieces of information corresponding one-to-one to multiple specific sources.

[0026] The above link delay metric may, but is not limited to, include link delay.

[0027] The above link-node delay metric may, but is not limited to, include both link delay and node delay simultaneously.

[0028] Furthermore, in one embodiment, a technical means is provided that, specifically after receiving a BGP-intent route advertised by a BGP speaker, includes the steps of obtaining an intent identifier from the BGP-intent route, locally searching for an intent template based on the intent identifier to obtain intent information, and establishing a transmission path to the BGP-intent route or selecting an existing transmission path based on the intent information.

[0029] Furthermore, in one embodiment, a technical means is provided for establishing a transmission route to the BGP-intent route or selecting an existing transmission route based on the intent information, the technical means including the steps of: determining a metric credit piece threshold for a transmission route between a current BGP speaker and a neighbor BGP speaker downstream of the current BGP speaker, based on the metrics, total metric credits, estimated BGP hop count, and metric credit pieces included in the BGP-intent route; and establishing a transmission route or selecting an existing transmission route by limiting the total metric of the metric types of the established transmission route or selected existing transmission route to less than or equal to the metric credit piece threshold.

[0030] Furthermore, in one embodiment, if the metric credit information included in the BGP-intent route includes only the total metric credit associated with the source and does not include any explicit metric credit pieces, the total metric credit for each source's corresponding metric credit attribute is divided by the estimated number of BGP hops to obtain the average metric credit between two adjacent BGP Speakers in the end-to-end route, and the metrics included in the BGP-intent route are subtracted from the total metric credit to obtain the remaining metrics.

[0031] Furthermore, in one embodiment, the process includes a step of calculating the average metric credit and the remaining metric for all sources, and the metric credit piece reference value for the transmission path from this BGP speaker to downstream neighbor BGP speakers includes the smallest positive value among the average metric credit and the remaining metric calculated for all sources.

[0032] Furthermore, in one embodiment, specifically, if the BGP-intent route further includes explicit metric credit pieces, a technical means is provided that includes the steps of: obtaining the metric credit piece corresponding to the BGP Speaker from the BGP-intent route based on the BGP Speaker's end-to-end route location number for the metric credit information corresponding to each Source; and subtracting the metrics included in the BGP-intent route from the total metric credits to obtain the remaining metrics.

[0033] Furthermore, in one embodiment, the process includes a step of calculating metric credit pieces and remaining metrics for all sources, wherein the metric credit piece baseline value for the transmission path from this BGP speaker to downstream neighbor BGP speakers includes the smallest positive value among the metric credit pieces and remaining metrics calculated for all sources.

[0034] Furthermore, in one embodiment, if the BGP Speaker discovers that no transmission path to a downstream BGP Speaker satisfies the metric credit piece threshold, it selects from all candidate transmission paths the path whose total metric type is closest to the metric credit piece threshold. In embodiments of the present disclosure, if no transmission path satisfies the condition in the BGP Speaker, it can relax the condition and increase the margin to select from all candidate transmission paths the path whose total metric type is closest to the metric credit piece threshold.

[0035] Furthermore, the transmission path from the BGP Speaker to the downstream BGP Speaker includes at least one of the shortest forwarding path and the traffic engineering path, and the transmission path includes a plurality of subpaths, which distribute the load, form fast rerouting (FRR) protection, or form a path for multistream copying and deletion, and if the plurality of subpaths form a path for multistream copying and deletion, the metric differences between the plurality of subpaths should satisfy a configured limit.

[0036] Figure 3 is a flowchart of a method for advertising BGP-intent routes according to an embodiment of the present disclosure. As shown in Figure 3, the method includes the following step S302.

[0037] In step S302, a BGP-intent route is advertised to the neighbor BGP Speaker, and the BGP-intent route includes at least one of the following: metric type, metric, and metric credit information.

[0038] The above steps advertise a BGP-intent route to a neighbor BGP speaker, and the BGP-intent route includes at least one of the metric type, metric, and metric credit information. This solves the problem in related technologies where the content included in the BGP-intent route results in low efficiency in establishing transmission paths, and by including the metric type, metric, and metric credit information in the BGP-intent route, the efficiency of establishing transmission paths is further improved.

[0039] Furthermore, in one embodiment, the metric type includes IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics, the metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces, and the metric credit information includes only one piece of information regardless of the specific source, or includes multiple pieces of information corresponding one-to-one to multiple specific sources.

[0040] Furthermore, in one embodiment, the metric corresponding to the metric type is the sum of the metric included in the BGP-intent route advertisement received from the downstream neighbor BGP speaker and the total metric corresponding to the metric type for the transmission path from this BGP speaker to the downstream neighbor BGP speaker, or, if this BGP speaker is the original advertising node, the metric corresponding to the metric type is a configured initial value.

[0041] Note that the above initial value may be 0, but is not limited to this. Next, we will consider a more general method, with reference to the following examples, that allows a BGP speaker that receives a BGP-intent route to establish a transmission path to the next BGP speaker with greater flexibility and precise intent, or to select an existing transmission path to the next BGP speaker.

[0042] In one embodiment, a technical means comprising the following steps 1 to 2 is provided. Step 1 extends BGP so that when a BGP speaker advertises a BGP-intent route to its upstream neighbors, it includes selective metric-type, metric, and metric-credit information. The metric-credit information consists of total-metric-credit, estimated BGP hop count, and metric-credit-piece. The metric-credit information may include only one piece of information regardless of a particular source (i.e., a particular Ingress PE), or it may include multiple pieces of information corresponding one-to-one to each particular source.

[0043] In Step 2, a BGP speaker that receives a BGP-intent route advertisement retrieves the intent identifier from the route advertisement, performs a local lookup of the intent template to obtain intent information, and then establishes a transmission route or selects an existing transmission route based on the intent information. In particular, when establishing a transmission route or selecting an existing transmission route, the BGP speaker must obtain the "metric credit piece threshold" for the transmission route from this BGP speaker to downstream neighbor BGP speakers based on the metric, total metric credit, estimated number of BGP hops, and explicit metric credit piece information included in the route advertisement, and then establish a transmission route or select an existing transmission route, limiting it so that the total metric of the corresponding metric type of the transmission route used does not exceed the "metric credit piece threshold".

[0044] To better understand Step 1 above, please refer to the following recommended specific protocol extensions for BGP.

[0045] RFC4271 defines BGP Path Attributes, which are included with BGP route advertisements and indicate various attributes of a route. This disclosure adds, but is not limited to, the following Attribute Type Codes and their attribute values ​​to indicate attributes such as metric-type and metric-credit. Note: The metric attribute is an AIGP Attribute as defined in RFC7311.

[0046] In one embodiment, the metric-type attribute and the metric-credit attribute will be explained, specifically as follows.

[0047] a) The metric-type attribute indicates that, in the case of Path Attribute Type Code=TBD1 (awaiting allocation from IANA (Internet Assigned Numbers Authority)), the attribute value contains the metric-type attribute, which is 1 byte in length. The metric-type attribute is a selectable, non-transferable attribute that indicates the type of metric contained in the AIGP Attribute, and its current value is as follows:

[0048] 0: IGP Metric (as defined in RFC5305, RFC2328, and RFC5340), 1: Unidirectional Link Delay (as defined in RFC7810), 2: TE default metric (defined in RFC5305), 3: Bandwidth Metric (defined in draft-ietf-lsr-flex-algo-bw-con-01), 4: Deterministic Delay Metric (As discussed in other documents, while the above Unidirectional Link Delay only considers link delay, Deterministic Delay includes not only link delay but also delay within the node), 5-255: To be defined in the future.

[0049] b) The metric-credit attribute indicates that, when the Path Attribute's Type Code is TBD2 (awaiting allocation at IANA), the attribute value contains the metric-credit attribute in the following format: The metric-credit attribute is a selectable, non-transferable attribute that displays information such as the total end-to-end metric credit, estimated BGP hop count, and metric credit pieces.

[0050] In one embodiment, the metric-credit attribute can be explained with reference to Figure 4. Figure 4 is a schematic diagram of the metric-credit attribute format according to an embodiment of this disclosure. The fields in Figure 4 are described below.

[0051] Count of Sources occupies 1 byte, its value is at least 1, and indicates the Source count result, i.e., how many Sources (i.e., Ingress PEs) are associated with metric credit information. The metric credit information for each Source consists of "Flags", "Network Address of Source", "Total Metric Credit for Source", "Estimated BGP Hops Count for Source", "Current Hop Number", and "Metric Credit Piece[]".

[0052] Flags occupy one byte and are flag bits. Currently, three flags are defined, as follows:

[0053] The S-Flag is the Source Address Flag, which indicates whether or not the Network Address of Source field is included. 0 indicates it is not included, and 1 indicates it is included.

[0054] F-Flag stands for Family Flag and indicates the address cluster of the Network Address of Source. If S-Flag is 1, the length of the Network Address of Source is determined based on F-Flag, where 0 indicates a 4-byte IPv4 address and 1 indicates a 16-byte IPv6 address.

[0055] P-Flag is a Piece Flag that indicates whether or not it contains specific metric credit piece information (consisting of "Current Hop Number" and "Metric Credit Piece[]"), with 0 indicating it is not included and 1 indicating it is included.

[0056] The Network Address of Source is a variable-length field that indicates the IP address of the Source. If the S-Flag is 0, this field is absent; if the S-Flag is 1 and the F-Flag is 0, this field is a 4-byte IPv4 address; and if the S-Flag is 1 and the F-Flag is 1, this field is a 16-byte IPv6 address. The absence of the Network Address of Source indicates that the metric credit information is independent of a specific Source. This generally occurs in coarse-grained scenarios where you want to control the establishment of transmission routes based on metric credits. For example, within a single AS, if an Egress PE advertises BGP-intent routes to multiple Ingress PEs within the same AS, it will include only a single, unified metric credit information, regardless of the Source.

[0057] Total Metric Credit for Source occupies 4 bytes and represents the total metric credits from a specific Source (or any Source, or if no Network Address of Source exists) to the Egress PE.

[0058] The Estimated BGP Hops Count for Source occupies one byte and indicates the estimated number of BGP hops from a specific Source (or any Source, or if no Network Address of Source exists) to an Egress PE. It calculates only for BGP Speakers that need to modify their BGP Next-hop to themselves when receiving a BGP-intent route advertisement. For example, in an advertised route SABCD consisting of five BGP Speakers, if S is the Ingress PE, D is the Egress PE, and A / B / C are three intermediate BGP Speaker nodes, and each of them modifies their BGP Next-hop to itself when receiving a BGP-intent route advertisement, the estimated BGP hop count in this case is 4, meaning the entire advertised route consists of 4 segments.

[0059] The Current Hop Number occupies one byte and indicates the current subscript of the Metric Credit Piece[] array. Note that the "Current Hop Number" and "Metric Credit Piece[]" fields do not exist when the P-Flag is 0. In a BGP-intent route advertisement message sent by an Egress PE to its adjacent upstream BGP Speaker neighbor, the initial value of the Current Hop Number is 0. Each time the BGP-intent route advertisement message passes through a BGP Speaker, and the BGP Speaker modifies the route's BGP Next-hop to itself (the BGP Speaker), it reads an element from the Metric Credit Piece[] array according to the subscript Current Hop Number to obtain the metric credit piece for the transmission path from this BGP Speaker to the downstream BGP Speaker neighbor, and then continues to advertise the route to the upstream BGP Speaker neighbor by incrementing the Current Hop Number in the message. Note that when reading elements from the Metric Credit Piece[] array using the subscript Current Hop Number, it is necessary to avoid crossing array boundaries.

[0060] A Metric Credit Piece[] is an array whose number of elements is specified by the Estimated BGP Hops Count for Source, with each element occupying 2 bytes. In the process of advertising a BGP-intent route, each BGP Speaker along the way, when modifying the BGP Next-hop of the route to its own, accesses this array with the Current Hop Number as a subscript to obtain explicit Metric Credit Piece information. The use of Metric Credit Pieces is subject to very strict limitations: BGP-intent routes must be advertised hop by hop to a specific Source in strict accordance with the advertised route desired by the Egress PE. In the event of an anomaly, if a BGP Speaker discovers that the Current Hop Number value in the received BGP-intent route advertisement message is already greater than or equal to the Estimated BGP Hops Count for Source value, it must stop searching for a transmission route based on Metric Credit Piece information.

[0061] To better understand Step 2 described above, Step 2 can be explained by combining the following examples. (Example 1) In this embodiment, if the metric credit attribute information included in the BGP-intent route advertisement message contains only the total metric credits related to the Source and does not contain explicit metric credit piece information, the following operations can be performed on the metric credit information corresponding to each Source.

[0062] Operation 1: Set the variable total_metric_credit_value to the value of Total Metric Credit for Source, Operation 2: Set the variable bgp_hops_count to the value of Estimated BGP Hops Count for Source, Operation 3: Set the variable metric_value to the value of the metric included in the AIGP Attribute of the received BGP-intent route. Operation 4: Set the variable metric_residual_value to the remaining metric, where metric_residual_value = total_metric_credit_value - metric_value.

[0063] Furthermore, if metric credit information exists for multiple sources, a large metric_value may accumulate when BGP-intent routes are advertised. Therefore, the metric_residual_value for one source is negative, while the metric_residual_value for other sources is positive.

[0064] Operation 5: Set the variable average_metric_credit_value to the average metric credit between each neighboring BGP Speaker in an end-to-end route, where average_metric_credit_value = total_metric_credit_value / bgp_hops_count. Additionally, the following operations can be performed on metric credit information corresponding to all sources.

[0065] Operation 6: Set the variable min_metric_residual_value to the smallest positive value among the metric_residual_values ​​corresponding to all Sources. Operation 7: Set the variable min_average_metric_credit_value to the minimum value among the average_metric_credit_values ​​corresponding to all Sources. In this embodiment, the "metric credit piece reference value" for the transmission path from one BGP speaker to a downstream neighbor BGP speaker is the smallest of min_metric_residual_value and min_average_metric_credit_value. (Example 2) In this embodiment, if the BGP-intent route advertisement message also includes explicit metric credit piece information, the following operations can be performed on the metric credit information corresponding to each source.

[0066] Operation 8: Set the variable total_metric_credit_value to the value of Total Metric Credit for Source, Action 9: Set the variable bgp_hops_count to the value of Estimated BGP Hops Count for Source, Operation 10: Set the variable metric_value to the value of the metric included in the AIGP Attribute of the received BGP-intent route. Operation 11: Set the variable metric_residual_value to the remaining metric, where metric_residual_value = total_metric_credit_value - metric_value.

[0067] Furthermore, if metric credit information exists for multiple sources, a large metric_value may accumulate when BGP-intent routes are advertised. Therefore, the metric_residual_value for one source is negative, while the metric_residual_value for other sources is positive.

[0068] Operation 12: Set the variable explicit_metric_credit_piece_value to the value of the element to be read from the array Metric Credit Piece[] using the subscript Current Hop Number. However, if the read exceeds a boundary, explicit_metric_credit_piece_value is considered to be 0.

[0069] Additionally, the following operations can be performed on metric credit information corresponding to all sources.

[0070] Operation 13: Set the variable min_metric_residual_value to the smallest positive value among the metric_residual_values ​​corresponding to all Sources. Operation 14: Set the variable min_explicit_metric_credit_piece_value to the smallest positive value among the explicit_metric_credit_piece_values ​​corresponding to all Sources.

[0071] In this embodiment, the "metric credit piece reference value" for the transmission path from one BGP speaker to a downstream neighbor BGP speaker is the smallest of min_metric_residual_value and min_explicit_metric_credit_piece_value.

[0072] From the above embodiment, it can be determined that the purpose of the "metric credit piece threshold" calculated in the above embodiment is to restrict the total metric of the transmission path used so as not to exceed the "metric credit piece threshold." However, in some cases, the BGP Speaker may appropriately relax such a restriction if it finds that there is no transmission path that can satisfy the above requirement, but the transmission path that the BGP Speaker ultimately uses will have a total metric of its corresponding metric type that is closest to the "metric credit piece threshold" compared to other candidate transmission paths.

[0073] In BGP-intent routes generated by this BGP Speaker, the included metric type is copied from the received route advertisement, the included metric attribute value is updated to the sum of the metric included in the received route advertisement plus the corresponding metric type of the transmission path used, and the included metric credit attribute is copied from the received route advertisement (the Current Hop Number is incremented).

[0074] Furthermore, this BGP Speaker can continue to advertise the generated BGP-intent route to its upstream BGP Speaker neighbors, thereby correcting the BGP Next-hop to itself. In this case, the route advertisement will include the updated metric and metric-credit attributes.

[0075] Next, the method for receiving BGP-intent routes according to the embodiment of this disclosure will be described with reference to the following example. (Example 3) This embodiment will be described with reference to Figure 5. Figure 5 is a schematic diagram of transmission paths of different intentions for the same source and sink according to an embodiment of the present disclosure. The network shown in Figure 5 includes two IGP domains, establishes BGP neighbors between PE1 and ABR, and between ABR and PE2, and advertises BGP-intent routes. For example, according to the method described in draft-zhou-idr-inter-domain-lcu-02, Egress PE2 advertises its loopback route (denoted as loopback-PE2) to ABR via BGP, and the route advertisement includes a color-extended community so as to include intent information. After receiving the route advertisement, ABR continues to advertise it to PE1 via BGP, i.e., Ingress PE1, ABR, and Egress PE2 are BGP Speakers in the aforementioned technical means.

[0076] In this example, assuming that two types of services need to communicate between Ingress PE1 and Egress PE2, the intent of one type of service is that the end-to-end total latency of the transmission path used does not exceed 10ms, and the intent of the other type of service is that the end-to-end total latency of the transmission path used does not exceed 100ms. Since we need to represent paths related to both intents between the same source / destination, in this example, we need to set two Colors on Egress PE2, denoted as Color-1000 and Color-2000.

[0077] The intent settings corresponding to Color-1000 are metric-type: Unidirectional Link Delay (unit: ms), total-metric: 10, and metric-credit enabled.

[0078] The intent settings corresponding to Color-2000 are metric-type: Unidirectional Link Delay (unit: ms), total-metric: 100, and metric-credit enabled.

[0079] The intent configuration information corresponding to the two colors mentioned above is also configured uniformly on the other BGP Speaker nodes (ABR, Ingress PE1). Since the intent configuration information includes the metric-credit enabled command, these other BGP Speakers, after receiving a BGP-intent route advertisement from a downstream BGP Speaker neighbor, do not calculate the transmission route to the downstream BGP Speaker neighbor based solely on the total-metric included in the intent configuration information. Instead, they obtain metric credit information from the received BGP-intent route advertisement and, based on this, establish a transmission route that satisfies the intent, or use an existing transmission route that satisfies the intent. Alternatively, the intent configuration set on these other BGP Speaker nodes does not necessarily have to include total-metric information.

[0080] In this embodiment, a technical means is provided that includes the following steps 1) to 3). In step 1), Egress PE2 generates BGP-intent routes and advertises them to the ABR, that is, Egress PE2 handles each corresponding<prefix=loopback-PE2、color=1000> and<prefix=loopback-PE2、color=2000> Two BGP-intent routes are generated and advertised to the ABR, with the BGP Next-hop in the route advertisement being Egress PE2.

[0081] Note that BGP-intent routes<prefix=loopback-PE2、color=1000> When advertised, the information included in the route advertisement may be set based on the intent setting information corresponding to color-1000, namely, metric-type is set to Unidirectional Link Delay and initial metric is set to 0.

[0082] The metric credit information is then set as follows: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=0, Network Address of Source: loopback-PE1 (assuming an IPv4 address), Total Metric Credit for Source: 10, Estimated BGP Hops Count for Source: 2 (meaning that two BGP speakers are needed to reach Ingress PE1).

[0083] Also, BGP-intent routes<prefix=loopback-PE2、color=2000> When advertising, the information included in the route advertisement is configured based on the intent setting information corresponding to color-2000, namely, metric-type is set to Unidirectional Link Delay, and the initial metric is set to 0. The metric credit information is then configured as follows: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=0, Network Address of Source: loopback-PE1 (assuming an IPv4 address), Total Metric Credit for Source: 100, Estimated BGP Hops Count for Source: 2 (meaning that two BGP Speakers are needed to reach Ingress PE1).

[0084] In step 2), when the ABR receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., the ABR establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving this, a corresponding routing table entry is generated locally, with metric-type being Unidirectional Link Delay and BGP Next-hop being Egress PE2.

[0085] Furthermore, when the ABR learns, based on the metric credit information included in the route advertisement it receives, that the "metric credit piece threshold" from this BGP Speaker (i.e., the ABR) to the downstream BGP Speaker neighbor (i.e., Egress PE2) is 5ms (total metric credits divided by 2), the ABR node internally invokes the CSPF (Constraint Shortest Path First) calculation module to calculate an extremely low-latency route to Egress PE2 that does not exceed 5ms. Assuming this is TE path-12 in Figure 5, its latency is 4ms. Therefore, the BGP-intent routing table entry generated by the ABR is...<prefix=loopback-PE2、color=1000> This process is repeated until the lower layer transmission path of the BGP Next-hop becomes TE path-12, and the metric of the routing table entry is set to 4 accordingly. The ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with the metric-type being Unidirectional Link Delay, the metric being 4, the BGP Next-hop being modified to the ABR, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0086] Similarly, ABR is BGP-intent route<prefix=loopback-PE2、color=2000> Upon receiving the BGP-intent, the ABR may generate a corresponding routing table entry locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is Egress PE2. Based on the metric credit information contained in the received route advertisement, the ABR learns that the "metric credit piece threshold" from this BGP Speaker (i.e., the ABR) to the downstream BGP Speaker neighbor (i.e., Egress PE2) is 50ms (total metric credits divided by 2). The ABR node then internally invokes the CSPF calculation module to calculate a low-latency route to Egress PE2 that does not exceed 50ms, which, assuming it is TE path-22 in Figure 5, has a latency of 40ms. Thus, the BGP-intent routing table entry generated by the ABR is...<prefix=loopback-PE2、color=2000> This process is repeated until the lower layer transmission path of the BGP Next-hop becomes TE path-22, and the metric of the routing table entry is set to 40 accordingly. The ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with the metric-type being Unidirectional Link Delay, the metric being 40, the BGP Next-hop being modified to the ABR, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0087] In step 3), when Ingress PE1 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., Ingress PE1 establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving this, a corresponding routing table entry is generated locally, with metric-type being Unidirectional Link Delay and BGP Next-hop being ABR.

[0088] Furthermore, when Ingress PE1 learns, based on the metric credit information included in the route advertisement it receives, that the "metric credit piece threshold" from this BGP Speaker (i.e., Ingress PE1) to the downstream BGP Speaker neighbor (i.e., ABR) is 5ms (the total metric credit divided by 2 is 5, and the remaining metric credit is 6, taking the smaller value), the Ingress PE1 node internally calls the CSPF calculation module to calculate an extremely low-latency route to the ABR that does not exceed 5ms, and assuming this is TE path-11 (route-11) in Figure 5, its latency is 4ms. Therefore, the BGP-intent routing table entry generated by Ingress PE1<prefix=loopback-PE2、color=1000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-11, and accordingly sets the metric of the routing table entry to 8 (=4+4).

[0089] Similarly, Ingress PE1 is a BGP-intent route<prefix=loopback-PE2、color=2000> Upon receiving this, Ingress PE1 may generate a corresponding routing table entry locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is ABR. Based on the metric credit information contained in the received route advertisement, Ingress PE1 learns that the "metric credit piece threshold" from this BGP Speaker (i.e., Ingress PE1) to the downstream BGP Speaker neighbor (i.e., ABR) is 50ms (the total metric credit divided by 2 is 50, and the remaining metric credit is 60, taking the smaller value), so the Ingress PE1 node internally calls the CSPF calculation module to calculate a low-latency route to the ABR that does not exceed 50ms, and assuming this is TE path-21 (route-21) in Figure 5, its delay is 40ms. Therefore, the BGP-intent routing table entry generated by Ingress PE1<prefix=loopback-PE2、color=2000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-21, and accordingly sets the metric of the routing table entry to 80 (=40+40).

[0090] Thus, in this embodiment, the metric credit information included in the route advertisement allows each BGP speaker to establish a differentiated transmission path based on evidence and avoid competition for superior, ultra-low latency link resources. (Example 4) Referring to the network shown in Figure 5, where two IGP domains are managed by a single service provider, and this service provider is familiar with the network's performance metrics and the propagation path of BGP-intent route advertisements is clear, a local policy can be set on Egress PE2 to include explicit metric credit piece information in the advertised BGP-intent routes. The main steps are as follows:

[0091] In step 1), Egress PE2 generates BGP-intent routes and advertises them to the ABR, that is, Egress PE2 handles each corresponding<prefix=loopback-PE2、color=1000> and<prefix=loopback-PE2、color=2000> Two BGP-intent routes are generated and advertised to the ABR, with the BGP Next-hop in the route advertisement being Egress PE2.

[0092] Note that BGP-intent routes<prefix=loopback-PE2、color=1000> When advertised, the information included in the route advertisement may be set based on the intent setting information corresponding to color-1000, namely, metric-type is set to Unidirectional Link Delay and initial metric is set to 0.

[0093] Then, set the metric credit information as follows: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=1, Network Address of Source: loopback-PE1 (assuming it's an IPv4 address), Total Metric Credit for Source: 10, Estimated BGP Hops Count for Source: 2 (it needs to go through two BGP Speakers to reach Ingress PE1), Current Hop Number: 0, Metric Credit Piece[2]: [0]=4, [1]=6.

[0094] Note that BGP-intent routes<prefix=loopback-PE2、color=2000> When advertised, the information included in the route advertisement may be set based on the intent setting information corresponding to color-2000, namely, metric-type is set to Unidirectional Link Delay and initial metric is set to 0.

[0095] Then, set the metric credit information to: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=0, Network Address of Source: loopback-PE1 (assuming an IPv4 address), Total Metric Credit for Source: 100, Estimated BGP Hops Count for Source: 2 (two BGP speakers are needed to reach Ingress PE1), Current Hop Number: 0, Metric Credit Piece[2]: [0]=40, [1]=60.

[0096] In step 2), when the ABR receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., the ABR establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving this, a corresponding routing table entry is generated locally, with metric-type being Unidirectional Link Delay and BGP Next-hop being Egress PE2.

[0097] Furthermore, when the ABR learns, based on the metric credit information included in the route advertisement it receives, that the "metric credit piece threshold" from this BGP Speaker (i.e., the ABR) to the downstream BGP Speaker neighbor (i.e., Egress PE2) is 4ms (the total metric credit divided by 2 is 5, and the metric credit piece[0] element is 4, taking a small value), the ABR node internally calls the CSPF calculation module to calculate an extremely low-latency route to Egress PE2 that does not exceed 4ms, and assuming this is TE path-12 in Figure 5, its latency is 4ms. Therefore, the BGP-intent routing table entry generated by the ABR<prefix=loopback-PE2、color=1000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-12, and accordingly sets the metric of the routing table entry to 4. The ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with the metric-type being Unidirectional Link Delay, the metric being 4, the BGP Next-hop being modified to the ABR, and the metric credit information being that the Current Hop Number is incremented to 1.

[0098] Similarly, ABR is BGP-intent route<prefix=loopback-PE2、color=2000> Upon receiving the traffic, the ABR may generate a corresponding routing table entry locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is Egress PE2. Based on the metric credit information contained in the received route advertisement, the ABR learns that the "metric credit piece threshold" from this BGP Speaker (i.e., the ABR) to the downstream BGP Speaker neighbor (i.e., Egress PE2) is 40ms (where the total metric credit divided by 2 is 50, and the metric credit piece[0] element is 40, taking the smallest value). The ABR node then internally invokes the CSPF calculation module to calculate a low-latency route to Egress PE2 that does not exceed 40ms, and assuming this is TE path-22 in Figure 5, its delay is 40ms. Thus, the BGP-intent routing table entry generated by the ABR<prefix=loopback-PE2、color=2000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-22, and accordingly sets the metric of the routing table entry to 40. The ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with the metric-type being Unidirectional Link Delay, the metric being 40, the BGP Next-hop being modified to the ABR, and the metric credit information being that the Current Hop Number is incremented to 1.

[0099] In step 3), when Ingress PE1 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., Ingress PE1 establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving this, a corresponding routing table entry is generated locally, with metric-type being Unidirectional Link Delay and BGP Next-hop being ABR.

[0100] Furthermore, when Ingress PE1 learns, based on the metric credit information contained in the route advertisement it receives, that the "metric credit piece threshold" from this BGP Speaker (i.e., Ingress PE1) to the downstream BGP Speaker neighbor (i.e., ABR) is 5ms (the total metric credit divided by 2 is 5, the remaining metric credit is 6, and the metric credit piece[1] element is 6, taking the smallest value), the Ingress PE1 node internally calls the CSPF calculation module to calculate an extremely low-latency route to the ABR that does not exceed 5ms, and assuming this is TE path-11 in Figure 5, its latency is 4ms. Therefore, the BGP-intent routing table entry generated by Ingress PE1<prefix=loopback-PE2、color=1000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-11, and accordingly sets the metric of the routing table entry to 8 (=4+4).

[0101] Similarly, Ingress PE1 is a BGP-intent route<prefix=loopback-PE2、color=2000> Upon receiving the metric-type, Ingress PE1 may generate a corresponding routing table entry locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is ABR. Based on the metric credit information contained in the received route advertisement, Ingress PE1 knows that the "metric credit piece threshold" from this BGP Speaker (i.e., Ingress PE1) to the downstream BGP Speaker neighbor (i.e., ABR) is 50ms (the total metric credit divided by 2 is 50, the remaining metric credit is 60, and the metric credit piece[1] element is 60, taking the smallest value), so the Ingress PE1 node internally invokes the CSPF calculation module to calculate a low-latency route to the ABR that does not exceed 50ms, and assuming this is TE path-21 in Figure 5, the delay is 40ms. Thus, the BGP-intent routing table entry generated by Ingress PE1<prefix=loopback-PE2、color=2000> This iterates until the lower layer transmission path of the BGP Next-hop becomes TE path-21, and accordingly sets the metric of the routing table entry to 80 (=40+40). (Example 5) The technical means in this embodiment will be described with reference to Figure 6. Figure 6 is a schematic diagram of the same intent transmission path between multiple pairs of sources and sinks according to an embodiment of the present disclosure. The network shown in Figure 6 includes three ASs (Autonomous Systems) and establishes BGP neighbors between PE1 and ASBR1, between ASBR1 and ASBR2, between ASBR1 and ASBR3, between ASBR2 and PE2, and between ASBR3 and PE3, and advertises BGP-intent routes. For example, according to the method described in draft-zhou-idr-inter-domain-lcu-02, Egress PE2 advertises its loopback route (denoted as loopback-PE2) to ASBR2 via BGP, and Egress PE3 advertises its loopback route (denoted as loopback-PE3) to ASBR3 via BGP, and the route advertisement includes a color extended community so that intent information is included. After receiving the route advertisement, ASBR2 / ASBR3 continue to advertise to ASBR1 via BGP, and after receiving the route advertisement, ASBR1 continues to advertise to Ingress PE1 via BGP. In other words, Ingress PE1, ASBR1, ASBR2, ASBR3, Egress PE2, and Egress PE3 are BGP Speakers in the aforementioned technical configuration.

[0102] In this example, we assume that the same type of service needs to communicate between Ingress PE1 and Egress PE2, and between Ingress PE1 and Egress PE3, and that the intent of this type of service is a specific value related to the total end-to-end latency and distance of the transmission path used.

[0103] Assuming that Egress PE2 is set to the corresponding color-1000, the corresponding intent settings would be metric-type: Unidirectional Link Delay (in ms), total-metric: 200 (considering the short actual distance), and metric-credit enabled.

[0104] Assuming that Egress PE3 is set to the corresponding color-1000, the corresponding intent settings would be: metric-type: Unidirectional Link Delay (unit is ms), total-metric: 300 (considering the long actual distance), and metric-credit enabled.

[0105] The intent setting information corresponding to the above color is also configured uniformly across other BGP Speaker nodes (ASBR1, ASBR2, ASBR3, Ingress PE1), and does not necessarily need to include total-metric information.

[0106] The specific process is the same as in the previously described examples, and only the important points will be explained here.

[0107] In step 1), Egress PE2 generates and advertises BGP-intent routes to ASBR2, that is, Egress PE2 generates the corresponding BGP-intent routes.<prefix=loopback-PE2、color=1000> The following information is generated and advertised to ASBR2: BGP Next-hop is set to loopback-PE2, metric-type is set to Unidirectional Link Delay, and initial metric is set to 0.

[0108] Then, set the metric credit information to: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=0, Network Address of Source: loopback-PE1 (assuming it's an IPv4 address), Total Metric Credit for Source: 200, Estimated BGP Hops Count for Source: 3 (it needs to go through 3 BGP Speakers to reach Ingress PE1).

[0109] In step 2), Egress PE3 generates BGP-intent routes and advertises them to ASBR3, that is, Egress PE3 generates the corresponding BGP-intent routes.<prefix=loopback-PE3、color=1000> The following information is generated and advertised to ASBR3: the BGP Next-hop is set to loopback-PE3, the metric-type is set to Unidirectional Link Delay, and the initial metric is set to 0.

[0110] Then, set the metric credit information to: Count of Sources: 1, Flags: S-Flag=1, F-Flag=0, P-Flag=0, Network Address of Source: loopback-PE1 (assuming it's an IPv4 address), Total Metric Credit for Source: 300, Estimated BGP Hops Count for Source: 3 (3 BGP Speakers are needed to reach Ingress PE1).

[0111] In step 3), when ASBR2 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., ASBR2 establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving the message, a corresponding routing table entry is generated locally, with the main attributes including a metric-type of Unidirectional Link Delay, a BGP Next-hop of loopback-PE2 (repeated until the transmission path of PE2 becomes TE path-13, depending on the metric credit piece threshold of 66), a metric of 60 (accumulating 60ms of cumulative delay on TE path-13), and metric-credit information remaining unchanged from the information in the received route advertisement.

[0112] Furthermore, ASBR2 continues to advertise the BGP-intent route to ASBR1, with the metric-type being Unidirectional Link Delay, the metric being 60, the BGP Next-hop being modified to ASBR2, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0113] In step 4), when ASBR3 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., ASBR3 establishes a BGP-intent route<prefix=loopback-PE3、color=1000> Upon receiving this, a corresponding routing table entry is generated locally, with the main attributes including a metric-type of Unidirectional Link Delay, a BGP Next-hop of loopback-PE3 (repeating until the transmission path of PE2 becomes TE path-23, depending on the metric credit piece threshold of 100), a metric of 100 (accumulating 100ms of cumulative delay on TE path-23), and the metric-credit information remaining unchanged from the information in the received route advertisement.

[0114] Furthermore, ASBR3 continues to advertise the BGP-intent route to ASBR1, with the metric-type being Unidirectional Link Delay, the metric being 100, the BGP Next-hop being modified to ASBR3, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0115] In step 5), when ASBR1 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., ASBR1 establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving the request, a corresponding routing table entry is generated locally, with the main attributes including a metric-type of Unidirectional Link Delay, a BGP Next-hop of ASBR2 (repeated until the transmission path of ASBR2 becomes TE path-12, according to the metric credit piece threshold of 66), a metric of 70 (accumulating 10ms of cumulative delay for TE path-12), and metric-credit information remaining unchanged from the information in the received route advertisement.

[0116] Furthermore, ASBR1 continues to advertise the BGP-intent route to Ingress PE1, with the metric-type being Unidirectional Link Delay, the metric being 70, the BGP Next-hop being modified to ASBR1, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0117] Similarly, ASBR1 is BGP-intent route<prefix=loopback-PE3、color=1000> Upon receiving this, a corresponding routing table entry may be generated locally, the main attributes of which include a metric-type of Unidirectional Link Delay, a BGP Next-hop of ASBR3 (repeated until the transmission path of ASBR3 becomes TE path-22, depending on the metric credit piece threshold of 100), a metric of 110 (accumulated with the cumulative delay of 10ms on TE path-22), and the metric-credit information remaining unchanged from the information in the received route advertisement.

[0118] Furthermore, ASBR1 continues to advertise the BGP-intent route to Ingress PE1, with the metric-type being Unidirectional Link Delay, the metric being 110, the BGP Next-hop being modified to ASBR1, and the metric credit information remaining unchanged from the metric credit information in the previously received route advertisement.

[0119] In step 6), when Ingress PE1 receives a BGP-intent route, it establishes a lower-layer transmission path that satisfies the intent to the BGP Next-hop, i.e., Ingress PE1 establishes a BGP-intent route<prefix=loopback-PE2、color=1000> Upon receiving, a corresponding routing table entry is generated locally, with the main attributes including a metric-type of Unidirectional Link Delay, a BGP Next-hop of ASBR1 (repeating until the transmission path of ASBR2 becomes TE path-11, depending on the metric credit piece threshold of 66), a metric of 130 (accumulating 60ms of cumulative delay on TE path-11), and the metric-credit information remaining unchanged from the information in the received route advertisement.

[0120] Similarly, Ingress PE1 is a BGP-intent route<prefix=loopback-PE3、color=1000> Upon receiving this, a corresponding routing table entry may be generated locally, the main attributes of which include a metric-type of Unidirectional Link Delay, a BGP Next-hop of ASBR1 (repeated until the transmission path of ASBR1 becomes TE path-21, depending on the metric credit piece threshold of 100), a metric of 210 (accumulating 100ms of cumulative delay on TE path-22), and the metric-credit information remaining unchanged from the information in the received route advertisement.

[0121] By using the technical means described in the above embodiment, it is possible to justify the establishment of transmission paths for intentional routes, provide differentiated transmission resources, and avoid competition among all services for superior resources.

[0122] Furthermore, the technical means described in the above embodiment can be applied to IPRAN / SPN and metropolitan area networks / backbones, but are not limited thereto.

[0123] Figure 7 is a block diagram of a BGP-intent route receiving device according to an embodiment of the present disclosure. As shown in Figure 7, the BGP-intent route receiving device is A receiving module configured to receive BGP-intent routes advertised by a BGP speaker, the receiving module 702 includes at least one of the following in the BGP-intent route: metric type, metric, and metric credit information.

[0124] According to the above solution, a BGP-intent route advertised by a BGP speaker is received, and the BGP-intent route includes at least one of the metric type, metric, and metric credit information. This solves the problem in related technologies where the efficiency of establishing transmission paths for BGP-intent routes is low depending on the content included in the BGP-intent route, and by including the metric type, metric, and metric credit information in the BGP-intent route, the efficiency of establishing transmission paths is further improved.

[0125] Furthermore, the metric types include IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics; the metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces; and the metric credit information may include only one piece of information regardless of the specific source, or may include multiple pieces of information corresponding one-to-one to multiple specific sources.

[0126] The above link delay metric may, but is not limited to, include link delay.

[0127] The above link-node delay metric may, but is not limited to, include both link delay and node delay simultaneously.

[0128] Furthermore, the BGP-intent route receiving device further includes an acquisition module configured to obtain an intent identifier from the BGP-intent route, obtain intent information by locally searching for an intent template based on the intent identifier, and establish a transmission route to the BGP-intent route or select an existing transmission route based on the intent information.

[0129] Furthermore, the acquisition module is configured to determine a metric credit piece threshold for a transmission path between the current BGP speaker and a downstream neighbor BGP speaker, based on the metrics included in the BGP-intent route, total metric credits, estimated BGP hop count, and metric credit pieces, and to establish a transmission path or select an existing transmission path by limiting the total metric of the metric type of the established transmission path or selected existing transmission path to less than or equal to the metric credit piece threshold.

[0130] Furthermore, the BGP-intent route receiver further includes a first metric acquisition module configured to, if the metric credit information included in the BGP-intent route includes only the total metric credit associated with the source and does not include any explicit metric credit pieces, to obtain the average metric credit between two adjacent BGP Speakers in the end-to-end route by dividing the total metric credit by the estimated number of BGP hops for each source's corresponding metric credit attribute, and then to subtract the metrics included in the BGP-intent route from the total metric credit to obtain the remaining metrics.

[0131] Furthermore, the first metric acquisition module is configured to calculate the average metric credit and remaining metrics for all sources, and the metric credit piece baseline value for the transmission path from this BGP speaker to downstream neighbor BGP speakers includes the smallest positive value among the average metric credit and remaining metrics calculated for all sources.

[0132] Furthermore, the BGP-intent route receiver further includes a second metric acquisition module configured to obtain the metric credit piece corresponding to the BGP Speaker from the BGP-intent route based on the BGP Speaker's end-to-end route location number, and to subtract the metrics included in the BGP-intent route from the total metric credits to obtain the remaining metrics, if the BGP-intent route also includes explicit metric credit pieces.

[0133] Furthermore, the second metric acquisition module is configured to calculate metric credit pieces and remaining metrics for all sources, so that the metric credit piece baseline for the transmission path from this BGP speaker to downstream neighbor BGP speakers includes the smallest positive value among the metric credit pieces and remaining metrics calculated for all sources.

[0134] Furthermore, if the acquisition module discovers that no transmission path to a downstream BGP Speaker meets the metric credit piece threshold, it is configured to select from all candidate transmission paths the path whose total metric type is closest to the metric credit piece threshold.

[0135] Furthermore, in one embodiment, the transmission path from the BGP Speaker to a downstream BGP Speaker includes at least one of the shortest forwarding path and the traffic engineering path, and the transmission path includes a plurality of subpaths, which distribute the load, form fast rerouting (FRR) protection, or form a path for multistream copying and deletion, and when the plurality of subpaths form a path for multistream copying and deletion, the metric difference between the plurality of subpaths should satisfy a configured limit.

[0136] Figure 8 is a block diagram of a BGP-intent route advertisement device according to an embodiment of the present disclosure. As shown in Figure 8, the BGP-intent route advertisement device is An advertisement module configured to advertise a BGP-intent route to a neighbor BGP Speaker, the advertisement module 802 includes an advertisement module 802 in which the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0137] According to the above solution, a BGP-intent route is advertised to a neighbor BGP speaker, and the BGP-intent route includes at least one of the metric type, metric, and metric credit information. This solves the problem in related technologies where the efficiency of establishing transmission paths for BGP-intent routes is low due to the content included in the BGP-intent route, and further improves the efficiency of establishing transmission paths by including the metric type, metric, and metric credit information in the BGP-intent route.

[0138] Furthermore, in one embodiment, the metric type includes IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics, the metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces, and the metric credit information includes only one piece of information regardless of the specific source, or includes multiple pieces of information corresponding one-to-one to multiple specific sources.

[0139] The metric corresponding to the aforementioned metric type is the sum of the metric included in the BGP-intent route advertisement received from the downstream neighbor BGP speaker and the total metric corresponding to the aforementioned metric type along the transmission path from this BGP speaker to the downstream neighbor BGP speaker. Alternatively, if this BGP speaker is the original advertising node, the metric corresponding to the aforementioned metric type is a configured initial value.

[0140] Note that the above initial value may be 0, but is not limited to this. In one exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB disks, read-only memory (ROM), random access memory (RAM), mobile hard disks, magnetic disks, or optical disks.

[0141] Specific examples in this embodiment can be found by referring to the examples described in the above embodiment and exemplary embodiment; therefore, this embodiment will not be described here.

[0142] In embodiments of the present disclosure, an electronic device is provided that further includes a memory in which a computer program is stored, and a processor configured to execute the computer program and perform the steps in any of the embodiments of the above method.

[0143] Selectively, in this embodiment, the processor is controlled by a computer program. The system may be configured to perform step S1, which involves receiving a BGP-intent route advertised by a BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0144] Selectively, in other embodiments, the processor is controlled by a computer program. The procedure may be configured to perform step S1, which involves advertising a BGP-intent route to a neighbor BGP Speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

[0145] In one exemplary embodiment, the electronic device may further include a transmission device connected to the processor and an input / output device connected to the processor.

[0146] Specific examples in this embodiment can be found by referring to the examples described in the above embodiment and exemplary embodiment; therefore, this embodiment will not be described here.

[0147] Clearly, those skilled in the art will understand that each module or step in the above-described disclosure may be implemented on a general-purpose computing device, they may be concentrated on a single computing device, or they may be distributed across a network of multiple computing devices, and they may be implemented as program code executable on a computing device, so that they can be stored in a memory device and executed on a computing device, and in some cases the illustrated or described steps can be executed in an order different from that specified herein, or they can be implemented by making each of them on an integrated circuit module, or by making multiple of them on a single integrated circuit. Thus, the disclosure is not limited to any particular combination of hardware and software.

[0148] The foregoing are merely preferred embodiments of the Disclosure and do not limit the Disclosure, and those skilled in the art can make various modifications and changes to the Disclosure. Any modifications, equivalent substitutions, and improvements made within the principles of the Disclosure should be within the scope of protection of the Disclosure.

Claims

1. A step of receiving a BGP-intent route advertised by a BGP speaker, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information; The steps include obtaining an intent identifier from the BGP-intent route, and obtaining intent information by locally searching for an intent template based on the intent identifier, The steps include determining a metric credit piece reference value for the transmission path between the current BGP speaker and a neighbor BGP speaker downstream of the current BGP speaker, based on the metric, total metric credit, estimated number of BGP hops, and metric credit piece included in the BGP-intent route, A method for receiving a BGP-intent route, comprising the steps of establishing a transmission route or selecting an existing transmission route such that the total metric of the metric types of an established transmission route or a selected existing transmission route is limited to or less than the metric credit piece threshold value.

2. The metric types include IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics. The aforementioned metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces. The method for receiving a BGP-intent route according to claim 1, wherein the metric credit information includes only one piece of information regardless of the specific source, or includes multiple pieces of information corresponding one-to-one to multiple specific sources.

3. If the metric credit information included in the BGP-intent route only includes the total metric credits associated with the source and does not include any explicit metric credit pieces, then for each source corresponding to the metric credit attribute, The steps include: dividing the total metric credits by the estimated number of BGP hops to obtain the average metric credits between two adjacent BGP speakers in an end-to-end path; A method for receiving a BGP-intent route according to claim 1, further comprising the steps of subtracting the metrics included in the BGP-intent route from the total metric credits to obtain the remaining metrics.

4. This includes the step of calculating the average metric credit and remaining metrics for all sources, The method for receiving a BGP-intent route according to claim 3, wherein the metric credit piece reference value for the transmission path from this BGP speaker to a downstream neighbor BGP speaker includes the average metric credit calculated for all sources and the smallest positive value among the remaining metrics.

5. If the BGP-intent route further includes explicit metric credit pieces, then for the metric credit information corresponding to each Source, The steps include: obtaining a metric credit piece corresponding to the BGP Speaker from the BGP-intent route based on the location number of the BGP Speaker in the end-to-end route of the BGP Speaker; A method for receiving a BGP-intent route according to claim 1, comprising the steps of subtracting the metrics included in the BGP-intent route from the total metric credits to obtain the remaining metrics.

6. This includes the step of calculating metric credit pieces and remaining metrics for all sources. The method for receiving a BGP-intent route according to claim 5, wherein the metric credit piece reference value for the transmission path from this BGP speaker to a downstream neighbor BGP speaker includes the smallest positive value among the metric credit pieces calculated for all sources and the remaining metrics.

7. The method for receiving a BGP-intent route according to claim 1, further comprising the step of selecting from all candidate transmission routes the route whose total metric of the metric type is closest to the metric credit piece criterion value if the BGP Speaker finds that there is no transmission route to a downstream BGP Speaker that satisfies the metric credit piece criterion value.

8. The transmission path from this BGP Speaker to the downstream BGP Speaker includes at least one of the shortest forwarding path and the traffic engineering path, The method for receiving a BGP-intent route according to claim 3, wherein the transmission path includes a plurality of subpaths, which distribute the load, form fast rerouting (FRR) protection, or form a path for copying and deleting multistreams, and when the plurality of subpaths form a path for copying and deleting multistreams, the metric differences between the plurality of subpaths should satisfy a set limit.

9. The BGP-intent route is advertised to neighbor BGP Speakers, and the neighbor BGP Speakers obtain an intent identifier from the BGP-intent route, locally search for an intent template based on the intent identifier to obtain intent information, and based on the metrics, total metric credits, estimated BGP hop count, and metric credit pieces included in the BGP-intent route, the current BGP speaker and the neighbor BGP downstream of the current BGP speaker... A method for advertising a BGP-intent route, comprising the steps of determining a metric credit piece threshold for a transmission path to and from a speaker, establishing a transmission path or selecting an existing transmission path such that the sum of the metric types of an established transmission path or a selected existing transmission path is less than or equal to the metric credit piece threshold, wherein the BGP-intent route includes at least one of a metric type, a metric, and metric credit information.

10. The metric types include IGP metrics, link delay metrics, link node delay metrics, TE default metrics, and bandwidth metrics. The aforementioned metric credit information includes total metric credits, estimated BGP hop count, and metric credit pieces. The method for advertising a BGP-intent route according to claim 9, wherein the metric credit information includes only one piece of information regardless of the specific source, or includes multiple pieces of information corresponding one-to-one to multiple specific sources.

11. The metric corresponding to the aforementioned metric type is the sum of the metric included in the BGP-intent route advertisement received from the downstream neighbor BGP speaker and the total metric corresponding to the aforementioned metric type for the transmission path from this BGP speaker to the downstream neighbor BGP speaker. Alternatively, if the BGP speaker is the original advertiser node, the metric corresponding to the metric type is a set initial value, and the original advertiser node is the node that initially generates and advertises the BGP-intent route, according to claim 9, the method for advertising a BGP-intent route.

12. A receiving module configured to receive BGP-intent routes advertised from a BGP speaker, wherein the BGP-intent route includes at least one of metric type, metric, and metric credit information. A BGP-intent route receiving device, comprising: an acquisition module configured to acquire an intent identifier from the BGP-intent route; retrieve intent information by locally searching an intent template based on the intent identifier; determine a metric credit piece threshold for a transmission path between the current BGP speaker and a downstream neighbor BGP speaker based on the metrics, total metric credits, estimated BGP hop count, and metric credit pieces included in the BGP-intent route; and establish a transmission path or select an existing transmission path by limiting the total metric of the metric type of an established transmission path or a selected existing transmission path to less than or equal to the metric credit piece threshold.

13. The BGP-intent route is advertised to neighbor BGP Speakers, and the neighbor BGP Speakers obtain an intent identifier from the BGP-intent route, locally search for an intent template based on the intent identifier to obtain intent information, and based on the metrics, total metric credits, estimated BGP hop count, and metric credit pieces included in the BGP-intent route, the current BGP speaker and the neighbor BGP downstream of the current BGP speaker... Advertisement device for a BGP-intent route, comprising an advertisement module configured to determine a metric credit piece reference value for a transmission path to a speaker, and to establish a transmission path or select an existing transmission path such that the total metric of the metric types of an established transmission path or a selected existing transmission path is limited to or less than the metric credit piece reference value, wherein the BGP-intent route includes an advertisement module that includes at least one of metric type, metric, and metric credit information.

14. A computer-readable storage medium in which a computer program is stored, wherein the computer program is configured to execute, when executed, the method according to any one of claims 1 to 8 or any one of claims 9 to 11.

15. An electronic device comprising: a memory storing a computer program; and a processor configured to perform the method according to any one of claims 1 to 8 or the method according to any one of claims 9 to 11 by the computer program.

Images