Route advertisement method, communication device, storage medium, and program product

Abstract

The present application relates to the technical field of communications, and discloses a route advertisement method, a communication device, a storage medium, and a program product. The route advertisement method is applied to a first leaf node device, and comprises: acquiring first route information corresponding to the first leaf node device; and sending a first route advertisement to a neighbor node, wherein the first route advertisement carries the first route information, non-blocking tunnel information, and an interface bandwidth corresponding to the first route information.

Description

Routing announcement methods, communication equipment, storage media and program products

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510124592.6, filed on January 26, 2025, entitled "Route Announcement Method, Communication Device, Storage Medium and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a routing announcement method, communication device, storage medium, and program product. Background Technology

[0004] With the rapid development of artificial intelligence (AI) and machine learning (ML), data centers are becoming increasingly large, and the amount of routing is increasing exponentially, putting a heavier burden on equipment. Moreover, due to the nature of large-scale model calculations, there are often sudden surges in traffic. If the link bandwidth is insufficient, packet loss may occur, which in turn leads to retransmission, which in turn causes packet loss again, creating a vicious cycle that exacerbates network congestion. Summary of the Invention

[0005] This application provides a routing announcement method, communication device, storage medium, and program product that can avoid network congestion and packet loss caused by insufficient bandwidth.

[0006] In a first aspect, a routing announcement method is provided, applied to a first leaf node device, comprising: obtaining first routing information corresponding to the first leaf node device; and sending a first routing announcement to neighboring nodes, wherein the first routing announcement carries the first routing information, non-blocking tunnel information, and interface bandwidth corresponding to the first routing information.

[0007] Secondly, a routing announcement method is provided, applied to an intermediate node device, comprising: receiving a routing announcement corresponding to a leaf node device sent by a first neighbor node, wherein the routing announcement carries routing information corresponding to the leaf node device, non-blocking tunnel information, and interface bandwidth corresponding to the routing information; and sending the routing announcement to a second neighbor node.

[0008] Thirdly, a communication device is provided, the communication device comprising a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method described in the first or second aspect above.

[0009] Fourthly, a readable storage medium is provided, characterized in that a program or instructions are stored on the readable storage medium, and when the program or instructions are executed by a processor, they implement the steps of the method described in the first or second aspect above.

[0010] Fifthly, a computer program product is provided, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions that, when executed by a computer, cause the computer to perform the steps of the method described in the first or second aspect above.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0013] Figure 1 shows a schematic diagram of the structure of a data center network provided in an exemplary embodiment of this application;

[0014] Figure 2 shows a flowchart of a routing announcement method provided in an exemplary embodiment of this application;

[0015] Figure 3 shows a flowchart of a routing announcement method provided by another exemplary embodiment of this application;

[0016] Figure 4 shows an example diagram of a forwarding table path based on device identifier in an exemplary embodiment of this application;

[0017] Figure 5a shows an example diagram of information carried in a routing advertisement in an exemplary embodiment of this application;

[0018] Figure 5b shows an example diagram of information carried in a routing advertisement in another exemplary embodiment of this application;

[0019] Figure 6 shows a flowchart of a routing announcement method provided in yet another exemplary embodiment of this application;

[0020] Figure 7a shows an example diagram of a forwarding table entry based on routing information in an exemplary embodiment of this application;

[0021] Figure 7b shows an example diagram of a forwarding table entry based on routing information in another exemplary embodiment of this application;

[0022] Figure 7c shows an example diagram of a forwarding table entry based on routing information in yet another exemplary embodiment of this application;

[0023] Figure 8 shows a flowchart of a routing announcement method provided in yet another exemplary embodiment of this application;

[0024] Figure 9 is a structural block diagram of a communication device according to an exemplary embodiment;

[0025] Figure 10 shows a block diagram of a communication device provided in an exemplary embodiment of this application. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] With the rapid development of Artificial Intelligence (AI) and Machine Learning (ML), data centers are becoming increasingly large, and routing volume is rising exponentially, placing a heavier burden on equipment. Furthermore, due to the nature of large-scale model computations, sudden surges in traffic are frequent. If link bandwidth is insufficient, packet loss may occur, leading to retransmissions, which in turn cause further packet loss, creating a vicious cycle that exacerbates network congestion. Border Gateway Protocol (BGP), the most widely used routing protocol, is frequently used in data centers. However, when faced with the new demands of AI and ML, it also faces the problem of large routing volumes and the inability to achieve non-blocking networks.

[0028] For example, in the data center network shown in Figure 1, the leaf nodes are used to connect servers. Leaf nodes are interconnected with spine nodes, and spine nodes are interconnected with core nodes. In some data center networks, the core node layer may not exist, and spine nodes can be directly interconnected. When the network scale is relatively large, Figure 1 can be represented as a single plane, and several such planes can be interconnected to form a larger-scale data center network. Because of the large number of servers, host routing will occupy a lot of space on network devices and put a great strain on forwarding performance. At the same time, AI / ML model training may cause a large amount of burst traffic. For example, a server under the L1 node in Figure 1 has a training task that requires transmitting a large amount of data to a server under the L2 node for collaborative computing in a short period of time. However, the link bandwidth from L2 to the server is insufficient to meet the needs, resulting in packet loss. As a result, the server under L1 will re-initiate data transmission, but insufficient bandwidth will cause packet loss again, leading to retransmission and creating a vicious cycle. This will exacerbate network congestion, cause more problems, and even make the network unusable. When using BGP as a routing protocol, although BGP avoids the link bandwidth consumption caused by the timed flooding of protocols such as Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) due to its own protocol characteristics, it still cannot avoid network congestion and packet loss caused by a large number of routes and sudden large traffic.

[0029] To address the aforementioned issues, this application provides a route announcement scheme.

[0030] Figure 2 illustrates a flowchart of a routing advertisement method provided in an exemplary embodiment of this application. This method can be executed by a first leaf node device, which can be any leaf node device shown in Figure 1. As shown in Figure 2, the method mainly includes the following steps.

[0031] S210, Obtain the first routing information corresponding to the first leaf node device.

[0032] In some embodiments of this application, the first routing information corresponding to the first leaf node device may be a server host route, for example, a server host route connected to the first leaf node device.

[0033] In other embodiments of this application, the first routing information corresponding to the first leaf node device may also be a prefix route based on Internet Protocol (IP), such as the IP prefix route of the server connected to the first leaf node device. Alternatively, the first routing information corresponding to the first leaf node device may also be a Media Access Control (MAC) route. Specific embodiments of this application are not limited to these.

[0034] S220, send a first route advertisement to neighboring nodes, wherein the first route advertisement carries the first route information, non-blocking tunnel information, and the interface bandwidth corresponding to the first route information.

[0035] In this embodiment, each node in the network can establish neighbor relationships, which can be BGP neighbor relationships, such as EBGP (External BGP) neighbors. This embodiment does not limit the form of BGP neighbors. For example, in the network shown in Figure 1, C1 establishes BGP neighbors with S1 and S2 respectively, S1 establishes BGP neighbors with L1 to Lm respectively, and S2 establishes BGP neighbors with L1 to Lm respectively. Through these established neighbor relationships, each node can learn about its neighbors.

[0036] In this embodiment, the first leaf node device sends a first routing advertisement to its neighboring nodes. This first routing advertisement carries first routing information, such as server host routes, IP-based prefix routes, or MAC routes. It may also carry non-blocking tunnel (NBT) information, which indicates that the first routing information is of NBT type. Furthermore, the first routing advertisement also carries the interface bandwidth corresponding to the first routing information, i.e., the available bandwidth corresponding to the first routing information.

[0037] In some embodiments, the first routing information can be the IP address of the server to which the first leaf node device is connected. For example, the first leaf node device can use a Layer 3 Virtual Private Network (L3VPN) to transmit server host routes. In these embodiments, traditional L3VPN extensions can be utilized for route advertising.

[0038] Furthermore, in this embodiment, the first routing information can be a host route or an IP address route of the first leaf node device itself. This embodiment does not limit the first routing information to be a host route. When the first routing information is an IP address route of the first leaf node device itself, the first routing advertisement may also carry the identifiers of each interface of the first leaf node device and the bandwidth information of each interface.

[0039] To make AI / ML applications more flexible, multiple servers may share the same IP address. For example, in the network shown in Figure 1, all servers connected to L1 use the same IP address, 201.1.1.11. Therefore, in some embodiments, the first routing information can also be the MAC address of the server connected to the first leaf node device. For example, the first leaf node device can use an Ethernet Virtual Private Network (EVPN) to transmit server host routes. In these embodiments, the host routes advertised by the first leaf node device are represented by the server's MAC address, regardless of whether the server has a separate IP address.

[0040] Regardless of whether the first routing information is an IP address or a MAC address, the first routing advertisement can carry the specific interface bandwidth information connected to the server. Each interface of the first leaf node device corresponds to an actual server. When L1 advertises the server host route 201.1.1.11, in addition to carrying non-blocking routing information, it can also carry specific interface and bandwidth information. Each interface corresponds to an actual server, indicating that it carries multiple interface and bandwidth information. This allows other nodes to know the bandwidth information between L1 and each connected server, thus providing other nodes with available bandwidth information for reference when selecting a destination server, preventing congestion.

[0041] Additionally, it should be noted that, in the embodiments of this application, in addition to using L3VPN and EVPN for route announcement, the first leaf node device can also use a defined new Address Family Indicator (AFI) or Subsequent Address Family Indicator (SAFI) for announcement. This application does not limit the specific announcement type, and the announcement content is similar, so it will not be repeated here.

[0042] In some embodiments, the routing information advertised by the first leaf node device may be updated. For example, the bandwidth corresponding to an interface may decrease because it needs to forward one or more traffic flows, or the bandwidth corresponding to an interface may increase because it releases one or more traffic flows. To improve resource utilization, after S220, the method may further include: in response to an update of at least one of the first routing information and the interface bandwidth corresponding to the first routing information, the first leaf node device sends an updated first routing advertisement to the neighboring nodes, wherein the updated first routing advertisement carries at least one of the updated first routing information and the updated interface bandwidth corresponding to the first routing information. Through this embodiment, when at least one of the first routing information corresponding to the first leaf node device or the interface bandwidth corresponding to the first routing information is updated, an updated first routing advertisement can be sent to notify other nodes on the network, thereby enabling other nodes to obtain the updated first routing information or at least one of the interface bandwidth corresponding to the first routing information.

[0043] In the above embodiments, when the bandwidth between the leaf node and the connected server changes, the leaf node can resend the host route of the server. For example, in the network shown in Figure 1, the interface 1 of L1 is reduced to 5G due to traffic usage. L1 can re-announce the host route 201.1.1.1, carrying non-blocking tunnel information and bandwidth of 5G, thereby avoiding congestion and packet loss caused by other servers sending traffic with larger bandwidth.

[0044] It should be noted that the above update process does not need to be refreshed every moment. Leaf node devices can take the average value over a period of time, or set multiple thresholds. When the bandwidth is less than the average value or threshold, an announcement can be made. This avoids repeated announcements from the host router.

[0045] The technical solution provided in this application embodiment allows a first leaf node device to send a first routing advertisement to neighboring nodes. This first routing advertisement carries first routing information, non-blocking tunnel information, and the interface bandwidth corresponding to the first routing information for the first leaf node device. Because the first routing advertisement carries the interface bandwidth corresponding to the first routing information, other devices can refer to the available interface bandwidth when sending traffic to the device corresponding to the first routing information, thus avoiding network congestion and packet loss due to insufficient bandwidth.

[0046] Figure 3 illustrates a flowchart of a route advertisement method provided in another exemplary embodiment of this application. This method can be executed by a first leaf node device, which can be any leaf node device shown in Figure 1. As shown in Figure 3, the method mainly includes the following steps.

[0047] S310, the first leaf node device announces its identification information, wherein the identification information of the first leaf node device is used by neighboring nodes to construct forwarding table entries based on the device identification.

[0048] In some embodiments, the aforementioned identification information may be a device identifier (Device-ID), which may be assigned by the network management system. Taking the network shown in Figure 1 as an example, a device ID (Device-ID) is assigned to each leaf node, spine node, and core node (the core node may not exist). Depending on the size of the data center, 1 byte, 2 bytes, or 4 bytes may be used to represent the Device-ID. Taking 2 bytes as an example, each leaf node, spine node, and core node in the network is assigned a number from 1 to 65535 for distinction. In some scenarios, spine nodes and core nodes may not be assigned a Device-ID.

[0049] In other embodiments, the network management system may not assign a Device-ID; instead, the leaf node's identification information can be its address information, such as an IP address or loopback address. Alternatively, the identification information can also be the leaf node's router-ID. For example, the identification information of the first leaf node device can also be the first leaf node device's IP address or router-ID.

[0050] S320, the first leaf node device receives the identification information of the neighboring node announced by the neighboring node.

[0051] In this embodiment of the application, the first leaf node device and its neighboring nodes can announce their identification information to each other based on the establishment of a neighbor relationship, so that the other party can know their identification information.

[0052] In practical applications, there is no necessary order in which S310 and S320 are executed.

[0053] S330, the first leaf node device constructs a forwarding table entry based on the device identifier based on the identifier information of the neighboring nodes.

[0054] In some embodiments, a device-identifier-based forwarding table entry may include at least one entry, each entry including: destination node identification information, next-hop identification information, and outgoing interface information. Figure 4 illustrates a device-identifier-based forwarding table entry in an exemplary embodiment of this application. As shown in Figure 4, the Device-ID in this forwarding table entry may be the device identifier of the destination node, the next hop may be the address information of the next hop, and the outgoing interface is used to indicate the outgoing interface corresponding to the next hop.

[0055] In some implementations, where all nodes in the network, including leaf nodes, spine nodes, and core nodes, are assigned Device-IDs, the address information of the next hop can also be replaced with the Device-ID of the next hop.

[0056] The device identifier-based forwarding table entries provided in the embodiments of this application can simplify routing and forwarding table lookups.

[0057] Taking the network as an example in the data shown in Figure 1, a device ID is assigned to each leaf node, spine node, and core node (the core node may not exist). In practical applications, depending on the size of the data center, the device ID can be represented by 1 byte, 2 bytes, or 4 bytes. The following uses 2 bytes as an example. Each leaf node, spine node, and core node in the network is assigned a number from 1 to 65535 to distinguish them. In some scenarios, the spine node and core node may not be assigned a device ID.

[0058] BGP neighbor relationships are established between core nodes and spine nodes, and between spine nodes and leaf nodes, typically EBGP (External BGP) neighbors. For example, C1 establishes BGP neighbors with S1 and S2, S1 establishes BGP neighbors with L1 to Lm, and S2 establishes BGP neighbors with L1 to Lm. Each node carries its own Device-ID when advertising its Loopback or interface address. If no Device-ID is assigned to the spine or core nodes, the advertised Device-ID is 0; however, the advertised Device-ID from leaf nodes is always non-zero. After the advertising process, each node generates forwarding table entries based on the Device-ID, as shown in Figure 4. Each entry contains the destination node's Device-ID, the next-hop IP address, and outgoing interface information. When all nodes, including leaf nodes, spine nodes, and core nodes, are assigned Device-IDs, the next-hop IP address can also be replaced with the Device-ID.

[0059] S340, obtain the first routing information corresponding to the first leaf node device.

[0060] This step is the same as S210 above, and you can refer to the relevant description in S210 above for details.

[0061] S350, send a first route advertisement to neighboring nodes, wherein the first route advertisement carries the first route information, non-blocking tunnel information, and the interface bandwidth corresponding to the first route information.

[0062] This step is the same as S220 above. For details, please refer to the relevant description in S220 above. It will not be repeated here.

[0063] In some embodiments, the first route advertisement may also carry the aforementioned identification information of the first leaf node device, such as the Device-ID of the first leaf node device. Figures 5a and 5b illustrate schematic diagrams of the information carried in a route advertisement in an example embodiment of this application. As shown in Figures 5a and 5b, the route advertisement may carry at least one server host route, the type of which is indicated as a non-blocking tunnel, the Device-ID of the advertised node, and the bandwidth of the corresponding interface.

[0064] When multiple server hosts connected to the first leaf node device all use the same IP address, the first routing advertisement can carry not only MAC routing information and non-blocking tunnel information, but also specific interface identifiers and bandwidth information. Each interface corresponds to a server connected to the first leaf node device. As shown in Figure 5b, the bandwidth corresponding to each interface can be carried in the routing advertisement.

[0065] Taking the network as an example in the data shown in Figure 1, leaf nodes advertise the routes of the server hosts they are connected to, carrying non-blocking tunnel information and other options such as Device-ID or bandwidth. Assume L1 connects to 10 servers, and these server host routes are 201.1.1.1-201.1.1.10. L1 divides these host routes into L3VPNs and advertises these 10 routes through L3VPN, carrying the non-blocking tunnel type and various options as shown in Figure 5a. These options may include the L1 node's Device-ID and possible interface bandwidth. Each leaf node uses a similar method for advertising.

[0066] When a ridge node receives a host route advertised by a leaf node, it does not generate a forwarding table entry and does not change the next hop before sending it to its neighbors, such as core nodes. Similarly, when a core node receives the route, it does not generate a forwarding table entry and does not change the next hop before sending it to other ridge node neighbors. For example, in Figure 1, after ridge node S1 receives a server host route sent by L1, it does not change the next hop before sending it to leaf nodes L2-Lm and core node C1. If other planes exist, C1 will not change the next hop before sending it to other core nodes. Ridge node S2 receives a server host route from L1 and sends it to other leaf nodes and node C1. However, because it does not change the next hop, the received nodes will treat it as a duplicate route without causing any adverse effects.

[0067] When multiple server hosts connected to the first leaf node device all use the same IP address, when L1 advertises the server host route 201.1.1.11, in addition to carrying non-blocking routing information, it can also carry specific interface and bandwidth information. Each interface corresponds to an actual server, as shown in Figure 5b. The option type carries multiple interface and bandwidth information. In this way, other leaf nodes can know the bandwidth information between L1 and each connected server, so that when other nodes' servers select a destination server, they have available bandwidth information for reference, thus avoiding congestion.

[0068] Through the technical solutions provided in the embodiments of this application, each node device in the network can announce its own identification information, thereby constructing forwarding table entries based on the device identifier, which simplifies routing and forwarding table lookup.

[0069] Figure 6 shows a flowchart of a routing advertisement method according to another exemplary embodiment of this application. This method can be executed by a first leaf node device, which can be any leaf node device shown in Figure 1. As shown in Figure 6, the method mainly includes the following steps.

[0070] S610, the first leaf node device receives a second routing advertisement from a neighboring node for the second leaf node device, wherein the second routing advertisement carries second routing information, non-blocking tunnel information, and interface bandwidth corresponding to the second routing information for the second leaf node device.

[0071] The second route advertisement is similar to the first route advertisement, except that it is sent by the second leaf node device. For example, in the data center network shown in Figure 1, the first leaf node device can be L1, while the second leaf node device can be any one of L2 to Lm.

[0072] In this embodiment, when an intermediate node, such as a ridge node or core node in Figure 1, receives a routing advertisement from a leaf node device, it does not generate a forwarding table entry based on the routing information, nor does it change the next hop of the routing advertisement. Instead, it forwards the received routing advertisement to its neighboring nodes. Therefore, the second routing advertisement received by the first leaf node device from the second leaf node device only carries routes with the second leaf node device as the next hop, and does not include duplicate routing information with intermediate nodes as the next hop, thereby reducing the number of routes.

[0073] S620, the first leaf node device generates a forwarding table entry based on routing information based on the second routing advertisement. Each entry in the forwarding table entry based on routing information includes: the second routing information, the interface bandwidth corresponding to the second routing information, the outgoing interface information, and the next hop information.

[0074] In this embodiment of the application, after receiving the second routing advertisement from the second leaf node device, the first leaf node device can generate a forwarding table entry based on the routing information based on the second routing advertisement. When receiving forwarding traffic, it can forward the traffic according to the forwarding table entry based on the routing information.

[0075] In some embodiments, each entry in the forwarding table based on routing information may further include: identification information of the second leaf node device, which is the same as the identification information in the embodiments shown in Figures 2 and 3 above, and can be referred to the relevant description above for details.

[0076] Figure 7a shows an example diagram of a forwarding table entry based on routing information in an exemplary embodiment of this application. As shown in Figure 7a, each entry of the forwarding table entry based on routing information may include: host route (i.e., second routing information, which is the IP address of the server connected to the second leaf node device in Figure 7a), outgoing interface information corresponding to the second routing information, identification information of the advertised leaf node, and the actual next hop.

[0077] Figure 7b shows an example diagram of a forwarding table entry based on routing information in another exemplary embodiment of this application. As shown in Figure 7b, each entry of the forwarding table entry based on routing information may include, in addition to the information in Figure 7a, the interface bandwidth corresponding to the second routing information (i.e., the server bandwidth connected to the second leaf node device).

[0078] Figure 7c shows an example diagram of a forwarding table entry based on routing information in another exemplary embodiment of this application. As shown in Figure 7c, in this exemplary embodiment, the multiple server hosts connected to the advertising node (i.e., leaf node L1) all use the same IP address. Therefore, in the forwarding table entry based on routing information generated according to the routing advertisement, the same destination address (i.e., host route) corresponds to multiple entries, each entry corresponds to an interface, each interface corresponds to an actual server, and the interface bandwidth of each interface may be different.

[0079] In this embodiment, after a leaf node receives a host route advertised by another leaf node from a ridge node, it can generate a forwarding table entry based on the host route. For example, leaf node L2 in Figure 1, after receiving the server host route of L1 forwarded by ridge nodes S1 / S2, generates a forwarding table entry as shown in Figure 7a. Each host route corresponds to the actual leaf node's Device-ID as the advertising node; here, we assume 1 is the Device-ID of leaf node L1. The outgoing interface corresponds to the non-blocking tunnel NBT-1 of leaf node 1. The table also contains the actual next hop, which we assume to be node S1. Similarly, all leaf nodes in the network will generate similar host table entries, storing the advertising leaf node for the host route, as well as outgoing interface tunnel information and the actual next hop.

[0080] In some embodiments, leaf nodes may optionally carry bandwidth information when announcing server host routes. For example, when leaf node L1 announces host routes, it carries bandwidth information between itself and each server. Each server connects to a leaf node interface, and the available bandwidth of the corresponding interface can be 10G, 200M, or any other arbitrary representation, as shown in Figure 5b.

[0081] Each leaf node receives server host routes and bandwidth information from other leaf nodes. For example, after receiving a host route from L1, L2 can generate a forwarding table entry as shown in Figure 7b. Compared to the forwarding table entry shown in Figure 7a, this one includes an entry for the bandwidth of the leaf node servers. Suppose a server connected to L2 wants to send 15G of traffic to server 201.1.1.1 connected to L1. Based on the forwarding table entry in Figure 7b, L2 can determine that this is impossible because the available bandwidth from L1 to server 201.1.1.1 is currently only 10G. Therefore, the server can postpone sending the traffic until the bandwidth between L1's interface 1 and the server increases, or it can send the traffic to server 201.1.1.2 connected to L1's interface 2, thus avoiding congestion.

[0082] In some embodiments, when all the server hosts connected to L1 use the same IP address 201.1.1.11, when L1 announces the server host route 201.1.1.11, in addition to carrying non-blocking routing information, it can also carry specific interface and bandwidth information. Each interface corresponds to an actual server, as shown in Figure 5b. After receiving the route announcement, other leaf nodes generate forwarding table entries as shown in Figure 7c, thereby obtaining the bandwidth information between L1 and each connected server. This allows other nodes' servers to have available bandwidth information for reference when selecting a destination server, thus preventing congestion.

[0083] After generating the aforementioned forwarding table entries based on routing information, traffic can be forwarded based on these entries. For example, suppose a server under L2 has traffic that needs to be sent to server 201.1.1.2 corresponding to interface 2 under the L1 node. After consulting the table entry, the traffic is tunneled and sent out. The intermediate spine nodes and core nodes forward the traffic according to the pre-established forwarding table entries based on Device-ID until it reaches the destination leaf node, which then forwards it to the corresponding server.

[0084] The above methods can significantly reduce the number of routes to spine nodes and core nodes in the network, thereby greatly improving forwarding efficiency.

[0085] In some embodiments, the first leaf node device may also perform the steps shown in FIG2 or FIG3 above, which will not be repeated here.

[0086] In some embodiments, after S620, the method may further include the following steps:

[0087] Step 1: In response to the need to send target traffic to multiple target servers, obtain entries matching each of the target servers from the forwarding table entries based on routing information.

[0088] In practical applications, the first leaf node device may need to send target traffic to multiple target servers. For example, the first leaf node device may send traffic to multiple servers at once for load sharing. For instance, in the data center network shown in Figure 1, there are servers under leaf node Lm. It is necessary to send 15G of traffic to two servers 201.1.1.1 and 201.1.1.2 under L1 for load sharing. Leaf node Lm can obtain entries with destination addresses matching 201.1.1.1 and 201.1.1.2 from the forwarding table entries based on routing information shown in Figure 7b.

[0089] Step 2: Determine the proportion of traffic sent to each target server according to the interface bandwidth in the entries that match each target server.

[0090] In practical applications, a simple 50 / 50 split can be used. For example, 7.5G of traffic can be sent to 201.1.1.1, and another 7.5G of traffic can be sent to 201.1.1.2 for computation. This is feasible in the state shown in Figure 7b. However, due to the possibility of other new traffic consumption, the bandwidth between L1 and server 201.1.1.1 may be reduced to 5G. This could lead to the inability to properly share the computation, or even cause the entire computation to need to be initiated and performed by a new server before the previous computation is completed, thus having a significant impact on AI / ML services.

[0091] Therefore, in this embodiment of the application, when performing load sharing calculations, the bandwidth can be adjusted proportionally. For example, if the bandwidth between L1 and server 201.1.1.1 is reduced to 5G, L1 can send a routing advertisement to update the bandwidth between L1 and server 201.1.1.1. After receiving the routing advertisement from L1, leaf node Lm updates the bandwidth between L1 and server 201.1.1.1 in the forwarding table entry to 5G. To ensure that the calculation proceeds normally, leaf node Lm can adjust the traffic load sharing proportionally, that is, adjust the traffic sent to 201.1.1.1 to 4G and the traffic sent to 201.1.1.2 to 11G. This allows the previous calculation process to continue, thereby avoiding congestion and packet loss caused by continuing to send 7.5G of traffic to 201.1.1.1, or the complete waste of the previous calculation results if the service on server 201.1.1.1 is switched to another server.

[0092] Alternatively, in this embodiment of the application, in the state shown in Figure 7b, leaf node Lm can know that the bandwidth between L1 and 201.1.1.1 is 10G, and the bandwidth between L1 and 201.1.1.2 is 20G. Therefore, leaf node Lm can divide the traffic from the beginning without using a 50 / 50 split, but instead divide it according to the ratio. That is, the server under Lm can initially send 5G of traffic to the server 201.1.1.1 under L1 and send 10G of traffic to 201.1.1.2 for calculation. This reduces the probability of load balancing adjustments that may be caused by bandwidth fluctuations in links with lower bandwidth.

[0093] Step 3: According to the traffic ratio, forward the target traffic to each of the target servers.

[0094] Through the above embodiments, the proportion of traffic sent to each target server can be determined according to the interface bandwidth in the entries that match each target server, and the target traffic can be forwarded to multiple target servers according to the traffic proportion. This can reduce the probability of load balancing adjustments that may be caused by bandwidth fluctuations in links with low bandwidth, and reduce the probability of congestion and packet loss.

[0095] Figure 8 shows a flowchart of a route advertisement method according to another exemplary embodiment of this application. This method can be executed by an intermediate node device, which can be the spine node device or the core node device shown in Figure 1. As shown in Figure 8, the method mainly includes the following steps.

[0096] S810, receive the routing advertisement corresponding to the leaf node device sent by the first neighbor node, wherein the routing advertisement carries the routing information, non-blocking tunnel information, and interface bandwidth corresponding to the routing information corresponding to the leaf node device.

[0097] For example, in the data center network shown in Figure 1, S1 receives a routing advertisement sent by leaf node L1, or C1 receives a routing advertisement sent by S1 corresponding to leaf node L1.

[0098] In the embodiments of this application, each node in the network, such as the core node and the spine node, and the spine node and the leaf node, can establish BGP neighbor relationships respectively. Based on these neighbor relationships, each node can communicate with its neighbor nodes.

[0099] In this embodiment, the routing advertisement carries routing information corresponding to the leaf node device, non-blocking tunnel information, and interface bandwidth corresponding to the routing information. The routing advertisement can be either the first routing advertisement or the second routing advertisement described in the various embodiments above.

[0100] S820, send the routing announcement to the second neighbor node.

[0101] For example, in the data center network shown in Figure 1, S1 receives a routing advertisement sent by leaf node L1 and then sends the routing advertisement to its neighbor node C1 or leaf nodes L2 to Lm. Alternatively, C1 receives the routing advertisement corresponding to leaf node L1 sent by S1 and then sends the routing advertisement to its neighbor node S2.

[0102] In some embodiments, when sending a route advertisement to a second neighbor node, the next hop of the route advertisement is not changed.

[0103] In some embodiments, after S810, intermediate node devices are prohibited from generating forwarding table entries based on routing information according to the routing advertisement. For example, the network management system can be pre-configured to prohibit intermediate nodes from generating forwarding table entries containing routing information based on received routing advertisements.

[0104] In these embodiments, when a ridge node receives a host route advertised by a leaf node, it does not generate a forwarding table entry and does not change the next hop before sending it to its neighbors, such as core nodes. Similarly, when a core node receives the route, it also does not generate a forwarding table entry and does not change the next hop before sending it to other ridge node neighbors. For example, in Figure 1, after ridge node S1 receives a server host route sent by L1, it does not change the next hop before sending it to leaf nodes L2-Lm and core node C1. If other planes exist, C1 will not change the next hop before sending it to other core nodes. Ridge node S2 will also receive the server host route from L1 and send it to other leaf nodes and node C1. However, because it does not change the next hop, the received nodes treat it as a duplicate route without causing any adverse effects.

[0105] In some embodiments, prior to S810, the method may further include the following steps:

[0106] Step 1: Receive the identification information of the neighboring nodes announced by each neighboring node;

[0107] Step 2: Based on the identification information of each neighboring node, construct a forwarding table entry based on the device identifier.

[0108] In the above embodiments, the network management system can assign a device ID (Device-ID) to each leaf node, spine node, and core node (the core node may also be non-existent). Depending on the scale of the data center network, the Device-ID can be represented by 1 byte, 2 bytes, or 4 bytes. Taking 2 bytes as an example, each leaf node, spine node, and core node in the network is assigned a number from 1 to 65535 for differentiation. In some scenarios, spine nodes and core nodes may not be assigned a Device-ID. When a spine node and core node are not assigned a Device-ID, the advertised Device-ID can be 0. The Device-ID advertised by a leaf node must not be 0. For example, when no Device-ID is assigned, the Device-ID advertised by a leaf node can be the leaf node's address information or routing information. After the advertisement process is completed, each node generates a forwarding table entry based on the Device-ID, as shown in Figure 4.

[0109] In some embodiments, after constructing a forwarding table entry based on device identifiers based on the identification information of each of the neighboring nodes, the method may further include: forwarding the traffic according to the forwarding table entry based on device identifiers in response to receiving traffic. In these embodiments, when an intermediate node device receives traffic to be forwarded, it forwards the traffic according to the forwarding table entry based on device identifiers. For example, in Figure 1, a server under L2 has traffic that needs to be sent to server 201.1.1.2 corresponding to interface 2 under node L1. After consulting the forwarding table entry based on routing information, the traffic is tunnel-encapsulated and sent out. The intermediate spine nodes and core nodes forward the traffic according to the established forwarding table entry based on Device-ID until it reaches the destination leaf node, which then forwards it to the corresponding server.

[0110] The method described above in the embodiments of this application can significantly reduce the number of routes for spine nodes and core nodes in the network, thereby greatly improving forwarding efficiency.

[0111] In this embodiment, the Device-ID not only distinguishes the routing from existing methods but also simplifies routing lookup. In some networks where Device-IDs may not be assigned, existing loopback IP addresses or Router-IDs of leaf nodes can be used to create forwarding entries. Compared to the above process, only the announcement and processing of Device-IDs differ. The Device-ID carried in the announced tunnel can be directly replaced with the leaf node's IP address or Router-ID. In the examples of forwarding entries in Figures 7a, 7b, and 7c, the announced leaf node is directly replaced with its IP address or Router-ID. Other steps, such as the unchanged next-hop transmission method for spine nodes and core nodes, remain completely identical, thus allowing the advantages of reduced routing volume and non-blocking forwarding in this embodiment to be applied.

[0112] As shown in Figure 9, this application embodiment also provides a communication device 900, including a processor 901 and a memory 902. The memory 902 stores a program or instructions that can run on the processor 901. For example, when the communication device 900 is a leaf node, when the program or instructions are executed by the processor 901, they implement the various steps of the method embodiments shown in Figures 2, 3, and 6 above, and achieve the same technical effect. When the communication device 900 is an intermediate node, when the program or instructions are executed by the processor 901, they implement the various steps of the method embodiment shown in Figure 8 above, and achieve the same technical effect. To avoid repetition, this will not be described again here.

[0113] As shown in Figure 10, an embodiment of this application also provides another communication device, including a memory 1020, a processor 1000, a transceiver 1010, a bus interface, and a program stored in the memory 1020 and executable on the processor 1000. The processor 1000 is used to read the program from the memory 1020 and execute the following processes:

[0114] Obtain the first routing information corresponding to the first leaf node device;

[0115] Send a first route advertisement to neighboring nodes, wherein the first route advertisement carries the first route information, non-blocking tunnel information, and the interface bandwidth corresponding to the first route information.

[0116] or,

[0117] Receive a routing advertisement for the leaf node device sent by the first neighbor node, wherein the routing advertisement carries routing information, non-blocking tunnel information, and interface bandwidth corresponding to the routing information for the leaf node device;

[0118] Send the route announcement to the second neighbor node.

[0119] In Figure 10, the bus architecture may include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 1000 and memory represented by memory 1020. The bus architecture may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. The bus interface provides an interface. Transceiver 1010 may be multiple elements, including transmitters and transceivers, providing a unit for communicating with various other devices over a transmission medium. Processor 1000 is responsible for managing the bus architecture and general processing, and memory 1020 may store data used by processor 1000 during operation.

[0120] Those skilled in the art will understand that the structure shown in FIG10 does not constitute a limitation on the communication device 1000, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0121] In one exemplary embodiment, a readable storage medium is also provided, which stores a program or instructions that are executed by a processor to implement all or part of the steps in the above-described route announcement method. For example, the readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0122] In one exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored on a non-transitory readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform all or part of the steps in the above-described route announcement method.

[0123] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0124] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A route advertisement method, wherein, Applied to first leaf node devices, including: Obtain the first routing information corresponding to the first leaf node device; Send a first route advertisement to neighboring nodes, wherein the first route advertisement carries the first route information, non-blocking tunnel information, and the interface bandwidth corresponding to the first route information.

2. The method according to claim 1, wherein, Before sending the first route advertisement to neighboring nodes, the method further includes: The first leaf node device announces its identification information, which is used by neighboring nodes to construct forwarding table entries based on the device identification. The first leaf node device receives the identification information of the neighboring node announced by the neighboring node; The first leaf node device constructs a forwarding table entry based on the device identifier based on the identifier information of the neighboring nodes.

3. The method according to claim 2, wherein, The identification information includes one of the following: device identifier assigned by the network management system, address information, or router identifier.

4. The method according to claim 2 or 3, wherein, Each entry in the forwarding table based on device identifier includes: the identifier information of the destination node, the identifier information of the next hop, and the outgoing interface information.

5. The method according to claim 1, wherein, The first routing information includes one of the following: server host routing, Internet Protocol (IP) prefix routing, and Media Access Control (MAC) routing.

6. The method according to claim 5, wherein, The first routing information includes one of the following: IP address, MAC address of the server connected to the first leaf node device, and interface identifier of the first leaf node device.

7. The method according to claim 1, wherein, After sending the first route advertisement to the neighboring nodes, the method further includes: In response to an update of at least one of the first routing information and the interface bandwidth corresponding to the first routing information, the first leaf node device sends an updated first routing announcement to the neighbor node, wherein the updated first routing announcement carries at least one of the updated first routing information and the updated interface bandwidth corresponding to the first routing information.

8. The method according to claim 1, wherein, The method further includes: The first leaf node device receives a second routing advertisement from a neighboring node for the second leaf node device. The second routing advertisement carries second routing information, non-blocking tunnel information, and interface bandwidth corresponding to the second routing information for the second leaf node device. The first leaf node device generates a forwarding table entry based on the second routing advertisement. Each entry in the forwarding table entry based on the routing information includes: the second routing information, the interface bandwidth corresponding to the second routing information, the outgoing interface information, and the next hop information.

9. The method according to claim 8, wherein, Each entry in the forwarding table based on routing information also includes: the identification information of the second leaf node device.

10. The method according to claim 8, wherein, After the first leaf node device generates a forwarding table entry based on the routing information according to the second routing advertisement, the method further includes: In response to the need to send target traffic to multiple target servers, entries matching each of the target servers are obtained from the forwarding table entries based on routing information; Determine the proportion of traffic sent to each of the target servers based on the interface bandwidth in the entries that match each target server; According to the stated traffic ratio, the target traffic is forwarded to each of the target servers.

11. A route advertisement method, wherein, Applications to intermediate node devices include: Receive a routing advertisement for the leaf node device sent by the first neighbor node, wherein the routing advertisement carries routing information, non-blocking tunnel information, and interface bandwidth corresponding to the routing information for the leaf node device; Send the route announcement to the second neighbor node.

12. The method according to claim 11, wherein, Sending the route advertisement to the second neighbor node includes: The route advertisement is sent to the second neighbor node without changing the next hop of the route advertisement.

13. The method according to claim 11, wherein, After receiving the routing advertisement corresponding to the leaf node device sent by the first neighbor node, the method further includes: prohibiting the generation of forwarding table entries based on routing information according to the routing advertisement.

14. The method according to claim 11, wherein, Before receiving the routing advertisement corresponding to the leaf node device sent by the first neighbor node, the method further includes: Receive the identification information of the neighboring nodes announced by each neighboring node; Based on the identification information of each neighboring node, a forwarding table entry based on the device identifier is constructed.

15. The method according to claim 14, wherein, After constructing the forwarding table entry based on the device identifier based on the identifier information of each of the neighboring nodes, the method further includes: In response to receiving traffic, the traffic is forwarded according to the forwarding table entry based on the device identifier.

16. A communication device, wherein, The communication device includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the routing announcement method as described in any one of claims 1 to 15.

17. A readable storage medium, wherein, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the routing announcement method as described in any one of claims 1 to 15.

18. A computer program product, wherein, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the steps of the routing announcement method as described in any one of claims 1 to 15.

Images