Multicast network traffic scheduling method and system, electronic device and readable medium

Abstract

This disclosure provides a multicast network traffic scheduling method, system, electronic device, and readable medium, belonging to the field of communications. The method includes: dividing the uplink of an access node into multiple link groups, each link group containing multiple uplinks corresponding to the same relay node; and dividing multiple downlink multicast sources from the access node into multiple source groups; constructing a weight matrix, where rows correspond to source groups and columns correspond to relay nodes; and determining unicast routes for each source group based on the weight matrix, so that each source group selects the node with the highest weight among multiple relay nodes as the traffic-carrying node, thereby distributing traffic from different source groups to different relay nodes. The multicast network traffic scheduling method, system, electronic device, and readable medium provided in this disclosure can achieve load balancing and reduce congestion risk; simultaneously, it can be implemented using conventional routing strategies without changing the terminal and multicast protocol, resulting in low modification costs and strong scalability.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and specifically relates to a multicast network traffic scheduling method, system, electronic device, and readable medium. Background Technology

[0002] In common multicast video streaming scenarios, multicast terminals are typically connected to access switches, which in turn connect upstream to a high-capacity aggregation switch. This aggregation switch leverages its high bandwidth to ensure non-blocking and packet-loss-free transmission of multicast services. This single-aggregation-node architecture is prevalent in traditional network designs and can effectively handle multicast traffic, but it also exposes a series of problems.

[0003] First, due to economic constraints, users often face the dilemma of high-bandwidth chassis aggregation equipment being expensive. While these chassis devices offer powerful performance, their high procurement and maintenance costs lead many users to prefer using general-purpose box switches to build multicast networks, thereby reducing overall investment. However, box switches have relatively limited bandwidth and capacity and cannot directly replace chassis devices, thus limiting their application in large-scale multicast networks.

[0004] Secondly, the design of a single aggregation node lacks redundancy. If this aggregation node fails, the entire network service will be interrupted, causing severe impact. To ensure redundancy, users might consider using multiple high-bandwidth chassis devices to form a stacked system, but this further increases costs because stacking requires additional interconnect resources and configuration complexity.

[0005] In existing technologies, stacking technology is a common practice for implementing high-bandwidth aggregation devices, but this technology has significant drawbacks. Because the cross-board bandwidth of stacked devices is limited, increasing the cross-board bandwidth can only be achieved by increasing the number of interconnect ports on the stacked devices. This not only reduces the number of service ports available for multicast service interconnection, resulting in significant port waste, but also leads to poor scalability and difficulty in expansion of the stacked system. Summary of the Invention

[0006] The purpose of this disclosure is to provide a multicast network traffic scheduling method, system, electronic device, and readable medium that can build large-scale multicast networks using box-type devices, saving costs while achieving high redundancy and high scalability.

[0007] To achieve the above objectives, the technical solution provided in this disclosure is as follows:

[0008] In a first aspect, this disclosure provides a multicast network traffic scheduling method applied to a multi-node relay network, wherein the multi-node relay network includes multiple access nodes and multiple relay nodes, and the multicast network traffic scheduling method includes:

[0009] The uplink of the access node is divided into multiple link groups, and each link group contains multiple uplinks corresponding to the same relay node. The multiple multicast sources downlink from the access node are also divided into multiple source groups. A weight matrix is ​​constructed, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node. Based on the weight matrix, the unicast route for each source group is determined, so that each source group selects the node with the highest weight among multiple relay nodes as the traffic-carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

[0010] In one or more embodiments, the unicast routing is controlled by a routing policy that influences the path comparison results of each relay node, so that the receiving side is consistent with the weight matrix when performing the optimal incoming path selection.

[0011] In one or more embodiments, the multicast network traffic scheduling method further includes: subdividing the source group into multiple source subgroups, and mapping each source subgroup to the uplink in its corresponding link group, so that the traffic of the multiple source subgroups is respectively loaded onto multiple uplinks.

[0012] In one or more embodiments, the multicast network traffic scheduling method further includes: setting different and adjacent priorities for each uplink in a link group mapped to the same relay node, so as to switch the traffic of the source subgroup to other uplinks in the same link group when a link fails.

[0013] In one or more embodiments, in the weight matrix, for any row corresponding to a source group, the maximum weight value in the row appears only in one column, and the weight values ​​in the same row are all different.

[0014] In one or more embodiments, the multicast network traffic scheduling method further includes: when a relay node carrying a source group fails, switching the relay node according to the second largest weight in the row corresponding to the source group in the weight matrix.

[0015] In one or more embodiments, the link between the access node and the relay node is a Layer 3 interconnection structure. The receiving side performs an inbound RPF check on the arriving multicast traffic and then forwards the multicast traffic according to the SPT. The unicast routing controls the routing result of the SPT based on the weight matrix.

[0016] Secondly, this disclosure provides a multicast network traffic scheduling system applied to a multi-node relay network, wherein the multi-node relay network includes multiple access nodes and multiple relay nodes, and the multicast network traffic scheduling system includes:

[0017] The grouping module is used to divide the uplink of the access node into multiple link groups, each link group containing multiple uplinks corresponding to the same relay node, and to divide the multiple multicast sources downlink of the access node into multiple source groups; the weighting module is used to construct a weight matrix, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node; the routing module is used to determine the unicast route for each source group based on the weight matrix, so that each source group selects the relay node with the highest weight among multiple relay nodes as the traffic carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

[0018] Thirdly, this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multicast network traffic scheduling method as described above.

[0019] Fourthly, this disclosure provides a computer-readable medium carrying computer-executable instructions, which, when executed by a processor, are used to implement the multicast network traffic scheduling method described above.

[0020] The multicast network traffic scheduling method, system, electronic device, and readable medium disclosed herein transform multicast bearers from random / centralized to programmable, distributed mappings through source group-relay two-dimensional modeling and weight matrix-driven routing. On the access side, uplinks are grouped into link groups by relays, and multiple sources are grouped into source groups. The control plane uses a weight matrix to determine the optimal unicast direction to the source, ensuring that each source group falls on different relay nodes. The optimal incoming direction then guides the establishment of SPTs along the corresponding relays, thereby achieving cross-relay load balancing and reducing single-point hotspots and congestion risks. At the same time, it can be implemented using conventional routing strategies without changing the terminal and multicast protocol, resulting in low modification costs and strong scalability. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a multicast network traffic scheduling method in one embodiment of the present disclosure;

[0023] Figure 2 This is a schematic diagram of a 4*4 weight matrix in one embodiment of this disclosure;

[0024] Figure 3This is a schematic diagram of a 4*8 weight matrix in one embodiment of this disclosure;

[0025] Figure 4 This is a schematic diagram of the transformed 4*8 weight matrix in one embodiment of this disclosure;

[0026] Figure 5 This is a schematic diagram of an 8*8 weight matrix in one embodiment of this disclosure;

[0027] Figure 6 This is a schematic diagram of a 5*5 weight matrix in one embodiment of this disclosure;

[0028] Figure 7 This is a schematic diagram of an extended weight matrix in one embodiment of the present disclosure;

[0029] Figure 8 This is a schematic diagram of a multicast network traffic scheduling system in one embodiment of this disclosure;

[0030] Figure 9 This is a schematic diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0031] To enable those skilled in the art to better understand the technical solutions in this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this disclosure.

[0032] In traditional network architectures for high-concurrency services such as video multicast, a centralized bearer mode consisting of access switches and high-bandwidth aggregation switches is typically used. With the continuous growth of user scale and service traffic, this mode has exposed several problems: Firstly, high-end aggregation equipment is expensive, and to ensure reliability, multiple chassis-based devices are often stacked, further increasing costs; secondly, stacking solutions are limited by cross-board bandwidth and stack size expansion, resulting in insufficient flexibility during network expansion; furthermore, multicast traffic is concentrated at a single aggregation node, leading to uneven resource utilization and making it easy for network-wide service interruptions to occur in the event of equipment failure.

[0033] The technical approach disclosed herein is to shift from centralized aggregation to multi-node collaboration, achieving distributed balanced load balancing through traffic scheduling. The inventors discovered that although multicast traffic originates from diverse sources on the access side, under existing routing and forwarding mechanisms, it often concentrates through a few nodes, leading to bottlenecks and concentrated risks. If, without altering the basic framework of the existing multicast protocol, a controllable routing strategy can be used to rationally distribute multicast traffic from various sources to different relay nodes while maintaining orderly switching, the problems of bandwidth waste, single-point bottlenecks, and polarization during failover can be effectively solved.

[0034] Based on this understanding, the implementation approach proposed in this disclosure is as follows: Uplinks carrying multicast traffic and multicast sources in the network are grouped for management to clarify the connection relationships under a distributed architecture, laying a structured foundation for subsequent load balancing and switching. A weight matrix-driven traffic scheduling strategy is introduced to map the source and relay relay relationship to a weight distribution, allowing different sources to preferentially select different relay nodes. When a node or link fails, traffic can be distributed and switched according to a predetermined weight order. Then, through weight-based unicast routing, strategic guidance is applied to existing Layer 3 multicast protocols (such as PIM-SM) and their SPT construction mechanisms, ensuring that the routing protocol itself maintains consistency with the designed weight matrix when selecting the optimal inbound path, thus enabling implementation without modifying multicast terminals or protocol stacks.

[0035] The technical solution disclosed herein enables the network to achieve throughput and stability close to that of high-end aggregation equipment while using lower-cost general-purpose equipment, through this transformation from centralized to distributed and from static to schedulable, and also provides better scalability and operational flexibility.

[0036] Please refer to Figure 1 The diagram shown is a flowchart of a multicast network traffic scheduling method according to an embodiment of this disclosure. This multicast network traffic scheduling method can be applied to a multi-node relay network, which includes multiple access nodes and multiple relay nodes.

[0037] Specifically, the multicast network traffic scheduling method is designed for a multi-node relay network consisting of several access nodes and several relay nodes, which communicate with each other using a Layer 3 interconnection structure. In this structure, multicast control and data forwarding follow a layered and decoupled principle: access nodes are responsible for aggregating multicast requests and uploading data from the terminal side, while relay nodes are responsible for multi-point distribution and aggregation on the backbone side. Due to the Layer 3 interconnection, access nodes only need to maintain several Layer 3 uplinks to each relay node, avoiding Layer 2 broadcasting or flooding, and eliminating reliance on stacked backplane capacity to complete replication and forwarding control, thus leaving ample room for subsequent policy-based path selection.

[0038] In this three-layer architecture, multicast control follows the timing sequence from the shared tree to the shortest path tree. The network first forms a shared tree around the aggregation point, and multicast traffic reaches the receiving side along the shared tree path. Upon receiving multicast traffic arriving along the shared tree, the receiving node executes an inbound consistency criterion, i.e., a reverse path forwarding (RPF) check: if the current inbound interface is inconsistent with the optimal unicast outbound interface to the multicast source, it is determined that the inbound direction of the traffic is inconsistent with the optimal inbound direction. Based on this, the receiving side initiates a join request hop-by-hop along the optimal unicast direction, pruning the branches of the original shared tree, thereby constructing a source-oriented shortest path tree. This check and switching process is triggered by the receiving side, enabling a transition from centralized aggregation to distributed bearer without changing the terminal protocol behavior.

[0039] Taking a three-layer spine-leaf network as an example, the leaf node acts as the access node, carrying the access and downlink replication of multicast terminals; the spine node acts as the relay node, undertaking uplink aggregation and multi-point distribution across leaf nodes. The leaf and each spine are interconnected using L3, typically with m×100G parallel uplink links, and the leaf row faces several 10G interfaces; the entire network does not carry replication through Layer 2 flooding, but performs one-time uplink replication at the Layer 3 boundary, thus fixing the replication location on the L3 adjacency of leaf→spine, satisfying the goal of one uplink replication for one downlink traffic.

[0040] In this L3 architecture, multicast control follows the timing of PIM-SM (Protocol Independent Multicast-SparseMode): First, a shared tree (RPT) is formed around the RP (Rendezvous Point). The RP is preferably deployed on one or more spines because it is located at the upper layer of the topology and has better reachability to the entire network. In the initial stage of the service, the source side registers (S,G) with the RP via a Register message, and the receiving leaf initiates a (*,G) Join in the direction of the RP. Thus, multicast data is sent from the RP to each leaf along the RPT. Subsequently, the receiving leaf performs an RPF (Reverse Path Forwarding check) on the multicast traffic arriving along the RPT: the unicast optimal direction to the source is used as the inbound consistency criterion. If the current inbound interface is inconsistent with the unicast optimal outbound interface to the source, the receiving side initiates a Join / Prune hop by hop according to the unicast optimal path, prunes the shared tree branches, and switches to SPT (Shortest Path Tree) forwarding with the source as the root. Therefore, the RPT only undertakes initial traction, while the SPT is responsible for efficient carrying in the steady state. If it is a PIM-SSM model, the RPT construction process is skipped, and the SPT is constructed directly. The subsequent forwarding process is consistent and also applies to this disclosure.

[0041] The multicast network traffic scheduling method in one embodiment of this disclosure specifically includes the following steps:

[0042] S101: Divide the uplink of the access node into multiple link groups, each link group containing multiple uplinks corresponding to the same relay node, and divide the multiple multicast sources of the downlink of the access node into multiple source groups.

[0043] By dividing multiple uplinks of the access node into several link groups according to their affiliation with the same relay node, each link group contains multiple uplinks pointing to the same relay node; and dividing multiple multicast sources on the downlink side of the access node into several source groups according to preset rules, so that the mapping relationship between source group-relay node-link can be uniformly arranged in a weighted manner in subsequent steps.

[0044] In one optional implementation, there are n logically independent uplink directions between the access node and the relay node, each direction can be carried in parallel by m physical uplink links. In this case, the access node merges all m uplink links pointing to relay node j into link group j, thus forming a total of n link groups. Links within each link group have the same next-hop semantics but are physically independent, allowing for subsequent link-level priority expansion and fault cohesion switching. Link group identification can be based on the routing next hop, adjacent objects in the forwarding table, L3 interface peers, or static identifiers. When a physical link joins or leaves the interconnection of a relay, only the membership set of the link group to which that link belongs needs to be updated, maintaining the stability of the group semantics.

[0045] On the source side, multiple multicast sources can be grouped based on multicast source address ranges, service domain labels, VLAN / VRF boundaries, program / channel identifiers, or statistical traffic characteristics. Preferably, source grouping should balance manageability and balance: on the one hand, ensuring that the traffic variance of each source group is small over long-term operation, facilitating the long-term stability of the weight matrix mapping between groups and trunks; on the other hand, allowing hotspot sources to be grouped or split separately to reduce the impact of single hotspots on a particular trunk or link group. In specific implementations, source groups can be expressed through prefix tables, access control lists, policy routing matching items, or equivalent classification mechanisms; when the source set is added to or deleted from, a rolling remapping strategy is used to adjust only the affiliation of the incremental group, avoiding large-scale migration of existing groups.

[0046] For ease of understanding, an example is given below. Assume an access node is connected to 4 relay nodes (n=4), with 2 physical uplinks (m=2) between it and each relay. Following the above method, the access node forms 4 link groups: Link group 1 corresponds to relay 1, containing two uplinks; Link group 2 corresponds to relay 2; Link group 3 corresponds to relay 3; and Link group 4 corresponds to relay 4. Simultaneously, there are several multicast sources on the downlink side of the access node, which can be divided into 4 source groups based on source address ranges or channel numbers (or further subdivided into 8 source subgroups as needed). After this division, the rows of the subsequent weight matrix will correspond to these source groups, the columns will correspond to the four relay nodes, and the link-level expansion will correspond to the two uplinks in a certain column. Therefore, any weight settings, priority ranking, and failover order for source group → relay → link can be consistently expressed and distributed using the aforementioned method.

[0047] S102: Construct a weight matrix, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node.

[0048] Step S102 aims to establish an orchestratable bearer mapping model decoupled from subsequent path selection mechanisms. Its core is to construct a weight matrix in the control plane, with source groups as rows and relay nodes as columns. The relative sizes of the matrix elements externalize the preference relationships of each source group for different relay nodes. This matrix does not directly change the multicast protocol's workflow but serves as a higher-level constraint for unicast route comparison, ensuring that the receiving side, when executing the optimal inbound criterion for the source, directs the shortest path trees of different source groups to different relay nodes. To ensure the determinism and convergence of the mapping, preferably, each row has a unique maximum weight to indicate the preferred bearer node for that source group, with the remaining weights decreasing in a comparable order to form a clear substitution sequence.

[0049] For any row corresponding to a source group, only one element in the row has the maximum weight, and all other elements in the row are different from this maximum value and are not equal to each other. This constraint allows for a clear and unambiguous priority selection and an ordered alternative chain on the control plane. This enables the subsequent shortest path tree driven by unicast routing to guide the source group to the single preferred bearer node in a deterministic manner. When this node is unavailable or the strategy is adjusted, the second-best and third-best nodes are selected in a strict order of size, thus avoiding undesirable situations such as ties for best value, disordered switching, or cyclical reselection.

[0050] In one alternative implementation, the weight matrix can be generated using a construction rule that strictly arranges each row in total order. For example, assuming the network contains n relay nodes, for any source group i, its corresponding row can be set as an arrangement of {1,2,…,n}, and the maximum value can be uniquely assigned to the target relay node column through numerical mapping, with the remaining columns decreasing sequentially or arranged according to a predetermined pattern. To ensure that this property is maintained at different scales and evolution stages, the matrix can be obtained by recursively expanding low-order primitives, maintaining the unique maximum and all-dissimilar properties at the row level; when the number of relays changes, the total order within the rows can be maintained through pruning or insertion to avoid introducing equal weights. Another implementation can perform monotonic transformations (such as linear scaling or weighted shifting) on ​​the weights while maintaining the relative order relationship within the rows to adapt to specific routing metric systems, without changing the core constraints of unique maximum and all-dissimilar.

[0051] To facilitate understanding, consider this example: Suppose there are 4 relay nodes. Construct a row vector [4,1,2,3] for the first source group. In steady state, the first column containing the weight 4 corresponds to the unique preferred carrier node. When this node fails, it is replaced sequentially according to the numerical sequence from 3 (fourth column) to 2 (third column) and then to 1 (second column). Since there are no equal elements in the row, there will be no situation where two relays are simultaneously determined as optimal. Furthermore, the replacement order is strictly single-chained, preventing oscillations between multiple candidates and reducing oscillations during convergence. Extending this idea to any n, we can achieve the requirement of unique maximum value and distinct elements within each row by selecting a unique peak column for each row and providing a strictly descending or rule-based permutation of the remaining columns.

[0052] In one feasible implementation, the weight matrix can be recursively generated from lower-order primitives. Starting with second-order primitives, fourth-order, eighth-order, and even 2-order primitives are obtained step-by-step through copying, equivalent substitution, and mirror expansion about the center point. n A high-order matrix; when the number of relay nodes is not a power of two, a submatrix matching the actual size can be directly pruned from the high-order matrix without violating properties such as unique maximum value within a row, ordered switching, and inter-row balance. The advantage of this generation method is its simplicity and clear rules, facilitating the rapid generation of weight tables with consistent forms at different scales using algorithms, and supporting smooth scaling up and down as the network evolves. The numerical domain of the weights is not limited to the weight definition of a specific protocol; it only needs to maintain the relative size relationship within rows and the global distribution characteristics. During engineering deployment, the mapping to specific routing metrics can be completed by the policy layer.

[0053] To make it easier to understand, here is an example: Figure 2As shown, assuming there are four source groups and four relay nodes, the matrix can be set as follows: first row [4,1,2,3], second row [1,4,3,2], third row [2,3,4,1], and fourth row [3,2,1,4]. Therefore, the preferred bearer node for the first source group corresponds to the first column, the second source group to the second column, and so on. If a bearer node becomes temporarily unavailable, the corresponding row will be replaced by the next largest and then the next largest column. Because the replacement order of different source groups is distinguished within each row, when multiple nodes fail simultaneously, multiple source groups will not switch to the same surviving node in a concentrated manner, thus suppressing the risk of polarization and congestion.

[0054] At a larger scale, recursive generation and submatrix pruning can still guarantee key characteristics such as distributed priority, ordered switching, and overall balance. If further refinement of the carrying capacity is required at the link level, the row weights can be expanded into adjacent priorities for parallel uplink without changing the matrix backbone. However, this expansion does not affect the source group-relay node level relationship described in this step.

[0055] In one implementation, to ensure the routing weight matrix can adapt to different numbers of spine nodes and maintains balanced load distribution among multicast sources under normal conditions and orderly failover under fault conditions even after matrix expansion, a routing weight parameter derivation method can be used, recursively generating routing weight parameters from lower-order matrices to higher-order matrices. The basic idea of ​​this derivation method is to first construct a base matrix that reflects the initial load and fault replacement relationships, and then, based on this, generate higher-order weight matrices step-by-step through replication expansion, peer replacement, and mirror symmetric expansion.

[0056] This approach not only ensures that each group of multicast sources has a unique, prioritized spine node after matrix expansion, but also allows different groups of multicast sources to switch to different surviving spine nodes according to their weights when one or more spine nodes fail. This prevents multiple multicast sources from converging on the same spine node and creating polarization. Furthermore, this approach can be recursively applied to higher dimensions, making it suitable for reuse in multicast networks of varying sizes and easy to automate calculations and deployments using scripting tools.

[0057] In this implementation, a basic pattern can be established starting with a smaller-scale routing weight matrix. For example, when n=2, a 2x2 matrix can be constructed, where the weights of spine1 and spine2 in the first group are 2 and 1 respectively, and the weights of spine1 and spine2 in the second group are 1 and 2 respectively. Using this 2x2 matrix, multicast sources in the first group are preferentially loaded onto spine1, and multicast sources in the second group are preferentially loaded onto spine2; when any spine node fails, the corresponding multicast source automatically switches to another spine node to continue carrying the load.

[0058] Although this 2x2 matrix is ​​relatively small, it already demonstrates the most fundamental rule in matrix generation: each row has a unique maximum weight value, the maximum weight values ​​of different rows are distributed in different columns, and in the event of a fault, the rows can form an ordered substitution relationship based on the remaining weights. Based on this fundamental principle, we can continue to deduce higher dimensions.

[0059] When expanding a 2x2 matrix into a 2x4 matrix, the newly added columns `spine3` and `spine4` can be copied from columns `spine1` and `spine2` respectively, resulting in an intermediate matrix with the first group being 2, 1, 2, 1 and the second group being 1, 2, 1, 2. Then, considering the equivalence between `spine1`, `spine2`, and `spine3`, `spine4`, values ​​are selected from the first and second halves of each row and modified, expanding each row from the original 1, 2 to a complete weight sequence of 1, 2, 3, 4.

[0060] This process yields a 2x4 matrix, where the first group is 4, 1, 2, 3, and the second group is 1, 4, 3, 2. Furthermore, considering that the newly added third and fourth groups are also equivalent to the first and second groups, a mirror expansion along the row directions can be performed with the table center as the origin, thus forming a 4x4 matrix: the first group is 4, 1, 2, 3; the second group is 1, 4, 3, 2; the third group is 2, 3, 4, 1; and the fourth group is 3, 2, 1, 4 (e.g., ...). Figure 2 (As shown).

[0061] This 4x4 matrix satisfies the following characteristics: Group 1 prioritizes load on spine1, Group 2 prioritizes load on spine2, Group 3 prioritizes load on spine3, and Group 4 prioritizes load on spine4. Simultaneously, when a spine1 node fails, Group 1 switches to spine4; when a spine2 node fails, Group 2 switches to spine3; when a spine3 node fails, Group 3 switches to spine2; and when a spine4 node fails, Group 4 switches to spine1. Therefore, the 4x4 matrix not only provides the load correspondence under normal conditions but also the replacement order under fault conditions, thus serving as a foundational matrix for extending 4x4 to higher-order matrices.

[0062] Building upon this, we can further explain the method for expanding the 4x4 matrix of routing weights to an 8x8 matrix. For ease of understanding, this expansion process can be divided into three stages. The first stage is the column-direction copying expansion stage. In this stage, the 4x4 matrix is ​​copied once, forming the left half of the original matrix and the right half of the copied matrix, thus creating a 4x8 intermediate matrix.

[0063] Figure 3 The left half of the matrix is ​​represented by blue, and the right half by green, with the green portion being a copy of the blue portion. After this step, the values ​​for the first group (spine1 to spine8) are 4, 1, 2, 3, 4, 1, 2, 3; the values ​​for the second group (spine1 to spine8) are 1, 4, 3, 2, 1, 4, 3, 2; the values ​​for the third group (spine1 to spine8) are 2, 3, 4, 1, 2, 3, 4, 1; and the values ​​for the fourth group (spine1 to spine8) are 3, 2, 1, 4, 3, 2, 1, 4. This step expands the matrix from 4 columns to 8 columns, increasing the node dimension. However, each row still consists of only two identical sets of 1, 2, 3, 4, which does not yet fully reflect the priority differences between the eight spine nodes. Therefore, the next stage is required.

[0064] The second stage is the numerical replacement stage for the equivalent regions. In this stage, since each row contains two sets of 1, 2, 3, and 4, and the blue and green parts are equivalent, the values ​​in the blue and green parts can be selected and replaced respectively without disrupting the original relative sorting rules, so that each row eventually forms a complete weight set from 1 to 8.

[0065] Specific methods could be: such as Figure 4As shown, two numbers in the blue section are selected and changed to the larger numbers 7 and 8, while two numbers in the green section are selected and changed to the smaller numbers 5 and 6, maintaining the overall change logic of 1→5, 2→6, 3→7, 4→8. After this processing, the weights of the first group corresponding to spine1 to spine8 become 8, 1, 2, 7, 4, 5, 6, 3; the weights of the second group corresponding to spine1 to spine8 become 1, 8, 7, 2, 5, 4, 3, 6; the weights of the third group corresponding to spine1 to spine8 become 2, 7, 8, 1, 6, 3, 4, 5; and the weights of the fourth group corresponding to spine1 to spine8 become 7, 2, 1, 8, 3, 6, 5, 4.

[0066] As can be seen, through this step, each row forms a complete set of non-repeating weight sequences, and the position of the maximum weight in each row falls on different columns. In other words, this step, by applying differentiated weight changes to the equivalent regions after copying in the column direction, enables each row to form a strictly comparable total order priority relationship in the new node dimension, laying the foundation for subsequent mirror expansion.

[0067] The third stage is the row-direction mirror-symmetric expansion stage. In this stage, the 4*8 matrix that has already undergone numerical replacement can be... Figure 5 The red dot is the mirror image point. Continuing to expand along the rows, we obtain a complete 8x8 matrix. After expansion, the two blue regions are mirror images of the red dot, and the two green regions are also mirror images of the red dot (e.g., ...). Figure 5 (As shown).

[0068] After this mirroring expansion, a complete 8x8 routing weight table can be obtained. The first group is 8, 1, 2, 7, 4, 5, 6, 3; the second group is 1, 8, 7, 2, 5, 4, 3, 6; the third group is 2, 7, 8, 1, 6, 3, 4, 5; the fourth group is 7, 2, 1, 8, 3, 6, 5, 4; the fifth group is 4, 5, 6, 3, 8, 1, 2, 7; the sixth group is 5, 4, 3, 6, 1, 8, 7, 2; the seventh group is 6, 3, 4, 5, 2, 7, 8, 1; and the eighth group is 3, 6, 5, 4, 7, 2, 1, 8.

[0069] This 8x8 matrix retains the basic characteristics of a 4x4 matrix: each row has a unique maximum weight, and the maximum weights of different rows are distributed across different spine nodes. Therefore, under normal conditions, groups 1 through 8 can be preferentially loaded onto different spine nodes. Simultaneously, the remaining weight values ​​in each row form a strictly ordered substitution relationship. When any one or more spine nodes fail, the multicast sources can switch to different surviving spine nodes according to the remaining weights, thus preventing multiple multicast sources from switching to the same spine node simultaneously. In other words, the column expansion of the matrix mainly introduces new node dimensions, while the row-level mirror expansion mainly introduces new multicast source dimensions. Combining these two aspects allows the 4x4 matrix to be fully derived into an 8x8 matrix while maintaining the core properties of load distribution and failover.

[0070] Based on the above approach of expanding from 4x4 matrices to 8x8 matrices, we can continue to iterate towards higher-order matrices. In other words, when the order n of the target matrix is ​​a power of 2, we can repeatedly execute the process of "column-direction copying and expansion—equivalent region numerical replacement—row-direction mirror symmetric expansion" to generate 16x16, 32x32, and so on up to any nxn order weight matrix. This recursive process does not rely on manually designing weight tables for each higher-order matrix. Instead, it starts from lower-order matrices and automatically derives higher-order matrices according to unified structural rules. Therefore, it can ensure the consistency and reusability of matrix construction methods in network scenarios of different scales.

[0071] More importantly, during each recursive process, the matrix retains its unique maximum weight within each row, strictly comparable order within rows, and dispersed distribution of maximum values ​​across different rows. This allows the expanded matrix to still be used for load balancing of multicast sources and distributed switching during multi-node failures. As explicitly stated in the appendix, this method can obtain any n*n weight matrix, where n is a power of 2. Therefore, this method is not limited to 8*8 scenarios but can serve as a general method for generating higher-order matrices.

[0072] When the number of spine nodes n in the network is not equal to 2 raised to the power of x, a high-order matrix pruning method can be used to construct the target weight table. Specifically, a high-order matrix of not less than n can be generated first using the aforementioned recursive method, and then the submatrix formed by the intersection of the first n rows and the first n columns of this high-order matrix can be used as the actual weight table.

[0073] For example, when n=5, an 8x8 matrix can be generated first, and then the local matrices corresponding to groups 1 to 5 and spine1 to spine5 can be used as a 5x5 weight table. Figure 6In the given 5*5 weight table, the weights of spine1 to spine5 in group 1 are 8, 1, 2, 7, and 4; the weights of spine1 to spine5 in group 2 are 1, 8, 7, 2, and 5; the weights of spine1 to spine5 in group 3 are 2, 7, 8, 1, and 6; the weights of spine1 to spine5 in group 4 are 7, 2, 1, 8, and 3; and the weights of spine1 to spine5 in group 5 are 4, 5, 6, 3, and 8.

[0074] Although the target matrix is ​​no longer a power of 2, it still inherits the fundamental principles of unique maximum weight, load distribution, and ordered substitution from the earlier part of a higher-order matrix, since it originates from the former region of the higher-order matrix. In other words, when the node size does not meet the power of 2 condition, it is not necessary to redesign a completely new weight matrix; instead, the target matrix can be directly formed by extracting the effective portion of the higher-order matrix, thereby improving the versatility and adaptability of the matrix generation method.

[0075] After obtaining the node-level n*n weight matrix, each group can be further divided into m subsets, and different actual weight values ​​can be assigned to each subset based on the group's weight, to obtain the routing weights for any n*m links at the link level. Specifically, for a certain broadcast source group, an incremental value representing the subset index can be superimposed on the basic weight values ​​on different spine node columns to form differentiated weights between different links within the same node.

[0076] For example, in the case of n=8, if the load of the first group is distributed to the spine1 node, the actual weight values ​​corresponding to the m subsets of the first group can be 8*8+1, 8*8+2, 8*8+3...8*8+m in sequence; if the load is distributed to the spine2 node, the actual weight values ​​corresponding to the m subsets of the first group can be 1*1+1, 1*1+2, 1*1+3...1*1+m in sequence. Following this expansion, the actual weights of the first subset 1 corresponding to spine1 to spine5 can be written as 8*8+1, 1*1+1, 2*2+1, 7*7+1, 4*4+1; the actual weights of the first subset 2 corresponding to spine1 to spine5 can be written as 8*8+2, 1*1+2, 2*2+2, 7*7+2, 4*4+2; the actual weights of the first subset 3 corresponding to spine1 to spine5 can be written as 8*8+3, 1*1+3, 2*2+3, 7*7+3, 4*4+3, and so on, until the actual weights corresponding to the first subset m can be written as 8*8+m, 1*1+m, 2*2+m, 7*7+m, 4*4+m (e.g., ...). Figure 7 (As shown).

[0077] For groups 2 through 5, the same logic can be applied to expand the result into the form of "weight^2 + [1, m]". In this way, the priority relationship of each row in the node-level matrix can be further refined to multiple specific links under the corresponding node, thereby extending the expressive power of the matrix from node-level mapping to link-level mapping.

[0078] In this manner, the aforementioned weight matrix construction method first establishes new node peer regions by copying a lower-order matrix along the column direction; then, by replacing the values ​​in the peer regions, each row forms a complete weight sequence in a higher dimension; finally, by mirror-symmetric expansion along the row direction, new multicast source rows are introduced to obtain a higher-order matrix. When n is not a power of 2, the target matrix can be obtained by pruning the higher-order matrix; furthermore, by expanding the subset weights, the actual routing weights for any n*m link can be formed.

[0079] The aforementioned method ensures a balanced distribution of different multicast sources across multiple spine nodes. Furthermore, when one or more spine nodes fail, the corresponding multicast sources can be switched to different surviving spine nodes according to their weights in the matrix, thus avoiding the polarization problem caused by multiple multicast sources switching to the same spine node simultaneously. Simultaneously, this method features unified derivation rules and good scalability, facilitating automatic generation and deployment in multicast networks of varying sizes using scripting tools.

[0080] In a spine-leaf structure, rows of the weight matrix correspond to source groups (which can be divided by source address range, channel, or service domain), and columns correspond to spine nodes. The unique maximum value of the weight within a row indicates the target spine for that source group. When link / node failures or scaling occur, the order of the second-largest and third-largest weights within a row ensures orderly and distributed handover. To make this abstraction effective at the protocol plane, unicast routing (e.g., BGP for routing policy control) runs between the leaf and spine. Through strategies such as local-pref / MED / community / next-hop weighting, the matrix weights are projected onto the unicast comparison results of each spine. Thus, when the receiving-side leaf performs optimal inbound selection on the source and triggers SPT, the previous hop of the SPT will be consistent with the weight matrix: the first source group is treeed via spine1, the second source group via spine2, and so on, thereby spreading different sources across different spines.

[0081] In one exemplary embodiment, the source group can be subdivided into multiple source subgroups, and each source subgroup can be mapped one-to-one with the uplink in its corresponding link group, so that the traffic of multiple source subgroups can be distributed to multiple uplinks respectively.

[0082] Based on the aforementioned weight matrix with a two-dimensional relationship between source groups and relay nodes, the service set covered by each row can be partitioned into subsets without changing the row-column correspondence. This allows several source subgroups under a row to be mapped to multiple parallel uplinks of the corresponding relay node. Thus, while maintaining the determinism of different source groups being distributed to different relay nodes, it also enables fine-grained carrying of multiple source subgroups across multiple links within the same relay node, providing link-level endpoints for load balancing and redundancy switching.

[0083] In one feasible implementation, the division of source subgroups can be based on address prefixes, channel numbers, service tags, or statistical characteristics. The goal of the division is to ensure that the long-term load of each subgroup within the same source group is relatively balanced and that the number of subgroups matches the number of links in their corresponding link groups. For the link-side mapping, a strict one-to-one correspondence can be adopted: the k-th uplink within a link group only carries the main path of the k-th source subgroup. When it is necessary to reflect the link-level priority order to support fast switching within the same group, each link can be assigned adjacent but unequal priorities in the control plane. This ensures that when a link fails, the source subgroups carried by that link migrate to backup links in a preset order within the same link group, avoiding crossovers to other relay nodes and causing wider routing convergence. To ensure consistency with the upper-level weight matrix, the link-level priority can be expanded from the row weights using a monotonic mapping function. For example, the row weight w can be mapped to a set of ordered values ​​{f(w,1), f(w,2), …}, where f strictly increases with respect to the second parameter to distinguish the relative preference of parallel links. In practice, this mapping can be expressed through routing policy parameters, next-hop metrics, or equivalent path comparison factors. The specific parameter system is not limited, as long as the order relationship of links within the same group is stable and comparable.

[0084] To illustrate with an example: Assume there are two parallel uplinks between an access node and a relay node, and the first source group on the downlink side of the access node is subdivided into two source subgroups. Through a one-to-one mapping, source subgroup A corresponds to uplink 1, and source subgroup B corresponds to uplink 2. In the initial operating state, A and B establish shortest path trees to the relay node through uplink 1 and uplink 2 respectively, forming a link-level parallel bearer. When uplink 1 becomes momentarily unavailable, source subgroup A immediately switches to link 2 within the same group according to link-level priority. This does not change the node-level bearer relationship between the first source group and the relay node, nor does it affect the mapping of other sources such as the second and third source groups on their respective relay nodes, thus confining the fault disturbance to the link set of the same relay node. If link 1 recovers, source subgroup A can switch back to link 2 according to the recovery strategy or remain on link 2. The specific strategy can be configured by the operation and maintenance side according to jitter suppression and black hole protection requirements.

[0085] Specifically, different but adjacent priorities are set for each uplink within a link group mapped to the same relay node, so that traffic from the source subgroup is switched to other uplinks within the same link group in the event of a link failure.

[0086] By confining the convergence range of redundancy protection within the link group, local self-healing is achieved solely through link-level priority without altering the node-level bearer relationship between the source group and relay nodes. To this end, the control plane assigns strictly comparable and adjacent priorities (e.g., a sequence formed by monotonic mapping based on sovereign weight plus small offsets) to each parallel uplink within the link group. This ensures that when any link fails, the path selection mechanism carrying its corresponding source subgroup can shift to the next priority link within the same group, avoiding crossing to other relay nodes and triggering a wider range of tree-like path reconstruction and route convergence.

[0087] In one feasible implementation, the priority setting is consistent with the row weights of the source group → relay node: Let the row weight of a source group in the weight matrix be w. Then, for the m parallel uplinks mapped to this relay node, a set of adjacent and strictly increasing link-level priority values ​​are generated using a monotonic function f(w,k) (where k=1…m represents the link's order within the group). For example, f(w,k)=w 2 +k ensures that the comparison results of any two links in the same group are stable and is decoupled from cross-group (cross-relay) comparisons.

[0088] To illustrate with an example: Suppose there are two parallel uplinks L1 and L2 between an access node and a relay node. The corresponding source groups are subdivided into two source subgroups A and B, and carried in a one-to-one mapping: A→L1, B→L2. The control plane generates a link-level priority sequence w based on the row weight w. 2 +1 (L1) and w 2 +2(L2). In steady state, the shortest path tree for A is established via L1, and for B via L2. When L1 momentarily fails, the receiving side's incoming criterion for A immediately changes from w. 2 +1 Revert to the adjacent w 2 +2, A's traffic remains on the same relay node, with the switchover only occurring within the link group; L2 bearer increases but remains manageable. Throughout the process, B's bearer is unaffected; node-level mappings in other source groups are also unaffected, thus limiting the blast radius of the fault disturbance to a single link group.

[0089] S103: Determine the unicast route for each source group based on the weight matrix, so that each source group selects the node with the largest weight among multiple relay nodes as the traffic carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

[0090] The source group-to-relay node preference relationship determined by the weight matrix on the control plane is projected onto the comparison results of unicast routes. This allows the receiving side to select the relay node with the highest weight in the row corresponding to the source group as the previous hop when executing the optimal incoming criterion for the source and triggering the shortest path tree (SPT) construction. This achieves the goal of distributing different source groups across different relay nodes in a stable state. This step does not change the basic flow of the multicast protocol, but indirectly controls the SPT topology by influencing the priority of unicast paths, thus forming a closed loop between the control plane, route comparison, and SPT tree construction.

[0091] In one feasible implementation, unicast routing preferences can be expressed by policy-based routing or the policy mechanism of the Border Gateway Protocol (BGP). The control plane first generates a priority sequence consistent with the rows of the weight matrix for each source group, and then maps this sequence to path preference parameters to each relay node. Preferably, local priority (Local-Pref) can be used as the primary comparison factor, supplemented by metric (MED), next-hop weight, or community attribute-driven policy divergence, so that for the same source group, the unicast path to the source from the relay node corresponding to the highest weight in the row is comparatively superior to the alternative paths of other relay nodes.

[0092] To avoid ties when devices round down or multiple factors are combined, a minimum interval is reserved between parameters and a fixed comparison order is agreed upon, so that the intra-row priority relationship is strictly reflected by total order. In scenarios where the device supports Equal Cost Multipath (ECMP), ECMP for the corresponding prefix of the source group can be disabled or unequal weights can be applied to equal cost paths to prevent the preferred relay from being scattered by ECMP. When multipath must be enabled due to capacity requirements, load can be limited to parallel links under the same relay node, thus not violating the principle of node-level distribution.

[0093] In another implementation, if the network uses IGP to carry the data between relay nodes and access nodes, the optimal unicast direction to the source can be directed through IGP metrics, policy routing, or segment routing policies to ensure consistency with the weight matrix. For environments using multiple VRFs or multiple instance BGP, differentiated Local-Prefs and policy entries can be applied at the instance or VRF level to maintain consistent control over different source groups. Regardless of the routing protocol and parameter system used, for any source group, the comparison result of the unicast path to each relay node should be consistent with the magnitude of the weights in that row, and the preferred path should be uniquely identifiable. When the preferred relay node is unavailable, the comparison result immediately falls to the second-best relay node, ensuring that the switching order is consistent with the order within the matrix rows.

[0094] In one exemplary embodiment, the unicast routing is controlled by a routing policy that influences the path comparison results of each relay node, so that the receiving side is consistent with the weight matrix when performing the optimal incoming path selection.

[0095] In one alternative implementation, the control plane first extracts the ordered sequence of source group-relay node from the weight matrix and maps it to policy entries for the corresponding prefix or matching field. Taking BGP as an example, for the target prefix set of the i-th source group, a higher Local-Pref is set from the relay direction corresponding to the largest weight, decreasing sequentially for the second-best directions, and only intra-link weight expansion is performed between parallel uplinks of the same relay. After receiving traffic arriving along the RPT, the receiving side performs optimal inbound selection based on the unicast routing table, and the previous hop of the SPT is consistent with the preferred relay of that row. When the preferred relay is unreachable, the route comparison naturally falls to the second-best entry, and the SPT is reconstructed along the second-best relay. Since the second-best sequences of different source groups are different, multiple sources will not converge to the same live node at the moment of failure, thereby suppressing polarization and transient congestion.

[0096] If the network uses multiple VRFs or multiple instance BGPs, differentiated Local-Pref and community policies can be set at the instance level to isolate comparison domains of different source groups. In IGP-dominated campus scenarios, by fine-tuning the metric to the source in layers between access and relay, the optimal inbound direction can also be kept consistent with the matrix. For high-throughput scenarios where ECMP must be enabled, multiple paths can be limited to parallel links within the same relay node, preserving throughput while maintaining node-level distribution.

[0097] To facilitate understanding, consider this example: Suppose a network has four relay nodes, numbered 1 to 4. The sources of a certain access node are divided into four source groups, with the four rows of the weight matrix being [4,1,2,3], [1,4,3,2], [2,3,4,1], and [3,2,1,4]. Based on this, the control plane sets the Local-Pref for the path to relay 1 to 400 for source group 1, to relay 4 to 300, to relay 3 to 200, and to relay 2 to 100. For source group 2, the Local-Pref for relay 2 is set to 400, and the rest decrease sequentially according to the row order, and so on. During operation, upon receiving traffic arriving along the Shared Tree (RPT), the receiving side performs an RPF check and initiates SPT construction hop-by-hop along the optimal unicast direction to the source: the SPT of source group 1 is established via relay 1, the SPT of source group 2 via relay 2, and so on, thus forming a distributed bearer in the steady state: source group 1 → relay 1, source group 2 → relay 2, source group 3 → relay 3, and source group 4 → relay 4. If relay 1 fails, the unicast comparison result of source group 1 immediately drops to the suboptimal relay 4, and its SPT is reconstructed along relay 4. Since the suboptimal order of source groups 2, 3, and 4 is different, multiple source groups will not simultaneously rush to the same surviving relay, thereby avoiding polarization and transient congestion.

[0098] Please refer to Figure 3 As shown, based on the same inventive concept as the aforementioned multicast network traffic scheduling method, this disclosure provides a multicast network traffic scheduling system 300, which includes: a grouping module 301, a weighting module 302, and a routing module 303.

[0099] The grouping module 301 is used to divide the uplink of the access node into multiple link groups, each link group containing multiple uplinks corresponding to the same relay node, and to divide the multiple multicast sources downlink from the access node into multiple source groups. The weighting module 302 is used to construct a weight matrix, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node. The routing module 303 is used to determine the unicast route for each source group based on the weight matrix, so that each source group selects the node with the highest weight among multiple relay nodes as the traffic-carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

[0100] Please refer to Figure 4As shown, this disclosure also provides an electronic device 400, which includes at least one processor 401, a memory 402 (e.g., non-volatile memory), a main memory 403, and a communication interface 404, and the at least one processor 401, memory 402, main memory 403, and communication interface 404 are connected together via an internal bus 405. The at least one processor 401 is used to invoke at least one program instruction stored or encoded in the memory 402 to cause the at least one processor 401 to perform various operations and functions of the multicast network traffic scheduling method described in the various embodiments of this specification.

[0101] In the embodiments of this specification, electronic device 400 may include, but is not limited to: personal computer, server computer, workstation, desktop computer, laptop computer, notebook computer, mobile electronic device, smartphone, tablet computer, cellular phone, personal digital assistant (PDA), handheld device, messaging device, wearable electronic device, consumer electronic device, etc.

[0102] This disclosure also provides a computer-readable medium carrying computer-executable instructions, which, when executed by a processor, can be used to implement various operations and functions of the multicast network traffic scheduling method described in the various embodiments of this specification.

[0103] The computer-readable medium in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0104] In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0105] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, systems, and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0107] It will be apparent to those skilled in the art that this disclosure is not limited to the details of the exemplary embodiments described above, and that this disclosure can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of this disclosure is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this disclosure. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0108] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A multicast network traffic scheduling method, applied to a multi-node relay network, wherein the multi-node relay network includes multiple access nodes and multiple relay nodes, characterized in that, The multicast network traffic scheduling method includes: The uplink of the access node is divided into multiple link groups, each link group contains multiple uplinks corresponding to the same relay node, and the multiple multicast sources of the downlink of the access node are divided into multiple source groups. Construct a weight matrix, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node; Based on the weight matrix, the unicast route for each source group is determined, so that each source group selects the node with the highest weight among multiple relay nodes as the traffic-carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

2. The multicast network traffic scheduling method according to claim 1, characterized in that, The unicast routing is controlled by a routing policy, which affects the path comparison results of each relay node, so that the receiving side is consistent with the weight matrix when performing the optimal incoming path selection.

3. The multicast network traffic scheduling method according to claim 1, characterized in that, The multicast network traffic scheduling method further includes: The source group is subdivided into multiple source subgroups, and each source subgroup is mapped one by one to the uplink in its corresponding link group, so that the traffic of multiple source subgroups is respectively loaded onto multiple uplinks.

4. The multicast network traffic scheduling method according to claim 3, characterized in that, The multicast network traffic scheduling method further includes: Set different but adjacent priorities for each uplink in a link group mapped to the same relay node, so that traffic from the source subgroup can be switched to other uplinks in the same link group in the event of a link failure.

5. The multicast network traffic scheduling method according to claim 1, characterized in that, In the weight matrix, for any row corresponding to a source group, the maximum weight value in the row appears only in one column, and the weight values ​​in the same row are all different.

6. The multicast network traffic scheduling method according to claim 5, characterized in that, The multicast network traffic scheduling method further includes: When a relay node carrying a certain source group fails, the relay node is switched according to the second largest weight in the row corresponding to that source group in the weight matrix.

7. The multicast network traffic scheduling method according to claim 1, characterized in that, The link between the access node and the relay node is a Layer 3 interconnection structure. The receiving side performs an inbound RPF check on the incoming multicast traffic and then forwards the multicast traffic according to the SPT. The unicast route controls the routing result of the SPT based on the weight matrix.

8. A multicast network traffic scheduling system, applied to a multi-node relay network, the multi-node relay network comprising multiple access nodes and multiple relay nodes, characterized in that, The multicast network traffic scheduling system includes: The grouping module is used to divide the uplink of the access node into multiple link groups, each link group containing multiple uplinks corresponding to the same relay node, and to divide the multiple multicast sources of the downlink of the access node into multiple source groups. The weight module is used to construct a weight matrix, where each row of the weight matrix corresponds to a source group and each column of the weight matrix corresponds to a relay node. The routing module is used to determine the unicast route for each source group based on the weight matrix, so that each source group selects the node with the largest weight among multiple relay nodes as the traffic carrying node, so that the traffic of different source groups is respectively loaded onto different relay nodes.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the multicast network traffic scheduling method as described in any one of claims 1 to 7.

10. A computer-readable medium, characterized in that, The computer-readable medium carries computer-executable instructions, which, when executed by a processor, are used to implement the multicast network traffic scheduling method as described in any one of claims 1 to 7.

Images