Method for receiving BGP-intent route and method for announcing BGP-intent route

Abstract

Embodiments of the present application provide a BGP-intent route receiving method and a BGP-intent route announcing method, wherein the BGP-intent route receiving method comprises: receiving a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data communication, in particular, to a method for receiving BGP-intent route and a method for announcing BGP-intent route. BACKGROUND

[0002] In large-scale networks across multiple domains, Border Gateway Protocol (BGP) is generally used to provide end-to-end intent-aware paths. An intent-aware path refers to a path selected by BGP route according to a specific intent when iterating the next hop, which means that the BGP route needs to carry intent information when announcing. Since the underlying transmission path is a traffic engineering path established based on a specific intent, the intent can also be referred to as a traffic engineering target in a network providing transmission services. There are currently various methods for BGP route to carry intent information when announcing, such as draft-kaliraj-idr-bgp-classful-transport-planes-12 defining "Classful Transport" SAFI NLRI and "TransportClass" Route Target extended community to carry intent information, draft-dskc-bess-bgp-car-02 defining BGP CAR SAFI NLRI to carry intent information, and draft-zhou-idr-inter-domain-lcu-02 directly using Color extended community to carry intent information. Such BGP routes are collectively referred to as BGP-intent routes in this paper.

[0003] Generally, a node receiving a BGP-intent route advertisement message interprets the intent according to intent configuration information (also referred to as intent-template) locally to establish a transmission path or select an existing transmission path that meets the intent to the message advertiser. The intent configuration information contains a set of constraints, such as the link bandwidth size to be provided in the path, the limited minimum and maximum delay, the limited delay jitter, the limited packet loss rate, the inclusion or exclusion of specific nodes or links, the limitation of path calculation in a specific virtual network, and the like. On an ingress PE node (i.e., a node responsible for service access) in the network, a BGP-intent route to the egress PE that matches the service requirements will be selected according to the SLA (Service Level Agreement) of the service, that is, the intent configuration information on the ingress PE node is generally consistent with the service SLA, but this does not mean that the intent configuration information on the intermediate node is also consistent with the service SLA. For example, observing a BGP route forwarding behavior across multiple domains, the SLA of the service needs to meet "providing a path from the ingress PE to the egress PE with a maximum delay of 100 ms", obviously, the delay of 100 ms refers to the cumulative end-to-end delay upper limit, not the cumulative delay of a certain section of the path in the BGP route forwarding, that is, the BGPspeakers in the middle of the path cannot establish or select an existing transmission path to the next BGP speaker according to the delay of 100 ms as an index. As for how to solve this problem, one method is to configure different delay indexes (or delay credits) in the intent-template on different BGPspeakers in the path. However, this static configuration method has obvious defects, because a certain intent-template is not necessarily bound to a specific end-to-end path, and may serve multiple paths.

[0004] Currently, no effective solution has been proposed to solve the problem that the content carried in the BGP-intent route makes the establishment of the transmission path of the BGP-intent route inefficient.

[0005] Therefore, it is necessary to improve the related art to overcome the defects in the related art. SUMMARY

[0006] Embodiments of the present application provide a BGP-intent route receiving method and a BGP-intent route advertisement method to at least solve the problem that the content carried in the BGP-intent route in the related art makes the establishment of the transmission path of the BGP-intent route inefficient.

[0007] According to an aspect of the embodiments of the present application, a method for receiving BGP-intent route is provided, comprising: receiving BGP-intent route announced by BGP speaker, wherein the BGP-intent route carries at least one of the following: metric type, metric, and metric credit information.

[0008] Further, the metric type comprises: IGP metric, link latency metric, link and node latency metric, TE default metric, and bandwidth metric; the metric credit information comprises: total metric credit, estimated BGP hop number, and metric credit segment; the metric credit information only contains one piece of information, and is irrelevant to specific source; or the metric credit information contains multiple pieces of information, and the multiple pieces of information correspond to multiple specific sources one by one.

[0009] Further, after receiving the BGP-intent route announced by the BGP speaker, the method further comprises: obtaining intent identifier from the BGP-intent route, and locally searching intent template according to the intent identifier to obtain intent information; and establishing or selecting existing transmission path for the BGP-intent route according to the intent information.

[0010] Further, the establishing or selecting existing transmission path for the BGP-intent route according to the intent information comprises: determining metric credit segment reference value of transmission path between current BGP speaker and downstream neighbor BGP speaker of the current BGP speaker according to metric, total metric credit, estimated BGP hop number, and metric credit segment included in the BGP-intent route; limiting cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, so as to establish or select existing transmission path.

[0011] Further, the method further comprises: in the case that the metric credit information included in the BGP-intent route only contains total metric credit related to source, but does not contain explicit metric credit segment, for each source corresponding metric credit attribute: dividing the total metric credit by the estimated BGP hop number to obtain average metric credit between adjacent two BGP speakers in end-to-end path; subtracting the metric included in the BGP-intent route from the total metric credit to obtain remaining metric.

[0012] Further, the method further comprises: for the average metric credit calculated by all sources and the remaining metric, the reference value of the metric credit segment of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises: the minimum positive value in the average metric credit calculated by all sources and the remaining metric.

[0013] Further, the method further comprises: in the case that the BGP-intent route further contains an explicit metric credit segment, for the metric credit information corresponding to each source: according to the position number of the BGP speaker in the end-to-end path, the metric credit segment corresponding to the BGP speaker is obtained from the BGP-intent route; the remaining metric is obtained by subtracting the metric included in the BGP-intent route from the total metric credit.

[0014] Further, the method further comprises: for the metric credit segment calculated by all sources and the remaining metric, the reference value of the metric credit segment of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises: the minimum positive value in the metric credit segment calculated by all sources and the remaining metric.

[0015] Further, the method further comprises: when the BGP speaker finds that there is no transmission path to the downstream BGP speaker that can meet the reference value of the metric credit segment, selecting a path in all candidate transmission paths, the cumulative metric of the path is closest to the reference value of the metric credit segment.

[0016] Further, the method further comprises: the transmission path from the BGP speaker to the downstream BGP speaker comprises at least one of: the shortest forwarding path, the traffic engineering path; the transmission path comprises a plurality of sub-paths, through which the load sharing, the fast reroute (FRR) protection, or the multi-flow replication and elimination path is formed, wherein, when the multi-flow replication and elimination path is formed through the plurality of sub-paths, the difference between the metrics of the plurality of sub-paths should meet the set limit value.

[0017] According to another aspect of the embodiments of the present application, a method for announcing a BGP-intent route is provided, comprising: announcing a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

[0018] Further, the metric type includes: an IGP metric, a link latency metric, a link and node latency metric, a TE default metric, and a bandwidth metric; the metric credit information includes: a total metric credit, an estimated BGP hop count, and a metric credit segment; the metric credit information includes only one piece of information and is irrelevant to a specific source; or the metric credit information includes multiple pieces of information and the multiple pieces of information correspond to multiple specific sources one by one.

[0019] Further, the method further includes: when the metric type corresponds to a metric included in a BGP-intent route announcement received from a downstream neighbor BGP speaker, the metric is a sum of the metric included in the BGP-intent route announcement and accumulated metrics of a transmission path from the BGP speaker to the downstream neighbor BGP speaker corresponding to the metric type; or when the BGP speaker is an original announcing node, the metric corresponding to the metric type is a certain initial value.

[0020] According to another aspect of the embodiments of the present application, a receiving device of a BGP-intent route is provided, including: a receiving module, configured to receive a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

[0021] According to another aspect of the embodiments of the present application, a device of announcing a BGP-intent route is provided, including: an announcing module, configured to announce a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

[0022] According to another aspect of the embodiments of the present application, a computer readable storage medium is further provided, and the computer readable storage medium stores a computer program, wherein the computer program is configured to execute any of the above methods when running.

[0023] According to another aspect of the embodiments of the present application, an electronic device is further provided, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes any of the above methods through the computer program.

[0024] Through the present application, by receiving a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information, the problem of low establishment efficiency of a transmission path of a route in the related art is solved, and the establishment efficiency of the transmission path is improved. BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:

[0026] Figure 1 Fig. 1 is a hardware structure block diagram of a computer terminal of a receiving method of a BGP-intent route according to an embodiment of the application;

[0027] Figure 2 Fig. 2 is a flow chart of a receiving method of a BGP-intent route according to an embodiment of the application;

[0028] Figure 3 Fig. 3 is a flow chart of an announcing method of a BGP-intent route according to an embodiment of the application;

[0029] Figure 4 Fig. 4 is a schematic diagram of a metric-credit attribute format according to an embodiment of the application;

[0030] Figure 5 Fig. 5 is a schematic diagram of a transmission path of different intents between homologous and homostatic according to an embodiment of the application;

[0031] Figure 6 Fig. 6 is a schematic diagram of a transmission path of same intents between multiple pairs of source and sink according to an embodiment of the application;

[0032] Figure 7 Fig. 7 is a structure block diagram of a receiving device of a BGP-intent route according to an embodiment of the application;

[0033] Figure 8 Fig. 8 is a structure block diagram of an announcing device of a BGP-intent route according to an embodiment of the application. DETAILED DESCRIPTION

[0034] In order to enable persons skilled in the art to better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first", "second" and the like in the description and in the claims of the present application as well as above-mentioned appended drawings are intended to distinguish between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of the terms data, or the like, herein is not intended to limit the application that is described herein to any particular terminology. Moreover, the terms "comprising" and "including" and any of their derivatives, are intended to be construed in a non-exclusive manner when used in this description and the claims of the present application, and are intended to be inclusive of the items that are described in the specification and of equivalents thereof. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

[0036] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or similar computing device. Taking the case of running on a computer terminal, Figure 1 is a hardware structure block diagram of a computer terminal of the receiving method of the BGP-intent route of the embodiments of the present application. As shown in Figure 1 , the computer terminal can include one or more (only one is shown in Figure 1 ) processors 102 (the processor 102 can include but is not limited to a microprocessor unit (Microprocessor Unit, abbreviated as MPU) or a programmable logic device (Programmable logic device, abbreviated as PLD)) and a memory 104 for storing data. In an exemplary embodiment, the above-mentioned computer terminal can also include a transmission device 106 for communication function and an input and output device 108. Those skilled in the art can understand that Figure 1 The structure shown is only schematic, which does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal can also include more or less components than those shown in Figure 1 , or have a different configuration with the same function as Figure 1 or more functions than Figure 1 .

[0037] The memory 104 can be configured to store computer programs, for example, software programs of application software and modules, such as a computer program corresponding to the method for receiving BGP-intent route in embodiments of the present application. The processor 102 can perform various functional applications and data processing, that is, implement the method described above, by running the computer programs stored in the memory 104. The memory 104 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include memories remotely arranged with respect to the processor 102, which can be connected to the computer terminal through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0038] The transmission device 106 is configured to receive or send data via a network. A specific example of the network can include a wireless network provided by a communication provider of the computer terminal. In one example, the transmission device 106 includes a network adapter (NIC), which can be connected to other network devices through a base station so as to be capable of communicating with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is configured to communicate with the Internet in a wireless manner.

[0039] Figure 2 is a flowchart of the method for receiving BGP-intent route according to embodiments of the present application, as shown in Figure 2 The steps of the method include:

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

[0041] Through the above steps, by receiving the BGP-intent route announced by the BGP speaker, wherein the BGP-intent route carries at least one of the following: the metric type, the metric, and the metric credit information, the problem that the content carried in the BGP-intent route in the related art makes the establishment efficiency of the transmission path of the BGP-intent route low is solved, and the establishment efficiency of the transmission path is further improved by carrying the metric type, the metric, and the metric credit information in the BGP-intent route.

[0042] Further, in one embodiment, the metric type includes: IGP metric, link latency metric, link and node latency metric, TE default metric, bandwidth metric; the metric credit information includes: total metric credit, estimated BGP hop count, and metric credit segment; the metric credit information only contains one piece of information, and is irrelevant to a specific source; or the metric credit information contains multiple pieces of information, and the multiple pieces of information correspond to multiple specific sources one by one.

[0043] It should be noted that the link latency metric can include the latency of the link, but is not limited thereto.

[0044] It should be noted that the link and node latency metric can include the latency of the link and the latency within the node at the same time, but is not limited thereto.

[0045] Further, in one embodiment, after receiving the BGP-intent route announced by the BGP speaker, a technical solution is further provided, and the specific steps include: obtaining an intent identifier from the BGP-intent route, and locally searching for an intent template according to the intent identifier to obtain intent information; and establishing or selecting an existing transmission path for the BGP-intent route according to the intent information.

[0046] Further, in one embodiment, a technical solution for establishing or selecting an existing transmission path for the BGP-intent route according to the intent information is provided, which includes: determining a metric credit segment reference value of a transmission path between a current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to the metric, the total metric credit, the estimated BGP hop count, and the metric credit segment included in the BGP-intent route; limiting the cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, so as to establish or select the existing transmission path.

[0047] Further, in one embodiment, in the case that the metric credit information included in the BGP-intent route only contains the total metric credit related to the source, but does not contain the explicit metric credit segment, for each source corresponding to the metric credit attribute: the total metric credit is divided by the estimated BGP hop count to obtain the average metric credit between adjacent two BGP speakers in an end-to-end path; and the total metric credit is subtracted by the metric included in the BGP-intent route to obtain the remaining metric.

[0048] Further, in one embodiment, the method further comprises: for all source calculated average metric credits and remaining metric, the metric credit segment reference value of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises: the minimum positive value in all source calculated average metric credits and remaining metric.

[0049] Further, in one embodiment, a technical solution is provided, and the specific steps comprise: in the case that the BGP-intent route further contains an explicit metric credit segment, for each Source corresponding metric credit information: according to the position number of the BGP speaker in the end-to-end path, the BGP-intent route is acquired to obtain the metric credit segment corresponding to the BGP speaker; the remaining metric is obtained by subtracting the metric included in the BGP-intent route from the total metric credit.

[0050] Further, in one embodiment, the method further comprises: for all source calculated metric credit segments and remaining metric, the metric credit segment reference value of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises: the minimum positive value in all source calculated metric credit segments and remaining metric.

[0051] Further, in one embodiment, when the BGP speaker finds that there is no transmission path to the downstream BGP speaker that can meet the metric credit segment reference value, a path is selected from all candidate transmission paths, in which the cumulative metric of the metric type is closest to the metric credit segment reference value. In the embodiment of the application, in the case that there is no qualified transmission path at the BGP speaker, the condition can be relaxed to increase the margin, and then a path is selected from all candidate transmission paths, in which the cumulative metric of the metric type is closest to the metric credit segment reference value.

[0052] Further, the transmission path from the BGP speaker to the downstream BGP speaker comprises at least one of the following: a shortest forwarding path, a traffic engineering path; the transmission path comprises a plurality of sub-paths, through which a load sharing, a fast reroute (FRR) protection, or a multi-flow replication and elimination path is formed, wherein when the multi-flow replication and elimination path is formed through the plurality of sub-paths, the difference between the metrics of the plurality of sub-paths should satisfy a set limit value.

[0053] Figure 3 is a flowchart of the method for advertising the BGP-intent route according to the embodiment of the application, as shown in Figure 3 The steps of the method comprise:

[0054] Step S302, announcing the BGP-intent route to the neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: the metric type, the metric, and the metric credit information.

[0055] Through the above steps, by announcing the BGP-intent route to the neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: the metric type, the metric, and the metric credit information, the problem that the content carried in the BGP-intent route in the related art makes the establishment efficiency of the transmission path of the BGP-intent route low is solved, and the establishment efficiency of the transmission path is further improved by carrying the metric type, the metric, and the metric credit information in the BGP-intent route.

[0056] Further, in one embodiment, the metric type includes: an IGP metric, a link latency metric, a link and node latency metric, a TE default metric, and a bandwidth metric; the metric credit information includes: a total metric credit, an estimated BGP hop number, and a metric credit segment; the metric credit information only contains one piece of information and is irrelevant to a specific source; or the metric credit information contains multiple pieces of information and the multiple pieces of information correspond to multiple specific sources one by one.

[0057] Further, in one embodiment, the metric corresponding to the metric type is the sum of the metric contained in the BGP-intent route announcement received from the downstream neighbor BGP speaker and the cumulative metric corresponding to the metric type of the transmission path from the BGP speaker to the downstream neighbor BGP speaker; or, when the BGP speaker is an original announcement node, the metric corresponding to the metric type is a certain initial value set.

[0058] It should be noted that the initial value can be 0, but is not limited thereto.

[0059] Next, a more general method is discussed in combination with the following embodiments, so that the BGP speaker receiving the BGP-intent route can establish or select an existing transmission path to the next BGP speaker with more flexible and accurate intent.

[0060] In one embodiment, a technical solution is provided, and the specific steps are as follows:

[0061] Step 1, extend BGP, when a BGP speaker advertises BGP-intent route to its upstream neighbor, carry optional metric-type, metric, and metric-credit information. The metric-credit information is composed of total-metric-credit, estimated BGP hop, and metric-credit-piece. The metric-credit information can contain only one copy, regardless of the specific source (i.e. specific Ingress PE), or can contain multiple copies, each corresponding to a specific source.

[0062] Step 2, the BGP speaker receiving the BGP-intent route advertisement, obtains the intent identifier from the route advertisement, locally looks up the intent template to obtain intent information, and establishes or selects an existing transmission path according to the intent information. In particular, when establishing or selecting an existing transmission path, the metric, total-metric-credit, estimated BGP hop, and explicit metric-credit-piece information contained in the route advertisement are used to obtain the "metric-credit-piece reference value" of the transmission path from the BGP speaker to the downstream neighbor BGP speaker, which is used as a basis for establishing or selecting an existing transmission path, and limits the cumulative metric of the corresponding metric type of the transmission path used to not exceed the "metric-credit-piece reference value".

[0063] In order to better understand step 1, the following is a recommended specific protocol extension for BGP:

[0064] RFC4271 defines the Path Attributes of BGP, which are carried with BGP route advertisements to represent various properties of the route. The following Attribute Type Codes and attribute values are added to represent the metric-type, metric-credit, and other attributes described above, but are not limited to this. Note that the metric attribute is the AIGP Attribute defined in RFC7311.

[0065] It should be noted that in one embodiment, the metric-type attribute and the metric-credit attribute are described as follows:

[0066] a) metric-type attribute: When Type Code of Path Attribute = TBD1 (to be assigned by IANA (Internet Assigned Numbers Authority)), to indicate that the attribute value contains a metric-type attribute with length of one byte. The metric-type attribute is an optional non-transitive attribute, used to indicate what kind of metric is contained in the AIGP Attribute. The current values are as follows:

[0067] 0: IGP Metric (defined in RFC5305, RFC2328, RFC5340);

[0068] 1: Unidirectional Link Delay (defined in RFC7810);

[0069] 2: TE default metric (defined in RFC5305);

[0070] 3: Bandwidth Metric (defined in draft-ietf-lsr-flex-algo-bw-con-01);

[0071] 4: Deterministic Delay Metric (discussed in other documents, compared with the above Unidirectional Link Delay, the Deterministic Delay contains both link delay and intra-node delay);

[0072] 5-255: to be defined in the future.

[0073] b) metric-credit attribute: When Type Code of Path Attribute = TBD2 (to be assigned by IANA), to indicate that the attribute value contains a metric-credit attribute in the following format. The metric-credit attribute is an optional non-transitive attribute, used to indicate the total credit of end-to-end metric, estimated BGP hop count, metric credit segment, and the like.

[0074] In an embodiment, the metric-credit attribute can be described in combination with Figure 4 the metric-type attribute. Figure 4is a schematic diagram of the metric-credit attribute format according to an embodiment of the present application. The fields in are explained as follows: Figure 4

[0075] Count of Sources: occupies 1 byte, whose value is at least 1, indicating the result of the Source count, i.e., how many Sources (i.e., Ingress PEs) correspond to the metric credit information. The metric credit information corresponding to 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 CreditPiece[]".

[0076] Flags: occupies 1 byte, which is a flag bit. Currently, three flags are defined, which are:

[0077] S-Flag: Source Address Flag, indicating whether the Network Address of Source field is included. 0 indicates that it is not included, and 1 indicates that it is included.

[0078] F-Flag: Family Flag, indicating the address family of the Network Address of Source. When the S-Flag is 1, the length of the Network Address of Source is determined according to the F-Flag, 0 indicating a 4-byte IPv4 address and 1 indicating a 16-byte IPv6 address.

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

[0080] ​Network Address of Source: variable number of bytes, indicates the IP address of Source. When S-Flag is 0, this field does not exist; when S-Flag is 1 and F-Flag is 0, this field is 4 bytes of IPv4 address; when S-Flag is 1 and F-Flag is 1, this field is 16 bytes of IPv6 address. If Network Address of Source does not exist, it means that the metric credit information is not related to a specific Source, which generally occurs in scenarios where a coarse-grained control of transmission path establishment based on metric credit is desired, such as when an Egress PE announces BGP-intent routes to multiple Ingress PEs within the same AS, and only carries a single piece of unified metric credit information that is not related to Source.

[0081] Total Metric Credit for Source: 4 bytes, indicates the total metric credit from a specific Source (or any Source when Network Address of Source does not exist) to the Egress PE.

[0082] Estimated BGP Hops Count for Source: 1 byte, indicates the estimated BGP hop count from a specific Source (or any Source when Network Address of Source does not exist) to the Egress PE, only counting those BGP Speakers that need to modify the BGP Next-hop to itself when receiving BGP-intent route announcements. For example, in an announced path S-A-B-C-D composed of 5 BGP Speakers, S is the Ingress PE and D is the Egress PE, A / B / C are three intermediate BGP Speaker nodes and they all modify the BGP Next-hop to themselves when receiving BGP-intent route announcements, then the estimated BGP hop count is 4, i.e. the entire announced path consists of 4 segments.

[0083] Current Hop Number: occupies 1 byte, indicating the current subscript of the array Metric Credit Piece[]. Note that when P-Flag is 0, the "Current Hop Number" and "Metric Credit Piece[]" fields do not exist. In the BGP-intent route advertisement message sent by the Egress PE to its adjacent upstream BGP Speaker neighbor, the initial value of Current Hop Number is 0; each time the BGP-intent route advertisement message passes through a BGP Speaker and the BGP Speaker modifies the BGP Next-hop of the route to itself, it will read the element from the array Metric Credit Piece[] according to the subscript Current Hop Number, obtain the metric credit piece of the transmission path from the BGP Speaker to the downstream BGP Speaker neighbor, and then increment the Current Hop Number in the message by 1 and continue to advertise the route to the upstream BGP Speaker neighbor. Note that when reading the element from the array Metric Credit Piece[] using the subscript Current Hop Number, it is necessary to avoid array out-of-bounds.

[0084] Metric Credit Piece[]: is an array, the number of elements contained is specified by Estimated BGP Hops Count for Source, and each element occupies 2 bytes. In the process of BGP-intent route advertisement, each BGP Speaker along the way modifies the BGP Next-hop of the route to itself, and uses Current Hop Number as a subscript to access the array to obtain explicit metric credit piece information. The use of metric credit pieces has very strict restrictions, i.e., BGP-intent routes must be strictly advertised to a specific Source according to the expected advertised path hop-by-hop by the Egress PE. When an exception occurs, the BGP Speaker finds that the value of Current Hop Number in the received BGP-intent route advertisement message is greater than or equal to the value of Estimated BGP Hops Count for Source, and then it must stop seeking the transmission path according to the metric credit piece information.

[0085] In order to better understand the above step 2, the following embodiment can be combined to explain step 2.

[0086] Embodiment 1

[0087] In this embodiment, if the metric credit attribute information contained in the BGP-intent route advertisement message only contains the total metric credit related to the Source, but does not contain the explicit metric credit segment information, the following operations can be performed on the metric credit information corresponding to each Source:

[0088] Operation 1: set the variable total_metric_credit_value to the value of the Total Metric Credit for Source;

[0089] Operation 2: set the variable bgp_hops_count to the value of the Estimated BGP Hops Count for Source;

[0090] Operation 3: set the variable metric_value to the value of the metric contained in the AIGP Attribute of the received BGP-intent route;

[0091] Operation 4: set the variable metric_residual_value to the remaining metric, where metric_residual_value = total_metric_credit_value - metric_value;

[0092] It should be noted that when there are multiple Source corresponding metric credit information, the BGP-intent route may accumulate a large metric_value when advertising, resulting in the metric_residual_value corresponding to a certain Source being negative and the metric_residual_value corresponding to other Sources being positive.

[0093] Operation 5: set the variable average_metric_credit_value to the average metric credit between each adjacent BGP speaker in the end-to-end path, where average_metric_credit_value = total_metric_credit_value / bgp_hops_count;

[0094] In addition, the following operations can be performed on the metric credit information corresponding to all Sources:

[0095] Operation 6: set the variable min_metric_residual_value to the minimum positive value of the metric_residual_value corresponding to all Sources;

[0096] Operation 7: Set variable min_average_metric_credit_value as the minimum value among all the average_metric_credit_value corresponding to the Sources;

[0097] The "metric credit segment reference value" of the one of the BGP speakers to the downstream neighbor BGP speaker in this transmission path is the minimum value among min_metric_residual_value and min_average_metric_credit_value.

[0098] Embodiment 2

[0099] In this embodiment, if the BGP-intent route advertisement message further contains explicit metric credit segment information, the following operations can be performed for the metric credit information corresponding to each Source:

[0100] Operation 8: Set variable total_metric_credit_value as the value of Total Metric Credit for Source;

[0101] Operation 9: Set variable bgp_hops_count as the value of Estimated BGP Hops Count for Source;

[0102] Operation 10: Set variable metric_value as the value of metric contained in the AIGP Attribute of the received BGP-intent route;

[0103] Operation 11: Set variable metric_residual_value as the remaining metric, where metric_residual_value = total_metric_credit_value - metric_value;

[0104] It should be noted that when there are multiple Sources corresponding to the metric credit information, the BGP-intent route may accumulate a large metric_value when being advertised, resulting in that the metric_residual_value corresponding to a Source is negative and the metric_residual_value corresponding to other Sources is positive.

[0105] Operation 12: Set variable explicit_metric_credit_piece_value to the value of the element read from array Metric Credit Piece[] using subscript CurrentHop Number, noting that if the read occurs out of bounds, explicit_metric_credit_piece_value is considered to be 0;

[0106] Additionally, the following operations can be performed for all Source corresponding metric credit information:

[0107] Operation 13: Set variable min_metric_residual_value to the smallest positive value of all Source corresponding metric_residual_value;

[0108] Operation 14: Set variable min_explicit_metric_credit_piece_value to the smallest positive value of all Source corresponding explicit_metric_credit_piece_value;

[0109] The "metric credit piece reference value" for the segment of the transmission path from this BGP speaker to the downstream neighbor BGP speaker in this embodiment is the smaller of min_metric_residual_value and min_explicit_metric_credit_piece_value.

[0110] Through the above embodiments, it can be determined that the purpose of the "metric credit piece reference value" calculated in the above embodiments is to constrain the cumulative metric (metric) of the segment of the transmission path used to not exceed the "metric credit piece reference value". However, in some cases, the BGP speaker finds that there is no transmission path that can meet the above requirements, and then the constraint can be appropriately relaxed. However, the transmission path ultimately used by the BGP speaker is the one whose cumulative metric of the corresponding metric type (metric-type) is closest to the "metric credit piece reference value" compared to other candidate transmission paths.

[0111] Among them, the metric-type contained in the BGP-intent route generated on the BGP Speaker is copied from the received route announcement, the metric attribute value contained is updated to the metric contained in the received route announcement plus the accumulated metric of the corresponding metric-type of the transmission path used, and the metric-credit attribute contained is copied from the received route announcement (note that the Current Hop Number is incremented by 1).

[0112] In addition, the BGP Speaker can continue to announce the above-mentioned generated BGP-intent route to the upstream BGP Speaker neighbor and modify the BGP Next-hop to itself, at which time the route announcement will carry the above-mentioned updated metric attribute and metric-credit attribute.

[0113] Next, the receiving method of the BGP-intent route of the embodiment of the present application can be described through the following embodiments.

[0114] Embodiment 3

[0115] In combination Figure 5 The embodiment is described, Figure 5 is a schematic diagram of transmission paths of different intents between homologous and homostatic nodes according to the embodiment of the present application. As Figure 5 shown in the network, two IGP domains are contained, BGP neighbors are established between PE1 and ABR, and ABR and PE2, and BGP-intent routes are announced. For example, according to the method described in draft-zhou-idr-inter-domain-lcu-02, the egress PE2 announces its loopback route (denoted as loopback-PE2) to the ABR through BGP, and carries the Color extended community to carry the intent information in the route announcement. After receiving the route announcement, the ABR continues to announce through BGP to PE1, that is, the ingress PE1, the ABR, and the egress PE2 are the BGP Speaker in the foregoing scheme.

[0116] Assume in this example, there are two types of traffics need to communicate between Ingress PE1 and Egress PE2, one of which has an intent that the end-to-end total delay of the transmission path used cannot exceed 10 ms, and the other has an intent that the end-to-end total delay of the transmission path used cannot exceed 100 ms. Since two intent-related paths need to be characterized between the same source / destination, in this embodiment, two colors, color-1000 and color-2000, need to be configured on Egress PE2.

[0117] It should be noted that the intent configuration corresponding to Color-1000 is as follows: metric-type: UnidirectionalLink Delay (unit: ms); total-metric: 10; metric-credit enabled.

[0118] It should be noted that the intent configuration corresponding to Color-2000 is as follows: metric-type: UnidirectionalLink Delay (unit: ms); total-metric: 100; metric-credit enabled.

[0119] It should be noted that the intent configuration information corresponding to the above two colors is also configured on other BGP Speaker nodes (ABR, Ingress PE1). It should be noted that since the metric-credit enabled command is included in the intent configuration information, these other BGP Speakers will not only calculate the transmission path to the downstream BGP Speaker neighbor according to the total-metric included in the intent configuration information after receiving the BGP-intent route advertisement from the downstream BGP Speaker neighbor, but also obtain the metric credit information from the received BGP-intent route advertisement, and establish or use the existing transmission path that meets the intent. Alternatively, the intent configuration configured on these other BGP Speaker nodes can not include total-metric information.

[0120] In this embodiment, a technical solution is provided, and the specific steps include:

[0121] Step 1) Egress PE2 generates BGP-intent routes and advertises to ABR: On Egress PE2, two BGP-intent routes are generated accordingly, <prefix=loopback-PE2, color=1000> and <prefix=loopback-PE2, color=2000>, which are advertised to ABR respectively, and the BGP Next-hop in the route advertisement is Egress PE2.

[0122] It should be noted that when the BGP-intent route <prefix=loopback-PE2, color=1000> is advertised, according to the intent configuration information corresponding to color-1000, the information contained in the route advertisement is set, that is: the metric-type is set to: Unidirectional Link Delay; the initial metric is set to: 0.

[0123] And the metric credit information is set to: Count of Sources: 1; Flags: S-Flag=1, F-Flag=0, P-Flag=0; Network Address of Source: loopback-PE1 (assuming IPv4 address); Total Metric Credit for Source: 10; Estimated BGP Hops Count for Source: 2 (two BGP Speakers to be experienced to Ingress PE1).

[0124] In addition, when the BGP-intent route <prefix=loopback-PE2, color=2000> is advertised, according to the intent configuration information corresponding to color-2000, the information contained in the route advertisement is set, that is: the metric-type is set to: Unidirectional Link Delay; the initial metric is set to: 0. And the metric credit information is set to: Count of Sources: 1; Flags: S-Flag=1, F-Flag=0, P-Flag=0; Network Address of Source: loopback-PE1 (assuming IPv4 address); Total Metric Credit for Source: 100; Estimated BGP Hops Count for Source: 2 (two BGP Speakers to be experienced to Ingress PE1).

[0125] Step 2) ABR receives the BGP-intent route, establishes a satisfied-intent underlay transport path to the BGP Next-hop: When ABR receives the BGP-intent route <prefix = loopback-PE2, color = 1000>, it locally generates a corresponding route entry with metric-type as Unidirectional Link Delay and BGP Next-hop as Egress PE2.

[0126] It is to be noted that, according to the metric credit information contained in the received route advertisement, ABR knows that the "metric credit segment reference value" from the current BGP Speaker (i.e. ABR) to the downstream BGP Speaker neighbor (i.e. Egress PE2) is 5ms (total metric credit divided by 2), then ABR internally invokes CSPF (Constraint Shortest Path First) computation module to calculate a path to Egress PE2 with a latency no more than 5ms, which is assumed to be TE path-12 in Figure 5 with a latency of 4ms. Therefore, the underlay transport path that the BGP-intent route entry <prefix = loopback-PE2, color = 1000> on ABR iterates to the BGP Next-hop is TE path-12, and the metric in the route entry is set to 4 accordingly. ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1) with metric-type as Unidirectional Link Delay, metric as 4, BGP Next-hop modified as ABR, and the metric credit information (which remains the same as the metric credit information in the previous received route advertisement).

[0127] Similarly, BGP-intent routes can also be received at the ABR.<prefix=loopback-PE2,color=2000> At that time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGPNext-hop is Egress PE2. Based on the metric credit information contained in the received routing advertisement, the ABR knows that the "metric credit fragment reference value" from this BGP speaker (i.e., ABR) to its downstream BGP speaker neighbor (i.e., Egress PE2) is 50ms (total metric credit divided by 2). Therefore, the ABR node will internally call the CSPF calculation module to calculate a low-latency path to Egress PE2 with a latency not exceeding 50ms. Let's assume it's... Figure 5 The TE path-22 in the ABR has a latency of 40ms. Therefore, the BGP-intent routing table entry generated on the ABR...<prefix=loopback-PE2,color=2000> The underlying transport path for iterating to the BGP Next-hop is TE path-22, and the metric in 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), where the metric-type is Unidirectional LinkDelay, the metric is 40, the BGP Next-hop is modified to ABR, and the metric credit information remains unchanged from the previously received route advertisement.

[0128] Step 3) Ingress PE1 receives the BGP-intent route and establishes the underlying transport path to the BGP Next-hop that satisfies the intent: Ingress PE1 receives the BGP-intent route<prefix=loopback-PE2,color=1000> At that time, the corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is ABR.

[0129] It is to be noted that according to the metric credit information contained in the received route advertisement, the Ingress PE1 knows that the "metric credit segment reference value" from the BGP Speaker (i.e. Ingress PE1) to the downstream BGP Speaker neighbor (i.e. ABR) is 5ms (total metric credit divided by 2 equals 5, and the remaining metric credit is 6, and the smaller value is taken), so the CSPF calculation module inside the Ingress PE1 node will calculate a very low latency path to the ABR of no more than 5ms, which is assumed to be TE path-11 (path-11) in Figure 5 , with a latency of 4ms. Therefore, the underlying transport path of the BGP-intent route table entry <prefix = loopback-PE2, color = 1000> generated on the Ingress PE1 to the BGP Next-hop is TE path-11, and the metric in the route table entry is set to 8 (= 4 + 4) accordingly.

[0130] Similarly, when the Ingress PE1 receives the BGP-intent route <prefix = loopback-PE2, color = 2000>, a corresponding route table entry can also be generated locally, where the metric-type is Unidirectional Link Delay, and the BGP Next-hop is ABR. According to the metric credit information contained in the received route advertisement, the Ingress PE1 knows that the "metric credit segment reference value" from the BGP Speaker (i.e. Ingress PE1) to the downstream BGP Speaker neighbor (i.e. ABR) is 50ms (total metric credit divided by 2 equals 50, and the remaining metric credit is 60, and the smaller value is taken), so the CSPF calculation module inside the Ingress PE1 node will calculate a low latency path to the ABR of no more than 50ms, which is assumed to be TE path-21 (path-21) in Figure 5 , with a latency of 40ms. Therefore, the underlying transport path of the BGP-intent route table entry <prefix = loopback-PE2, color = 2000> generated on the Ingress PE1 to the BGP Next-hop is TE path-21, and the metric in the route table entry is set to 80 (= 40 + 40) accordingly.

[0131] It can be seen that in the embodiment, through the metric credit information contained in the route advertisement, each BGP Speaker can establish a differentiated transmission path according to the metric credit information, avoiding the competition for high-quality very low latency link resources.

[0132] Embodiment 4

[0133] Reference can be made to the network shown in FIG. 1. Since the two IGP domains are managed by a single service provider, which is familiar with the performance indicators of the network, and the propagation path of the BGP-intent route advertisement is explicit, a local policy can be configured on the Egress PE2 at this time, so that the explicit metric credit piece information is contained in the BGP-intent route advertisement. The main steps are as follows: Figure 5

[0134] Step 1) Egress PE2 generates BGP-intent routes and advertises to ABR: On the Egress PE2, two BGP-intent routes <prefix = loopback-PE2, color = 1000> and <prefix = loopback-PE2, color = 2000> are generated respectively, and are advertised to the ABR, and the BGP Next-hop in the route advertisement is the Egress PE2.

[0135] It should be noted that when the BGP-intent route <prefix = loopback-PE2, color = 1000> is advertised, the information contained in the route advertisement is set according to the intent configuration information corresponding to the color-1000, that is: the metric-type is set to: Unidirectional Link Delay; the initial metric is set to: 0.

[0136] And the metric credit information is set to: Count of Sources: 1; Flags: S-Flag = 1, F-Flag = 0, P-Flag = 1; Network Address of Source: loopback-PE1 (assuming IPv4 address); Total Metric Credit for Source: 10; Estimated BGP Hops Count for Source: 2 (two BGP Speakers to be experienced to the Ingress PE1); Current Hop Number: 0; Metric Credit Piece[2] : [0] = 4, [1] = 6.

[0137] ​It should be noted that when the BGP-intent route <prefix=loopback-PE2, color=2000> is announced, according to the intent configuration information corresponding to the color-2000, the information contained in the route announcement is set, that is, the metric-type is set to: Unidirectional Link Delay; and the initial metric is set to: 0.

[0138] In addition, the metric credit information is set 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 to be experienced to the Ingress PE1); Current Hop Number: 0; Metric Credit Piece[2]: [0]=40, [1]=60.

[0139] Step 2) The ABR receives the BGP-intent route and establishes a bottom-layer transmission path meeting the intent to the BGP Next-hop: When the ABR receives the BGP-intent route <prefix=loopback-PE2, color=1000>, a corresponding routing table item is locally generated, in which the metric-type is Unidirectional Link Delay and the BGP Next-hop is the Egress PE2.

[0140] It should be noted that according to the metric credit information contained in the received route announcement, the ABR knows that the "metric credit piece reference value" from the current BGP Speaker (i.e., the ABR) to the downstream BGP Speaker neighbor (i.e., the Egress PE2) is 4 ms (the total metric credit divided by 2 is 5, and the metric credit piece [0] element is 4, taking the smaller value), so the ABR node internally calls the CSPF calculation module to calculate a path to the Egress PE2 with an extremely low delay of not more than 4 ms, which is assumed to be Figure 5TE path-12, which has a latency of 4 ms. Thus, the BGP-intent route entry <prefix= loopback-PE2, color=1000> generated on ABR iterates to the underlying transport path of the BGP Next-hop as TE path-12, and sets the metric in the route entry as 4 accordingly. ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with metric-type as Unidirectional Link Delay, metric as 4, BGP Next-hop modified as ABR, and metric credit information (Current Hop Number incremented by 1).

[0141] Similarly, when ABR receives the BGP-intent route <prefix= loopback-PE2, color=2000>, it can also locally generate the corresponding route entry with metric-type as Unidirectional Link Delay and BGP Next-hop as Egress PE2. ABR knows from the metric credit information contained in the received route advertisement that the "metric credit segment reference value" from the current BGP Speaker (i.e., ABR) to the downstream BGP Speaker neighbor (i.e., Egress PE2) is 40 ms (total metric credit divided by 2 is 50, and metric credit segment [0] element is 40, taking the smaller value). ABR node internally invokes the CSPF computation module to compute a low-latency path to Egress PE2 that does not exceed 40 ms, assuming that the path is Figure 5 TE path-22, which has a latency of 40 ms. Thus, the BGP-intent route entry <prefix= loopback-PE2, color=2000> generated on ABR iterates to the underlying transport path of the BGP Next-hop as TE path-22, and sets the metric in the route entry as 40 accordingly. ABR continues to advertise the BGP-intent route to the upstream BGP Speaker neighbor (Ingress PE1), with metric-type as Unidirectional Link Delay, metric as 40, BGP Next-hop modified as ABR, and metric credit information (Current Hop Number incremented by 1).

[0142] Step 3) Ingress PE1 receives the BGP-intent route, establishes a satisfied-intent underlay transport path to the BGP Next-hop: When Ingress PE1 receives the BGP-intent route <prefix = loopback-PE2, color = 1000>, it locally generates a corresponding route entry with metric-type as Unidirectional Link Delay and BGP Next-hop as ABR.

[0143] It is noted that according to the metric credit information contained in the received route advertisement, Ingress PE1 knows that the "metric credit segment reference value" from the current BGP Speaker (i.e. Ingress PE1) to the downstream BGP Speaker neighbor (i.e. ABR) is 5ms (total metric credit divided by 2 equals 5, remaining metric credit is 6, metric credit segment [1] element is 6, taking the smaller value), so Ingress PE1 internally invokes the CSPF computation module to compute a very low latency path to ABR no more than 5ms, which is assumed to be TE path-11 in Figure 5 with a latency of 4ms. Therefore, the underlay transport path to the BGP Next-hop of the BGP-intent route entry <prefix = loopback-PE2, color = 1000> generated on Ingress PE1 is TE path-11, and the metric in the route entry is set to 8 (= 4 + 4) accordingly.

[0144] Similarly, when Ingress PE1 receives the BGP-intent route <prefix = loopback-PE2, color = 2000>, it locally generates a corresponding route entry with metric-type as Unidirectional Link Delay and BGP Next-hop as ABR. According to the metric credit information contained in the received route advertisement, Ingress PE1 knows that the "metric credit segment reference value" from the current BGP Speaker (i.e. Ingress PE1) to the downstream BGP Speaker neighbor (i.e. ABR) is 50ms (total metric credit divided by 2 equals 50, remaining metric credit is 60, metric credit segment [1] element is 60, taking the smaller value), so Ingress PE1 internally invokes the CSPF computation module to compute a low latency path to ABR no more than 50ms, which is assumed to be TE path-12 in Figure 6TE path-21, whose latency is 40ms. Therefore, the BGP-intent route entry <prefix = loopback-PE2, color = 2000> generated on Ingress PE1 iterates to the underlying transport path of the BGP Next-hop, which is TE path-21, and sets the metric in the route entry to 80 (= 40 + 40) accordingly.

[0145] Embodiment 5

[0146] In combination Figure 6 The technical solutions in this embodiment are described. Figure 6 is a schematic diagram of the transmission paths of the same intent between a pair of source and destination according to the embodiments of the present application. As shown in the network, Figure 7 The network shown contains 3 ASes (Autonomous Systems), and BGP neighbors are established between PE1 and ASBR1, ASBR1 and ASBR2, ASBR1 and ASBR3, ASBR2 and PE2, and ASBR3 and PE3 to advertise 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 through BGP, and Egress PE3 advertises its loopback route (denoted as loopback-PE3) to ASBR3 through BGP, carrying Color extended community to carry intent information in the route advertisement. After receiving the route advertisement, ASBR2 / ASBR3 continues to advertise through BGP to ASBR1, and ASBR1 continues to advertise through BGP to Ingress PE1, i.e., Ingress PE1, ASBR1, ASBR2, ASBR3, Egress PE2, and Egress PE3 are the BGP speakers in the foregoing scheme.

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

[0148] It should be noted that assuming corresponding color-1000 is configured on Egress PE2, its corresponding intent configuration is as follows: metric-type: Unidirectional Link Delay (unit: ms); total-metric: 200 (considering the actual distance is shorter); metric-credit enabled.

[0149] It should be noted that assuming corresponding color-1000 is configured on Egress PE3, its corresponding intent configuration is as follows: metric-type: Unidirectional Link Delay (unit: ms); total-metric: 300 (considering the actual distance is longer); metric-credit enabled.

[0150] Wherein, the intent configuration information corresponding to the above color is also configured on other BGP Speaker nodes (ASBR1, ASBR2, ASBR3, Ingress PE1), and can not contain total-metric information.

[0151] The specific process is similar to the foregoing embodiment, and only the key content is described here:

[0152] Step 1) Egress PE2 generates BGP-intent route and advertises to ASBR2: on Egress PE2, the corresponding BGP-intent route <prefix=loopback-PE2, color=1000> is advertised to ASBR2, containing the following main information: set BGP Next-hop as: loopback-PE2; set metric-type as: Unidirectional Link Delay; set initial metric as: 0.

[0153] And, set the metric credit information as: Count of Sources: 1; Flags: S-Flag=1, F-Flag=0, P-Flag=0; Network Address of Source: loopback-PE1 (assuming IPv4 address); Total Metric Credit for Source: 200; Estimated BGP Hops Count for Source: 3 (to Ingress PE1 to experience 3 BGP Speaker).

[0154] Step 2) Egress PE3 generates BGP-intent route and announces to ASBR3: On Egress PE3, the corresponding BGP-intent route <prefix=loopback-PE3, color=1000> is generated and announced to ASBR3, containing the following main information: set BGP Next-hop as: loopback-PE3; set metric-type as: Unidirectional Link Delay; set initial metric as: 0.

[0155] And, set metric credit information as: Count of Sources: 1; Flags: S-Flag=1, F-Flag=0, P-Flag=0; Network Address of Source: loopback-PE1 (assuming IPv4 address); Total Metric Credit for Source: 300; Estimated BGP Hops Count for Source: 3 (to Ingress PE1, 3 BGP Speakers to be experienced).

[0156] Step 3) ASBR2 receives BGP-intent route and establishes the underlying transport path satisfying the intent to BGP Next-hop: When ASBR2 receives the BGP-intent route <prefix=loopback-PE2, color=1000>, it locally generates the corresponding routing table entry, the main attributes of which include: metric-type as: Unidirectional Link Delay; BGP Next-hop as: loopback-PE2 (according to the metric credit fragment reference value 66, the transport path to PE2 is TE path-13); metric as: 60 (cumulative delay of 60 ms of TE path-13 is added); metric-credit information: remains unchanged with the information in the received route announcement.

[0157] In addition, ASBR2 continues to announce the BGP-intent route to ASBR1, in which the metric-type is Unidirectional Link Delay, the metric is 60, the BGP Next-hop is modified to ASBR2, and the metric credit information (remains unchanged with the metric credit information in the previously received route announcement).

[0158] Step 4) ASBR3 receives the BGP-intent route and establishes the intent- satisfied underlay transport path to the BGP Next-hop: When ASBR3 receives the BGP-intent route <prefix = loopback-PE3, color = 1000>, it locally generates the corresponding route entry with the main attributes including: metric-type as Unidirectional Link Delay; BGP Next-hop as loopback-PE3 (according to the metric-credit fragment reference value 100, the transport path to PE2 is TE path-23); metric as 100 (accumulated with the accumulated delay 100 ms of TE path-23); and metric-credit information remains unchanged as in the received route advertisement.

[0159] In addition, ASBR3 continues to advertise the BGP-intent route to ASBR1 with metric-type as Unidirectional Link Delay, metric as 100, BGP Next-hop modified as ASBR3, and metric-credit information (remains unchanged as in the previously received route advertisement).

[0160] Step 5) ASBR1 receives the BGP-intent route and establishes the intent- satisfied underlay transport path to the BGP Next-hop: When ASBR1 receives the BGP-intent route <prefix = loopback-PE2, color = 1000>, it locally generates the corresponding route entry with the main attributes including: metric-type as Unidirectional Link Delay; BGP Next-hop as ASBR2 (according to the metric-credit fragment reference value 66, the transport path to ASBR2 is TE path-12); metric as 70 (accumulated with the accumulated delay 10 ms of TE path-12); and metric-credit information remains unchanged as in the received route advertisement.

[0161] In addition, ASBR1 continues to advertise the BGP-intent route to Ingress PE1 with metric-type as Unidirectional Link Delay, metric as 70, BGP Next-hop modified as ASBR1, and metric-credit information (remains unchanged as in the previously received route advertisement).

[0162] Similarly, when ASBR1 receives the BGP-intent route <prefix = loopback-PE3, color = 1000>, it locally generates a corresponding route entry with the following main attributes: metric-type is Unidirectional Link Delay; BGP Next-hop is ASBR3 (according to the metric-credit fragment reference value 100, the transmission path to ASBR3 is TE path-22); metric is 110 (cumulative delay of TE path-22 is 10 ms); metric-credit information remains unchanged from the received route announcement.

[0163] In addition, ASBR1 continues to announce the BGP-intent route to Ingress PE1, where metric-type is Unidirectional Link Delay, metric is 110, BGP Next-hop is modified to ASBR1, and the metric-credit information (remains unchanged from the metric-credit information in the previous received route announcement).

[0164] Step 6) Ingress PE1 receives the BGP-intent route and establishes an intent- satisfying underlay transmission path to the BGP Next-hop: When Ingress PE1 receives the BGP-intent route <prefix = loopback-PE2, color = 1000>, it locally generates a corresponding route entry with the following main attributes: metric-type is Unidirectional Link Delay; BGP Next-hop is ASBR1 (according to the metric-credit fragment reference value 66, the transmission path to ASBR2 is TE path-11); metric is 130 (cumulative delay of TE path-11 is 60 ms); metric-credit information remains unchanged from the received route announcement.

[0165] Similarly, when the Ingress PE1 receives the BGP-intent route <prefix=loopback-PE3, color=1000>, a corresponding routing entry can be generated locally, and main attributes include: metric-type is Unidirectional Link Delay; BGP Next-hop is ASBR1 (according to the metric credit fragment reference value 100, the transmission path iterated to the ASBR1 is TE path-21); metric is 210 (cumulative delay 100 ms of TE path-22 is added); metric-credit information remains unchanged with the information in the received route advertisement.

[0166] By adopting the technical solutions in the above embodiments, the transmission path establishment of the intent route can be controlled, differentiated forwarding resources are provided, and all services can avoid competing for high-quality resources.

[0167] In addition, the technical solutions in the above embodiments can be applied to IPRAN / SPN, metropolitan area network / backbone, but are not limited thereto.

[0168] Figure 7 is a structural block diagram of a receiving device of a BGP-intent route according to an embodiment of the present application. As shown in Figure 8 the receiving device of the BGP-intent route includes:

[0169] The receiving module 702 is configured to receive a BGP-intent route announced by a BGP speaker, and the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

[0170] By the above scheme, by receiving a BGP-intent route announced by a BGP speaker, and the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information, the problem that the content carried in the BGP-intent route in the related art makes the establishment efficiency of the transmission path of the BGP-intent route low is solved, and by carrying the metric type, the metric, and the metric credit information in the BGP-intent route, the establishment efficiency of the transmission path is further improved.

[0171] Further, the metric type includes: an IGP metric, a link delay metric, a link and node delay metric, a TE default metric, and a bandwidth metric; the metric credit information includes: a total metric credit, an estimated BGP hop count, and a metric credit segment; the metric credit information includes only one piece of information, and is irrelevant to a specific source; or the metric credit information includes multiple pieces of information, and the multiple pieces of information correspond to multiple specific sources one by one.

[0172] It should be noted that the link delay metric can include the delay of the link, but is not limited thereto.

[0173] It should be noted that the link and node delay metric can include the delay of the link and the delay within the node, but is not limited thereto.

[0174] Further, the receiving device of the BGP-intent route further includes: an obtaining module, configured to obtain an intent identifier from the BGP-intent route, and locally search an intent template according to the intent identifier to obtain intent information; and establish or select an existing transmission path for the BGP-intent route according to the intent information.

[0175] Further, the obtaining module is further configured to determine a metric credit segment reference value of a transmission path between a current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to a metric, a total metric credit, an estimated BGP hop count, and a metric credit segment included in the BGP-intent route; and limit an accumulated metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, so as to establish or select the existing transmission path.

[0176] Further, the receiving device of the BGP-intent route further includes: a first metric obtaining module, configured to, in a case where the metric credit information included in the BGP-intent route includes only a total metric credit related to a source, but does not include an explicit metric credit segment, for each source corresponding metric credit attribute: divide the total metric credit by the estimated BGP hop count to obtain an average metric credit between adjacent two BGP speakers in an end-to-end path; and subtract the metric included in the BGP-intent route from the total metric credit to obtain a remaining metric.

[0177] Further, the first metric obtaining module is further configured to, for the average metric credit and the remaining metric calculated for all sources: the metric credit segment reference value of the transmission path from the BGP speaker to the downstream neighbor BGP speaker includes the minimum positive value in the average metric credit and the remaining metric calculated for all sources.

[0178] Further, the receiving device of the BGP-intent route further comprises a second metric obtaining module, configured to, in the case that the BGP-intent route further comprises an explicit metric credit segment, for each Source corresponding metric credit information: obtaining the metric credit segment corresponding to the BGP speaker from the BGP-intent route according to the position number of the BGP speaker in the end-to-end path; and subtracting the metric included in the BGP-intent route from the total metric credit to obtain the remaining metric.

[0179] Further, the second metric obtaining module is further configured to, for the all-source calculated metric credit segment and the remaining metric: the metric credit segment reference value of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises the minimum positive value in the all-source calculated metric credit segment and the remaining metric.

[0180] Further, the obtaining module is further configured to, when the BGP speaker finds that there is no transmission path to the downstream BGP speaker that can meet the metric credit segment reference value, select a path in all candidate transmission paths, the cumulative metric of which is closest to the metric credit segment reference value.

[0181] Further, in an embodiment, the transmission path from the BGP speaker to the downstream BGP speaker comprises at least one of: a shortest forwarding path, a traffic engineering path; the transmission path comprises a plurality of sub-paths, through which a load sharing, a fast reroute (FRR) protection, or a multi-flow replication and elimination path is formed, wherein when the multi-flow replication and elimination path is formed through the plurality of sub-paths, the difference between the metrics of the plurality of sub-paths should meet a set limit value.

[0182] Figure 8 is a structural block diagram of the announcing device of the BGP-intent route according to an embodiment of the present application. As shown in ​ , the announcing device of the BGP-intent route comprises:

[0183] an announcing module 802, configured to announce the BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of: a metric type, a metric, and metric credit information.

[0184] By the above scheme, by being used for announcing the BGP-intent route to the neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: the metric type, the metric, the metric credit information, the problem that the content carried in the BGP-intent route in the related art makes the establishment efficiency of the transmission path of the BGP-intent route lower is solved, by carrying the metric type, the metric, the metric credit information in the BGP-intent route, the establishment efficiency of the transmission path is further improved.

[0185] Further, in one embodiment, the metric type includes: an IGP metric, a link latency metric, a link and node latency metric, a TE default metric, and a bandwidth metric; the metric credit information includes: a total metric credit, an estimated BGP hop number, and a metric credit segment; the metric credit information only contains one piece of information and is irrelevant to a specific source; or the metric credit information contains multiple pieces of information and the multiple pieces of information correspond to multiple specific sources one by one.

[0186] Further, it needs to be noted that the metric corresponding to the metric type is the sum of the metric contained in the BGP-intent route announcement received from the downstream neighbor BGP speaker and the cumulative metric corresponding to the metric type of the transmission path from the BGP speaker to the downstream neighbor BGP speaker; or when the BGP speaker is an original announcement node, the metric corresponding to the metric type is a certain initial value set.

[0187] It needs to be noted that the initial value can be 0, but is not limited thereto.

[0188] In one exemplary embodiment, the computer readable storage medium described above can include, but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various computer program storage media.

[0189] The specific examples in the embodiment can refer to the examples described in the above embodiments and exemplary implementation manners, and the embodiment will not be described here again.

[0190] The embodiment of the present application also provides an electronic device including a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0191] Optionally, in the embodiment, the processor can be configured to execute the following steps by the computer program:

[0192] S1, receiving a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

[0193] Optionally, in other embodiments, the processor can also be configured to perform the following steps by computer program:

[0194] S1, announcing a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information.

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

[0196] The specific examples in the embodiments can refer to the examples described in the above embodiments and exemplary embodiments, which will not be repeated here.

[0197] Obviously, those skilled in the art should understand that the modules or steps of the present application described above can be realized by general computing devices, which can be concentrated on a single computing device or distributed on a network composed of multiple computing devices, and they can be realized by program codes executable by computing devices, so that they can be stored in storage devices and executed by computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be manufactured into individual integrated circuit modules, or multiple modules or steps can be manufactured into a single integrated circuit module. Thus, the present application is not limited to any specific combination of hardware and software.

[0198] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for receiving BGP-intent routes, characterized in that, The method comprises: receiving a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information; after receiving the BGP-intent route announced by the BGP speaker, the method further comprises: obtaining an intent identifier from the BGP-intent route, and locally searching for an intent template according to the intent identifier to obtain intent information; establishing or selecting an existing transmission path for the BGP-intent route according to the intent information; establishing or selecting an existing transmission path for the BGP-intent route according to the intent information comprises: determining a metric credit segment reference value of a transmission path between a current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to a metric included in the BGP-intent route, a total metric credit, an estimated BGP hop number, and a metric credit segment included in the BGP-intent route; limiting a cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, to establish or select the existing transmission path. 2.The method of Claim 1, wherein, The method further comprises: the metric type comprises: an IGP metric, a link latency metric, a link and node latency metric, a TE default metric, and a bandwidth metric; the metric credit information comprises: a total metric credit, an estimated BGP hop number, and a metric credit segment; the metric credit information only contains one piece of information and is irrelevant to a specific source, or the metric credit information contains multiple pieces of information and the multiple pieces of information correspond to multiple specific sources one by one. 3.The method of Claim 1, wherein, The method further comprises: in the case that the metric credit information included in the BGP-intent route only contains a total metric credit related to a source but does not contain an explicit metric credit segment, for each source corresponding to a metric credit attribute: divide the total metric credit by the estimated BGP hop number to obtain an average metric credit between adjacent two BGP speakers in an end-to-end path; subtract the metric included in the BGP-intent route from the total metric credit to obtain a remaining metric. 4.The method of Claim 3, wherein, The method further comprises: for the average metric credit and the remaining metric calculated for all sources: a metric credit segment reference value of a transmission path from the BGP speaker to a downstream neighbor BGP speaker comprises: a minimum positive value in the average metric credit and the remaining metric calculated for all sources.

5. The method of Claim 1, wherein, The method further comprises: in the case that the BGP-intent route further contains an explicit metric credit segment, for each source corresponding to metric credit information: obtain a metric credit segment corresponding to the BGP speaker from the BGP-intent route according to a position number of the BGP speaker in an end-to-end path; subtract the metric included in the BGP-intent route from the total metric credit to obtain a remaining metric.

6. The method of receiving BGP-intent routes of claim 5, wherein, The method further comprises: The metric credit segment calculated for all sources and the remaining metric: The metric credit segment reference value of the transmission path from the BGP speaker to the downstream neighbor BGP speaker comprises the minimum positive value in the metric credit segment calculated for all sources and the remaining metric.

7. The method of receiving BGP-intent routes of claim 1, wherein, The method further comprises: When the BGP speaker finds that there is no transmission path to the downstream BGP speaker that can meet the metric credit segment reference value, the BGP speaker selects a path in all candidate transmission paths, wherein the cumulative metric of the path is closest to the metric credit segment reference value.

8. The method of Claim 3-7, wherein, The method further comprises: The transmission path from the BGP speaker to the downstream BGP speaker comprises at least one of the following: a shortest forwarding path, a traffic engineering path; The transmission path comprises a plurality of sub-paths, and the plurality of sub-paths form a path for load sharing, fast reroute (FRR) protection, or multi-flow replication and elimination, wherein when the plurality of sub-paths form a path for multi-flow replication and elimination, the difference between the metrics of the plurality of sub-paths should meet a set limit value. 9.A method for announcing BGP-intent routes, the method comprising: Comprise: Announce a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information, so that after the neighbor BGP speaker receives the BGP-intent route announced by the BGP speaker, the neighbor BGP speaker obtains an intent identifier from the BGP-intent route, and locally looks up an intent template according to the intent identifier to obtain intent information; determines a metric credit segment reference value of a transmission path between the current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to the metric, the total metric credit, the estimated BGP hop count, and the metric credit segment included in the BGP-intent route; limits the cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, to establish or select an existing transmission path. 10.The method of announcing BGP-intent routes of claim 9, wherein, The method further comprises: The metric type comprises: an IGP metric, a link delay metric, a link and node delay metric, a TE default metric, and a bandwidth metric; The metric credit information comprises: a total metric credit, an estimated BGP hop count, and a metric credit segment; The metric credit information only contains one piece of information and is irrelevant to a specific source; or the metric credit information contains multiple pieces of information, and the multiple pieces of information correspond to multiple specific sources one by one. 11.The method of announcing BGP-intent routes of claim 10, wherein, The method further comprises: The metric corresponding to the metric type is the sum of the metric included in the BGP-intent route announced by the downstream neighbor BGP speaker and the cumulative metric of the transmission path from the BGP speaker to the downstream neighbor BGP speaker corresponding to the metric type. Or, when the BGP speaker is an original announcing node, the metric corresponding to the metric type is a certain initial value set.

12. A BGP-intent routing receiving device, characterized in that, Comprising: A receiving module, configured to receive a BGP-intent route announced by a BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information. The receiving module is further configured to acquire an intent identifier from the BGP-intent route, and locally look up an intent template according to the intent identifier to obtain intent information; and establish or select an existing transmission path for the BGP-intent route according to the intent information; wherein the establishing or selecting an existing transmission path for the BGP-intent route according to the intent information comprises: determining a metric credit segment reference value of a transmission path between a current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to a metric, a total metric credit, an estimated BGP hop number, and a metric credit segment included in the BGP-intent route; and limiting a cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, so as to establish or select the existing transmission path.

13. A device for announcing BGP-intent routes, characterized in that, Comprising: An announcing module, configured to announce a BGP-intent route to a neighbor BGP speaker, wherein the BGP-intent route carries at least one of the following: a metric type, a metric, and metric credit information, so that after the neighbor BGP speaker receives the BGP-intent route announced by the BGP speaker, the neighbor BGP speaker acquires an intent identifier from the BGP-intent route, and locally looks up an intent template according to the intent identifier to obtain intent information; and determines a metric credit segment reference value of a transmission path between a current BGP speaker and a downstream neighbor BGP speaker of the current BGP speaker according to a metric, a total metric credit, an estimated BGP hop number, and a metric credit segment included in the BGP-intent route; and limits a cumulative metric of the metric type of the established or selected existing transmission path to be less than or equal to the metric credit segment reference value, so as to establish or select the existing transmission path.

14. A computer readable storage medium, characterized in that, The storage medium has a computer program stored therein, wherein the computer program is configured to execute the method in any one of claims 1 to 8 or the method in any one of claims 9 to 11 when running.

15. An electronic device, comprising: The apparatus comprises a memory and a processor, the memory has a computer program stored therein, and the processor is configured to execute the method in any one of claims 1 to 8 or the method in any one of claims 9 to 11 through the computer program.

Images