Resource reservation multicast routing method and apparatus

Abstract

The application provides a resource reservation multicast routing method and device, the method comprising: a first switching node receiving a resource reservation request from a service node and flooding the request to each second switching node connected to each target working node in the same multicast group through each routing path, each request flooded to each second switching node carrying corresponding each routing path information; receiving each request returned along the original path from each second switching node based on each routing path information, each returned request being each request carrying the resource reservation request after each routing path is determined to reserve the resource request based on the set resource reservation logic, and being sent to the service node to enable the service node to aggregate each routing path information after the resource reservation request to generate a representation of a multicast tree, and multicast the to-be-multicast data to each target working node based on the representation of the multicast tree.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a path-aware resource reservation multicast routing method and apparatus. Background Technology

[0002] Today, machine learning solutions have achieved remarkable success thanks to their ability to train more complex network models using larger datasets. To shorten training time, distributed training is often used instead of single-node training, and the interconnection of training clusters is typically based on highly scalable data center network architectures. Performance improvements in computing nodes such as TPUs (Tensor Processing Units) and GPUs (Graphics Processing Units), along with the scaling law, have significantly improved training efficiency. However, this has also shifted the performance bottleneck of distributed training from computation to communication. During distributed training, frequent communication between nodes is required to synchronize parameters, and bandwidth contention caused by concurrent communication and redundant data transmission is the main reason for communication performance bottlenecks. In other words, in distributed training, communication efficiency has become the core bottleneck restricting system performance, rooted in the bandwidth waste caused by concurrent transmission contention and redundant traffic.

[0003] Taking a parameter server (PS) architecture as an example, in a homogeneous PS architecture, after all compute nodes complete their local model parameter updates, they simultaneously send their local gradient parameters to the service node for aggregation (push operation), leading to intense bandwidth contention. After the service node completes aggregation, it then sends the aggregated and updated model parameters to all compute nodes via multicast (pull operation). However, in actual implementations, this one-to-many aggregation communication is usually implemented using unicast. That is, the server needs to distribute multiple copies of the same model parameters to multiple worker nodes (i.e., compute nodes) via unicast. This means that the model parameter distribution process from the service node to the compute nodes not only involves bandwidth contention but also generates redundant traffic, resulting in significant bandwidth resource redundancy.

[0004] While multicast technology can theoretically reduce bandwidth consumption, existing solutions suffer from two major drawbacks: First, traditional protocols (such as PIM) require maintaining complex multicast state information in network nodes, leading to excessive equipment load and limited scalability. Second, multiple multicast trees corresponding to different training tasks or multi-stage sub-tasks of the same task lack a dynamic coordination mechanism, easily causing path conflicts and resource contention, further exacerbating communication latency and congestion. These problems limit the scalability of distributed training, increase energy costs, and may cause task interruptions or performance fluctuations due to network fluctuations. Therefore, a lightweight, self-coordinating multicast routing mechanism capable of intelligently optimizing paths is urgently needed to overcome existing communication performance bottlenecks. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a path-aware resource reservation multicast routing method and apparatus to eliminate or improve one or more defects existing in the prior art.

[0006] One aspect of the present invention provides a resource reservation multicast routing method, the method comprising the following steps:

[0007] The first switching node receives a resource reservation request from the service node and floods the resource reservation request to each second switching node connected to each target working node in the same multicast group through each routing path. Each resource reservation request flooded to each second switching node carries the corresponding routing path information.

[0008] Receive each resource reservation request from each second switching node, which is returned along its original path based on each routing path information. Each returned resource reservation request is a resource reservation request carrying the routing path information after determining whether each routing path reserves the requested resource based on the set resource reservation logic.

[0009] Each resource reservation request, carrying routing path information following the reserved resource, is sent to the service node. This enables the service node to aggregate the routing path information following the reserved resource carried in each resource reservation request to generate a representation of the multicast tree. Based on the representation of the multicast tree, the data to be multicast is multicast to each target worker node.

[0010] In some embodiments of the present invention, each routing path is formed by connecting the ports of each switching node, the switching node including multiple ports, and the routing path information including the ID information and port address information of each switching node in the routing path.

[0011] In some embodiments of the present invention, during the flooding process, the resource reservation request received by the first switching node is forwarded by each switching node in each routing path based on its respective multicast forwarding rules. The switching nodes include spine switches or leaf switches, and the multicast forwarding rules include:

[0012] When the leaf switch receives a resource reservation request from a service node, the leaf switch forwards the resource reservation request to each spine switch connected to the leaf switch.

[0013] When the spine switch receives a resource reservation request from the leaf switch, the spine switch forwards the resource reservation request to each leaf switch connected to each target worker node in the same multicast group.

[0014] In some embodiments of the present invention, the resource reservation logic includes:

[0015] For each port of each switching node, if the available resources of the port can meet the resources required by the resource reservation request, then the resource reservation request is executed based on the resource reservation request.

[0016] If there are multiple resource reservation requests on the shared link where the port is located, and the available resources of the port can meet the resources required by the multiple resource reservation requests, then the resource reservation request is executed based on the resource reservation request that arrives at the shared link first.

[0017] If the available resources on the port cannot meet the resources required by the resource reservation request, then the resource reservation request is discarded and the resources already reserved in the routing path corresponding to the resource reservation request are released.

[0018] If the first switching node receives multiple resource reservation requests returned along multiple equivalent routing paths that can reach the same target working node, it executes the requested resource reservation based on the resource reservation request that arrives at the first switching node first, rejects each of the multiple resource reservation requests except for the executed resource reservation request, and releases the resources already reserved in each of the corresponding routing paths.

[0019] In some embodiments of the present invention, resource reservation requests carrying routing path information following the reserved resource requests are sent to the service node, so that the service node can aggregate the routing path information following the reserved resource requests carried in each resource reservation request to generate a representation of the multicast tree, and multicast the data to be multicast to each target worker node based on the representation of the multicast tree, including:

[0020] Each resource reservation request, carrying routing path information following the reserved resource request, is sent to the service node. This enables the service node to aggregate the routing path information following the reserved resource request in each resource reservation request to generate a representation of the multicast tree. Based on the representation of the multicast tree, the data to be multicast is forwarded hop-by-hop to each target working node. During the hop-by-hop forwarding control multicast process, the data to be multicast is forwarded by each switching node based on its respective forwarding table. The forwarding table includes keys, corresponding forwarding masks, and port numbers. The keys represent the bit string encoding of the outgoing link of the switching node's outgoing port, and a bitwise AND operation is performed with the multicast tree representation to determine whether the data is forwarded through that outgoing link. The forwarding masks represent the result of a bitwise OR operation performed on the bit string encodings of each link reachable from the outgoing port in the network, and the multicast branch routing path of the outgoing port is extracted from the multicast tree representation.

[0021] In some embodiments of the present invention, the representation of the multicast tree includes the multicast packet bit string encoding obtained after the multicast tree is encoded and converted. The multicast packet bit string encoding is obtained by performing a bitwise OR operation on the bit string encoding of each link in each routing path after the reserved request resource contained in the multicast tree. In the bit string encoding of each link, the index position of each link is set to 1, and the remaining positions are set to 0. The length of the link encoding bit string is related to the number of links.

[0022] In some embodiments of the present invention, the method further includes:

[0023] The system receives resource release and state reset notification packets from service nodes, enabling each switching node to release the reserved resources in each routing path after the reserved requested resources are released based on the resource release notification packet, and enabling the first switching node to reset the requested resource reservation state information of the equivalent routing path recorded in the first switching node based on the state reset notification packet. The resource release notification packet and the multicast tree have the same representation, and are distinguished from the multicast tree representation by the packet type field.

[0024] Another aspect of the present invention provides a resource reservation multicast routing apparatus, the apparatus comprising: a computer device including a processor and a memory, the memory storing computer instructions, the processor executing the computer instructions stored in the memory, and the apparatus implementing the steps of the aforementioned method when the computer instructions are executed by the processor.

[0025] Another aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned method.

[0026] Another aspect of the present invention provides a computer program product including computer instructions that, when executed by a processor, implement the steps of the aforementioned method.

[0027] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0028] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0029] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.

[0030] Figure 1 This is a schematic diagram of the overall architecture of path-aware multicast in one embodiment of the present invention;

[0031] Figure 2 This is a flowchart illustrating a resource reservation multicast routing method in one embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of a resource reservation request flooding initiated by a service node in a two-layer ridge-leaf topology according to an embodiment of the present invention;

[0033] Figure 4 This is a schematic diagram of bandwidth reservation and multicast tree generation in one embodiment of the present invention;

[0034] Figure 5 This is a schematic diagram of hop-by-hop forwarding control based on multicast tree path in one embodiment of the present invention;

[0035] Figure 6 This is a schematic diagram of the existing packet format used for unicast.

[0036] Figure 7 This is a schematic diagram of the message format of a data packet used for multicast synchronization in one embodiment of the present invention;

[0037] Figure 8 This diagram illustrates the average pull rate of the multicast data under different target computing nodes in a single multicast group for two strategies: unicast and path-aware multicast according to the present invention.

[0038] Figure 9This diagram illustrates the bandwidth variance of the uplink of the ToR switch connected to the service node under two strategies: traditional multicast and path-aware multicast according to this invention.

[0039] Figure 10 This diagram illustrates the speedup of pull operations between the path-aware multicast strategy and the unicast strategy in an embodiment of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0041] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0042] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0043] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0044] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0045] To overcome communication performance bottlenecks in applications such as distributed training, this invention proposes a path-aware resource reservation multicast routing method and apparatus. Before each parameter pull operation initiated by a target worker node or computing node, and before the service node synchronizes the aggregated and updated model parameters and other data traffic to multiple target worker nodes, the service node first sends a resource reservation request signaling. By querying the available multicast tree (multicast can also be called a multicast tree) and reserving or pre-booking network resources, the service node forwards the data traffic to be synchronized according to the predetermined multicast path. This enables dynamic awareness of the multicast forwarding path. In each iteration of distributed training, the multicast synchronization stream of model parameters is switched to a low-load forwarding path, thereby reducing path conflicts, improving link load balancing, and increasing the speed of distributed training.

[0046] This method draws on the concept of circuit switching and is designed to address the characteristic of periodic on-off traffic patterns in communication loads in application scenarios such as distributed training. Figure 1 This is a schematic diagram of the overall architecture of path-aware multicast in one embodiment of the present invention. Figure 1 As shown, the network includes service nodes, worker nodes, and switching nodes. Service nodes communicate with worker nodes through the switching nodes and the routing paths formed between them. Service nodes can be servers or other devices; worker nodes can be computing devices, also called compute nodes; and switching nodes can be switches. The switching nodes connected to the service nodes and worker nodes can be top-of-rack (ToR) switches, such as... Figure 1 The switch 1 is connected to the service node, and switches 5 and 6 are connected to the two worker nodes respectively.

[0047] Figure 2 This is a flowchart illustrating a resource reservation multicast routing method according to an embodiment of the present invention. Figure 2 As shown, the method includes the following steps:

[0048] In step S210, the first switching node receives a resource reservation request from the service node and floods the resource reservation request to each second switching node connected to each target working node in the same multicast group through each routing path. Each resource reservation request flooded to each second switching node carries the corresponding routing path information.

[0049] In this step, the first switching node connects to the service node, and each second switching node connects to a different worker node. Both the first and second switching nodes can be ToR switches. Each target worker node is a worker node in the same multicast group that needs to receive multicast data sent by the service node. Each routing path is formed by connecting the ports of each switching node, and each switching node has multiple ports. Each switch has multiple ports, and connecting different ports of one switch to another will form different links, thus creating different routing paths. Each routing path consists of multiple links. For example... Figure 1 As shown, switch 1 is connected to switch 2, switch 3, and switch 4 through three different ports. The routing path from switch 1 to switch 5 via switch 2 is formed by the link between switch 1 and switch 2 and the link between switch 2 and switch 5.

[0050] The flooding mechanism in this step aims to achieve precise coverage of the target routing path. Theoretically, this means ensuring resource reservation requests cover the entire network to attempt to acquire available bandwidth resources, thereby pre-reserving bandwidth resources for multicast transmission of data to be multicast. Since network flooding essentially involves indiscriminately broadcasting or forwarding data packets to every node in the network, it can lead to network congestion and a large amount of redundant data transmission. However, this method only needs to cover the complete routing path from the service node to each rack top switch connected to each target worker node in the multicast group (also known as the multicast group). It does not need to reserve bandwidth resources for paths not connected to target worker nodes or connecting to non-target worker nodes (worker nodes not in the same multicast group or worker nodes in the same multicast group that do not receive multicast data), thus minimizing network congestion and redundant traffic. To this end, this invention sets and deploys dedicated multicast forwarding rules at each switching node, ensuring that all resource reservation requests are sent from ports other than the ingress port (the port from which the request enters the switch) during forwarding, thereby avoiding loops. During the flooding process, each switching node in each routing path forwards the resource reservation request based on its own multicast forwarding rules. The switching nodes involved in the network of this invention include two types of switches: spine switches and leaf switches. The multicast forwarding rules specifically include the following:

[0051] For a leaf switch, when the leaf switch receives a resource reservation request from a service node, the leaf switch forwards the resource reservation request to each spine switch connected to the leaf switch.

[0052] For a spine switch, when the spine switch receives a resource reservation request from a leaf switch, the spine switch forwards the resource reservation request to each leaf switch connected to each target worker node in the same multicast group.

[0053] Figure 3 This is a schematic diagram illustrating the flooding of resource reservation requests initiated by service nodes in a two-layer spine-leaf topology according to an embodiment of the present invention. Figure 3 As shown, leaf switch L1 receives a resource reservation request initiated by server Server0 and forwards the request to all spine switches S1 and S2 connected to L1. Spine switches S1 or S2, upon receiving the request, then forward it to leaf switches L2 and L3, which are respectively connected to target worker nodes Worker0 and Worker1 within the same multicast group. Therefore, during network flooding, the resource reservation request injected into the network by server Server0 has two routing paths to reach the target worker nodes Worker0 and Worker1 in the same multicast group: L1-S1-L2 and L1-S2-L2, and L1-S1-L3 and L1-S2-L3. Regarding... Figure 1 The multicast group shown has two target worker nodes. Based on the multicast forwarding rules deployed in the switching nodes, the paths from the serving node to one of the target worker nodes include three routing paths: 1-2-5, 1-3-5, and 1-4-5. Similarly, the paths to the other target worker node include three routing paths: 1-2-6, 1-3-6, and 1-4-6. These multicast forwarding rules ensure that resource reservation requests from the serving node are forwarded only to ToR switches connected to the target worker nodes within the same multicast group.

[0054] In each switch, multicast forwarding rules are implemented in the form of multicast tables. Specifically, leaf switches forward resource reservation requests from service nodes through multiple outgoing ports; spine switches use the multicast group identifier (Multicast_Group ID) carried in the resource reservation request header as the key of the multicast table and forward resource reservation requests only through preset designated outgoing ports. In distributed training scenarios, since the location of the target computing node is fixed, these forwarding rules can be pre-derived and deployed to the corresponding switches before the training task starts.

[0055] In some embodiments, the routing path information includes the ID information and port address information of each switching node in the routing path.

[0056] The resource reservation mechanism in this method is triggered when the resource reservation request returns to the service node from the rack top switch connecting the target working node along the original path. Successfully returned resource reservation requests need to carry the path information to assist the service node in building the multicast tree. Therefore, during the request flooding process, each switching node must record its routing path information in the corresponding resource reservation request. This routing path information can include two key pieces of information: first, the ingress port ID information of each switch along the routing path, which serves as the source routing data to guide the request back along the original path. This port ID information is gradually popped out each time the request passes through a switch to reduce header overhead; second, the switch ID information during the flooding process, which is completely retained in the resource reservation request. This information is used to generate an end-to-end bandwidth resource reservation path and build the final multicast tree after the request returns to the service node. Therefore, each resource reservation request flooded to each second switching node carries the corresponding routing path information.

[0057] Unlike classic Inband Network Telemetry (INT), which records only a single metric (such as queue depth or latency), this method records both switch ID information and port address (ID) information, constructing two hop-by-hop increasing stack structures in the packet header. Specifically, for example, in a P4 switch implementation, each switch first extracts the port stack information into the Packet Header Vector (PHV) and performs a push operation within the PHV; simultaneously, it directly performs a push operation on the original switch stack portion of the packet. Finally, in the P4 switch's Deparser (packet encapsulation) stage, the packet header carrying the port stack and the packet header carrying the switch stack are integrated.

[0058] Step S220: Receive each resource reservation request from each of the second switching nodes, which are returned along their respective original paths based on each routing path information. Each returned resource reservation request is a resource reservation request that carries the information of each routing path after determining whether to reserve the requested resources based on the set resource reservation logic.

[0059] In this method, the flooding process ends once the resource reservation requests reach the respective ToR switches connected to each target worker node. Subsequently, each resource reservation request that reaches the respective ToR switches connecting to each target worker node returns along its original path and is source-routed based on the corresponding port ID information to attempt to reserve bandwidth resources on each switch it passes through hop by hop. Since the flooding phase covers all possible routing paths to each target worker node through dedicated multicast forwarding rules, the returned resource reservation requests can initiate resource reservation attempts on all possible routing paths from the service node to each target worker node. Figure 4 This diagram illustrates bandwidth reservation and multicast tree generation in one embodiment of the present invention, showing all reachable paths from the service node Server0 to the two target computing nodes Worker0 and Worker1. Each reachable path corresponds to a return request packet initiating resource reservation, i.e., a returned resource reservation request data packet. However, some requests may fail to be reserved successfully due to insufficient bandwidth resources on the switch port, thus failing to meet the requested bandwidth resources.

[0060] Therefore, in some embodiments, the resource reservation logic in step S220 may specifically include the following:

[0061] For each port of each switching node, if the available resources of the port can meet the resources required by the resource reservation request, then the resource reservation request is executed based on the resource reservation request.

[0062] If there are multiple resource reservation requests on the shared link where the port is located, and the available resources of the port can meet the resources required by the multiple resource reservation requests, then the resource reservation request is executed based on the resource reservation request that arrives at the shared link first.

[0063] If the available resources on the port cannot meet the resources required by the resource reservation request, then the resource reservation request is discarded and the resources already reserved in the routing path corresponding to the resource reservation request are released.

[0064] If the first switching node receives multiple resource reservation requests returned along multiple equivalent routing paths that can reach the same target working node, it executes the requested resource reservation based on the resource reservation request that arrives at the first switching node first, rejects each of the multiple resource reservation requests except for the executed resource reservation request, and releases the resources already reserved in each of the corresponding routing paths.

[0065] For example, such as Figure 4As shown, when the available bandwidth of ports 2 and 3 of switch S1 meets the bandwidth resources requested by resource reservation request packets Pkt1 and Pkt2 respectively, ports 2 and 3 directly complete the bandwidth reservation. When there are multiple returned resource reservation requests on the link between port 1 of switch L1 and port 1 of switch S1, the link is a shared link. When there are multiple returned requests Pkt1 and Pkt2 on the shared link, and port 1 of switch L1 meets the bandwidth resources requested by these requests, bandwidth reservation is only based on the first resource reservation request Pkt1 arriving at the shared link, thereby avoiding bandwidth resource redundancy. Generally, it is assumed that the routing path L1-S1-L2 traversed by the request packet Pkt1 that arrives at the shared link first has a low load, good link status, and is relatively uncongested. When the available bandwidth of port 2 of switch L1 is insufficient to satisfy the bandwidth reserved by the resource reservation request packet Pkt3, the request is directly rejected and the reserved resources along the path of the request are released, such as the bandwidth reserved at the corresponding port of the corresponding switch S2. Since the port IDs of the switches traversed in the routing path of Pkt3 have been popped, the request Pkt3 needs to be forwarded back to the ToR switch L3 using the recorded switch ID through the adjacency forwarding table (with the switch ID as the key and the port number of the adjacent switch (i.e., the adjacent switch connected to this switch) before being discarded. In the case of multiple equal-cost routing paths in the network, when the ToR switch L1 receives requests Pkt1 and Pkt4 from two equal-cost routing paths L1-S1-L2 and L1-S2-L2, which can reach the same target compute node Worker0 from the service node Server0, it only selects the less congested and lower path load routing path for bandwidth reservation. Typically, bandwidth is reserved only based on the earliest arriving request, such as Pkt1, while other requests, such as Pkt4, are rejected and the path resources previously reserved for that request are released.

[0066] Therefore, the resource reservation request successfully returned from the second exchange node to the first exchange node carries the routing path information after the resource reservation request was successfully reserved based on the above resource reservation logic.

[0067] Step S230: Send each resource reservation request carrying the routing path information after the reserved request resource to the service node, so that the service node can aggregate the routing path information after the reserved request resource carried in each resource reservation request to generate a representation of the multicast tree, and multicast the data to be multicast to each target working node based on the representation of the multicast tree.

[0068] After step S220, the ToR switch connected to the service node successfully sends a request to the service node, meaning each request successfully returned to the service node carries a route path information for which bandwidth reservation has been completed. Upon receiving the returned request packets indicating successful bandwidth reservation, the service node first parses the route path information carried in each request packet, then aggregates this route path information to generate a multicast tree that meets the bandwidth requirements. For example... Figure 1 As shown, the multicast tree is formed by switching nodes ①-③-⑤ and ①-③-⑥. Since routing path information is represented by switch IDs and switch port IDs, it is necessary to convert the switching nodes in the multicast tree into link information for subsequent forwarding. Then, a representation of the multicast tree is generated based on the multicast tree. Specifically, this involves converting the multicast tree encoding represented by link information into an equivalent bit string encoding, i.e., obtaining the multicast packet bit string encoding. This provides support for the subsequent implementation of stateless multicast based on hop-by-hop forwarding control in the data plane. Finally, the serving node performs a pull operation, which involves encapsulating the updated model parameters, the multicast data to be multicast, and the multicast packet bit string encoding using the BIER (Bit Index Explicit Replication) multicast protocol to obtain an improved BIER packet. This improved BIER packet (containing the data to be multicast) is then synchronously and multicasted along the multicast tree path specified by the multicast packet bit string encoding to all target working nodes in the multicast group.

[0069] Specifically, the service node sends resource reservation requests carrying routing path information after the reserved resource requests to each resource reservation request, so that the service node can aggregate the routing path information after the reserved resource requests carried in each resource reservation request to generate a representation of the multicast tree, and multicast the data to be multicast to each target worker node based on the representation of the multicast tree, including the following steps:

[0070] Each resource reservation request, carrying routing path information following the reserved resource request, is sent to the service node. This enables the service node to aggregate the routing path information following the reserved resource request in each resource reservation request to generate a representation of the multicast tree. Based on the representation of the multicast tree, the data to be multicast is forwarded hop-by-hop to each target working node. During the hop-by-hop forwarding control multicast process, the data to be multicast is forwarded by each switching node based on its respective forwarding table. The forwarding table includes keys, corresponding forwarding masks, and port numbers. The keys represent the bit string encoding of the outgoing link of the switching node's outgoing port, and a bitwise AND operation is performed with the multicast tree representation to determine whether the data is forwarded through that outgoing link. The forwarding masks represent the result of a bitwise OR operation performed on the bit string encodings of each link reachable from the outgoing port in the network, and the multicast branch routing path of the outgoing port is extracted from the multicast tree representation.

[0071] In some embodiments, the representation of the multicast tree includes the multicast packet bit string encoding obtained after encoding conversion of the multicast tree. The multicast packet bit string encoding is obtained by performing a bitwise OR operation on the bit string encoding of each link in each routing path after the reserved request resource included in the multicast tree. In the bit string encoding of each link, the index position of each link is set to 1, and the remaining positions are set to 0. The length of the link encoding bit string is related to the number of links.

[0072] BIER is a recently proposed multicast protocol that encodes multicast destinations as bit strings in the packet header. Intermediate forwarding nodes do not need to maintain multicast state; instead, they simply copy and forward packets based on the bit strings contained in the packet header. However, because the multicast tree in BIER is predetermined, it is difficult for BIER to quickly adapt to sudden changes in network state, such as link failures. Furthermore, when multiple multicast trees from different training tasks share the same path segment, the stateless BIER, due to its lack of coordination, cannot flexibly resolve the resulting bandwidth contention problem.

[0073] Unlike traditional BIER methods that encode the target working node address, this method encodes each link in the entire network and achieves hop-by-hop multicast forwarding control by explicitly specifying the bit string in the header of the multicast packet and querying the forwarding table of each switching node. The length of the link encoding bit string depends on the number of links in the network. In the link bit string encoding, the index position of the link is set to 1, and all other positions are set to 0. For example, Figure 5 This is a multicast schematic diagram of hop-by-hop forwarding control based on multicast tree paths in one embodiment of the present invention, as shown below. Figure 5As shown, the network contains 7 links. The bit string encoding of link 1 is 1000000, the bit string encoding of link 2 is 0100000, and so on, yielding the corresponding bit string encodings for all 7 links. The multicast tree is formed by switches ABE, ABF, and ACG. The multicast packet bit string encoding is 1101110, obtained by performing a bitwise OR operation on the bit string encodings of all links 1, 2, 4, 5, and 6 involved in the forwarding within this multicast tree. In the stateless multicast process of hop-by-hop forwarding control based on the multicast tree path, each forwarding node (switching node) needs a forwarding table to guide the forwarding of improved BIER packets. For switch B, the forwarding table B contains three keys and three corresponding values. Each value includes a forwarding mask (F-BM) and the output port number of the forwarded packet. The three keys are the bit string codes of outgoing links 1, 4, and 5 of ports 1-3 of switch B, namely 1000000, 0001000, and 0000100. The keys are used to perform a bitwise AND operation with the multicast packet bit string code to determine whether to forward the data packet through the corresponding link. If the result of the bitwise AND operation is the same as the bit string code of the corresponding link, then it is determined that the data will be forwarded through that link; otherwise, the data will not be forwarded through that link. The three port numbers corresponding to the three keys mentioned above are port1-3, and the three F-BMs are 1110011, 0001000, and 0000100, respectively. The F-BMs are used to extract the multicast branch routing path for the corresponding outgoing port from the multicast packet bit string encoding. Since the links reachable through outgoing port1 are 1-3 and 6-7 in the network, 1110011 is obtained by performing a bitwise OR operation on the bit string encodings of links 1, 2, 3, and 6, 7. Since only link 4 is reachable through outgoing port2, its F-BM is the bit string encoding of link 4. Similarly, the F-BM for outgoing port3 is the bit string encoding of link 5. Similarly, the forwarding tables for switches A and C can be obtained.

[0074] When the multicast packet bit string encoding 1101110 matches a forwarding table entry, that is, after performing a bitwise AND operation between the multicast packet bit string encoding and each key in the forwarding table of the switch AD, 1101110 matches multiple keys such as 1000000 and 0100000 in forwarding table A, and 0001000 and 0000100 in forwarding table B. It can be seen that the multicast packet bit string encoding 1101110 is forwarded through the three routing paths formed by links 1 and 4, 1 and 5, and 2 and 6 respectively. In each path, the multicast packet bit string encoding is sequentially ANDed with each F-BM corresponding to each link to generate a new bit string encoding. For example, the new bit string encoding generated by performing a bitwise AND operation between the multicast packet bit string encoding and the F-BM corresponding to link 1 is then ANDed with the F-BM corresponding to link 4 to generate an updated bit string encoding. Furthermore, the index bits of the corresponding links in the new bit string encoding need to be cleared (set to 0) to avoid loops. When the data packet reaches the last-hop switch E, F, or G, all bits in the final generated bit string encoding are cleared. Afterward, the data packet is forwarded to the corresponding target working nodes through the built-in forwarding tables of the ToR switches E, F, and G.

[0075] Figure 6 This is a schematic diagram of the existing packet format used for unicast. Figure 7 This is a schematic diagram of the packet format for multicast synchronization in one embodiment of the present invention. In the pull operation of the unicast strategy, taking a typical Ethernet network card as an example, as follows... Figure 6 As shown, the packet used for forwarding transmission consists of an Ethernet header, an IP (IPv4) header, a TCP header, and a payload (model parameters awaiting unicast data). In this method, the improved BIER packet format is as follows: Figure 7 As shown, a bit string header is added between the Ethernet header and the IP header. This bit string header can be encapsulated in a similar way to the BIER header, namely Modified_BIER. The difference is that the bit string in the BIER header in this method is replaced with the aforementioned multicast packet bit string encoding. In addition, Ether_Type will be set to other identifiers to distinguish BIER for forwarding.

[0076] It should be noted that the operations of parsing request packets, generating multicast packet bit string encoding, and embedding multicast packet bit string encoding into the Ethernet header and IP header can be offloaded to the smart network interface card.

[0077] In some embodiments, the method further includes the following steps:

[0078] The system receives resource release and state reset notification packets from service nodes, enabling each switching node to release the reserved resources in each routing path after the reserved requested resources are released based on the resource release notification packet, and enabling the first switching node to reset the requested resource reservation state information of the equivalent routing path recorded in the first switching node based on the state reset notification packet. The resource release notification packet and the multicast tree have the same representation, and are distinguished from the multicast tree representation by the packet type field.

[0079] After distributing the multicast data to each target worker node through the routing paths following successful resource reservation requests, the service node sends a resource release notification packet to the rack top switch (first switching node) connected to it. This causes each switching node in the aforementioned paths to release the reserved bandwidth resources in the multicast paths, i.e., the bandwidth resources that have been pre-booked or reserved at each port of the corresponding switching node. This notification packet has the same bit string encoding as the multicast packet bit string encoding, but is distinguished by the packet type field. Furthermore, to address the resource reservation request redundancy issue caused by multiple equivalent paths between the service node and the target compute nodes, this method introduces a mechanism where the ToR switch connected to the service node selects resource reservation requests (one of the logics involved in the resource reservation logic involves an equivalent routing path problem). However, this mechanism retains the corresponding resource reservation status information for the selected equivalent path in the ToR switch. Therefore, after each round of multicast data multicasting, synchronization and distribution is completed, another state reset notification packet needs to be sent from the service node to the first switching node to trigger the state information reset in the ToR switch that is the first switching node, in order to avoid memory leaks and errors in the multicast tree calculation in the next round.

[0080] Corresponding to the above method, the present invention also provides a resource reservation multicast routing device, which includes a computer device, the computer device including a processor and a memory, the memory storing computer instructions, the processor executing the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the device implements the steps of the aforementioned method.

[0081] In summary, the path-aware resource reservation multicast routing method and apparatus provided by this invention involves a service node sending a bandwidth resource reservation request to the switch connected to it before the computing node initiates a parameter pull operation. This request is flooded through the network to the switches connected to the computing node to detect network bandwidth availability. Multiple switches are configured in the network between the switches connected to the service node and the computing node, respectively. During the flooding process, the request performs path probing to avoid link failure areas and records path information along the way. When the request successfully reaches the last-hop switch, it returns along the original path and attempts to complete the bandwidth reservation. During this process, each forwarding node on the return path performs multicast tree pruning, i.e., filtering redundant or unmet resource reservation requests. The finally approved resource reservation request returns to the service node carrying path information, which is then aggregated and converted into a multicast packet bit string encoding. Subsequently, the updated model parameters and the waiting multicast data and multicast packet bit string encoding are encapsulated to obtain an improved BIER data packet, enabling the multicast data to be transmitted along the multicast tree path specified by the multicast packet bit string encoding. Once the pull operation is complete, the service node sends a notification packet to release the reserved bandwidth and equivalent path status information for reuse by subsequent tasks or the next round of tasks.

[0082] Finally, simulation verification was performed: To evaluate the performance of the path-aware resource reservation multicast routing (also known as path-aware multicast) scheme provided in this embodiment of the invention, the simulation experimental parameters used are shown in Table 1 below:

[0083] Table 1 Mininet simulation experiment parameters

[0084]

[0085] Simulation results show that the path-aware multicast scheme provided in this embodiment of the invention achieves the following performance improvements:

[0086] (1) The path-aware multicast scheme of the present invention realizes one-to-many set communication, reduces redundant data streams, and improves scalability. Figure 8 This diagram illustrates the average pull rate of the multicast data under different target computing nodes in a single multicast group, using both unicast and path-aware multicast strategies according to embodiments of the present invention. Figure 8 As shown, the path-aware multicast scheme of this invention has good scalability. In contrast, unicast strategies encounter significant bandwidth resource contention, especially between the serving node and its adjacent (connected) rack-top switches. This contention intensifies as the number of target computing nodes increases.

[0087] (2) The path-aware multicast scheme in this embodiment of the invention improves link load balancing. Figure 9 This diagram illustrates the uplink bandwidth variance of the ToR switches connected to service nodes under two strategies: traditional random multicast and path-aware multicast according to this embodiment of the invention. It demonstrates the advantages of the path-aware multicast strategy in link load balancing compared to the traditional random multicast strategy. In this simulation experiment, multiple servers construct multiple multicast trees corresponding to multiple different training tasks. All service nodes are connected to the same rack top switch, and each multicast group contains two target worker nodes, which are randomly distributed across any rack top switch other than the one connected to the service node. The bandwidth occupancy variance of multiple uplinks on the ToR switch on the service node side is used as an evaluation metric to obtain the link load balancing effect. Figure 9 As shown, when the number of multicast trees is small, link load imbalance is likely to occur; however, as the number of multicast trees increases, the link load balance is significantly improved. Furthermore, the path-aware multicast scheme achieves better load balancing than the traditional random multicast scheme, improving it by approximately 32.6%. This is because the path-aware multicast scheme can allocate bandwidth more efficiently by strategically reserving bandwidth based on real-time link occupancy.

[0088] (3) The pull operation in the path-aware multicast scheme of this invention is accelerated by nearly N times. Figure 10 This diagram illustrates the speedup of pull operations for a path-aware multicast strategy compared to a unicast strategy, as described in this embodiment of the invention. Specifically, it shows the speedup of pull operations for a path-aware multicast scheme compared to a unicast scheme when four target compute nodes are deployed under four rack-top switches. The speedup ratio is used to evaluate the efficiency improvement of multicast transmission over unicast transmission. Theoretically, when there are N target compute nodes, the speedup ratio of multicast can reach N. However, due to the additional overhead caused by bandwidth reservation in the multicast tree, the actual speedup ratio will be lower than N. However, when the number of target compute nodes and their deployment locations are fixed, the bandwidth reservation overhead becomes a fixed value. Therefore, as the scale of the model parameters (data to be multicast) increases, the proportion of the total bandwidth used for additional overhead will gradually decrease, eventually causing the speedup ratio to approach the ideal value N.

[0089] Therefore, the path-aware multicast scheme proposed in this invention effectively solves the communication bottleneck of unicast and the problems of model parameter allocation in distributed training scenarios by supporting multicast tree preservation and hop-by-hop multicast control within the network. By periodically and dynamically reserving bandwidth and coordinating the multicast tree, link load balancing is improved, and the model parameter allocation speed is accelerated. Hop-by-hop multicast control extends the stateless BIER and introduces minimal overhead to the data plane. Simulation results show that this collective communication method achieves significant performance improvement under the PS architecture.

[0090] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned method. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0091] This invention also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the aforementioned method.

[0092] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0093] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0094] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0095] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A resource reservation multicast routing method, characterized in that, The method includes: The first switching node receives a resource reservation request from the service node and floods the resource reservation request to each second switching node connected to each target working node in the same multicast group through each routing path. Each resource reservation request flooded to each second switching node carries the corresponding routing path information. The system receives resource reservation requests from each of the second switching nodes, which are returned along their respective original paths based on the routing path information. Each returned resource reservation request is a resource reservation request carrying the requested resource information of each routing path after determining whether each routing path should reserve the requested resource based on a set resource reservation logic. The resource reservation logic includes: for each port of each switching node, if the available resources of the port can meet the resource requirements of the resource reservation request, then the requested resource is reserved based on the resource reservation request; if there are multiple resource reservation requests on the shared link where the port is located, and the available resources of the port can meet the multiple resource reservation requests... If the first switching node requests the required resources, it executes the resource reservation request based on the resource reservation request that arrives at the shared link first. If the available resources on the port cannot meet the resources required by the resource reservation request, it discards the resource reservation request and releases the resources already reserved in the routing path corresponding to the resource reservation request. If the first switching node receives multiple resource reservation requests returned along multiple equivalent routing paths that can reach the same target working node, it executes the resource reservation request based on the resource reservation request that arrives at the first switching node first, rejects all other resource reservation requests except the executed resource reservation request, and releases the resources already reserved in the corresponding routing paths. Each resource reservation request, carrying routing path information following the reserved resource, is sent to the service node. This enables the service node to aggregate the routing path information following the reserved resource carried in each resource reservation request to generate a representation of the multicast tree. Based on the representation of the multicast tree, the data to be multicast is multicast to each target worker node.

2. The method according to claim 1, characterized in that, Each routing path is formed by connecting the ports of each switching node. Each switching node includes multiple ports. The routing path information includes the ID information and port address information of each switching node in the routing path.

3. The method according to claim 2, characterized in that, During the flooding process, the resource reservation requests received by the first switching node are forwarded by each switching node in each routing path based on their respective multicast forwarding rules. The switching nodes include spine switches or leaf switches, and the multicast forwarding rules include: When the leaf switch receives a resource reservation request from a service node, the leaf switch forwards the resource reservation request to each spine switch connected to the leaf switch. When the spine switch receives a resource reservation request from the leaf switch, the spine switch forwards the resource reservation request to each leaf switch connected to each target worker node in the same multicast group.

4. The method according to claim 2, characterized in that, Sending resource reservation requests carrying routing path information after the reserved resource requests to the service nodes, so that the service nodes can aggregate the routing path information after the reserved resource requests carried in each resource reservation request to generate a representation of the multicast tree, and multicast the data to be multicast to each target worker node based on the representation of the multicast tree, including: Each resource reservation request, carrying routing path information following the reserved resource request, is sent to the service node. This enables the service node to aggregate the routing path information following the reserved resource request in each resource reservation request to generate a representation of the multicast tree. Based on the representation of the multicast tree, the data to be multicast is forwarded hop-by-hop to each target working node. During the hop-by-hop forwarding control multicast process, the data to be multicast is forwarded by each switching node based on its respective forwarding table. The forwarding table includes keys, corresponding forwarding masks, and port numbers. The keys represent the bit string encoding of the outgoing link of the switching node's outgoing port, and a bitwise AND operation is performed with the multicast tree representation to determine whether the data is forwarded through that outgoing link. The forwarding masks represent the result of a bitwise OR operation performed on the bit string encodings of each link reachable from the outgoing port in the network, and the multicast branch routing path of the outgoing port is extracted from the multicast tree representation.

5. The method according to any one of claims 1 to 4, characterized in that, The representation of the multicast tree includes the multicast packet bit string encoding obtained after the multicast tree is encoded. The multicast packet bit string encoding is obtained by performing a bitwise OR operation on the bit string encoding of each link in each routing path after the reserved request resources contained in the multicast tree. In the bit string encoding of each link, the index position of each link is set to 1, and the other positions are set to 0. The length of the link encoding bit string is related to the number of links.

6. The method according to claim 1, characterized in that, The method further includes: The system receives resource release and state reset notification packets from service nodes, enabling each switching node to release the reserved resources in each routing path after the reserved requested resources are released based on the resource release notification packet, and enabling the first switching node to reset the requested resource reservation state information of the equivalent routing path recorded in the first switching node based on the state reset notification packet. The resource release notification packet and the multicast tree have the same representation, and are distinguished from the multicast tree representation by the packet type field.

7. A resource reservation multicast routing device, comprising a processor, a memory, and computer instructions stored in the memory, characterized in that, The processor is configured to execute the computer instructions, and when the computer instructions are executed, the device implements the steps of the method as described in any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method as described in any one of claims 1 to 6.

9. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1 to 6.

Images