Multicast routing method and routing device

Abstract

The embodiment of the application provides a multicast routing method and a routing device, relates to the technical field of communication, and is used for solving the problem that four same flows exist on a public network side in a scenario where multicast routing is simultaneously deployed with access side dual-homing protection and dual-root 1+1 protection, bandwidth redundancy of the public network side is caused, and the technical effect of reducing the bandwidth redundancy of the public network side and reducing customer operation cost is achieved. A first node receives a first routing message, the first routing message comprises an extended group attribute, the extended group attribute comprises root node information, the root node information is used for indicating that the first node has root node capability, the first node is a backup leaf node, the first node enables the root node capability, root node information is sent to a second node, the second node is a master leaf node, the first node receives a second routing message of the second node, and the second routing message is used for indicating that the first node transmits multicast flow to the second node. The embodiment of the application is used in the process of multicast routing.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a multicast routing method and routing device. Background Technology

[0002] Multicast uses multicast routing protocols to establish multicast routing table entries hop-by-hop between the multicast receiver and the multicast source, ultimately constructing a tree structure (i.e., a multicast distribution tree) with the multicast source as the root and the multicast receivers as the leaves. Multicast traffic starts from the root node and proceeds towards the leaf nodes, being replicated on each multicast router until it reaches the multicast receiver. Currently, in multicast networks, when the link between the leaf node and the root node fails, traffic from the root node cannot be transmitted to the leaf node. At this point, the multicast network undergoes a convergence process, which involves refreshing the multicast routing table entries and re-forwarding multicast traffic from the root node to the leaf nodes. However, this convergence process is lengthy, resulting in a longer waiting time for the multicast receiver to receive multicast traffic.

[0003] Currently, a method has been proposed to simultaneously deploy dual-homed protection and dual-root 1+1 protection on the access side. This involves two root nodes directly connected to the multicast source: one primary root node and one backup root node. It also involves two leaf nodes directly connected to the multicast receiver: one primary leaf node and one backup leaf node. The two root nodes can forward four copies of multicast traffic to the two leaf nodes via four links: the primary link and backup link from the primary leaf node to the primary and backup root nodes, and the primary link and backup link from the backup leaf node to the primary and backup root nodes. When the primary link of the primary leaf node fails, the multicast traffic can be forwarded to the receiver via the remaining three links. However, because this method involves four identical copies of traffic on the public network side (between the root nodes and leaf nodes), it causes bandwidth redundancy on the public network side, resulting in high operating costs for customers. Summary of the Invention

[0004] This application provides a multicast routing method and routing device that can occupy only two links on the public network side during multicast routing when dual-homed protection and dual-root 1+1 protection are deployed simultaneously on the access side. This reduces bandwidth redundancy on the public network side and lowers customer operating costs.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a multicast routing method, the method comprising: a first node receiving a first routing message, the first routing message including extended community attributes, the extended community attributes including root node information, the root node information indicating that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; the first node enabling root node capability and sending root node information to a second node; the second node being a primary leaf node between a multicast source and a multicast receiver; and the first node receiving a second routing message from the second node, the second routing message indicating that the first node transmits multicast traffic to the second node.

[0007] Therefore, the multicast routing method provided in this application, by carrying extended community attributes in the route, including root node information, enables the first node (i.e., the backup leaf node) to have root node capabilities. By enabling root node capabilities, the first node acts as the root node (i.e., the backup root node) of the second node (i.e., the primary leaf node), transmitting multicast traffic to the second node. Compared to existing technologies that strictly plan cost values ​​to control the transmission path of primary and backup root traffic, and where the public network still has four identical copies of bandwidth redundancy even when each site is a multicast source, this application enables the first node to act as the root node of the second node, allowing the second node to receive multicast traffic from the first node. This achieves shared routing of backup root traffic between leaf nodes, resulting in only two identical copies of traffic on the public network, reducing bandwidth redundancy and lowering customer operating costs. Furthermore, it also reduces bandwidth redundancy on the public network even when each site is a multicast source.

[0008] In one possible design, the first node receiving the first routing message includes: the first node receiving the first routing message published via Border Gateway Protocol (BGP). The first routing message is used to select the primary root node and backup root node of the primary leaf node and backup leaf node. Thus, the first routing message can determine the primary root node and backup root node of the primary leaf node and backup leaf node. Compared to the prior art, which determines the primary and backup root nodes through unicast routing, and cannot change the primary and backup root nodes, resulting in four identical bandwidth redundancies on the public network side, this application can configure the primary leaf node and backup leaf node as backup root nodes for each other. This allows the backup root traffic of the leaf node to share a common path among the leaf nodes. Therefore, only two identical traffic sets exist on the public network side, reducing bandwidth redundancy on the public network side, reducing customer operating costs, and still reducing bandwidth redundancy on the public network side even in scenarios where each site is a multicast source for the others.

[0009] In one possible design, before the first node receives the second routing message from the second node, the method further includes: the first node sending a first tunnel establishment request to the second node. The first tunnel establishment request is used to establish a first tunnel between the first node and the second node, and the first tunnel is used to transmit multicast traffic between the first node and the second node. Thus, by sending the tunnel establishment request and establishing the first tunnel with the second node, the first node transmits multicast traffic to the second node through the first tunnel, enabling the backup root traffic of the leaf nodes to share a common path among the leaf nodes, reducing bandwidth redundancy on the public network side and reducing the customer's operating costs.

[0010] In one possible design, when the second node carries an IGMP table but the first node does not, the method further includes: after receiving a second routing message from the second node through a first tunnel, the first node sends a local third routing message to the third node, where the third node is the root node directly connected to the multicast source. The third routing message instructs the third node to transmit multicast traffic to the first node. Thus, when there is no multicast traffic at the first node, the first node can receive the second routing message from the second node and send a local third routing message to the third node (i.e., the root node directly connected to the multicast source), thereby diverting the multicast traffic at the third node to the first node. This allows the first node to transmit multicast traffic to the second node, enabling the backup root traffic of leaf nodes to share a common path among leaf nodes. This reduces bandwidth redundancy on the public network side and lowers customer operating costs.

[0011] Secondly, embodiments of this application provide a multicast routing method, the method comprising: a second node receiving root node information of a first node, the root node information indicating that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; the second node being a primary leaf node between a multicast source and a multicast receiver; and the second node sending a second routing message to the first node, the second routing message indicating that the first node transmits multicast traffic to the second node.

[0012] Therefore, the multicast routing method provided in this application allows the second node to learn that the first node has the capability to act as a root node by receiving root node information sent by the first node. The second node then sends a second routing message to the first node, thereby receiving multicast traffic from the first node. Compared to existing technologies that strictly plan cost values ​​to control the transmission path of primary and backup root traffic, and where the public network still has the same four bandwidth redundancies even when each site is a multicast source, this application makes the first node the root node of the second node, and the second node obtains multicast traffic from the first node. This allows the backup root traffic of the leaf nodes to share a common path among the leaf nodes, thus reducing bandwidth redundancy on the public network, reducing customer operating costs, and still reducing bandwidth redundancy on the public network even when each site is a multicast source.

[0013] In one possible design, root node information is indicated by extended community attributes, which are included in the first routing message. This first routing message is received by the first node via Border Gateway Protocol (BGP) and is used to select the primary and backup root nodes for the primary and backup leaf nodes. Thus, the first routing message can determine the primary and backup root nodes for the primary and backup leaf nodes. Compared to existing technologies that determine primary and backup root nodes via unicast routing, which prevents the primary and backup root nodes from being changed and results in four identical bandwidth redundancies on the public network side, this application configures the primary and backup leaf nodes as backup root nodes for each other. This allows backup root traffic for leaf nodes to share a common path between leaf nodes, resulting in only two identical traffic streams on the public network side. This reduces bandwidth redundancy on the public network side, lowers customer operating costs, and maintains bandwidth redundancy even when each site is a multicast source for the others.

[0014] In one possible design, before the second node sends a second routing message to the first node, the method further includes: the second node receiving a first tunnel establishment request from the first node. This first tunnel establishment request is used to establish a first tunnel between the first and second nodes, and the first tunnel is used to transmit multicast traffic between the first and second nodes. Thus, by receiving the tunnel establishment request from the first node, the second node establishes a first tunnel with the first node, and the first node transmits multicast traffic to the second node through the first tunnel. This allows the backup root traffic of the leaf nodes to share a common path among the leaf nodes, reducing bandwidth redundancy on the public network side and reducing the customer's operating costs.

[0015] In one possible design, when the second node carries an IGMP (Internet Group Management Protocol) table while the first node does not, the method further includes: the second node sending a second routing message to the first node through the first tunnel; and the second node receiving multicast traffic transmitted by the first node. Thus, when there is no multicast traffic at the first node, the second node sends a second routing message to the first node through the first tunnel to obtain multicast traffic from the first node, enabling the backup root traffic of leaf nodes to share a common path among leaf nodes. This reduces bandwidth redundancy on the public network side and lowers the customer's operating costs.

[0016] In one possible design, the second node sends a fourth routing message to the fourth node, which is the primary root node of the second node. The fourth routing message instructs the fourth node to pass multicast traffic to the second node; the second node receives the multicast traffic passed by the fourth node. Thus, the second node can also send a fourth routing message to the fourth node (i.e., the primary root node) to obtain multicast traffic (i.e., primary root traffic) from the fourth node.

[0017] Thirdly, embodiments of this application provide a node, which is a first node, comprising: a receiving unit for receiving a first routing message, the first routing message including extended community attributes, the extended community attributes including root node information, the root node information indicating that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; a sending unit for enabling root node capability and sending root node information to a second node; the second node being a primary leaf node between a multicast source and a multicast receiver; the receiving unit is further configured to receive a second routing message from the second node, the second routing message indicating that the first node transmits multicast traffic to the second node. The beneficial effects achieved in this third aspect can be found in the beneficial effects described in the first aspect.

[0018] In one possible design, the receiving unit is also used to: receive a first routing message published via the Border Gateway Protocol (BGP), the first routing message being used to select the primary root node and the backup root node of the primary leaf node and the backup leaf node.

[0019] In one possible design, before the first node receives the second routing message from the second node, the sending unit is further configured to: send a first tunnel establishment request to the second node, the first tunnel establishment request being used to establish a first tunnel between the first node and the second node, the first tunnel being used to transmit multicast traffic between the first node and the second node.

[0020] In one possible design, the receiving unit is further configured to: receive a second routing message sent by the second node through the first tunnel when the second node carries a network group management protocol IGMP table and the first node does not carry an IGMP table; the sending unit is further configured to send a local third routing message to a third node, the third node being a root node directly connected to the multicast source, the third routing message being used to instruct the third node to transmit multicast traffic to the first node.

[0021] Fourthly, embodiments of this application provide a node, which is a second node, comprising: a receiving unit for receiving root node information of a first node, the root node information indicating that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; and the second node being a primary leaf node between the multicast source and the multicast receiver; and a sending unit for sending a second routing message to the first node, the second routing message instructing the first node to transmit multicast traffic to the second node. The beneficial effects achieved in this fourth aspect are described in the beneficial effects section of the second aspect.

[0022] In one possible design, the root node information is indicated by extended community attributes, which are included in the first routing message. The first routing message is received by the first node via the Border Gateway Protocol (BGP) and is used to select the primary root node and the backup root node for the primary leaf node and the backup leaf node.

[0023] In one possible design, before the second node sends the second routing message to the first node, the receiving unit is further configured to: receive the first tunnel establishment request from the first node, the first tunnel establishment request being used to establish a first tunnel between the first node and the second node, the first tunnel being used to transmit multicast traffic between the first node and the second node.

[0024] In one possible design, the sending unit is also used to: send a second routing message to the first node through the first tunnel when the second node carries the Network Group Management Protocol (IGMP) table and the first node does not carry the IGMP table; the receiving unit is also used to receive the multicast traffic transmitted by the first node.

[0025] In one possible design, the sending unit is also used to send a fourth routing message to a fourth node, which is the primary root node of the second node. The fourth routing message is used to instruct the fourth node to transmit multicast traffic to the second node. The receiving unit is also used to receive the multicast traffic transmitted by the fourth node.

[0026] Fifthly, a computer-readable storage medium includes computer instructions that, when executed on a computer or processor, cause the computer or processor to perform the first aspect and any possible design method of the first aspect or the second aspect and any possible design method of the second aspect.

[0027] Sixthly, a computer program product including computer instructions that, when executed on a computer or processor, cause the computer or processor to perform the first aspect and any possible design method of the first aspect or the second aspect and any possible design method of the second aspect.

[0028] For the other beneficial effects mentioned above, please refer to the description of the beneficial effects of the method, which will not be repeated here. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of a multicast routing method.

[0030] Figure 2 This is a schematic diagram of a multicast routing method.

[0031] Figure 3 This is a schematic diagram of a multicast routing method.

[0032] Figure 4A This is a schematic diagram of a multicast routing method.

[0033] Figure 4B This is a schematic diagram of a multicast routing method.

[0034] Figure 5 This is a schematic diagram of a multicast routing method.

[0035] Figure 6 This is a schematic diagram illustrating an application scenario of a multicast routing method provided in an embodiment of this application.

[0036] Figure 7 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0037] Figure 8 A flowchart illustrating a multicast routing method provided in an embodiment of this application;

[0038] Figure 9 A schematic diagram of a multicast route provided in an embodiment of this application;

[0039] Figure 10 A flowchart illustrating a multicast routing method provided in an embodiment of this application;

[0040] Figure 11 A schematic diagram of the multicast traffic transmission path of a multicast routing method provided in an embodiment of this application;

[0041] Figure 12 This is a schematic diagram of the structural composition of an electronic device provided in an embodiment of this application;

[0042] Figure 13 This is a schematic diagram of the structural composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] For ease of understanding, some concepts related to the embodiments of this application are illustrated below for reference.

[0044] Customer edge router (CE): A user edge device, which is the user-end router to which the service provider connects. The CE router provides service access to users by connecting to one or more provider edge routers (PE). The CE router is typically an Internet Protocol (IP) router, which establishes an adjacency relationship with the connected PE router. In this embodiment, the CE router can be a multicast source or a multicast receiver.

[0045] Provider edge (PE) routers are edge devices of the service provider's backbone network, equivalent to label edge routers (LERs) in multi-protocol label switching (MPLS) networks. PE routers connect CE routers and provider backbone routers (P), and are the most important network nodes. User traffic flows into the user network through PE routers, or flows to the MPLS backbone network through PE routers. In this embodiment, the PE router can be a root node or a leaf node directly connected to the CE router.

[0046] Carrier backbone router (provider, P): This is a core layer device, a provider router. The service provider's backbone network routing device does not connect to any CE routers; it is equivalent to a label switching router (LSR). In this embodiment, the P router is a P node connecting the root node and the leaf nodes.

[0047] Cost value: refers to the cost of reaching the destination address indicated by a certain route, which can be set manually or automatically. In the embodiments of this application, multicast traffic is transmitted according to the path with the lowest cost value during routing.

[0048] Access-side dual-homing protection: In the multicast network, two leaf nodes are set up directly connected to the multicast receiver, one as the primary leaf node and the other as the backup leaf node. The root node directly connected to the multicast source will transmit multicast traffic to both the primary and backup leaf nodes. When the link from the root node to the primary leaf node is normal, only the primary leaf node will transmit multicast traffic to the multicast receiver; the backup leaf node will not transmit multicast traffic. Only in the event of a complete failure of the primary leaf node will the backup leaf node transmit multicast traffic to the multicast receiver. This ensures that the multicast receiver receives multicast traffic quickly when the primary leaf node fails, avoiding long waiting times.

[0049] Dual-root 1+1 protection: In a multicast network, two root nodes are set up directly connected to the multicast source, one as the primary root node and the other as the backup root node. Both the primary and backup root nodes forward multicast traffic to the leaf nodes directly connected to the multicast receiver. When the link from the primary root node to the leaf node is normal, the leaf nodes will forward the multicast traffic received from the primary root node to the multicast receiver, but will not forward multicast traffic received from the backup root node. Only when the link from the primary root node to the leaf node fails will the leaf nodes forward the multicast traffic received from the backup root node to the multicast receiver. This ensures that the multicast receiver receives multicast traffic quickly when the link from the primary root node to the leaf node fails, avoiding long waiting times for the multicast receiver.

[0050] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments, unless otherwise stated, "multiple" means two or more.

[0051] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0052] Bit index explicit replication (BIERv6) of Internet Protocol version 6 (IPv6) encapsulation is a current multicast technology. In IPv6 networks (i.e., public IPv6 networks), multicast services are carried using the encapsulation of the native IPv6 network, such as public network multicast and multicast virtual private network (MVPN) multicast services. The Interior Gateway Protocol (IGP) uses IS-IS for IPv6 to establish a BIERv6 forwarding table, and the Border Gateway Protocol (BGP) uses the IPv6 Transmission Control Protocol (TCP) to establish connections and uses BGP-MP to publish routes for various address families such as VPNv4, VPNv6, Unicast4, Unicast6, MVPN4, or MVPN6.

[0053] When BIERv6 transmits information at the BGP layer, the MVPN over BIERv6 (multicast VPN service iteration to BIERv6 tunnel) control message is used to achieve automatic MVPN member discovery, establish and maintain provider mmulticast service interface (PMSI) tunnels, and transmit customer-side multicast join routes (C-multicast routes) to enable functions such as private network multicast member joining and leaving. Among these, BGP MVPN routes are divided into 7 categories: multicast virtual private network auto-discovery (MVPN AD) routes (including 5 types of routes) and C-multicast routes (including 2 types of routes). MVPN AD routes are mainly used for MVPN member auto-discovery and assisting MPLS in establishing PMSI tunnels. C-multicast routes are multicast routes originating from the private network, mainly used to initiate private network user joining and leaving, and guide the transmission of private network multicast data traffic. C-multicast routes carry the C-multicast Import RT, which stands for VRF Route Import Extended Community to multicast source unicast routes. The Import RT is primarily used by multiple sender PEs to help them identify whether a BGP C-multicast route from a receiver PE should be handled by them, and in which VPN instance routing table the route should be installed. C-multicast routes support VPN-IP routes (private network IPv4 unicast routes transmitted via BGP VPNv4) advertised by MVPN PEs containing the C-multicast Import RT attribute. This attribute is an extended community attribute for IP types and is mainly used for advertising C-multicast routes. This attribute must be included when advertising VPN-IP routes on private networks or rendezvous points (RPs), but it is not necessary for other routes.

[0054] refer to Figure 1This section provides a general overview of the multicast routing process. Specifically, the VPNv4 routes advertised by the root node to the leaf nodes include the VRF Route Import Extended Community (VRF ImportRT) attribute. When a leaf sends a BGP C-multicast route to the root, it includes this attribute in the route. Therefore, when multiple roots exist, the root receiving the BGP C-multicast route can identify whether it should handle the route sent by the leaf and in which VPN instance's routing table the route should be installed.

[0055] The value format for VRF Import RT is Administrator field: Local Administrator field, where the value of Administrator field is the local MVPN ID, and Local Administrator field is the identifier of the local VPN instance of the Sender PE (VRF Index ID).

[0056] like Figure 1 As shown, PE1 and PE2 are both roots, and PE3 is a leaf. Both PE1 and PE2 are connected to VPN1 and VPN2 respectively. On PE1, the RF Import RT of VPN1 is 1.1.1.9:1, and the RF Import RT of VPN2 is 1.1.1.9:2; on PE2, the RF Import RT of VPN1 is 2.2.2.9:1, and the RF Import RT of VPN2 is 2.2.2.9:2.

[0057] After PE1 and PE2 establish BGP neighbor relationships with PE3 in the BGP MVPN address family, both PE1 and PE2 will advertise VPNv4 routes to multicast source 192.168.1.2 to PE3. At this time, the VPNv4 route advertised by PE1 carries a VRF Import RT of 1.1.1.9:1, and the VPNv4 route advertised by PE2 carries a VRF Import RT of 2.2.2.9:1. After receiving the VPNv4 route, PE3 will install the preferred route into the routing table of VPN1, and then store the RF Import RT of the route for constructing a BGP C-multicast route.

[0058] Assume the preferred route is advertised by PE1, meaning its RF Import RT is 1.1.1.9:1. When PE3 receives the PIM join message from CE3, it constructs a BGP C-multicast route and sends it to PE1 and PE2. This route carries the Rt-import attribute, with a value equal to the previously stored RF Import RT, which is 1.1.1.9:1. When PE1 receives the BGP C-multicast route, it finds that the Administratorfield in the Rt-import attribute is 1.1.1.9, which is its own MVPN ID, so it accepts the route. Then, it finds that the Local Administratorfield is 1, so it installs this route into VPN1's routing table.

[0059] When PE2 receives the BGP C-multicast route, it finds that the Administrator field in the Rt-import attribute of the BGP C-multicast route is 1.1.1.9, which does not match the local MVPN ID 2.2.2.9. Therefore, it discards the BGP C-multicast route and does not process it.

[0060] In MVPN over BIERv6 scenarios, when a node or link fails, multicast services can only recover after BGP neighbors converge. However, the convergence time for BGP neighbor failures is relatively long, making it difficult to meet the high reliability requirements of multicast services. Therefore, configuring BFD for BGP can reduce the convergence time of BGP failures to some extent, thereby accelerating the convergence of multicast services. To further improve the convergence performance of multicast services, a dual-root 1+1 protection scheme was deployed.

[0061] MVPN over BIERv6 dual-root 1+1 protection scheme, for example, according to Figure 2 The deployment method shown includes two Sender PEs, Root1 and Root2. PMSI tunnels are created in Root1 and Root2, each acting as a bit-forwarding ingress router (BFIR). Leaf nodes are the leaf nodes of these two tunnels.

[0062] Deploy VPN Fast ReRoute (FRR) in Leaf to create two routes from Leaf to the same multicast source: the route advertised by Root1 is the primary route, and the route advertised by Root2 is the backup route.

[0063] Deploy the C-multicast Fast Rerouting (FRR) feature in Leaf and specify traffic detection as the detection method. When the links are normal, the same multicast data traffic is forwarded simultaneously along both the primary and backup links. Leaf node PE1 will receive primary tunnel traffic with Root1 as the BFIR and discard backup tunnel traffic with Root2 as the BFIR.

[0064] As the above principles indicate, when deploying the MVPN Over BIERv6 dual-root 1+1 protection scheme, it is recommended to ensure that the paths of the primary tunnel and the backup tunnel are separated as much as possible, thereby avoiding prolonged multicast service interruptions caused by the simultaneous failure of both tunnels. However, current technical implementations can only mitigate this by planning the IGP cost value, which has significant limitations on the scenarios.

[0065] Currently, deploying both access-side dual-homed protection and dual-root 1+1 protection simultaneously results in four identical copies of multicast traffic on the public network side, such as... Figure 3 , Figure 4A and Figure 4B As shown. Figure 3 The diagram illustrates a scenario where backup root traffic for two leaf nodes shares a path between the two root nodes. For leaf node-1, root node-1 is the primary root, and the link from root-1 to leaf-1 is the primary link. Root node-2 is the backup root, and the link from root-2 to leaf-1 is the backup link. For leaf node-2, root-2 is the primary root, and the link from root-2 to leaf-2 is the primary link. Root-1 is the backup root, and the link from root-1 to leaf-2 is the backup link. Figure 3Traffic on the primary link of Leaf-1 (the link from Root-1 to Leaf-1) flows from Root-1 to P-1 and then to Leaf-1. Traffic on the backup link of Leaf-1 (the link from Root-2 to Leaf-1) flows from Root-2 to Root-1, then to P-1, and finally to Leaf-1. Traffic on the primary link of Leaf-2 (the link from Root-2 to Leaf-2) flows from Root-2 to P-2 and then to Leaf-2. Traffic on the backup link of Leaf-2 (the link from Root-1 to Leaf-2) flows from Root-1 to Root-2, then to P-2, and finally to Leaf-2. It can be seen that the multicast traffic at the root node has two directions. Taking Root-1 as an example, one direction is from Root-1 to Leaf-1, and the other is from Root-1 to Root-2. Therefore, the backup root traffic of Leaf-1 and Leaf-2 will share a common path between Root-1 and Root-2, resulting in four identical multicast traffic instances on the public network side (between the root node and the leaf node).

[0066] Figure 4A and Figure 4B The diagram illustrates a scenario where the backup root traffic of two leaf nodes is shared between two P nodes. Figure 4A and Figure 4B The meanings are the same, where the primary and backup roots of Leaf-1 and Leaf-2 are the same as... Figure 3 Similarly, the traffic transmission paths in the main links of Leaf-1 and Leaf-2 are also the same. Figure 3 The same applies here, so I won't go into too much detail. Figure 4A and Figure 4B Traffic on the backup link of Leaf-1 (the link from Root-2 to Leaf-1) flows from Root-2 to P-2, then to P-1, and finally to Leaf-1. Traffic on the backup link of Leaf-2 (the link from Root-1 to Leaf-2) flows from Root-1 to P-1, then to P-2, and finally to Leaf-2. Therefore, the backup root traffic for Leaf-1 and Leaf-2 shares a path between P-1 and P-2. It can be seen that multicast traffic at the P nodes has two directions. Taking P-1 as an example, one direction is from P-1 to Leaf-1, and the other is from P-1 to P-2. Therefore, the backup root traffic for Leaf-1 and Leaf-2 shares a path between the two P nodes. However, since multicast traffic at the root node only has one direction, it's equivalent to only having one set of multicast traffic on the link from Root-1 to P-1. Therefore, compared to... Figure 3 In terms of bandwidth redundancy, Figure 4A and Figure 4B The bandwidth redundancy in the process will be reduced, but there will still be four identical multicast traffic between the P node and the leaf node on the public network side.

[0067] When dual-homed protection and dual-root 1+1 protection are deployed simultaneously on the access side, the ideal scenario is that the backup root traffic of the two leaf nodes shares a common path between the two leaf nodes, such as... Figure 5 As shown, the primary and backup roots of Leaf-1 and Leaf-2 are... Figure 3 , Figure 4A and Figure 4B Similarly, the traffic transmission paths in the main links of Leaf-1 and Leaf-2 are also the same. Figure 3 and Figure 4A and Figure 4B The same applies here, so I won't go into too much detail. Figure 5 The traffic in the link from Root-2 to Leaf-1 goes from Root-2 to P-2, then to Leaf-2, and finally to Leaf-1. The traffic in the link from Root-1 to Leaf-2 goes from Root-1 to P-1, then to Leaf-1, and finally to Leaf-2. It can be seen that multicast traffic at the leaf nodes has two directions. Taking Leaf-1 as an example, one direction is from Leaf-1 to Leaf-2, and the other direction is from Leaf-1 to the multicast receiver. Figure 5 (not shown in the image), so the backup root traffic of Leaf-1 and Leaf-2 will share the same path between Leaf-1 and Leaf-2, so that there are only two identical multicast traffic on the public network side, which can effectively reduce the bandwidth redundancy on the public network side and reduce the customer's operating costs.

[0068] To control the routing path of multicast traffic, it is necessary to strictly plan the cost value in the multicast network, ensuring that the primary and backup links are separated to avoid prolonged multicast service interruptions due to simultaneous failure of both primary and backup links. Since routing prioritizes the path with the lowest cost for multicast traffic, ensuring that the routing path of multicast traffic is as efficient as possible is crucial. Figure 5 As shown, if the backup root traffic between two leaf nodes shares a common path, then the cost of the link between the two leaf nodes needs to be smaller than the cost of the link between the two root nodes and the cost of the link between the two P nodes when planning the cost. For example... Figure 5 The cost value of the link between two leaf nodes is set to 800, the cost value of the link between two P nodes is set to 1000, and the cost value of the link between two root nodes is set to 1000. Since the cost value of the link from Root-2 to Leaf-1 is the lowest when multicast traffic is transmitted through the path from Root-2 to P-2, then to Leaf-2, and finally to Leaf-1, this cost value planning allows the backup root traffic of the two leaf nodes to share the same path between the two leaf nodes.

[0069] However, even by planning the cost value in a multicast network, the problem of public network bandwidth redundancy cannot be avoided in some scenarios. For example, in scenarios where various sites act as multicast sources for each other, such as video conferencing services, the roles of multicast source and multicast receiver can be interchanged—that is, a multicast source can also be a multicast receiver, and vice versa. Therefore, if calculated according to... Figure 5 The diagram illustrates how to plan the cost value in a multicast network. Even when the roles of the multicast source and multicast receiver are reversed, the cost will still occur. Figure 3 In scenarios where the backup root traffic of two leaf nodes shares a common path between the two root nodes, four identical multicast traffic instances exist on the public network side, which fails to solve the bandwidth redundancy problem on the public network side.

[0070] Therefore, this application proposes a multicast routing method. Considering that in the prior art, when access-side dual-homing protection and dual-root 1+1 protection are deployed simultaneously, there are four identical traffic streams on the public network side, causing bandwidth redundancy on the public network side, this application, in the scenario of multicast routing with access-side dual-homing protection and dual-root 1+1 protection deployed simultaneously, makes leaf nodes mutually designated root nodes, so that the backup root traffic of leaf nodes shares the same path between leaf nodes, so that there are only two identical traffic streams on the public network side. Therefore, it reduces bandwidth redundancy on the public network side, reduces customer operating costs, and can still reduce bandwidth redundancy on the public network side even in the scenario where each site is a multicast source for each other.

[0071] like Figure 6 As shown, the multicast routing method proposed in this application embodiment can be applied to multicast routing scenarios, specifically in multicast routing scenarios where access-side dual-homing protection and dual-root 1+1 protection are deployed simultaneously. This scenario includes multiple routers. Specifically, some of these routers can be CE routers, some can be PE routers, some can be P routers, etc. CE routers can be multicast sources or multicast receivers, and PE routers can be root nodes directly connected to the multicast source or leaf nodes directly connected to the multicast receiver. Figure 6Taking a multicast network consisting of two P routers, two CE routers, and four PE routers as an example, one of the two CE routers acts as a multicast source, and the other as a multicast receiver. The multicast source provides services to the multicast receiver by transmitting multicast traffic, while the multicast receiver provides service access to users by receiving multicast traffic from the multicast source. Two of the four PE routers act as root nodes, each consisting of a primary root node and a backup root node. The other two act as leaf nodes, each consisting of a primary leaf node and a backup leaf node. The root nodes receive multicast traffic from the multicast source and transmit it to the leaf nodes, which then transmit the multicast traffic to the multicast receivers. For example, the multicast source can be understood as a television station, and the multicast receiver as a user. When a user selects a television program, it's equivalent to selecting the program from the primary leaf node. The multicast traffic (the data of the television program) from the television station is transmitted through the two root nodes to the two leaf nodes, and the primary leaf node then transmits the multicast traffic to the user.

[0072] The multicast routing method proposed in this application can be applied to the BIERv6 MVPN described above, as well as to BIERv4, MPLS and other MVPNs. This application does not limit it.

[0073] like Figure 7 As shown in the figure, this application provides a schematic diagram of the hardware structure of an electronic device. This electronic device can be a routing device. Figure 7 The electronic device 700 is an example of an electronic device. Electronic device 700 may include a processor 701, a memory 702, and a communication interface 703, etc.

[0074] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 700. In other embodiments of this application, the electronic device 700 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0075] Processor 701 may include one or more processing units. For example, processor 701 may include a graphics processing unit (GPU), a central processing unit (CPU), a controller, and / or a neural network processing unit (NPU). Different processing units may be independent components or integrated into one or more processors. In some embodiments, electronic device 700 may also include one or more processors 701. In this application embodiment, processor 701 can execute or retrieve instructions or information stored in memory 702 and process information transmitted through communication interface 703.

[0076] The processor 701 is the nerve center and command center of the electronic device 700. It can generate operation control signals according to the instruction opcode and timing signals to control the fetching and execution of instructions.

[0077] The memory 702 can be used to store one or more computer programs, which include instructions. The processor 701 can execute the instructions stored in the memory 702, thereby causing the electronic device 700 to perform methods such as the calculation of data center load factors provided in some embodiments of this application. The memory 702 may include a code storage area and a data storage area. The data storage area may store data created during the use of the electronic device 700. Furthermore, the memory 702 may include high-speed random access memory and may also include non-volatile memory, such as one or more disk storage components, flash memory components, universal flash storage (UFS), etc. In embodiments of this application, the memory 702 may store multicast routing table entries and configuration code, etc.

[0078] The communication interface 703 can be used to communicate with external devices and can be one or more devices integrating at least one communication processing module. In embodiments of this application, the communication interface 703 can communicate with the communication interfaces of other nodes.

[0079] Using the electronic device 700 provided in this application, the following describes, with reference to the accompanying drawings, the process in which the backup root traffic of the leaf nodes is shared among the leaf nodes by making the leaf nodes mutually designated root nodes during multicast routing in the multicast routing method proposed in this application for the electronic device 700.

[0080] like Figure 8 The diagram shown is a flowchart illustrating a multicast routing method provided in an embodiment of this application, which is applied to an electronic device. Figure 7 Taking the hardware structure of the illustrated electronic device 700 as an example, the method includes:

[0081] Step 801: The first node receives the first routing message.

[0082] In this system, the first node is a leaf node directly connected to the multicast receiver, serving as a backup leaf node between the multicast source and the multicast receiver. The first node can be a PE router. The first routing message is a routing message published by the second node to the first node. The second node is also a leaf node directly connected to the multicast receiver, serving as the primary leaf node between the multicast source and the multicast receiver. The second node can also be a PE router. The first routing message includes extended community attributes, which can be understood as carrying extended community attributes. For example, when the multicast network is a BIERv6 network, the first routing message carrying the IPv6 extended community attribute is VRF Route Import Extended Community. Additionally, the first routing message may also include BGP VPNv4 unicast routing information, etc. Extended community attributes include root node information, which can be understood as the extended community attribute used to identify the root node. Root node information can be, for example, a root node identifier. Root node information indicates that the first node has root node capabilities, meaning the first node can act as the root node of leaf nodes, transmitting multicast traffic to leaf nodes. It can also be understood as the first node being the next-hop node for routes from leaf nodes to the multicast source.

[0083] In some embodiments, the first node receiving the first routing message includes: the first node receiving the first routing message published via the Border Gateway Protocol (BGP).

[0084] The first routing message is a routing message published by the second node via the Border Gateway Protocol (BGP). This first routing message can be a Multicast Virtual Private Network (MVPN) Auto-Discovery (MVPN AD) routing message. MVPN AD routes are used for MVPN member auto-discovery and to assist MPLS in establishing provider mmulticast service interface (PMSI) tunnels. Carrying extended community attributes in the MVPN AD route ensures that all nodes traversed by the MVPN AD route carry root node information, enabling these nodes to act as root nodes. This can be seen as laying the groundwork for subsequent root node designation. Therefore, by carrying extended community attributes in the MVPN AD route, the primary and secondary root nodes corresponding to leaf nodes can be selected. In essence, the first routing message can be understood as the primary and secondary root nodes for selecting primary and secondary leaf nodes.

[0085] For example, such as Figure 9 As shown, the first node can be leaf node-2 (backup leaf node). Leaf node-2 receives MVPN AD routes published via BGP. These MVPN AD routes carry extended community attributes, which in turn carry root node information. Therefore, leaf node-2 has the capability to act as a root node.

[0086] Step 802: The first node enables the root node capability and sends the root node information to the second node.

[0087] In this system, the second node is a leaf node directly connected to the multicast receiver, serving as the primary leaf node between the multicast source and the multicast receiver. The second node can be a PE router. After the first node acquires root node capabilities, it enables these capabilities and sends root node information to the second node. The second node receives this information, effectively making the first node the designated root node for the second node. This allows the second node to recognize the first node's root node capability. Specifically, the first node first enables the root node capability and then associates it with the designated backup root's MVPN-id. For example, the first node can be configured with code to enable root node capabilities and code to associate the MVPN-id. The first node first executes the code `assigned sender-enable` to enable root node capabilities, and then executes the code `backup root mvpn MVPN-id` to associate the backup root's MVPN-id. This enables the root node capability and associates the backup root's MVPN-id before sending root node information to the second node, effectively designating the first node as the designated root node (designated backup root node) for the second node.

[0088] For example, such as Figure 9 As shown, the first node can be leaf node-1 (primary leaf node). Leaf node-2 enables the root node capability and sends root node information to leaf node-1, so that leaf node-1 can know that leaf node-2 has the capability to be a root node, and thus select leaf node-2 as the backup root.

[0089] After receiving the root node information from the first node, the second node can know that the first node has the ability to be a root node, and therefore can select the first node as the root node (backup root node) of the second node.

[0090] Step 803: The first node receives the second routing message from the second node.

[0091] In this process, the second node sends a second routing message to the first node. This second routing message instructs the first node to pass multicast traffic to the second node. For example, the second routing message can be a customer-multicast route (C-multicast route), also known as a C-multicast route message. The C-multicast route message includes multicast member joining information and is used to initiate private network user joining and leaving, and to guide the transmission of private network multicast data traffic. The extended community attribute included in the first routing message in step 801 is the extended community attribute required for C-multicast routing. This can be understood as the ability to determine the root node through this extended community attribute, thereby sending the C-multicast route message to the root node. After the second node sends the C-multicast route to the first node, the first node can then pass multicast traffic to the second node, effectively acting as the root node of the second node. This can be understood as the first node acting as a backup root node for the second node.

[0092] For example, such as Figure 9 As shown, leaf node-1 sends a second routing message to leaf node-2, and leaf node-2 receives the second routing message from leaf node-1. Therefore, leaf node-2 can transmit multicast traffic to leaf node-1 and act as the root node (backup root node) of leaf node-1.

[0093] In some embodiments, prior to step 803, the method further includes: the first node sending a first tunnel establishment request to the second node, and the second node receiving the first tunnel establishment request from the first node.

[0094] The first tunnel establishment request can be, for example, an MVPN AD route. The first tunnel establishment request is used to establish a first tunnel between the first node and the second node. The first tunnel can be, for example, a PMSI tunnel. The first tunnel is used to transmit multicast traffic between the first node and the second node. It can be understood that leaf node-1 needs to transmit multicast traffic to leaf node-2 through the first tunnel.

[0095] For example, such as Figure 9As shown, leaf node-2 sends a first tunnel establishment request to leaf node-1. After receiving the first tunnel establishment request from leaf node-2, leaf node-1 sends a first tunnel establishment request response to leaf node-2. Taking a BIERv6 network scenario as an example, the root node (leaf node-2) sends an Intra-AS I-PMSI AD route to the root node (leaf node-1) through BGP neighbor relationships. This route carries the following information: MVPN RT (Route Target) and PMSI Tunnel Attribute. After receiving the route sent by the root node, the leaf node responds with a Leaf AD route, which carries the following information: Sub-domain-id, BFR-ID, and BFR-prefix. After receiving the route sent by the leaf node, the root node records the leaf node members of the MVPN and sets the bitposition corresponding to each leaf node in the BIERv6 bit string corresponding to the tunnel to 1, thereby adding each leaf node to the BIERv6 I-PMSI tunnel. Thus, the first tunnel between the root node (leaf node-2) and the leaf node (leaf node-1) is established.

[0096] In some embodiments, when the second node carries an Internet Group Management Protocol (IGMP) table and the first node does not carry an IGMP table, the second node sends a second routing message to the first node through the first tunnel, the first node sends a local third routing message to the third node, and the second node receives the multicast traffic transmitted by the first node.

[0097] The IGMP table is used to transmit multicast member joining information. This joining information can be, for example, PIM(C-*,CG) or PIM(CS,CG), and is used to guide multicast traffic. Normally, when a multicast member joins the multicast network (typically from the primary leaf node directly connected to the multicast receiver), an IGMP table is generated at the primary leaf node to transmit the joining information. Additionally, the remote backup profile (RBP) in the IGMP table also creates a backup IGMP table at the backup leaf node, ensuring that the backup leaf node also has access to the multicast member joining information. When a leaf node receives a multicast member's join message, it generates a PIMJoin message via the PIM protocol and then publishes a C multicast route to the multicast source through BGP neighbor relationships. This can be understood as the leaf node needing to obtain multicast traffic from the multicast source to pass on to the multicast receiver. Therefore, if a leaf node does not carry an IGMP table, it cannot obtain multicast member join information and thus cannot obtain multicast traffic from the multicast source. When the second node carries an IGMP table while the first node does not, it can be understood that the second node can obtain multicast traffic from the multicast source, while the first node cannot. In other words, the first node has no multicast traffic, so it needs to redirect the multicast traffic from the multicast source to itself. Specifically, this means redirecting the multicast traffic from the root node directly connected to the multicast source, allowing the root node to pass the multicast traffic to the first node.

[0098] Since there is no multicast traffic at the first node, when the second node sends a second routing message to the first node through the first tunnel, the second node cannot obtain multicast traffic from the first node. At this time, the first node will convert the second routing message received from the second node into a local third routing message. This third routing message can be, for example, a C-multicast routing message, used to redirect multicast traffic. The first node then sends this local third routing message to the third node, which is the root node directly connected to the multicast source. The third node can be a PE router. This can be understood as the first node receiving the second routing message from the second node through the first tunnel and then sending its local third routing message to the third node. This third routing message instructs the third node to pass multicast traffic to the first node. Essentially, the first node obtains multicast traffic from the third node and then passes it to the second node, which receives the multicast traffic from the first node.

[0099] For example, such as Figure 9As shown, the third node can be either root node-2 or root node-1. Taking root node-2 as the third node, when leaf node-1 carries an IGMP table and leaf node-2 does not, leaf node-1 sends a second routing message to leaf node-2 to redirect multicast traffic from leaf node-2. After receiving the second routing message from leaf node-1, leaf node-2 converts the second routing message into a local third routing message. Leaf node-2 then sends the local third routing message to root node-2 to redirect multicast traffic from root node-2. The multicast traffic received from root node-2 is then passed to leaf node-1, where leaf node-1 receives the multicast traffic passed from leaf node-2.

[0100] In some embodiments, the second node sends a fourth routing message to the fourth node, and the second node receives multicast traffic transmitted by the fourth node.

[0101] In this context, the fourth node is the root node directly connected to the multicast source, serving as the primary root node of the second node. The fourth node can be a PE router. The fourth routing message can be, for example, a C-multicast routing message used to direct multicast traffic. This can be understood as the fourth routing message instructing the fourth node to transmit multicast traffic to the second node.

[0102] For example, such as Figure 9 As shown, the fourth node can be root node-1. For leaf node-1, root node-1 can be the primary root node, and leaf node-2 can be the designated backup root node. Leaf node-1 will send a fourth routing message to root node-1 and receive multicast traffic from root node-1. Leaf node-1 will also send a second routing message to leaf node-2 and receive multicast traffic from leaf node-2.

[0103] In the embodiments of this application, both the first node and the second node are leaf nodes directly connected to the multicast receiver. The first node and the second node can be designated roots for each other, that is, the first node can be designated as the backup root node of the second node, and the second node can also be designated as the backup root node of the first node.

[0104] Therefore, the multicast routing method provided in this application can be applied to electronic devices, such as routers. When performing multicast routing and simultaneously deploying dual-homed protection and dual-root 1+1 protection on the access side, this application enables leaf nodes to have root node capabilities by carrying extended community attributes in the MVPN AD route. This allows two leaf nodes to be designated backup root nodes for each other through configuration, with backup root traffic sharing a common path between the two leaf nodes. Compared to the prior art, which selects primary and backup root nodes for leaf nodes through unicast routing, choosing root nodes directly connected to the multicast source as primary and backup root nodes for leaf nodes, and requiring strict cost planning to control the transmission path of primary and backup root traffic, thus resulting in bandwidth redundancy on the public network side, this application's solution ensures that only two identical traffic streams exist on the public network side, effectively reducing bandwidth redundancy on the public network side, reducing customer operating costs, and maintaining bandwidth redundancy even when each site is a multicast source for the other.

[0105] like Figure 10 As shown, taking a multicast route that includes a multicast source, a multicast receiver, two leaf nodes, two root nodes, and two P nodes as an example, the two leaf nodes are leaf node-1 and leaf node-2, the two root nodes are root node-1 and root node-2, and the two P nodes are P-1 and P-2. The multicast routing method proposed in this application will be described in detail below.

[0106] Step 1001: Leaf node-1 publishes MVPN AD routes to both root node-1 and leaf node-2.

[0107] The MVPN AD route includes extended community attributes, which include root node information. This can be understood as root node-1 and leaf node-2 carrying root node information and having the ability to act as root nodes.

[0108] Step 1002: Enable the root node capability for root node-1 and leaf node-2, and send root node information to leaf node-1.

[0109] This can be understood as the root node-1 and leaf node-2 being configured with code that enables the root node capability. The root node-1 and leaf node-2 run this code to enable the root node capability and send root node information to the leaf node-1, thereby letting the leaf node-1 know that both the root node-1 and the leaf node-2 have the capability to act as a root node.

[0110] Step 1003: Leaf node-1 publishes C multicast routes to root node-1 and leaf node-2.

[0111] In step 801, the extended community attribute carried in the MVPN AD route is required for C-multicast routing. This extended community attribute allows the root node to be determined during C-multicast routing. In other words, when leaf node-1 advertises a C-multicast route, it can determine the primary root node as root node-1 and the backup root node as leaf node-2 based on the extended community attribute carried in the MVPN AD route. Therefore, it advertises the C-multicast route to both root node-1 and leaf node-2, enabling root node-1 and leaf node-2 to transmit multicast traffic to leaf node-1.

[0112] At this point, route advertising has been completed in the multicast network. This can be understood as the multicast network having completed the primary and backup root node selection for leaf node-1, where the primary root node is root node-1 and the backup root node (also known as the designated root node) is leaf node-2. The following describes the processing procedures after route advertising in the inclusive provider multicast service interface tunnel (I-PMSI Tunnel) and the selective provider multicast service interface tunnel (S-PMSI Tunnel). I-PMSI and S-PMSI tunnels are two tunnel types in multicast routing. When the multicast traffic transmitted in the I-PMSI tunnel reaches a threshold, the system switches to the S-PMSI tunnel for traffic transmission.

[0113] The I-PMSI tunnel processing involves steps 1004, 1005, 1006, and 1007.

[0114] Step 1004: Root node-1 sends an Intra-ASI-PMSI AD route to leaf node-1.

[0115] Step 1005: Leaf node-1 sends the Leaf A-Droute to root node-1.

[0116] Steps 1004 and 1005 can be understood as establishing an I-PMSI tunnel between the root node-1 and the leaf node-1, so that when the multicast traffic sent by the multicast source reaches the root node-1, the root node-1 can transmit the multicast traffic to the leaf node-1 through the I-PMSI tunnel.

[0117] Step 1006: Leaf node-2 sends I-PMSI AD route to leaf node-1.

[0118] Step 1007: Leaf node-1 sends Leaf AD route to leaf node-2.

[0119] Steps 1006 and 1007 can be understood as establishing an I-PMSI tunnel between leaf node-2 and leaf node-1, so that leaf node-2 can transmit multicast traffic to leaf node-1 through the I-PMSI tunnel.

[0120] At this point, the I-PMSI tunnels between root node-1 and leaf node-1, as well as between leaf node-2 and leaf node-1, are established. After leaf node-1 sends the customer multicast route (C-multicast route) to root node-1 and leaf node-2, root node-1 and leaf node-2 can transmit multicast traffic to leaf node-1 through the I-PMSI tunnels.

[0121] When the multicast traffic in the I-PMSI tunnel reaches the threshold, the multicast traffic can be switched from the I-PMSI tunnel to the S-PMSI tunnel for transmission, with steps 1008, 1009, 1010 and 1011.

[0122] Step 1008: Root node-1 sends a Selective Carrier Multicast Service Interface Automatic Discovery Route (S-PMSI AD route) to leaf node-1, where the S-PMSI AD route carries the Multicast Service Tunnel Attribute (PMSI TunnelAttribute).

[0123] Step 1009: Leaf node-1 sends Leaf AD route to root node-1.

[0124] Steps 1008 and 1009 can be understood as establishing an S-PMSI tunnel between the root node-1 and the leaf node-1, so that when the multicast traffic sent by the multicast source reaches the root node-1, the root node-1 can transmit the multicast traffic to the leaf node-1 through the S-PMSI tunnel.

[0125] Step 1010: Leaf node-2 sends an S-PMSI AD route to leaf node-1, where the S-PMSI AD route carries the PMSI Tunnel Attribute.

[0126] Step 1011: Leaf node-1 sends Leaf AD route to leaf node-2.

[0127] Steps 1010 and 1011 can be understood as establishing an S-PMSI tunnel between leaf node-2 and leaf node-1, so that when the multicast traffic sent by the multicast source arrives at leaf node-2, leaf node-2 can transmit the multicast traffic to leaf node-1 through the S-PMSI tunnel.

[0128] At this point, the S-PMSI tunnels between root node-1 and leaf node-1, as well as between leaf node-2 and leaf node-1, are established. When the multicast traffic in the I-PMSI tunnel reaches the threshold, root node-1 and leaf node-2 can switch the I-PMSI tunnel to the S-PMSI tunnel and transmit multicast traffic to leaf node-1 through the S-PMSI tunnel.

[0129] Steps 1001-1011 above are the normal process when multicast members are added in both leaf node-1 and leaf node-2. If multicast members are added in leaf node-1 but not in leaf node-2, that is, leaf node-1 carries an IGMP table but leaf node-2 does not carry an IGMP table, steps 1012, 1013 and 1014 also exist.

[0130] Step 1012: Leaf node-1 sends a C-multicast route to root node-1 and leaf node-2.

[0131] Step 1012 can be understood as leaf node-1 drawing multicast traffic from root node-1 and leaf node-2. However, since leaf node-2 does not carry an IGMP table, there is no multicast traffic at leaf node-2, and leaf node-1 cannot receive multicast traffic from leaf node-2.

[0132] Step 1013: Leaf node-2 enables the root node capability and converts the C-multicast route sent from leaf node-1 to leaf node-2 into a local C-multicast route before sending it to root node-2.

[0133] Step 1013 can be understood as leaf node-2 drawing multicast traffic from root node-2, and then leaf node-2 being able to pass the multicast traffic to leaf node-1.

[0134] Step 1014: Leaf node-2 connects the tunnel from root node-2 to leaf node-2 and the new tunnel from leaf node-2 to leaf node-1.

[0135] Step 1014 can be understood as performing tunnel splicing at leaf node-2, so that the multicast traffic at root node-2 can be transmitted to a new tunnel with leaf node-2 as the root node and leaf node-1 as the leaf node, that is, the multicast traffic at root node-2 can be transmitted to leaf node-1. Tunnel splicing can be performed, for example, through loopback processing, and this application does not limit it.

[0136] After the tunnel splicing is completed, the transmission path of multicast traffic is as follows: Figure 11 As shown, root node-1 serves as the primary root of leaf node-1, and leaf node-2 serves as the designated backup root of leaf node-1. Root node-1 transmits a multicast traffic to leaf node-1 as the primary root traffic of leaf node-1, and leaf node-2 transmits a multicast traffic to leaf node-1 as the backup root traffic of leaf node-1. The multicast traffic transmitted by leaf node-2 to leaf node-1 is received from root node-2.

[0137] Steps 1001-1014 above are described with the primary leaf node as leaf node-1 and the backup leaf node as leaf node-2. The primary leaf node can also be leaf node-2 and the backup leaf node can also be leaf node-1. For details, please refer to steps 1001-1014 above, which will not be elaborated here.

[0138] Therefore, the multicast routing method provided in this application embodiment can be applied to electronic devices, such as routers. When multicast routing is performed, and access-side dual-homing protection and dual-root 1+1 protection are deployed simultaneously, only two identical traffic streams exist on the public network side, effectively reducing bandwidth redundancy on the public network side and reducing customer operating costs. Furthermore, in special scenarios where multicast members join at leaf node-1 but not at leaf node-2, a C-multicast route can be sent from leaf node-2 to root node-2, enabling leaf node-2 to receive multicast traffic. This allows leaf node-2 to transmit multicast traffic to leaf node-1, achieving shared routing of backup root traffic between the two leaf nodes, effectively reducing bandwidth redundancy on the public network side and reducing customer operating costs.

[0139] It is understood that, in order to achieve the aforementioned functions, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware-driven or software-driven manner 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 the embodiments of this application.

[0140] This application embodiment can divide the above-described electronic device into functional modules based on the method example described above. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0141] When dividing each function into modules according to its corresponding function. Figure 12 A schematic diagram of a possible composition of the electronic device 1200 involved in the above embodiments is shown. The electronic device 1200 can be understood as the electronic device 700 involved in the above embodiments, and the electronic device 1200 can be understood as the first node (leaf node-2) or the second node (leaf node-1) involved in the above embodiments. Figure 12 As shown, the electronic device 1200 may include a receiving unit 1201 and a transmitting unit 1202.

[0142] The receiving unit 1201 can be used to support the electronic device 1200 in performing the above steps 801, 803, etc., and / or other processes used in the technology described herein.

[0143] The transmitting unit 1202 can be used to support the electronic device 1200 in performing the above-described steps 802, etc., and / or other processes used in the technology described herein.

[0144] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0145] The electronic device 1200 provided in this embodiment is used to execute the multicast routing method described above, and thus can achieve the same effect as the above implementation method.

[0146] When using integrated units, such as Figure 13 As shown in the illustration, this application discloses an electronic device 1300, which can be the electronic device 700 described in the above embodiments. The electronic device 1300 may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the actions of the electronic device 1300, for example, it can support the electronic device 1300 in performing the steps described above, such as determining whether a node has root node capabilities, enabling root node capabilities, and transmitting multicast traffic. The storage module can support the electronic device 1300 in storing program code and data. The communication module can support communication between the electronic device 1300 and other devices, for example, it can support the electronic device 1300 in performing the steps performed by the receiving unit 1201 and the sending unit 1202.

[0147] Of course, the unit modules in the above-mentioned electronic device 1300 include, but are not limited to, the processing module, storage module and communication module.

[0148] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as including one or more microprocessor combinations. The storage module can be a memory. The communication module can specifically be a device that interacts with other external devices. For example, the processing module can be a processor 701, the storage module can be a memory 702, and the communication module can be a communication interface 703. The electronic device 1300 provided in the embodiments of this application can be... Figure 7 The electronic device 700 shown. The processor 701, memory 702, communication interface 703, etc., can be connected together, for example, via a bus.

[0149] This application also provides an electronic device, including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions. When the one or more processors execute the computer instructions, the electronic device performs the aforementioned method steps to implement the multicast routing method in the above embodiments.

[0150] This application also provides a computer-readable storage medium storing computer program code, which, when computer instructions are executed on a computer or processor, causes the computer or processor to perform the broadcast routing method described above.

[0151] Embodiments of this application also provide a computer program product, which includes computer instructions that, when executed on a computer or processor, cause the computer or processor to perform the aforementioned related steps to implement the broadcast routing method executed by the electronic device in the above embodiments.

[0152] The electronic device, computer storage medium, and computer program product provided in this embodiment all include the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0153] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0154] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0155] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0157] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0158] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of multicast routing, characterized by, The method comprises: The first node receives a first routing message, the first routing message comprising an extended community attribute, the extended community attribute comprising root node information, the root node information being used to indicate that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; The first node enables the root node capability, and sends the root node information to a second node; the second node being a primary leaf node between the multicast source and the multicast receiver; The first node receives a second routing message of the second node, the second routing message being used to indicate that the first node transmits multicast traffic to the second node.

2. The method of claim 1, wherein, The first node receiving the first routing message comprises: The first node receives the first routing message published through a border gateway protocol (BGP), the first routing message being used to select a primary root node and a backup root node of the primary leaf node and the backup leaf node.

3. The method according to claim 1 or 2, characterized in that, Before the first node receives the second routing message of the second node, the method further comprises: The first node sends a first tunnel establishment request to the second node, the first tunnel establishment request being used to establish a first tunnel between the first node and the second node, the first tunnel being used to transmit multicast traffic between the first node and the second node.

4. The method of claim 3, wherein, When the second node carries an Internet Group Management Protocol (IGMP) table, and the first node does not carry the IGMP table, the method further comprises: After the first node receives the second routing message sent by the second node through the first tunnel, the first node sends a local third routing message to a third node, the third node being a root node directly connected to the multicast source, the third routing message being used to indicate that the third node transmits multicast traffic to the first node.

5. A multicast routing method, characterized by, The method comprises: A second node receives root node information of a first node, the root node information being used to indicate that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast receiver; the second node being a primary leaf node between the multicast source and the multicast receiver; The second node sends a second routing message to the first node, the second routing message being used to indicate that the first node transmits multicast traffic to the second node.

6. The method of claim 5, wherein: The root node information is indicated by an extended community attribute, the extended community attribute being included in a first routing message, the first routing message being received by the first node through a border gateway protocol (BGP), the first routing message being used to select a primary root node and a backup root node of the primary leaf node and the backup leaf node.

7. The method according to claim 5 or 6, characterized in that, Before the second node sends the second routing message to the first node, the method further comprises: The second node receives a first tunnel establishment request of the first node, the first tunnel establishment request being used to establish a first tunnel between the first node and the second node, the first tunnel being used to transmit multicast traffic between the first node and the second node.

8. The method of claim 7, wherein, When the second node carries an Internet Group Management Protocol (IGMP) table and the first node does not carry the IGMP table, the method further comprises: The second node sends the second routing message to the first node through the first tunnel; The second node receives multicast traffic delivered by the first node.

9. The method of claim 8, wherein, the second node sends a fourth routing message to a fourth node, the fourth node being a primary root node of the second node, the fourth routing message being used to instruct the fourth node to deliver multicast traffic to the second node; the second node receives multicast traffic delivered by the fourth node.

10. A multicast routing device, characterized by The multicast routing device is a first node, and the first node comprises: a receiving unit, configured to receive a first routing message, the first routing message comprising an extended community attribute, the extended community attribute comprising root node information, the root node information being used to indicate that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast sink; a sending unit, configured to enable the root node capability and send the root node information to a second node; the second node being a primary leaf node between the multicast source and the multicast sink; The receiving unit is further configured to receive a second routing message of the second node, the second routing message being used to instruct the first node to deliver multicast traffic to the second node.

11. The multicast routing device of claim 10, wherein, The receiving unit is further configured to: receive the first routing message published through a Border Gateway Protocol (BGP), the first routing message being used to select a primary root node and a backup root node of the primary leaf node and the backup leaf node.

12. The multicast routing device according to claim 10 or 11, characterized by Before the first node receives the second routing message of the second node, the sending unit is further configured to: send a first tunnel establishment request to the second node, the first tunnel establishment request being used to establish a first tunnel between the first node and the second node, the first tunnel being used to deliver multicast traffic between the first node and the second node.

13. The multicast routing device of claim 12, wherein, When the second node carries an Internet Group Management Protocol (IGMP) table and the first node does not carry the IGMP table, the receiving unit is further configured to: receive the second routing message sent by the second node through the first tunnel; The sending unit is further configured to send a local third routing message to a third node, the third node being a root node directly connected to the multicast source, the third routing message being used to instruct the third node to deliver multicast traffic to the first node.

14. A multicast routing device, characterized by The multicast routing device is a second node, and the second node comprises: a receiving unit, configured to receive root node information of a first node, the root node information being used to indicate that the first node has root node capability; the first node being a backup leaf node between a multicast source and a multicast sink; the second node being a primary leaf node between the multicast source and the multicast sink; a sending unit, configured to send a second routing message to the first node, the second routing message being used to instruct the first node to deliver multicast traffic to the second node.

15. The multicast routing device of claim 14, wherein the root node information is indicated by an extended community attribute, the extended community attribute is included in a first routing message, the first routing message is received by the first node via a border gateway protocol (BGP), and the first routing message is used to select a primary root node and a backup root node of the primary leaf node and the backup leaf node. The receiving unit is further configured to receive a first tunnel establishment request of the first node, the first tunnel establishment request is used to establish a first tunnel between the first node and the second node, and the first tunnel is used to transmit multicast traffic between the first node and the second node.

16. The multicast routing device according to claim 14 or 15, characterized by The sending unit is further configured to send the second routing message to the first node via the first tunnel when the second node carries an Internet Group Management Protocol (IGMP) table and the first node does not carry the IGMP table. The receiving unit is further configured to receive multicast traffic transmitted by the first node.

17. The multicast routing device of claim 16, wherein, 18. The multicast routing device of claim 17, wherein the sending unit is further configured to send a fourth routing message to a fourth node, the fourth node is a primary root node of the second node, and the fourth routing message is used to instruct the fourth node to transmit multicast traffic to the second node. The receiving unit is further configured to receive multicast traffic transmitted by the fourth node. The computer program product includes computer instructions, and when the computer instructions are run on a computer or a processor, the computer or the processor executes the method in any one of claims 1-4 or 5-9. The computer program product includes computer instructions, and when the computer instructions are run on a computer or a processor, the computer instructions execute the method in any one of claims 1-4 or 5-9. ​ ​ 19. A computer-readable storage medium, characterized in that, ​ 20. A computer program product, characterised in that, ​

Images