Processing method and device of route advertisement message, storage medium and electronic device

Abstract

Embodiments of the present application provide a method and device for processing a route advertisement message, a storage medium and an electronic device. The method comprises obtaining, at a current node, a border gateway protocol (BGP) route advertisement message sent by a previous node, the BGP route advertisement message carrying information of a propagation path, the propagation path being a path in a direction from a network egress node to a network ingress node, the BGP route advertisement message indicating a BGP next hop node in a forwarding direction, the forwarding direction being a direction from the network ingress node to the network egress node; and in a case where the BGP next hop node and the current node are two adjacent nodes on the propagation path, determining an underlying transmission path from the current node to the BGP next hop node according to instruction information corresponding to the current node in the information of the propagation path. Through the embodiments of the present application, the technical problem that the underlying transmission path cannot be flexibly determined in the related art is solved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communications, and more specifically, to a method, apparatus, storage medium, and electronic device for processing routing announcement messages. Background Technology

[0002] With the development and progress of Internet technology, people's demand for network address space is also increasing. Traditional network servers have only one network transmission line per IP address (Internet Protocol), and it is difficult for different types of network transmission lines to communicate with each other. Therefore, people have proposed BGP (Border Gateway Protocol) to improve the shortcomings of Internet communication.

[0003] In related technologies, in large-scale, multi-domain networks, BGP is generally used to provide end-to-end intent-aware paths. Intent-aware paths mean that when BGP routes iterate to the next hop, they select the underlying transport path based on a clear intent. This means that BGP routes need to carry intent information when advertising. Since the underlying transport path is a traffic engineering path established based on a specific intent, in networks providing transport services, the intent can also be referred to as the traffic engineering goal. Currently, there are several methods to enable BGP route advertisements to carry intent information. For example, draft-kaliraj-idr-bgp-classful-transport-planes-13 defines "ClassfulTransport" SAFI NLRI (Classful Transport Sub-Address Family Identifier Network Layer Reachability Information) and "Transport Class" Route Target extended community (Transport Class Route Target Extended Community Attribute) to carry intent information; draft-dskc-bess-bgp-car-03 defines BGP CAR SAFI NLRI (Border Network Protocol Color-Aware Route Sub-Address Family Identifier Network Layer Reachability Information) to carry intent information; and draft-zhou-idr-inter-domain-lcu-04 directly uses Color extended community (Color Extended Community Attribute) to carry intent information. This application collectively refers to BGP routes that carry intent information, such as these, as BGP-intent routes.

[0004] Generally, a node receiving a BGP-intent route advertisement message will interpret the intent locally based on the intent configuration information (also known as the intent-template) to establish or select an existing transmission path to the message advertiser that conforms to the intent. The intent configuration information contains a set of constraints, such as the required link bandwidth in the path, the minimum and maximum latency limits, the latency jitter limits, the packet loss rate limits, including or excluding specific nodes or links, and limiting the path calculation to a specific virtual network, etc. On the Ingress PE node (i.e., the node responsible for service access, or the network entry node), a BGP-intent route matching the service requirements to the Egress PE (i.e., the node responsible for service output, or the network exit node) will be selected according to the service SLA (Service Level Agreement). In other words, the intent configuration information on the Ingress PE node is generally consistent with the service SLA. However, this does not mean that the intent configuration information on intermediate nodes must also be consistent with the service SLA. For example, observing the forwarding behavior of a BGP route across multiple domains, the service SLA must satisfy "provide a path from the Ingress PE (network entry node) to the Egress PE (network exit node) with a maximum latency of 100ms." Clearly, 100ms latency refers to the maximum end-to-end cumulative latency, not the cumulative latency of a specific segment of the path during BGP route forwarding. In other words, BGP speakers (or BGP nodes) in the middle of the path cannot also establish or select an existing transmission path to the next BGP speaker based on a 100ms latency metric. To address this issue, draft-peng-idr-bgp-metric-credit-00 defines a method for carrying the Metric Credit attribute in BGP route advertisements, providing conditions for underlying path iteration between two adjacent BGP speakers. However, this method is only applicable to some simple scenarios, i.e., it is not suitable for more complex scenarios.

[0005] As can be seen, in related technologies, BGP nodes determine the underlying transmission path with the next-hop node based on the locally pre-configured intent configuration information. This makes it difficult to flexibly configure or update the intent configuration information on the BGP node and to flexibly determine the underlying transmission path, thus failing to meet the needs of more complex scenarios. Currently, no effective solution has been proposed. Summary of the Invention

[0006] This invention provides a method, apparatus, storage medium, and electronic device for processing routing announcement messages, to at least solve the technical problem in related technologies where the underlying transmission path cannot be flexibly determined.

[0007] According to an embodiment of the present invention, a method for processing routing advertisement messages is provided, comprising: obtaining a Border Gateway Protocol (BGP) routing advertisement message sent by a previous node on a current node, wherein the BGP routing advertisement message carries information about a propagation path, the propagation path being a path from a network egress node to a network ingress node, and the BGP routing advertisement message indicating a BGP next-hop node in a forwarding direction, the forwarding direction being from the network ingress node to the network egress node; and, if the BGP next-hop node and the current node are two adjacent nodes on the propagation path, determining the underlying transmission path from the current node to the BGP next-hop node based on instruction information corresponding to the current node in the propagation path information.

[0008] According to another embodiment of the present invention, a processing apparatus for routing advertisement messages is provided, comprising: a first acquisition module, configured to acquire a Border Gateway Protocol (BGP) routing advertisement message sent by a previous node at a current node, wherein the BGP routing advertisement message carries information about a propagation path, the propagation path being a path from a network egress node to a network ingress node, and the BGP routing advertisement message indicating a BGP next-hop node in a forwarding direction, the forwarding direction being a direction from the network ingress node to the network egress node; and a first determination module, configured to, when the BGP next-hop node and the current node are two adjacent nodes on the propagation path, determine the underlying transmission path from the current node to the BGP next-hop node based on instruction information corresponding to the current node in the propagation path information.

[0009] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0010] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0011] In this embodiment of the invention, the BGP route advertisement message sent between nodes carries propagation path information. Based on the instruction information in the propagation path information, the underlying transmission path from the current node to the BGP next-hop node is determined. In other words, different BGP route advertisement messages can carry different instruction information, flexibly determining the corresponding underlying transmission path. Using this method, for different services on the same path, different BGP route advertisement messages can be transmitted along the transmission path, carrying different instruction information, such as different transmission delay requirements. Thus, when the same node receives the aforementioned different BGP route advertisement messages, it can choose different underlying transmission paths to meet the requirements of different services. Therefore, this embodiment of the invention, by carrying different instruction information in different BGP route advertisement messages, flexibly determines the corresponding underlying transmission path, avoiding the need for BGP nodes to determine the underlying transmission path with the next-hop node based on pre-configured intent information. This solves the technical problem of inflexible determination of the underlying transmission path in related technologies, achieving the technical effect of flexible determination of the underlying transmission path and meeting the needs of more complex scenarios. Attached Figure Description

[0012] Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of processing routing announcement messages according to an embodiment of the present invention.

[0013] Figure 2 This is a flowchart of a method for processing routing advertisement messages according to an embodiment of the present invention;

[0014] Figure 3 This is a schematic diagram showing the location of information about the propagation path according to an embodiment of the present invention;

[0015] Figure 4 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 1 ;

[0016] Figure 5 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 2 ;

[0017] Figure 6 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 3 ;

[0018] Figure 7 This is a schematic diagram of the propagation path from the network exit node to the network entry node according to an embodiment of the present invention;

[0019] Figure 8This is a schematic diagram of the propagation paths from multiple different network exit nodes to the network entry node according to an embodiment of the present invention;

[0020] Figure 9 This is a schematic diagram of the propagation path from the network exit node to multiple different network entry nodes according to an embodiment of the present invention;

[0021] Figure 10 This is a schematic diagram of the Explicit Propagation Object Path Attribute (i.e., EPO Path Attribute) according to an embodiment of the present invention.

[0022] Figure 11 This is a schematic diagram of transmission paths with different intentions between sources and destinations according to an embodiment of the present invention;

[0023] Figure 12 A schematic diagram illustrating multiple propagation paths to the same Ingress PE carried in a routing advertisement according to an embodiment of the present invention;

[0024] Figure 13 A schematic diagram illustrating multiple propagation paths to different Ingress PEs carried in a routing advertisement according to an embodiment of the present invention;

[0025] Figure 14 This is a structural block diagram of a device for processing routing announcement messages according to an embodiment of the present invention. Detailed Implementation

[0026] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0028] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of processing routing announcement messages according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0029] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the routing announcement message processing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0030] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0031] This embodiment provides a method for collecting information. Figure 2 This is a flowchart of a method for processing routing advertisement messages according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0032] Step S202: Obtain the Border Gateway Protocol (BGP) route advertisement message sent by the previous node on the current node. The BGP route advertisement message carries information about the propagation path, which is the path from the network egress node to the network ingress node. The BGP route advertisement message indicates the BGP next-hop node in the forwarding direction, which is the direction from the network ingress node to the network egress node.

[0033] Step S204: If the BGP next-hop node and the current node are two adjacent nodes on the propagation path, determine the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the propagation path information.

[0034] The entity performing the above steps can be a network device, such as a router or switch, a controller or control system, a device with control capabilities, or other processing devices or units with similar processing capabilities. The following explanation uses a network device performing the above operations as an example (this is merely an illustrative example; in actual operation, other devices or modules can also perform the above operations):

[0035] In the above embodiments, multiple nodes can send Border Gateway Protocol (BGP) route advertisement messages. Based on the priorities of these nodes, the node with the highest priority is determined, and that node is chosen to send the BGP route advertisement message. For example, if the current node is node A, and nodes B, C, and D can all send BGP route advertisement messages to node A, and the priorities of these three nodes are B > C > D, then node B can be chosen to send the BGP route advertisement message to node A according to the priority order B > C > D. Furthermore, when node B fails, node C can be replaced in real-time to send the BGP route advertisement message. The BGP route advertisement message is sent to node A. Furthermore, there can be multiple types of BGP route advertisement messages. Therefore, different BGP route advertisement messages can be sent to node A in the order of node B > node C > node D. Alternatively, different BGP route advertisement messages can be sent to different nodes sequentially. Nodes B, C, and D can also send different BGP route advertisement messages to node A simultaneously, or different BGP route advertisement messages can be sent to different nodes simultaneously, and so on. It should be noted that the above examples illustrating the priority of nodes sending BGP route advertisement messages are only exemplary embodiments, and the priority of nodes sending BGP route advertisement messages is not limited to the examples described above.

[0036] In the above embodiments, the BGP route advertisement message can carry information about multiple propagation paths. These propagation paths can point to the same network ingress node or to different network ingress nodes. Furthermore, the network egress node can determine the corresponding network ingress node based on the propagation path information carried in the BGP route advertisement message and send the BGP route advertisement message to the network ingress node. Then, the network ingress node can determine the BGP next-hop node with which it establishes a lower-level transmission path based on the received BGP route advertisement message. Subsequently, if it is determined that the BGP next-hop node and the network ingress node are two adjacent nodes on the same propagation path, the lower-level transmission path from the network ingress node to the BGP next-hop node is determined according to the instruction information corresponding to the network ingress node in the propagation path information. There can be multiple lower-level transmission paths from the network ingress node to the BGP next-hop node, and the lower-level transmission path determined based on the instruction information is the optimal lower-level transmission path between the network ingress node and the BGP next-hop node. Therefore, different lower-level transmission paths can be determined according to different instruction information.

[0037] In the above embodiments, the BGP route advertisement messages sent between nodes carry propagation path information. Based on the instruction information in the propagation path information, the underlying transmission path from the current node to the BGP next-hop node is determined. In other words, different BGP route advertisement messages can carry different instruction information, flexibly determining the corresponding underlying transmission path. Using this method, for different services on the same path, different BGP route advertisement messages can be transmitted along the transmission path, carrying different instruction information, such as different transmission delay requirements. Thus, when the same node receives the different BGP route advertisement messages, it can choose different underlying transmission paths to meet the requirements of different services. Therefore, through the embodiments of the present invention, by carrying different instruction information in different BGP route advertisement messages, the corresponding underlying transmission path is flexibly determined, avoiding the need for BGP nodes to determine the underlying transmission path with the next-hop node based on pre-configured intent information. This solves the technical problem of inflexible determination of the underlying transmission path in related technologies, achieving the technical effect of flexibly determining the underlying transmission path and meeting the needs of more complex scenarios.

[0038] In an optional embodiment, the propagation path information is located in a newly added path attribute field in the BGP route advertisement message, or in an existing path attribute field in the BGP route advertisement message. In this embodiment, free fields in the BGP route advertisement message can be used to add a new path attribute, and the propagation path information can be added to the newly added path attribute field. The propagation path information can also occupy free bytes in an existing path attribute field in the BGP route advertisement message. Furthermore, the newly added path attribute field and the existing path attribute field can be fields containing the same type of information, or fields containing different types of information. For example, both the newly added path attribute field and the existing path attribute field can contain propagation path information or information similar to propagation paths. Additionally, instruction information can be added to the existing path attribute field, and vice versa. It should be noted that the above examples of newly added path attribute fields and existing path attribute fields are merely exemplary embodiments, and the newly added path attribute fields and existing path attribute fields are not limited to the above examples.

[0039] In the above embodiments, Figure 3 This is a schematic diagram illustrating the location of information about the propagation path according to an embodiment of the present invention, such as... Figure 3 As shown, PA1 and PA3 are existing path attribute fields in the BGP route advertisement message, while PA4 is a newly added path attribute field in the BGP route advertisement message. Figure 3 As shown in (a), the EPO attribute (i.e., information about the propagation path) can be located in the newly added path attribute field, such as... Figure 3 As shown in (b) and (c), the EPO attribute (i.e., the propagation path information) can be located in the free bytes of the existing path attribute field. Therefore, the position of the propagation path information can be adjusted according to the actual application.

[0040] In an optional embodiment, the BGP route advertisement message carries propagation path information including: a node count field, representing the number N of nodes on the propagation path, where N is a positive integer greater than or equal to 1; N node identifier fields, each representing the identifier of a corresponding node on the propagation path; and M instruction fields, each representing instruction information corresponding to a node on the propagation path, where M is a positive integer greater than or equal to 1 and less than or equal to N. In this embodiment, a Count field can be used to represent the node count field, where Count occupies 1 byte in each propagation path and represents the total number of nodes in a propagation path. Furthermore, each propagation path can begin with a Count field followed by one or more tuples.<Flags,Node ID,Length of Instructions,Instructions Content> (A tuple <flag field, node identifier field, instruction length field, instruction field>), where each tuple corresponds to one node. The node identifier field can be represented by a Node ID, and each node has a unique Node ID. For example, when there are two nodes with the same name and value, they can be distinguished by their Node IDs. Furthermore, there are two ways to implement node identifiers: one is a multi-field node identifier, which identifies each node in the propagation path by combining multiple fields; the other is a single-field node identifier, which identifies all nodes in the propagation path by a single field. It should be noted that the above examples of the Node Count field, the Node ID field, and the implementation methods of the node identifiers are only exemplary embodiments, and the implementation methods of the Node Count field, the Node ID field, and the node identifiers are not limited to the above examples.

[0041] In the above embodiments, the Instructions Content can be used to represent the instruction field, which contains one or more specific instructions, and each instruction can be represented by a tuple.<IT,IV> The tuple (<instruction type, instruction value>) represents the instruction type, where IT represents the instruction type and IV represents the instruction value. In addition, a specific IT can implicitly imply the length of the corresponding IV. For example, the IT type can be defined such that when IT=0, the length of the IV field is 0, and when IT=1, it represents MetricCredit, and the IV field is a 3-byte metric credit value. Its unit can be determined by the BGP route's own Metric Type (metric attribute, i.e., AIGP Attribute, Accumulated Interior Gateway Protocol MetricAttribute). For example, when the Metric Type is latency type, the unit of the metric credit value is microseconds (μs), and so on.

[0042] In the above embodiments, Figure 4 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 1 ,like Figure 4 As shown, 1st path represents the first propagation path, nth path represents the nth propagation path, Count (1 octet) indicates that the Count field occupies 1 byte in this propagation path, Node ID (1 octet) indicates that the Node ID field occupies 1 byte in this propagation path, and Instructions Content (2 octet) indicates that the Instructions Content field occupies 2 bytes in this propagation path. In addition, each propagation path starts with a byte count field (Count), and not all propagation path information on all BGP nodes includes an instruction field (InstructionsContent), but each node in each propagation path must have a node identifier (Node ID). Therefore, each propagation path can include N node identifiers and M instruction fields. It should be noted that the number of bytes occupied by the Count field, Node ID field, and Instructions Content field mentioned above is only an exemplary embodiment, and the number of bytes occupied by the Count field, Node ID field, and Instructions Content field is not limited to the example above.

[0043] In an optional embodiment, the BGP route advertisement message carrying propagation path information further includes: N flag fields, each flag field being used to represent the address information of a node corresponding to the propagation path, and to represent whether a node corresponding to the propagation path has the instruction field. In this embodiment, Flags can be used to represent the flag field. Flags occupies 1 byte in each propagation path. In addition, two flags are defined to represent different information. One is A-Flag, which is used to represent the address information of a node on the propagation path. For example, when A-Flag is 0, it represents a 4-byte IPv4 address, and when A-Flag is 1, it represents a 16-byte IPv6 address. The other is I-Flag, which is used to indicate whether a node on the propagation path has an instruction field. For example, when I-Flag is 0, it means that a node on the propagation path does not have an instruction field, and when I-Flag is 1, it means that a node on the propagation path has an instruction field. It should also be noted that when I-Flag is 0, the instruction field included in the subsequent bytes does not exist. It should be noted that the above definition of the Flags field and the examples of the defined A-Flag and I-Flag are only exemplary embodiments, and the definition of the Flags field and the defined A-Flag and I-Flag are not limited to the above examples.

[0044] In the above embodiments, Figure 5 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 2 ,like Figure 5 As shown, Flags represents the flag field. Flags(1 octet) means that the Flags field occupies 1 byte in this propagation path. In addition, Flags also includes the address information of the nodes, and includes the address information of all nodes on this propagation path. Therefore, in the case of BGP route advertisement, the node receiving the BGP route advertisement message can be more accurately determined based on this address information. Thus, each propagation path can include N flag fields.

[0045] In an optional embodiment, the BGP route advertisement message carrying propagation path information further includes: M instruction length fields, each instruction length field representing the number of bytes of a corresponding instruction field among the M instruction fields; wherein, the N flag fields are further used to indicate whether a node on the propagation path has the instruction length field. In this embodiment, the Length of Instructions can be used to represent the instruction length field, which can be located before the instruction fields and is used to represent the number of bytes occupied by each instruction field. In addition, when the above I-Flag is 0, it indicates that a node on the propagation path does not have an instruction length field; when the above I-Flag is 1, it indicates that a node on the propagation path has an instruction length field. It should also be noted that when I-Flag is 0, the instruction length field included in the subsequent bytes does not exist.

[0046] In the above embodiments, Figure 6 This is a schematic diagram of the attributes of the propagation path information according to an embodiment of the present invention. Figure 3 ,like Figure 6 As shown, Length of Instruction (1 byte) indicates that the Length of Instruction field occupies 1 byte in this propagation path, and Instruction Content (variable) indicates that the number of bytes occupied by the Instruction Content field in this propagation path is variable, and the number of bytes occupied by the Instruction Content field in the propagation path can be determined by the Length of Instruction field. In addition, like the instruction field, this instruction length field is not included in the propagation path information on all BGP nodes on a complete propagation path. Therefore, each propagation path can include M instruction length fields.

[0047] In an optional embodiment, the propagation path includes one or more paths in the direction from the network egress node to the network ingress node, wherein each path is a path from the network egress node to the network ingress node, or a partial path from the network egress node to the network ingress node. In this embodiment, there can be multiple propagation paths for transmitting BGP route advertisement messages, and these multiple propagation paths can point to the same network ingress node or to different network ingress nodes. For example, when the propagation paths are BACDEF and BAGDEF, and these two propagation paths point to the same network ingress node, and it is necessary for node B (i.e., the network egress node) to send the BGP route advertisement message to node F (i.e., the network ingress node), these two propagation paths are both complete propagation paths in the direction from the network egress node to the network ingress node, and BAC(G)-D in these two propagation paths is a partial path from the network egress node to the network ingress node. When the propagation paths are BACDEF and BACDEG, which are two propagation paths pointing to different network entry nodes, and when node B (i.e., the network exit node) needs to send the BGP route advertisement message to node F (or G, i.e., the network entry node), both propagation paths are two complete propagation paths from the network exit node to the network entry node. CDEF(G) is a partial path from the network exit node to the network entry node. It should be noted that the above example of propagation paths is only an exemplary embodiment, and the propagation paths are not limited to the above example.

[0048] In the above embodiments, Figure 7 This is a schematic diagram of the propagation path from the network egress node to the network ingress node according to an embodiment of the present invention, as shown below. Figure 7 As shown, PE1 represents the network egress node, PE2 represents the network ingress node, P1 and P2 represent the different nodes traversed from the network egress node to the network ingress node, and TE path-1 and TE path-2 represent the different underlying transmission paths iterating from PE2 to PE1.

[0049] In an optional embodiment, when the network egress node includes multiple different egress nodes, the propagation path includes multiple paths in the direction from the multiple different egress nodes toward the network ingress node, wherein each path is a path from a corresponding egress node to the network ingress node, or a portion of the path from a corresponding egress node to the network ingress node. In this embodiment, multiple different egress nodes can send BGP route advertisement messages. These multiple different egress nodes can send the same BGP route advertisement message or send different BGP route advertisement messages. In practical applications, when the propagation paths are ADFG, BDFG, and CDFG, the network egress nodes include egress node A, egress node B, and egress node C. ADFG, BDFG, and CDFG are three complete paths from the corresponding egress nodes A, B, and C to the network ingress node. AD, BD, and CD are partial paths from the three complete paths from the corresponding egress nodes A, B, and C to the network ingress node. Furthermore, the egress nodes included in the partial paths may not be egress nodes from the above three complete propagation paths (i.e., they may be partial paths composed of other egress nodes that can send BGP route advertisement messages to the network ingress node).

[0050] In the above embodiments, Figure 8 This is a schematic diagram of the propagation paths from multiple different network egress nodes to the network ingress node according to an embodiment of the present invention, such as... Figure 8 As shown, PE1 and PE2 represent network egress nodes, PE3 represents network ingress nodes, P1, P2, P3 and P4 represent different nodes traversed from the network egress node to the network ingress node, TE path-3 and TE path-4 represent different underlying transmission paths from PE3 to PE1, and TE path-5 and TE path-6 represent different underlying transmission paths from PE3 to PE2.

[0051] In an optional embodiment, when the network entry node includes multiple different entry nodes, the propagation path includes multiple paths in the direction from the network exit node to the multiple different entry nodes, wherein each path is a path from the network exit node to a corresponding entry node, or a part of the path from the network exit node to a corresponding entry node. In this embodiment, multiple different ingress nodes can receive BGP route advertisement messages. These multiple different ingress nodes can receive the same BGP route advertisement message or different BGP route advertisement messages. In practical applications, when the propagation paths are ABCD, ABCE, and ABCF, the network ingress nodes include ingress node D, ingress node E, and ingress node F. ABCD, ABCE, and ABCF are three complete paths from the network egress node A to the corresponding ingress nodes D, E, and F, respectively. CD, CE, and CF are partial paths from the three complete paths from the network egress node to the corresponding ingress nodes D, E, and F, respectively. Furthermore, the ingress nodes included in the partial paths may not be ingress nodes of the above three complete propagation paths (i.e., they may be partial paths composed of other ingress nodes that can receive BGP route advertisement messages sent by the network egress node).

[0052] In the above embodiments, Figure 9 This is a schematic diagram of the propagation path from the network exit node to multiple different network entry nodes according to an embodiment of the present invention, such as... Figure 9 As shown, PE3 represents the network egress node, PE1 and PE2 represent the network ingress nodes, P1, P2, P3 and P4 represent different nodes traversed from the network egress node to the network ingress node, TE path-7 and TE path-8 represent different underlying transmission paths iterating from PE1 to PE3, and TE path-9 and TE path-10 represent different underlying transmission paths iterating from PE2 to PE3.

[0053] In an optional embodiment, after obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: if the current node is among the multiple nodes in the propagation path, determining the next node of the current node in the propagation path from the information of the propagation path; and sending the BGP route advertisement message to the next node from the current node. In this embodiment, a propagation path can be pre-defined in a newly added path attribute field in the BGP route advertisement message or in an existing path attribute field in the BGP route advertisement message. Then, when performing BGP route advertisement and determining that the current node belongs to a node in the propagation path, the next node of the current node in the propagation path is determined from the information of the propagation path carried in the BGP route advertisement message, and the current node sends the BGP route advertisement message to the next node, and controls the next node to continue performing BGP route advertisement.

[0054] In an optional embodiment, sending the BGP route advertisement message from the current node to the next node includes: if a BGP session is configured between the current node and the next node, and the address clusters related to the BGP route advertisement message are enabled, then sending the BGP route advertisement message from the current node to the next node. In this embodiment, configuring a BGP session authorizes the current node and the next node to send and receive information, thereby making the information transmission between the current node and the next node smoother and more secure. Enabling the address clusters related to the BGP route advertisement message allows for more accurate identification of the nodes that need to perform BGP route advertisements and BGP route forwarding.

[0055] In an optional embodiment, after obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: if the current node is one of the multiple nodes in the propagation path; determining the next node of the current node in the propagation path from the information of the propagation path; and if no BGP session is configured between the current node and the next node, but the BGP route advertisement message is pre-configured to be transparently transmitted through a route reflector, sending the BGP route advertisement message to the route reflector on the current node. In this embodiment, the BGP route advertisement message can be transparently transmitted to the next node on the propagation path through a pre-configured route reflector. For example, when the propagation path is ENABH, and a BGP route advertisement message needs to be sent to node H, where the current node is node A, and the next node adjacent to the current node is node B, the current node A determines that it needs to send the BGP route advertisement message to node B based on the propagation path information carried in the BGP route advertisement message. However, node B and node A do not have a session established, but communicate through a reflector R. In this case, the BGP route advertisement message is sent from node A to node R.

[0056] In an optional embodiment, sending the BGP route advertisement message from the current node to the next node includes: modifying the BGP next-hop node in the forwarding direction indicated in the BGP route advertisement message to the current node, thereby obtaining an updated BGP route advertisement message; and sending the updated BGP route advertisement message from the current node to the next node. In this embodiment, the current node sends the updated BGP route advertisement message to the next node adjacent to the current node. The next node can determine, based on the BGP next-hop node in the updated BGP route advertisement message, that it needs to establish a lower-level transmission path in the forwarding direction with the current node as its destination, and, based on the service requirements between the next node and the current node determined in the BGP route advertisement message, establish a lower-level transmission path that meets the service requirements or the optimal lower-level transmission path.

[0057] In an optional embodiment, when the BGP next-hop node in the forwarding direction indicated in the BGP route advertisement message is modified to the current node, the method further includes: generating a BGP intent routing table entry on the current node, wherein the BGP intent routing table entry includes information representing the underlying transmission path, and the information representing the underlying transmission path includes at least one of the following: transmission delay of the underlying transmission path, bandwidth information of the underlying transmission path. In this embodiment, in addition to the aforementioned transmission delay and bandwidth information of the underlying transmission path, the information of the underlying transmission path also includes metric credit information of the underlying transmission path, affinity information of the underlying transmission path, etc.

[0058] In an optional embodiment, before obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: obtaining intent information of the service that needs to communicate between the network ingress node and the network egress node, wherein the service that needs to communicate corresponds to the propagation path, and the intent information represents the total metric from one end node to the other end node of the propagation path; configuring the information of the propagation path according to the intent information, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the propagation path information is equal to the total metric, and the metric includes at least one of the following: latency metric, traffic engineering metric, and interior gateway protocol metric. In this embodiment, when the intent of the service that needs to communicate between the network ingress node and the network egress node is that the total latency from one end node to the other end node of the propagation path cannot exceed 100ms, the corresponding latency can be configured for the nodes included in the propagation path based on the intent information. The sum of the latency of all nodes included in the propagation path must be equal to 100ms. The total end-to-end latency of 100ms can be evenly distributed to each node of the propagation path, or it can be unevenly distributed (i.e., the corresponding latency is determined according to the actual needs between every two nodes). In addition, the metrics include not only the latency metrics, traffic engineering metrics, and internal gateway protocol metrics mentioned above, but also bandwidth metrics, throughput metrics, etc.

[0059] In an optional embodiment, obtaining the intent information of the services that need to communicate between the network ingress node and the network egress node includes: if the services that need to communicate include P services, obtaining P intent information of the P services, where P is 1, or is a positive integer greater than or equal to 2, and each intent information represents the total metric from one end node to the other end node of a corresponding propagation path; configuring the propagation path information according to the intent information includes: configuring the information of P propagation paths according to the P intent information, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the information of each complete propagation path is equal to the total metric represented by the corresponding intent information. In this embodiment, there can be multiple services that need to communicate between the network ingress node and the network egress node. Therefore, multiple propagation paths can be configured based on the intent information of these services. In other words, the propagation path information can be predetermined. BGP route announcements are then made based on this predetermined information. In practical applications, when there are two types of services that need to communicate between the network ingress node and the network egress node, where one type of service's intent is that the total latency from one end of the propagation path to the other end cannot exceed 10ms, and the other type of service's intent is that the total latency from one end of the propagation path to the other end cannot exceed 100ms, two different propagation paths can be configured based on these two latency intents, and so on.

[0060] In an optional embodiment, after configuring the information of P propagation paths based on the P intent information, the method further includes: carrying the information of the P propagation paths in the BGP route advertisement message. In this embodiment, there may be several, dozens, or hundreds of services that need to communicate between the network ingress node and the network egress node, and the BGP route advertisement message carries information of several, dozens, or hundreds of propagation paths.

[0061] In an optional embodiment, the instruction information includes at least one of the following: transmission latency requirement information, bandwidth requirement information, and path affinity requirement information. In this embodiment, the instruction information also includes interior gateway protocol requirement information, metric credit requirement information, etc.

[0062] In an optional embodiment, when the instruction information includes transmission delay requirement information, the transmission delay of the underlying transmission path is less than or equal to the transmission delay indicated by the transmission delay requirement information. In this embodiment, when the intent of the service requiring communication between the network ingress node and the network egress node is that the total delay from one end node to the other end node of the propagation path used cannot exceed 90ms, and the propagation path is ABCD, the current node B needs to send a BGP route advertisement message to node C, and then node C needs to send a BGP route advertisement message to node D. The delay requirement in the instruction information sent by node B to node C is no more than 30ms, that is, the delay of the underlying transmission path between node C and node B must be less than or equal to 30ms. In other words, a 25ms transmission delay underlying transmission path or a 20ms transmission delay underlying transmission path can be established between node C and node B, and so on.

[0063] Obviously, the embodiments described above are only some embodiments of the present invention, and not all embodiments.

[0064] The present invention will be described in detail below with reference to specific embodiments:

[0065] Step 1: Protocol Extension

[0066] Explicit path control information is introduced into the BGP route advertisement message, which contains one or more lists representing propagation paths. Each list includes multiple ordered BGP speakers, and each BGP speaker element in the list further contains related instructions to guide the BGP route advertisement message to each of these BGP speakers in the list one by one along the expected propagation path, and to further update the state of the BGP route according to the corresponding instruction information.

[0067] One specific way to extend this is as follows:

[0068] RFC4271 defines BGP Path Attributes, which are carried with BGP route advertisements and represent various attributes of the route. Figure 10This is a schematic diagram of the Explicit Propagation Object PathAttribute (i.e., EPO Path Attribute) according to an embodiment of the present invention. This application introduces a new Explicit Propagation Object (EPO) attribute into the BGP protocol, which contains one or more propagation paths. The Type Code of the corresponding Path Attribute is TBD (i.e., To Be Defined, undefined, pending IANA (The Internet Assigned Numbers Authority) assignment), indicating that the attribute value contains the following: Figure 10 The format of the EPO attribute.

[0069] Figure 10 The diagram illustrates multiple propagation paths, each starting with a `count` field followed by one or more tuples.<Flags,Node ID,Length of Instructions,Instructions Content> Each tuple corresponds to one BGP Speaker.

[0070] The fields are explained below:

[0071] Count: Occupies 1 byte, representing the number of BGP Speakers in a propagation path; its value is at least 1. Flags: Occupies 1 byte, flag bits. Currently, two flags are defined: A-Flag, Address Family Flag, indicating the address family type of the Node ID in this tuple. When A-Flag is 0, it represents a 4-byte IPv4 address; when it is 1, it represents a 16-byte IPv6 address. I-Flag, Instruction Flag, indicating whether this tuple contains Instructions information; 0 indicates no information, 1 indicates yes. Note that if I-Flag is 0, the subsequent LengthofInstructions field and Instructions Content will not exist. Node ID: Represents the node identification information of the BGP Speaker. Its size is determined by the A-Flag preceding this field. When A-Flag is 0, the Node ID is a 4-byte IPv4 address; when A-Flag is 1, the Node ID is a 16-byte IPv6 address. Length of Instructions, occupying 1 byte, indicates the number of bytes in the Instructions content contained within this tuple. Instructions Content contains the specific instructions; its size in bytes is determined by the Length of Instructions preceding this field. This field can contain one or more instructions, each represented by a tuple.<IT,IV> This indicates that IT represents the instruction type and IV represents the instruction value. Note that a specific IT implies the length of the corresponding IV.

[0072] This application may define the following IT types:

[0073] IT=0: Reserved value, in which case the IV field length is 0.8. IT=1: Indicates Metric Credit, in which case the IV field is a 3-byte metric credit value, the unit of which depends on the BGP route's own Metric Type (i.e., AIGP Attribute). For example, if the Metric Type is latency, then the unit is microseconds (µs). Other values: Not defined in this application embodiment.

[0074] As can be seen from the foregoing, the above extension methods are only the optimal methods suggested in this application. In practical applications, other extension methods can also be adopted, such as extending the information to support EPO or similar EPO in other defined BGP path attributes (or BGP path properties).

[0075] It should also be noted that the propagation path included in the EPO attribute refers to the path from the network egress to the network ingress. It reflects the forward path of the control plane route advertisement, which is exactly the opposite of the direction of the BGP forwarding path formed by the data plane. The EPO attribute can contain one or more propagation paths, which can point to the same network ingress node or to different network ingress nodes. Some propagation paths included in the EPO attribute can be complete, meaning that the first node in the propagation path is the network egress node and the last node is the network ingress node, while some propagation paths can be any part of a complete propagation path. The EPO attribute can also contain only incomplete propagation paths. The propagation path included in the EPO attribute only provides a reference for BGP route advertising. However, the final generated BGP forwarding path still follows the BGP route selection rules. That is, the generated BGP forwarding path is not necessarily equal to the reverse propagation path (assuming a complete propagation path). For example, when the egress PE node E (network egress node) generates a BGP route locally and wants to advertise it to the ingress PE node I (network ingress node) along the desired single propagation path EDCBAI, the EPO can contain the single propagation path EDCBAI. This means that node E will advertise the BGP route to node D, node D will learn the route and then advertise it to node C, node C will learn the route and then advertise it to node B, and so on, until node I learns the route. In addition, the following multiple coexisting propagation paths in the EPO attribute included in the BGP route advertisement generated by node E are all valid:

[0076] Propagation path 1: EDCBA-I1, a complete propagation path pointing to Ingress PE node I1 (network entry node).

[0077] Propagation path 2: EQPO-I2, a complete propagation path pointing to Ingress PE node I2 (network entry node).

[0078] Propagation path 3: ETSR-I3, a complete propagation path pointing to Ingress PE node I3 (network entry node).

[0079] Propagation path 4: D-C2-B, a small segment of a complete propagation path.

[0080] Propagation path 5: Q-P2-O, a segment of a complete propagation path.

[0081] Propagation path 6: T-S2-R, a segment of a complete propagation path.

[0082] Propagation path 7: ZYX, a segment of a complete propagation path.

[0083] Step Two: Handling Behavior

[0084] When a BGP speaker receives a route advertisement from a neighbor that contains the EPO attribute, it will read all propagation paths from the EPO and then implement enhanced actions for the following processing behaviors:

[0085] a) Handling the next hop iteration

[0086] Compared to traditional next-hop iteration behavior, this application adds guidance on how to implement next-hop iteration based on instructions contained in the EPO. Specifically, in all propagation paths contained in the EPO, it checks whether the Node ID of the BGP Next-hop (or BGP next-hop address) in the route advertisement appears consecutively with the Node ID of the current BGP Speaker. If so, it retrieves the instructions associated with the Node ID of the current BGP Speaker from the propagation path and uses the information contained in the instructions for next-hop iteration. For example, when the current BGP Speaker is node A (network ingress node), the BGP Next-hop in the received route advertisement is node N (network egress node), and a certain propagation path contained in the EPO is E-...-NAB-...-H, since N and A appear consecutively in this propagation path, the current BGP Speaker (i.e., node A) will retrieve the instructions associated with node A from the propagation path. For example, the instructions may contain information of type Metric Credit.<IT,IV> When node A performs the next-hop iteration for the route, it will iterate to find a lower-level forwarding path to the next-hop node N that meets the requirements of the Metric Credit value, based on the corresponding Metric Credit value.

[0087] b) Processing of continuing to advertise the route to upstream neighbors

[0088] Compared to the traditional behavior of continuing to advertise routes to upstream neighbors (the traditional behavior mainly depends on which neighbors the BGPSpeaker has configured BGP sessions (or BG connections) with and enabled the required address families, or combines certain local policies to decide whether to continue advertising routes to which neighbors), this application embodiment further adds the ability to control which upstream neighbors to continue advertising routes based on the propagation path contained in the EPO. Specifically, within all propagation paths included in the EPO, the Node ID of the current BGP Speaker is checked. If it appears, the next adjacent node is obtained from that propagation path, and the route continues to be advertised to that next node. This is contingent on a BGP session being configured between the current node and the next node, and the required address families being enabled. However, this condition check does not apply to scenarios where the neighbor is a reflector. For example, if the current BGP Speaker is node A (network egress node), and the BGPNext-hop in the received route advertisement is node N (network ingress node), and a propagation path in the EPO is E-...-NAB-...-H, since A appears in this propagation path, the next adjacent node is obtained as B (network ingress node), and the route continues to be advertised to node B. Assuming another propagation path segment AC-...-D is also included, the next adjacent node will also be obtained as C (network ingress node), and the route will continue to be advertised to node C.

[0089] Example 1: A single propagation path is carried in the route advertisement.

[0090] Figure 11 This is a schematic diagram of transmission paths with different intentions between sources and destinations according to an embodiment of the present invention, such as... Figure 11 The network shown contains two IGP domains (Interior Gateway Protocols domains). BGP neighbors are established between PE1 and ABR, and between ABR and PE2, to advertise BGP-intent routes. For example, following the method described in draft-zhou-idr-inter-domain-lcu-04, Egress PE2 (the network egress node) advertises its loopback route (i.e., the local loopback route, denoted as loopback-PE2) to ABR (the network ingress node) via BGP. The route advertisement carries the Color extended community to carry intent information.

[0091] In this example, suppose there are two types of services that need to communicate between Ingress PE1 and Egress PE2. One type of service intends for the total end-to-end latency of the transmission path used to not exceed 10ms, and the other type of service intends for the total end-to-end latency of the transmission path used to not exceed 100ms. Since it is necessary to represent two intent-related paths between the same source / destination, in this embodiment, two colors (indicators) need to be configured on Egress PE2, denoted as color-1000 and color-2000.

[0092] The intent configuration corresponding to Color-1000 is as follows:

[0093] metric-type: Unidirectional Link Delay (unit: milliseconds)

[0094] total-metric: 10

[0095] The intent configuration for Color-2000 is as follows:

[0096] metric-type: Unidirectional Link Delay (unit: ms)

[0097] total-metric: 100

[0098] The intent configuration information corresponding to the two colors mentioned above is also uniformly configured on other BGP Speaker nodes (e.g., ABR (Area Border Router), Ingress PE1). It should also be noted that after receiving a BGP-intent route advertisement from a downstream BGP Speaker neighbor, these other BGP Speakers do not simply calculate the transmission path to the downstream BGP Speaker neighbor based on the total-metric contained in the intent configuration information. Instead, they obtain the metric credit information from the received BGP-intent route advertisement and establish or use an existing transmission path that satisfies the intent accordingly.

[0099] 1) Egress PE2 generates BGP-intent routes and advertises them to upstream neighbors.

[0100] On Egress PE2, two corresponding BGP-intent routes are generated, <prefix (prefix)=loopback-PE2, color=1000> and <prefix=loopback-PE2, color=2000>. The expected propagation paths of both routes are PE2 (network egress node) - ABR - PE1 (network ingress node).

[0101] In the advertisement of the BGP-intent route <prefix=loopback-PE2, color=1000>, the following attribute information can be included (where EPO is included):

[0102] Set metric-type to Unidirectional Link Delay;

[0103] Set the initial metric to 0;

[0104] Set the EPO information to:

[0105] Count: 3 (Note: The first propagation path contains 3 nodes);

[0106] Flags: A-Flag = 0, I-Flag = 0 (Note: The first Node ID is an IPv4 address and there are no associated Instructions);

[0107] Node ID: PE2;

[0108] Flags: A-Flag = 0, I-Flag = 1 (Note: The second Node ID is an IPv4 address and there are associated Instructions);

[0109] Node ID: ABR;

[0110] Instructions Content: <IT = Metric Credit, IV = 5000us>;

[0111] Flags: A-Flag = 0, I-Flag = 1 (Note: The third Node ID is an IPv4 address and there are associated Instructions);

[0112] Node ID: PE1;

[0113] Instructions Content: <IT = Metric Credit, IV = 5000us>.

[0114] That is, the entire end-to-end latency of 10ms is evenly distributed across the segments of the path. Of course, other values ​​can also be explicitly specified.

[0115] Similarly, in BGP-intent routing<prefix=loopback-PE2,color=2000> The notification may include the following attribute information (including EPO):

[0116] Set metric-type to Unidirectional Link Delay;

[0117] Set the initial metric to 0;

[0118] Set the EPO information as follows:

[0119] Count: 3 (Note: The first propagation path contains 3 nodes);

[0120] Flags: A-Flag = 0, I-Flag = 0 (Note: The first Node ID is the IPv4 address, with no associated instructions);

[0121] Node ID: PE2;

[0122] Flags: A-Flag = 0, I-Flag = 1 (Note: The second Node ID is the IPv4 address, which is associated with the instructions);

[0123] Node ID: ABR;

[0124] Instructions Content:<IT=Metric Credit,IV=50000us> ;

[0125] Flags: A-Flag = 0, I-Flag = 1 (Note: The third Node ID is the IPv4 address, which is associated with the instructions);

[0126] Node ID: PE1;

[0127] Instructions Content:<IT=Metric Credit,IV=50000us> .

[0128] Both of the above intended routes will be advertised to the next node ABR as instructed by the EPO.

[0129] 2) Upon receiving the BGP-intent route, the ABR establishes a low-level transport path to the BGP Next-hop that satisfies the intent.

[0130] ABR (Network Ingress Node) receives BGP-intent route<prefix=loopback-PE2,color=1000> At this time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGPNext-hop is Egress PE2 (network egress node). Based on the EPO information contained in the received routing advertisement, the ABR determines that the metric credit from this BGP Speaker (i.e., ABR) to its downstream BGP Speaker neighbor (i.e., Egress PE2) is 5ms. Then, the ABR node internally calls the CSPF (Constraint Shortest Path First) calculation module to calculate an extremely low-latency path to Egress PE2 with a latency not exceeding 5ms. Let's assume this is... Figure 11 The TE path-12 in the ABR has a latency of 4ms, therefore, the BGP-intent routing table entry generated on the ABR...<prefix=loopback-PE2,color=1000> The underlying transmission path for iterating to the BGP Next-hop is TE path-12, and the metric in the routing table entry is set to 4 accordingly. The ABR continues to advertise the BGP-intent route to the next node PE1 according to the propagation path indication in the EPO, where the metric-type is Unidirectional Link Delay, the metric is 4, the BGP Next-hop is modified to ABR, and the EPO information remains unchanged from the EPO information in the previously received route advertisement.

[0131] Similarly, the ABR (Network Ingress Node) receives a BGP-intent route.<prefix=loopback-PE2,color=2000> At this time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional LinkDelay and the BGP Next-hop is Egress PE2 (network egress node). Based on the EPO information contained in the received routing advertisement, the ABR determines that the metric credit from its BGP Speaker (i.e., ABR) to its downstream BGP Speaker neighbor (i.e., Egress PE2) is 50ms. The ABR node then internally calls 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 11The 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 transmission 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 next node PE1 according to the propagation path indication in the EPO, where the metric-type is Unidirectional Link Delay, the metric is 40, the BGP Next-hop is modified to ABR, and the EPO information remains unchanged from the EPO information in the previously received route advertisement.

[0132] 3) Ingress PE1 receives the BGP-intent route and establishes a low-level transport path to the BGP Next-hop that satisfies the intent. Ingress PE1 (network ingress node) receives the BGP-intent route.<prefix=loopback-PE2,color=1000> At this time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional LinkDelay and the BGP Next-hop is ABR (network egress node). Based on the EPO information contained in the received route advertisement, Ingress PE1 determines that the metric credit from this BGP Speaker (i.e., Ingress PE1) to its downstream BGP Speaker neighbor (i.e., ABR) is 5ms. Then, the Ingress PE1 node internally calls the CSPF calculation module to calculate an extremely low-latency path to the ABR with a latency of no more than 5ms. Let's assume it's... Figure 11 The TE path-11 in the Ingress has a latency of 4ms. Therefore, the BGP-intent routing table entry generated on Ingress PE1...<prefix=loopback-PE2,color=1000> The underlying transport path for iterating to BGP Next-hop is TE path-11, and the metric in the routing table entry is set to 8 (=4+4) accordingly.

[0133] Similarly, Ingress PE1 (the network ingress node) receives a BGP-intent route.<prefix=loopback-PE2,color=2000> At this time, a corresponding routing table entry is generated locally, where the metric-type is UnidirectionalLink Delay and the BGP Next-hop is ABR (Network Egress Node). Based on the EPO information contained in the received route advertisement, Ingress PE1 determines that the metric credit from its BGP Speaker (i.e., Ingress PE1) to its downstream BGP Speaker neighbor (i.e., ABR) is 50ms. Then, Ingress PE1 will internally call the CSPF calculation module to calculate a low-latency path to the ABR with a latency not exceeding 50ms. Let's assume it's... Figure 11 The TE path-21 in the Ingress has a latency of 40ms. Therefore, the BGP-intent routing table entry generated on Ingress PE1...<prefix=loopback-PE2,color=2000> The underlying transport path for iterating to BGP Next-hop is TE path-21, and the metric in the routing table entry is set to 80 (=40+40) accordingly.

[0134] As can be seen from the foregoing, in this embodiment, by using the EPO information contained in the routing announcement, differentiated transmission paths can be established on each BGP speaker with a basis, effectively avoiding the situation where everyone competes for high-quality, ultra-low latency link resources.

[0135] Example 2: The route advertisement carries multiple propagation paths to the same Ingress PE.

[0136] Figure 12 A schematic diagram illustrating multiple propagation paths to the same Ingress PE carried in the routing advertisement according to an embodiment of the present invention, as shown below. Figure 12The network shown contains three ASs (autonomous systems). BGP neighbors are established between PE1 and ASBR1 (Autonomous System Boundary Router), ASBR1 and ASBR2, ASBR1 and ASBR3, ASBR2 and PE2, and ASBR3 and PE3. BGP-intent routes are advertised. For example, following the method described in draft-zhou-idr-inter-domain-lcu-04, Egress PE2 (network egress node) advertises its loopback route (denoted as loopback-PE2) to ASBR2 (network ingress node) via BGP. The route advertisement carries the Color extended community to carry intent information.

[0137] In this example, suppose the intent of the service requiring communication between Ingress PE1 and Egress PE2 is that the total end-to-end latency of the transmission path used cannot exceed 100ms. Assume the color configured for this intent on Egress PE2 is color-1000.

[0138] The intent configuration corresponding to Color-1000 is as follows:

[0139] metric-type: Unidirectional Link Delay (unit: ms)

[0140] total-metric: 100

[0141] The intent configuration information corresponding to the aforementioned colors is also uniformly configured on other BGP Speaker nodes (e.g., ASBR1 / 2 / 3, PE1). It should also be noted that after receiving BGP-intent route advertisements from downstream BGP Speaker neighbors, these other BGP Speakers do not simply calculate the transmission path to the downstream BGP Speaker neighbors based solely on the total-metric contained in the intent configuration information. Instead, they obtain the metric credit information from the received BGP-intent route advertisements and establish or use existing transmission paths that satisfy the intent accordingly.

[0142] 1) Egress PE2 generates BGP-intent routes and advertises them to upstream neighbors.

[0143] On Egress PE2, a corresponding BGP-intent route is generated.<prefix=loopback-PE2,color=1000> The expected propagation path of this route is PE2 (network egress node)-ASBR2-ASBR1-PE1 (network ingress node) and ASBR2 (network egress node)-ASBR3-ASBR1 (network ingress node).

[0144] In BGP-intent routing<prefix=loopback-PE2,color=1000> The notification may include the following attribute information (including EPO):

[0145] Set metric-type to Unidirectional Link Delay;

[0146] Set the initial metric to 0;

[0147] Set the EPO information as follows:

[0148] Count: 4 (Note: The first propagation path contains 4 nodes);

[0149] Flags: A-Flag = 0, I-Flag = 0 (Note: The first Node ID is the IPv4 address, with no associated instructions);

[0150] Node ID: PE2;

[0151] Flags: A-Flag = 0, I-Flag = 1 (Note: The second Node ID is the IPv4 address, which is associated with the instructions);

[0152] Node ID: ASBR2;

[0153] Instructions Content:<IT=Metric Credit,IV=40000us> ;

[0154] Flags: A-Flag = 0, I-Flag = 1 (Note: The third Node ID is the IPv4 address, which is associated with the instructions);

[0155] Node ID: ASBR1;

[0156] Instructions Content:<IT=Metric Credit,IV=20000us>

[0157] Flags: A-Flag = 0, I-Flag = 1 (Note: The fourth Node ID is the IPv4 address, which is associated with the instructions);

[0158] Node ID: PE1;

[0159] Instructions Content:<IT=Metric Credit,IV=40000us> ;

[0160] Count: 3 (Note: The second propagation path contains 3 nodes);

[0161] Flags: A-Flag = 0, I-Flag = 0 (Note: The first Node ID is the IPv4 address, with no associated instructions);

[0162] Node ID: ASBR2;

[0163] Flags: A-Flag = 0, I-Flag = 1 (Note: The second Node ID is the IPv4 address, which is associated with the instructions);

[0164] Node ID: ASBR3;

[0165] Instructions Content:<IT=Metric Credit,IV=10000us> ;

[0166] Flags: A-Flag = 0, I-Flag = 1 (Note: The third Node ID is the IPv4 address, which is associated with the instructions);

[0167] Node ID: ASBR1;

[0168] Instructions Content:<IT=Metric Credit,IV=10000us> ;

[0169] That is, on the first propagation path PE2-ASBR2-ASBR1-PE1, the metric credit is specified as 40, 20, 40ms for each segment, and on the second propagation path ASBR2-ASBR3-ASBR1, the metric credit is specified as 10, 10ms for each segment. Then, the above intended route is advertised to the next node ASBR2 according to the EPO's instructions.

[0170] 2) ASBR2 receives the BGP-intent route and establishes a low-level transport path to the BGP Next-hop that satisfies the intent.

[0171] ASBR2 received a BGP-intent route.<prefix=loopback-PE2,color=1000> At this time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is Egress PE2. Based on the EPO information contained in the received route advertisement, ASBR2 determines that the metric credit from this BGP Speaker (ASBR2) to its downstream BGP Speaker neighbor (Egress PE2) is 40ms. Then, the ASBR2 node internally calls the CSPF (Constraint Shortest Path First) calculation module to calculate a low-latency path to Egress PE2 with a latency not exceeding 40ms. Let's assume this is... Figure 12 TE path-13 in the image has a latency of 40ms; therefore, the BGP-intent routing table entry generated on ASBR2...<prefix=loopback-PE2,color=1000> The underlying transmission path for iterating to the BGP Next-hop is TE path-13, and the metric in the routing table entry is set to 40 accordingly. ASBR2 continues to advertise BGP-intent routes to the next nodes ASBR1 and ASBR3 according to the propagation path indication in the EPO. Here, the metric-type is Unidirectional Link Delay, the metric is 40, the BGP Next-hop is modified to ASBR2, and the EPO information (which remains unchanged from the EPO information in the previously received route advertisement) is also included.

[0172] 3) ASBR1 / 3 receives the BGP-intent route and establishes a low-level transport path to the BGP Next-hop that satisfies the intent.

[0173] ASBR1 receives a BGP-intent route from ASBR2<prefix=loopback-PE2,color=1000> At that time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is ASBR2. Based on the EPO information contained in the received route advertisement, ASBR1 determines that the metric credit from its current BGP speaker (ASBR1) to its downstream BGP speaker neighbor (ASBR2) is 20ms. Then, ASBR1 will internally call the CSPF (Constraint Shortest Path First) calculation module to calculate a low-latency path to ASBR2 with a latency not exceeding 20ms. Let's assume this is... Figure 12 The TE path-12 in the image has a latency of 20ms; therefore, the BGP-intent routing table entry generated on ASBR1...<prefix=loopback-PE2,color=1000> The underlying transmission path for iterating to BGPNext-hop is TE path-12, and the metric in the routing table entry is set to 60 accordingly. ASBR1 continues to advertise the BGP-intent route to the next node PE1 according to the propagation path indication in EPO, where the metric-type is Unidirectional Link Delay, the metric is 60, the BGP Next-hop is modified to ASBR1, and the EPO information remains unchanged from the EPO information in the previously received route advertisement.

[0174] In addition, ASBR1 will also receive BGP-intent routes from ASBR3.<prefix=loopback-PE2,color=1000> Similarly, corresponding routing entries will be generated, which can form ECMP (Equal Cost Multi-path) or FRR (Fast Re-routing) with the previously generated entries. The difference from the above processing is that the metric credit obtained from EPO is 10ms, and the underlying transmission path for iteration is TE-path-14, which will not be elaborated further.

[0175] Similarly, ASBR3 will also receive BGP-intent routes from ASBR2.<prefix=loopback-PE2,color=1000> Similarly, corresponding routing table entries will be generated. The difference from the above processing is that the metric credit obtained from the EPO is 10ms, and the underlying transmission path for iteration is TE-path-15. ASBR3 continues to advertise the BGP-intent route to the next node ASBR1 according to the propagation path indication in the EPO, where the metric-type is Unidirectional Link Delay, the metric is 50, the BGP Next-hop is modified to ASBR3, and the EPO information (which remains unchanged from the EPO information in the previously received route advertisement).

[0176] 4) Upon receiving the BGP-intent route, Ingress PE1 establishes a corresponding underlying transport path to the BGP Next-hop that satisfies the intent.<prefix=loopback-PE2,color=1000> At this time, a corresponding routing table entry is generated locally, where the metric-type is Unidirectional Link Delay and the BGP Next-hop is ASBR1. Based on the EPO information contained in the received route advertisement, Ingress PE1 determines that the metric credit from its BGP Speaker (i.e., Ingress PE1) to its downstream BGP Speaker neighbor (i.e., ASBR1) is 40ms. Then, the Ingress PE1 node internally calls the CSPF calculation module to calculate an extremely low-latency path to the ABR with a latency not exceeding 40ms. Let's assume it's... Figure 12 The TE path-11 in the Ingress has a latency of 40ms. Therefore, the BGP-intent routing table entry generated on Ingress PE1...<prefix=loopback-PE2,color=1000> The underlying transport path for iterating to BGP Next-hop is TEpath-11, and the metric in the routing table entry is set to 100 accordingly.

[0177] Example 3: The route advertisement carries multiple propagation paths to different Ingress PEs.

[0178] Figure 13 A schematic diagram illustrating multiple propagation paths to different Ingress PEs carried in the routing advertisement according to an embodiment of the present invention, as shown below. Figure 13The network shown contains three ASs. BGP neighbors are established between PE1 and ASBR1, between ASBR1 and ASBR2, between ASBR1 and ASBR3, between ASBR2 and PE2, and between ASBR3 and PE3. BGP-intent routes are advertised. For example, following the method described in draft-zhou-idr-inter-domain-lcu-04, Egress PE2 (network ingress node) advertises its loopback route (denoted as loopback-PE2) to ASBR2 (network egress node) via BGP. The route advertisement carries the Color extended community to carry intent information.

[0179] In this example, suppose the intent of the service requiring communication between Ingress PE1 and Egress PE2, and between Ingress PE3 and Egress PE2, is that the total end-to-end latency of the transmission path used cannot exceed 100ms. Assume the color configured for this intent on Egress PE2 is color-1000.

[0180] The intent configuration corresponding to Color-1000 is as follows:

[0181] metric-type: Unidirectional Link Delay (unit: ms)

[0182] total-metric: 100

[0183] The intent configuration information corresponding to the aforementioned colors is also uniformly configured on other BGP Speaker nodes (e.g., ASBR1 / 2 / 3, PE1 / 3). It should also be noted that after receiving BGP-intent route advertisements from downstream BGP Speaker neighbors, these other BGP Speakers do not simply calculate the transmission path to the downstream BGP Speaker neighbors based on the total-metric included in the intent configuration information. Instead, they obtain the metric credit information from the received BGP-intent route advertisements and establish or use existing transmission paths that satisfy the intent accordingly.

[0184] On Egress PE2, a corresponding BGP-intent route is generated.<prefix=loopback-PE2,color=1000> The expected propagation path for this route is PE2 (network egress node) - ASBR2 - ASBR1 - PE1 (network ingress node) and ASBR2 (network egress node) - ASBR3 - PE3 (network ingress node). Compared with Example 2, except for a slight difference in the propagation path, the other processing procedures are completely similar. The figure shows the underlying TE path (Traffic Engineering Path) that the BGP route within each AS iterates to based on the metric credit, which will not be elaborated further.

[0185] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0186] This embodiment also provides a routing announcement message processing apparatus, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0187] Figure 14 This is a structural block diagram of a device for processing routing advertisement messages according to an embodiment of the present invention, such as... Figure 14 As shown, the device includes:

[0188] The first acquisition module 142 is used to acquire the Border Gateway Protocol (BGP) route advertisement message sent by the previous node on the current node. The BGP route advertisement message carries information about the propagation path, which is a path from the network egress node to the network ingress node. The BGP route advertisement message indicates the BGP next-hop node in the forwarding direction, which is from the network ingress node to the network egress node.

[0189] The first determining module 144 is used to determine the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the information of the propagation path when the BGP next-hop node and the current node are two adjacent nodes on the propagation path.

[0190] In an optional embodiment, the propagation path information is located in a newly added path attribute field in the BGP route advertisement message, or in an existing path attribute field in the BGP route advertisement message.

[0191] In an optional embodiment, the BGP route advertisement message carries information about the propagation path, including: a node count field, which represents the number N of nodes on the propagation path, where N is a positive integer greater than or equal to 1; N node identifier fields, each representing the identifier of a corresponding node on the propagation path; and M instruction fields, each representing instruction information corresponding to a node on the propagation path, where M is a positive integer greater than or equal to 1 and less than or equal to N.

[0192] In an optional embodiment, the BGP route advertisement message carrying propagation path information further includes: N flag fields, each flag field being used to represent the address information of a node corresponding to the propagation path, and to represent whether a node corresponding to the propagation path has the instruction field.

[0193] In an optional embodiment, the BGP route advertisement message carrying propagation path information further includes: M instruction length fields, each instruction length field being used to indicate the number of bytes of a corresponding instruction field among the M instruction fields; wherein, the N flag fields are also used to indicate whether a node on the propagation path has the instruction length field.

[0194] In an optional embodiment, the propagation path includes one or more paths in the direction from the network egress node to the network ingress node, wherein each path is a path from the network egress node to the network ingress node, or a portion of the path from the network egress node to the network ingress node.

[0195] In an optional embodiment, when the network egress node includes multiple different egress nodes, the propagation path includes multiple paths in the direction from the multiple different egress nodes toward the network ingress node, wherein each path is a path from a corresponding egress node to the network ingress node, or a portion of the path from a corresponding egress node to the network ingress node.

[0196] In an optional embodiment, when the network entry node includes multiple different entry nodes, the propagation path includes multiple paths in the direction from the network exit node to the multiple different entry nodes, wherein each path is a path from the network exit node to a corresponding entry node, or a part of the path from the network exit node to a corresponding entry node.

[0197] In an optional embodiment, the above-described apparatus further includes:

[0198] The second determining module is used to determine the next node of the current node in the propagation path from the information of the propagation path after obtaining the BGP route advertisement message sent by the previous node on the current node, when the current node is included among the multiple nodes in the propagation path.

[0199] The first sending module is used to send the BGP route advertisement message from the current node to the next node.

[0200] In an optional embodiment, the first transmitting module includes:

[0201] The first sending unit is configured to send the BGP route advertisement message from the current node to the next node when a BGP session is configured between the current node and the next node and the address cluster related to the BGP route advertisement message is enabled.

[0202] In an optional embodiment, the above-described apparatus further includes:

[0203] The third determining module is used to determine the next node of the current node in the propagation path from the information of the propagation path after obtaining the BGP route advertisement message sent by the previous node on the current node, when the current node is included among multiple nodes in the propagation path.

[0204] The second sending module is used to send the BGP route advertisement message to the route reflector on the current node when there is no BGP session configured between the current node and the next node, but the BGP route advertisement message is pre-configured to be transparently transmitted through the route reflector.

[0205] In an optional embodiment, the first transmitting module further includes:

[0206] The processing unit is configured to modify the BGP next-hop node in the forwarding direction indicated in the BGP route advertisement message to the current node, thereby obtaining an updated BGP route advertisement message;

[0207] The second sending unit is used to send the updated BGP route advertisement message from the current node to the next node.

[0208] In an optional embodiment, the above-described apparatus further includes:

[0209] The generation module is configured to generate a BGP intent routing table entry on the current node when the BGP next-hop node in the forwarding direction indicated in the BGP routing advertisement message is modified to the current node. The BGP intent routing table entry includes information representing the underlying transmission path, and the information representing the underlying transmission path includes at least one of the following: the transmission delay of the underlying transmission path and the bandwidth information of the underlying transmission path.

[0210] In an optional embodiment, the above-described apparatus further includes:

[0211] The second acquisition module is used to acquire intent information of the service that needs to communicate between the network ingress node and the network egress node before acquiring the BGP route advertisement message sent by the previous node on the current node. The service that needs to communicate corresponds to the propagation path, and the intent information represents the total metric from one end node to the other end node of the propagation path.

[0212] The configuration module is used to configure the information of the propagation path according to the intent information, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the propagation path information is equal to the total metric, and the metric includes at least one of the following: latency metric, traffic engineering metric, and internal gateway protocol metric.

[0213] In an optional embodiment, the second acquisition module includes: an acquisition unit, configured to acquire P intent information of the P services when the services requiring communication include P services, wherein P is 1, or is a positive integer greater than or equal to 2, and each intent information represents the total metric from one end node to the other end node of a corresponding propagation path; the configuration module includes: a configuration unit, configured to configure information of P propagation paths according to the P intent information, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the information of each complete propagation path is equal to the total metric represented by the corresponding intent information.

[0214] In an optional embodiment, the above-described apparatus further includes:

[0215] The processing module is configured to, after configuring the information of P propagation paths according to the P intent information, carry the information of the P propagation paths in the BGP route advertisement message.

[0216] In an optional embodiment, the above instruction information includes at least one of the following: transmission delay requirement information, bandwidth requirement information, and path affinity requirement information.

[0217] In an optional embodiment, when the instruction information includes transmission delay requirement information, the transmission delay of the underlying transmission path is less than or equal to the transmission delay indicated by the transmission delay requirement information.

[0218] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0219] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0220] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0221] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

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

[0223] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0224] The routing advertisement information processing method provided by this invention can carry a new path attribute EPO in the BGP routing advertisement message and specify the propagation path of the routing advertisement, which to some extent has the prototype of BGP traffic engineering. In addition, the instruction information carried in the EPO provides auxiliary information for BGP routing iteration and state maintenance at each hop. Furthermore, different types of requirements, such as latency requirements, bandwidth requirements, path affinity requirements, etc., can be introduced into the instruction information in real time. Moreover, the EPO attribute defined in this application embodiment is not only applicable to the BGP intention route in the above embodiment, but also applicable to any known BGP route type.

[0225] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0226] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing routing announcement messages, characterized in that, include: At the current node, obtain the Border Gateway Protocol (BGP) route advertisement message sent by the previous node. The BGP route advertisement message carries information about the propagation path, which is a path from the network egress node to the network ingress node. The BGP route advertisement message indicates the BGP next-hop node in the forwarding direction, which is from the network ingress node to the network egress node. When the BGP next-hop node and the current node are two adjacent nodes on the propagation path, the underlying transmission path from the current node to the BGP next-hop node is determined according to the instruction information corresponding to the current node in the propagation path information. Specifically, determining the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the propagation path information includes: determining the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the propagation path information used to indicate the transmission requirements of the current service; different services on the same path correspond to different BGP route advertisement messages, and different BGP route advertisement messages carry different instruction information used to indicate the transmission requirements of the corresponding service.

2. The method according to claim 1, characterized in that, The propagation path information is located in a newly added path attribute field in the BGP route advertisement message, or in an existing path attribute field in the BGP route advertisement message.

3. The method according to claim 1, characterized in that, The BGP route advertisement message carries information about the propagation path, including: The node count field is used to represent the number N of nodes on the propagation path, where N is a positive integer greater than or equal to 1; There are N node identifier fields, each of which is used to represent the identifier of a corresponding node on the propagation path; There are M instruction fields, each of which represents the instruction information corresponding to a node on the propagation path, where M is a positive integer greater than or equal to 1 and less than or equal to N.

4. The method according to claim 3, characterized in that, The BGP route advertisement message also includes information about the propagation path: There are N flag fields, each flag field is used to represent the address information of a corresponding node on the propagation path, and to indicate whether a corresponding node on the propagation path has the instruction field.

5. The method according to claim 4, characterized in that, The BGP route advertisement message also includes information about the propagation path: There are M instruction length fields, each of which represents the number of bytes in a single instruction field among the M instruction fields. The N flag fields are also used to indicate whether a node on the propagation path has the instruction length field.

6. The method according to any one of claims 1 to 5, characterized in that, The propagation path includes one or more paths in the direction from the network exit node to the network entry node, wherein each path is a path from the network exit node to the network entry node, or a part of the path from the network exit node to the network entry node.

7. The method according to any one of claims 1 to 5, characterized in that, When the network egress node includes multiple different egress nodes, the propagation path includes multiple paths from the multiple different egress nodes toward the network ingress node, wherein each path is a path from a corresponding egress node to the network ingress node, or a part of the path from a corresponding egress node to the network ingress node.

8. The method according to any one of claims 1 to 5, characterized in that, When the network entry node includes multiple different entry nodes, the propagation path includes multiple paths in the direction from the network exit node to the multiple different entry nodes, wherein each path is a path from the network exit node to a corresponding entry node, or a part of the path from the network exit node to a corresponding entry node.

9. The method according to any one of claims 1 to 5, characterized in that, After obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: In the case where multiple nodes in the propagation path include the current node, the next node of the current node in the propagation path is determined from the information of the propagation path; The BGP route advertisement message is sent from the current node to the next node.

10. The method according to claim 9, characterized in that, The step of sending the BGP route advertisement message from the current node to the next node includes: If a BGP session is configured between the current node and the next node, and the address clusters associated with the BGP route advertisement message are enabled, the BGP route advertisement message is sent from the current node to the next node.

11. The method according to any one of claims 1 to 5, characterized in that, After obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: In the case where multiple nodes in the propagation path include the current node, the next node of the current node in the propagation path is determined from the information of the propagation path; If no BGP session is configured between the current node and the next node, but the BGP route advertisement message is pre-configured to be transparently transmitted through the route reflector, the BGP route advertisement message is sent to the route reflector on the current node.

12. The method according to claim 9, characterized in that, The step of sending the BGP route advertisement message from the current node to the next node includes: Modify the BGP next-hop node in the forwarding direction indicated in the BGP route advertisement message to the current node to obtain an updated BGP route advertisement message; The updated BGP route advertisement message is sent from the current node to the next node.

13. The method according to claim 12, characterized in that, When the BGP next-hop node in the forwarding direction indicated in the BGP route advertisement message is modified to the current node, the method further includes: A BGP intent routing table entry is generated on the current node, wherein the BGP intent routing table entry includes information for representing the underlying transmission path, and the information for representing the underlying transmission path includes at least one of the following: the transmission delay of the underlying transmission path and the bandwidth information of the underlying transmission path.

14. The method according to any one of claims 1 to 5, characterized in that, Before obtaining the BGP route advertisement message sent by the previous node on the current node, the method further includes: Obtain intent information of the services that need to communicate between the network ingress node and the network egress node, wherein the services that need to communicate correspond to the propagation path, and the intent information represents the total metric from one end node to the other end node of the propagation path; Based on the intent information, the propagation path information is configured, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the propagation path information is equal to the total metric, and the metric includes at least one of the following: latency metric, traffic engineering metric, and internal gateway protocol metric.

15. The method according to claim 14, characterized in that, The step of obtaining the intent information of the services that need to communicate between the network ingress node and the network egress node includes: when the services that need to communicate include P services, obtaining P intent information of the P services, where P is 1, or is a positive integer greater than or equal to 2, and each intent information represents the total metric from one end node to the other end node of a corresponding propagation path. The step of configuring the propagation path information according to the intent information includes: configuring the information of P propagation paths according to the P intent information, wherein the sum of the metrics indicated by the instruction information corresponding to the nodes in the information of each complete propagation path is equal to the total metric represented by the corresponding intent information.

16. The method according to claim 15, characterized in that, After configuring the information for P propagation paths based on the P intent information, the method further includes: The BGP route advertisement message carries information about the P propagation paths.

17. The method according to any one of claims 1 to 5, characterized in that, The instruction information includes at least one of the following: transmission delay requirement information, bandwidth requirement information, and path affinity requirement information.

18. The method according to claim 17, characterized in that, When the instruction information includes transmission delay requirement information, the transmission delay of the underlying transmission path is less than or equal to the transmission delay indicated by the transmission delay requirement information.

19. A processing apparatus for routing announcement messages, characterized in that, include: The first acquisition module is used to acquire the Border Gateway Protocol (BGP) route advertisement message sent by the previous node on the current node. The BGP route advertisement message carries information about the propagation path, which is a path from the network egress node to the network ingress node. The BGP route advertisement message indicates the BGP next-hop node in the forwarding direction, which is from the network ingress node to the network egress node. The first determining module is configured to, when the BGP next-hop node and the current node are two adjacent nodes on the propagation path, determine the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the propagation path information; The device is further configured to determine the underlying transmission path from the current node to the BGP next-hop node based on the instruction information corresponding to the current node in the information of the propagation path, which is used to indicate the transmission requirements of the current service. Different services on the same path correspond to different BGP route advertisement messages, and different BGP route advertisement messages carry different instruction information used to indicate the transmission requirements of the corresponding services.

20. The apparatus according to claim 19, characterized in that, When the instruction information includes transmission delay requirement information, the transmission delay of the underlying transmission path is less than or equal to the transmission delay indicated by the transmission delay requirement information.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 18.

22. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 18.

Images