Multicast fast reroute method and device, electronic equipment and storage medium

Abstract

The application provides a multicast fast rerouting method and device, electronic equipment and a storage medium. In the application, first routing information is extracted from a first routing entry from a network device to a multicast source sending a current multicast flow, and it is determined whether a FRR resource matching the first routing information already exists. If the FRR resource exists, an MFIB table entry for forwarding the current multicast flow is generated based on the existing FRR resource. If the FRR resource does not exist, a FRR resource matching the first routing information is created, and an MFIB table entry for forwarding the current multicast flow is generated based on the created FRR resource. In this way, multiple multicast flows with the same first routing information can reuse the same FRR resource, avoiding table entry redundancy caused by repeated storage of the same backup forwarding information, and improving the carrying capacity of the device for the multicast flow. When a fault occurs, only the state of the primary and backup entry interface identifiers in the shared FRR resource needs to be switched, and all multicast flows sharing the FRR resource can be switched at the same time.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to multicast fast rerouting methods, apparatus, electronic devices and storage media. Background Technology

[0002] Multicast, as an efficient data transmission mechanism, is widely used in services with high real-time requirements such as online live streaming, video conferencing, and distance education because it can effectively solve the problem of single-point sending and multi-point receiving, realize efficient point-to-multipoint data transmission in the network, and reduce network load.

[0003] In multicast networks, link or node failures are inevitable, and these problems can lead to multicast service interruptions, thereby affecting the continuity of critical services. Therefore, Fast Reroute (FRR) technology for multicast has received widespread attention as an important means to ensure multicast service continuity. Multicast FRR effectively reduces service interruption time and improves network reliability and stability by pre-calculating backup links before a failure occurs and quickly switching to the backup link when the primary link fails.

[0004] However, in existing multicast FRR technology, each multicast stream occupies a dedicated backup forwarding resource. When a large number of multicast streams share the same primary and backup inbound interfaces, multiple backup forwarding resources with identical content are still repeatedly created and stored, resulting in redundancy of backup forwarding resources, wasting resources, and limiting the number of multicast streams the network can support. Summary of the Invention

[0005] In view of this, embodiments of this application provide a multicast fast rerouting method, apparatus, electronic device, and storage medium to solve the problems of wasted hardware resources and limited network scalability caused by each multicast stream exclusively occupying backup forwarding resources in related technologies.

[0006] This application provides a multicast fast rerouting method, which is applied to a network device, and the method includes: Obtain first routing information from the first routing entry, wherein the first routing entry is used to indicate the routing information of the network device to reach the multicast source that sent the current multicast stream; If a Fast Rerouting (FRR) resource that matches the first routing information already exists, then a Multicast Forwarding Table (MFIB) entry for forwarding the current multicast stream is generated based on the existing FRR resource. If no FRR resource matching the first routing information exists, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource.

[0007] This application embodiment also provides a multicast fast rerouting device, which is applied to a network device, and the device includes: An extraction module is used to obtain first routing information from a first routing entry, wherein the first routing entry is used to indicate the routing information of the network device to reach the multicast source that sends the current multicast stream; The resource management module is used to generate a multicast forwarding table (MFIB) entry for forwarding the current multicast stream based on the existing Fast Rerouting (FRR) resource that matches the first routing information, if a Fast Rerouting (FRR) resource already exists. If no FRR resource matching the first routing information exists, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource.

[0008] This application also provides an electronic device, including: a processor and a machine-readable storage medium for storing machine-executable instructions, wherein the machine-executable instructions, when run by the machine-readable storage medium, cause the processor to perform the steps of the above method.

[0009] This application also provides a machine-readable storage medium storing machine-executable instructions that, when executed, enable the implementation of the steps described above.

[0010] As can be seen from the above technical solution, when it is necessary to create an MFIB entry for the current multicast stream, the first routing information (used to indicate to the network device the multicast source sending the current multicast stream) is obtained from the first routing entry, and it is determined whether an FRR resource matching the first routing information already exists. If it exists, an MFIB entry for forwarding the current multicast stream is generated based on the existing FRR resource; if it does not exist, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource. In this way, multiple multicast streams with the same first routing information can reuse the same FRR resource, thereby realizing the sharing of the same FRR resource by different multicast streams. When there are a large number of different multicast streams with the same first routing information in the network, only one FRR resource needs to be stored to meet the backup requirements of the forwarding resources of multiple multicast streams, avoiding the redundancy of entries caused by repeatedly storing the same backup forwarding resources, and significantly reducing hardware resource consumption.

[0011] Furthermore, compared to traditional technologies that require traversing and updating all affected MFIB entries when a fault occurs, this application only needs to switch the status of the primary input interface identifier and the backup input interface identifier in the shared FRR resource. All multicast streams reusing the FRR resource can complete the switching simultaneously, without having to traverse and update each MFIB entry one by one as in related technologies. The time complexity of the switching operation is independent of the number of multicast streams, realizing batch and fast switching of all multicast streams reusing the FRR resource.

[0012] Furthermore, with the same hardware capacity, network devices can support faster rerouting protection for more multicast streams, breaking through the bottleneck in related technologies that limits the number of multicast streams due to the depletion of hardware resources. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of a multicast network architecture provided in an embodiment of this application; Figure 2 A flowchart illustrating the method provided in the embodiments of this application; Figure 3a A control plane architecture diagram provided for embodiments of this application; Figure 3b This is a schematic diagram of a multicast network architecture provided in an embodiment of this application; Figure 4 This is a schematic diagram of the device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] To make the methods provided in this application easier to understand, the methods provided in this application will be described in detail below with reference to the accompanying drawings and embodiments.

[0015] Before introducing the method provided in the embodiments of this application, let's first combine... Figure 1 The existing technical problems are explained as follows: As a communication method alongside unicast and broadcast, multicast technology effectively solves the problem of single-point sending and multi-point receiving, enabling efficient point-to-multipoint data transmission in a network, saving significant network bandwidth and reducing network load. Based on this, multicast technology has been widely applied in various industries in recent years, such as in information services with high requirements for bandwidth and real-time data interaction, including online live streaming, IPTV, distance education, telemedicine, internet radio, and real-time video conferencing.

[0016] Figure 1 This is a schematic diagram of the multicast network architecture provided in the embodiments of this application, such as... Figure 1As shown, in a multicast network, when some hosts (i.e., receivers) in the IP network need information, if multicast is used, the multicast source only needs to send one copy of the information. A multicast distribution tree is established with the help of multicast routing protocols such as Protocol Independent Multicast (PIM). The transmitted information is only copied and distributed on network nodes that are as far away from the multicast source as possible.

[0017] For example, if only hosts B, D, and E need information, using multicast, these hosts can join the same multicast group. The multicast source only needs to send one message to the multicast group, and each router in the network will copy and forward the message according to the distribution of members in the multicast group. Finally, the message will be accurately sent to hosts B, D, and E.

[0018] In multicast networks, when a link or node fails, messages that need to be transmitted through the failed link or router to reach the multicast receiver will be lost or create routing loops, causing multicast data traffic to be interrupted. The interrupted multicast traffic can only resume normal transmission after the new unicast network topology routes converge and the multicast forwarding tree is re-established. During this time, the long multicast traffic interruption time is far from meeting the needs of services with high real-time requirements.

[0019] Therefore, Fast Reroute (FRR) technology emerged. Multicast FRR refers to the pre-calculation of two available upstream interfaces for each multicast stream on network devices (such as switches or routers) carrying multicast functionality: a primary inbound interface and a backup inbound interface. The link upstream of the primary inbound interface is the primary link, and the link upstream of the backup inbound interface is the backup link. The number of network devices reused between the primary and backup links is minimized; ideally, these two links should not intersect upstream at all. Under normal circumstances, network devices configured with PIM-based multicast FRR (PIM FRR) can receive data packets through both the primary and backup links. However, only data packets received through the primary link are received and forwarded downstream; data packets received through the backup link are discarded. If a failure is detected in the primary link, the network device immediately switches to the backup link and begins receiving and forwarding data packets from the backup link. If the failure is resolved, the network device can switch back to the primary link.

[0020] In existing multicast FRR (Free Forwarding) systems, each multicast source on each network device has its own dedicated forwarding resources (including at least MFIB entries, hardware forwarding table entries for the primary and backup interfaces, or hardware forwarding labels). When a large number of multicast streams share the same primary and backup interfaces, it causes severe redundancy in forwarding resources, resulting in resource waste. Especially in large multicast networks, the number of protected multicast streams is enormous, leading to a surge in forwarding resources on devices (especially core nodes), potentially exhausting valuable hardware forwarding resources and limiting network scalability.

[0021] Based on this, embodiments of this application provide a multicast fast rerouting method, apparatus, electronic device, and storage medium to solve the problems of wasted hardware resources and limited network scalability caused by each multicast stream exclusively occupying backup resources in related technologies.

[0022] The method provided in the embodiments of this application is described in detail below: See Figure 2 , Figure 2 This is a flowchart illustrating the method provided in an embodiment of this application. The execution subject of this method is a network device, which may optionally be a switch or a router.

[0023] S201, Obtain first routing information from the first routing entry. The first routing entry is used to indicate the routing information for the network device to reach the multicast source that sent the current multicast stream.

[0024] In this embodiment, when a network device receives a join request for the current multicast stream (S,G) and needs to establish a multicast forwarding information base (MFIB) entry for the current multicast stream, it uses a multicast routing protocol, such as Protocol Independent Multicast (PIM), to extract the first routing information from the first routing entry (also known in the industry as a unicast routing entry) leading from the network device to the multicast source S, based on the IP address of the multicast source S that sent the current multicast stream (S,G).

[0025] The first routing information includes at least the primary in-interface identifier and backup / secondary in-interface identifier required for the multicast source S of the current multicast stream (S,G) to send multicast data to the multicast group G, as well as the network prefix and mask of the multicast source S.

[0026] In one specific implementation, the PIM (Plan-In-Process) query is used to look up the unicast routing table of the network device based on the IP address of the multicast source S. From the first routing entry leading from the network device to the multicast source S, the primary outgoing interface identifier and the backup outgoing interface identifier are extracted. The primary outgoing interface identifier is used as the primary incoming interface identifier for multicast source S to send multicast data to multicast group G, and the backup outgoing interface identifier is used as the backup incoming interface identifier. Simultaneously, the PIM extracts the network prefix and mask of the multicast source S from the first routing entry matching the multicast source IP address (the extracted network prefix and mask can also be called source routing prefix information). The primary incoming interface identifier, the backup incoming interface identifier, and the source routing prefix information together constitute the first routing information.

[0027] It should be noted that the FRR resource in this application represents a backup forwarding channel that can be shared by MFIB entries of multiple multicast streams. An FRR resource is defined by the following key attributes: primary ingress interface identifier (the identifier of the interface used to receive and forward multicast traffic under normal traffic conditions), backup ingress interface (the identifier of the interface enabled to receive and forward multicast traffic when the primary ingress interface fails), and multicast source routing prefix and mask. This ensures that multicast streams with not only the same primary and backup ingress interfaces but also identical upstream routing sources can share the FRR resource, thereby guaranteeing the consistency of Reverse Path Forwarding (RPF) checks.

[0028] S202, if a Fast Rerouting (FRR) resource that matches the first routing information already exists, then generate an MFIB entry for forwarding the current multicast stream based on the existing FRR resource.

[0029] S203. If no FRR resource matching the first routing information exists, create an FRR resource matching the first routing information and generate an MFIB entry for forwarding the current multicast stream based on the created FRR resource.

[0030] After retrieving the first routing information, the network device searches its locally maintained FRR resource database to determine if an FRR resource that perfectly matches the first routing information exists. If a matching FRR resource exists, it indicates that the current multicast stream (S,G) shares the same primary ingress interface, backup ingress interface, and network prefix and mask of the multicast source with one or more existing multicast streams. In this case, the FRR resource is directly reused to generate the MFIB entry for the current multicast stream (S,G).

[0031] If no matching FRR resource exists, it indicates that this is the first multicast stream using the primary ingress interface, backup ingress interface, and network prefix and mask of the multicast source. In this case, the control panel creates a new FRR resource, which records the primary ingress interface identifier, backup ingress interface identifier, and the network prefix and mask of the multicast source S of the current multicast stream (S,G). Based on the newly created FRR resource, an MFIB entry for the current multicast stream is generated.

[0032] In one specific implementation, the network device maintains a global FRR resource tree, such as the Adelson-Velsky and Landis (AVL) tree, for efficient management and retrieval of created FRR resources. Each tree node corresponds to an FRR resource, and each tree node records the key value of the corresponding FRR resource. The key value is obtained by performing specified operations, such as hash operations, on the primary inbound interface, backup inbound interface, multicast source network prefix and mask of the FRR resource.

[0033] Accordingly, after obtaining the aforementioned first routing information, a specified operation is performed on the extracted primary ingress interface identifier, backup ingress interface identifier, and the network prefix and mask of the multicast source to obtain the target key value. A search is then conducted in the FRR resource tree to find a tree node that matches the target key value. If a matching tree node is found (i.e., the key value is exactly the same), it indicates that an FRR resource matching the first routing information already exists, meaning that the current multicast flow (S,G) shares the same primary ingress interface, backup ingress interface, and the network prefix and mask of the multicast source with one or more existing multicast flows. At this point, the FRR resource is reused to generate the MFIB entry for the current multicast flow (S,G).

[0034] If no matching tree node is found, it indicates that the current multicast stream is the first multicast stream to use the primary ingress interface, backup ingress interface, and network prefix and mask of the multicast source. In this case, the network device (usually executed by the network device's control panel) creates a new FRR resource, which includes the aforementioned primary ingress interface identifier, backup ingress interface identifier, and network prefix and mask of the multicast source.

[0035] Specifically, when the network device is a switch, the switch includes a main control board and interface boards. The creation of FRRs is performed by the main control board, more specifically by the control logic of the control plane within the main control board. When the main control board creates a new FRR resource in the control plane, it calls the product-related callback function to request the FRR resource from the underlying hardware resources of the network device's hardware platform. It then converts the FRR resource (i.e., product information `product_priv`) adapted to the underlying hardware resource format of the network device's hardware platform into an FRR resource data structure record in the control plane and completes the initialization of the hardware resources. Furthermore, it creates a tree node corresponding to the newly created FRR resource in the FRR resource tree, recording the FRR resource's key value and FRR resource ID, among other information, in the newly created tree node. Finally, it generates the MFIB entry for the current multicast stream based on the newly created FRR resource.

[0036] The above search and creation process enables the automatic reuse or creation of FRR resources, avoiding the need to independently store the same backup forwarding resources for each multicast stream with the same first routing information.

[0037] This network device uses the acquired (reused or newly created) FRR resources to generate MFIB entries for the current multicast stream (S,G). These MFIB entries store an identifier pointing to the FRR resource (e.g., FRR ID or hardware index). Simultaneously, the MFIB entries record a list of outgoing interfaces (i.e., the interfaces through which this network device forwards multicast data downstream).

[0038] In traditional implementations, each MFIB entry independently maintains the state of its primary and backup inbound interfaces. Even if multiple entries have identical primary and backup inbound interfaces, FRR switching is independent. This application introduces FRR resources to transform this "one-to-one" mapping into a "many-to-one" mapping. Multicast streams no longer directly manage their own primary and backup inbound interfaces, but are associated with the same FRR resource. Operations for traffic forwarding and FRR switching are elevated from operations targeting individual MFIB entries to operations targeting shared FRR resources.

[0039] In this embodiment of the application, through the above mechanism, multiple multicast streams with the same primary inbound interface identifier, backup inbound interface identifier, and source routing prefix can share the same FRR resource, avoiding the repeated storage of the same backup forwarding resource for multiple multicast streams with the same first routing information, thereby saving hardware forwarding table entry resources.

[0040] It should be noted that the generation of the MFIB entry for the current multicast stream (S,G) using the obtained (reused or newly created) FRR resources is still executed by the control logic of the control plane in the main control board. After generating the MFIB entry for the current multicast stream (S,G), the main control board also needs to write it into the underlying hardware of the network device hardware platform, that is, write it into the forwarding plane for subsequent routing and forwarding. This process refers to relevant conventional technologies and will not be elaborated here.

[0041] This concludes the process. Figure 2 The process is shown below.

[0042] pass Figure 2 As shown in the process, when an MFIB entry needs to be created for the current multicast stream, the first routing information (used to indicate to the network device the multicast source sending the current multicast stream) is obtained from the first routing entry, and it is determined whether an FRR resource matching the first routing information already exists. If it exists, an MFIB entry for forwarding the current multicast stream is generated based on the existing FRR resource; if it does not exist, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource. In this way, multiple multicast streams with the same first routing information can reuse the same FRR resource, thereby achieving the sharing of the same FRR resource by different multicast streams. When there are a large number of different multicast streams with the same first routing information in the network, only one FRR resource needs to be stored to meet the backup requirements of the forwarding resources of multiple multicast streams, avoiding the redundancy of entries caused by repeatedly storing the same backup forwarding resources, and significantly reducing hardware resource consumption.

[0043] Furthermore, compared to traditional technologies that require traversing and updating all affected MFIB entries when a fault occurs, this application only needs to switch the status of the primary and backup interfaces in the shared FRR resource. All multicast streams reusing the FRR resource can complete the switching simultaneously, without having to traverse and update each MFIB entry one by one as in related technologies. The time complexity of the switching operation is independent of the number of multicast streams, thus achieving batch and fast switching of all multicast streams reusing the FRR resource.

[0044] Furthermore, with the same hardware capacity, network devices can support faster rerouting protection for more multicast streams, breaking through the bottleneck in related technologies that limits the number of multicast streams due to the depletion of hardware resources.

[0045] As an example, this network device maintains a reference count for each FRR resource. The reference count indicates the number of multicast streams using the FRR resource for forwarding. The default initial value is a set value, such as 1 (that is, when an FRR resource is created, its reference count is 1). When another multicast stream reuses an FRR resource, this network device increments the reference count of the FRR resource by a specified value, such as 1. When any multicast stream using the FRR resource terminates its usage relationship with that FRR resource, that is, when the MFIB entry generated based on the FRR resource is no longer used to forward multicast streams, this network device decrements the reference count of the FRR resource by a specified value, such as 1. When the reference count decreases to 0, it indicates that no multicast stream is using the FRR resource anymore, and this network device releases the hardware and software resources occupied by the resource (including deleting the FRR resource entry and releasing the hardware index).

[0046] The decision to no longer use MFIB entries generated based on the FRR resource for forwarding multicast streams includes at least one of the following: When a rejection notification is received, the rejection notification is sent by each receiver belonging to the same multicast group, and the rejection notification indicates that multicast data of the multicast stream is refused to be received. When the first routing information changes and cannot match the FRR resource. Specifically, when changes in the network topology cause changes in the first routing information corresponding to the multicast stream, resulting in a change in the path from the multicast source to this device, and the first routing information can no longer match the FRR resource. When a multicast stream using the FRR resource to generate MFIB entries meets any of the above conditions, the termination of the usage relationship between the multicast stream and the FRR resource is triggered.

[0047] Optionally, and exemplaryly, this network device maintains a global FRR resource tree, with each tree node corresponding to an FRR resource. Each tree node records at least the key value of the FRR resource (consisting of the primary ingress interface identifier, backup ingress interface identifier, source routing prefix, and mask), resource ID, and reference count. When a new FRR resource is initially created, a corresponding node is created in the tree, and the reference count of that node is set to a predetermined value (e.g., 1). When another multicast stream reuses an existing FRR resource, this network device finds the corresponding node in the tree and increments the reference count of that node by a specified value (e.g., 1). When a multicast stream no longer uses the FRR resource (e.g., the multicast stream is deleted or the path changes), this network device decrements the reference count of the corresponding node by a specified value (e.g., 1). When the reference count decreases to 0, indicating that no multicast stream is using the FRR resource, this network device deletes the node from the tree and releases the hardware and software resources occupied by the resource (including deleting the FRR resource table entry and releasing the hardware index). In this way, the tree nodes in the FRR resource tree reflect the number of multicast streams using the resource in real time, realizing automated lifecycle management of the resource.

[0048] The reference counting mechanism in the above embodiments enables automated management of FRR resources.

[0049] As an example, the steps of the above embodiment are applicable to network devices such as chassis switches, wherein the control board is responsible for running control plane protocols and managing FRR resources, and the interface board is responsible for data plane forwarding.

[0050] The method provided in the above embodiments is executed by the control board of the network device. After the network device (control board) creates an MFIB entry for the current multicast stream (S,G), it needs to synchronize the MFIB entry to the interface board.

[0051] If both the primary input interface indicated by the primary input interface identifier and the backup input interface indicated by the backup input interface identifier are physical interfaces, then only the MFIB entry will be synchronized to the interface board where these two interfaces are located (because other interface boards will not receive the MFIB entry), thus avoiding unnecessary resource consumption.

[0052] If the primary ingress interface indicated by the primary ingress interface identifier and / or the backup ingress interface indicated by the backup ingress interface identifier are non-physical interfaces, such as Virtual Local Area Network (VLAN) interfaces or Link Aggregation Group (LAG) interfaces, then since traffic may enter from any interface board, the MFIB entries need to be synchronized to all interface boards connected to the control board.

[0053] When the control board creates a new FRR resource, it also needs to synchronize the FRR resource configuration information (including the primary input interface identifier, backup input interface identifier, the status of the primary input interface identifier, the status of the backup input interface identifier, etc.) to the interface board. The synchronization strategy is the same as the MFIB entries: physical interfaces are synchronized only to the relevant interface board, while non-physical interfaces are synchronized to all interface boards. For cases where an existing FRR resource is reused, since the FRR resource already exists on the interface board, no resynchronization is required.

[0054] The aforementioned intelligent synchronization strategy avoids broadcasting MFIB entries to unrelated interface boards, saving inter-board communication bandwidth and hardware entry resources of the interface boards.

[0055] It should be noted that the above describes the synchronization between the main control board and the interface boards in a distributed chassis switch, and should not be confused with the control plane of the main control board sending data to the data forwarding plane.

[0056] It should also be noted that in box-type devices (where the control plane and data plane are integrated on the same chip), this synchronization step can be simplified to table entry sharing or pointer passing in software memory, without the need for actual inter-board communication.

[0057] The intelligent synchronization strategy described in the above embodiments avoids broadcasting forwarding information to unrelated interface boards, saving inter-board communication bandwidth and hardware table resources of the interface boards.

[0058] The configuration of multicast forwarding has been explained in detail above. The following section provides a detailed introduction to failover scenarios: As an example, the FRR resource includes a primary input interface identifier and a backup input interface identifier, each having a valid or invalid state. When the primary input interface identifier indicates that the primary input interface is normal, the primary input interface identifier is in a valid state and is used to receive and forward multicast data. The backup input interface identifier is in an invalid state and is prohibited from forwarding multicast data. At this time, both the primary and backup input interfaces receive multicast stream data, but the primary input interface forwards the data and discards packets without forwarding them.

[0059] When this network device detects an anomaly on the primary ingress interface (e.g., physical link interruption, BFD session timeout, or continuous loss of multicast data streams), it performs a handover operation. Specifically, the primary ingress interface identifier is switched from an active state to an inactive state, and the backup ingress interface identifier is switched from an inactive state to an active state, so that multicast data can be received and forwarded via the backup ingress interface. Since the MFIB entries of multiple multicast streams all point to the same FRR resource, this state switch will simultaneously affect all multicast streams using that FRR resource, causing them to begin receiving and forwarding traffic from the backup ingress interface, thus achieving batch handover.

[0060] Furthermore, when the primary input interface identifier switches from an active state to an inactive state, and the backup input interface identifier switches from an inactive state to an active state, the dependency table chain maintained in the FRR resource is used to traverse each MFIB entry generated based on the FRR resource. If an MFIB entry contains an output interface that includes a backup input interface identifier, the backup input interface identifier is deleted from the output interface. This prevents data from entering through the backup input interface and then being forwarded out through the same interface.

[0061] Through the above embodiments, batch switching can be achieved simply by switching the status of the primary inbound interface identifier and the backup inbound interface identifier in the FRR resource (i.e., switching the primary inbound interface identifier from an active state to an inactive state, and switching the backup inbound interface identifier from an inactive state to an active state), and the time complexity is independent of the number of multicast streams. At the same time, by deleting the backup inbound interface identifier in the outbound interface, possible loops are avoided, and the reliability of the backup path is increased.

[0062] It should be noted that the dependency table necklace table can be replaced with a bitmap index or other fast lookup structure, as long as it can quickly locate all related MFIB table entries.

[0063] To illustrate the method provided in this application in more detail, the solution provided in this application will be described in more detail below with reference to specific embodiments.

[0064] In this embodiment, the network device is a chassis switch, which includes a main control board and several interface boards (line cards). The main control board runs control plane protocols (such as PIM and IGP) and is responsible for route calculation, FRR resource management, and MFIB entry generation. The interface boards are responsible for data plane forwarding, and their hardware chips (such as ternary content addressable memory, TCAM) store hardware forwarding table entries.

[0065] This application introduces a new logical layer into the multicast forwarding control plane, the FRR resource management layer, for details of which can be found in the control plane architecture diagram (i.e., Figure 3a ), Figure 3a The document demonstrates how the control plane manages the binding relationship between FRR resources and MFIB entries, and the idea of ​​multiple MFIB entries sharing a single FRR resource entry in the data plane.

[0066] Combination Figure 3b The network topology shown is described in detail. For example... Figure 3b As shown, the IP address of multicast source S is 192.168.1.100, belonging to the network segment 192.168.1.0 / 24. Upstream of switch R5: the primary next hop points to switch R2, with the primary outgoing interface being GE0 / 0 / 1; the backup next hop points to switch R6, with the backup outgoing interface being GE0 / 0 / 2. Downstream of R5 are receivers (host B, host D, and host E).

[0067] As a network device implementing the method of this application, R5 maintains a global AVL tree (FRR resource tree) in its control plane, with each tree node corresponding to an FRR resource. The data structure of the FRR resource includes at least: resource ID (FRR_ID), primary input interface identifier, backup input interface identifier, multicast source prefix and mask, primary input interface identifier status, backup input interface identifier status, reference count (ref_count), product information (product_priv), and MFIB table chain table.

[0068] The creation of FRR resources and generation of MFIB entries for the first group of streams (S,G1) includes the following steps: 1. Route calculation When switch R5 receives a join request for multicast group G1 (e.g., 224.1.1.1), the PIM protocol queries the unicast routing table based on the source IP 192.168.1.100.

[0069] The unicast routing table provides the optimal outgoing interface GE0 / 0 / 1 for the source IP 192.168.1.100 (according to the RPF check rules, switch R5 identifies this outgoing interface as the primary incoming interface for the multicast flow). Simultaneously, since FRR is enabled, a backup next-hop outgoing interface is provided, assumed to be switch R6, and the physical interface GE0 / 0 / 2 connecting R5 and R6 is identified as the backup incoming interface. PIM extracts the destination network prefix 192.168.1.0 and the subnet mask 24 from the matched routing entry as the source routing prefix information. Thus, the first routing information is: Primary incoming interface identifier = GE0 / 0 / 1, Backup incoming interface identifier = GE0 / 0 / 2, Source routing prefix information = 192.168.1.0 / 24.

[0070] 2. FRR resource search The control plane of switch R5 constructs an index key Key based on the primary input interface identifier GE0 / 0 / 1, the backup input interface identifier GE0 / 0 / 2, and the source routing prefix 192.168.1.0 / 24.

[0071] A matching tree node was searched in the AVL tree, but no matching tree node was found, meaning there is no FRR resource node matching this key. At this time, no other multicast stream in the current network uses the same primary ingress interface identifier GE0 / 0 / 1, backup ingress interface identifier GE0 / 0 / 2, and source routing prefix 192.168.1.0 / 24.

[0072] 3. Create new FRR resources (1) Assign a unique FRR_ID, such as 100.

[0073] (2) Initialize FRR resource attributes: primary ingress interface identifier GE0 / 0 / 1=ACTIVE_PRIMARY, ingress interface identifier GE0 / 0 / 2= INACTIVE_BACKUP, source route prefix information source_prefix=192.168.1.0, prefix_len=24.

[0074] (3) Set the primary input interface identifier to an active state (i.e., ACTIVE_PRIMARY=GE0 / 0 / 1, indicating that it is used to receive and forward multicast data), set the backup input interface identifier to an inactive state (i.e., INACTIVE_BACKUP=GE0 / 0 / 2, indicating that it is prohibited from forwarding multicast data), set the reference count ref_count=1, create the dependency table necklace table for this FRR resource, the dependency table necklace table is associated with all MFIB table entries of multicast streams generated using this FRR resource, and is initially empty.

[0075] The dependency list linked list stores pointers to all MFIB entries bound to this FRR resource. Its core function is that when an FRR switch occurs, the control plane does not need to traverse the entire MFIB table; it only needs to traverse this linked list to perform necessary coordination operations on all affected multicast streams. For example, after switching to an alternate path, it may be necessary to remove interfaces with the same name as the alternate interface from the outgoing interface list to avoid loops.

[0076] (4) Call the product-related callback function to request FRR resources from the underlying hardware resources of this network device hardware platform. The underlying hardware (data forwarding plane of the control board) requests FRR resources in a resource format adapted to the R5 underlying hardware (such as TCAM). That is, it creates an index of the hardware table entry of the FRR resource. The underlying hardware returns the index of the FRR resource (e.g., 0x1003) to the control plane. This index is stored in the product_priv field in the FRR resource data format for subsequent direct hardware operations.

[0077] It should be noted that different hardware platforms (such as TCAM switches and Central Processing Unit (CPU) software switches) apply for and manage hardware resources in different ways. Therefore, this solution designs a "callback function" mechanism, equivalent to an abstract interface. When an FRR resource is created, the system calls this callback function, which is bound to the specific hardware platform, to complete the application for the underlying hardware resources (e.g., allocating an index number for a hardware entry in the TCAM, or a fast forwarding microcode handle in the CPU's software router). After successful application, the index (handle or index) of the hardware entry is stored in the product_priv field of the FRR resource for subsequent forwarding. In this way, the upper-level FRR resource management logic does not need to care about the underlying hardware details, achieving cross-platform adaptation. This allows different hardware platforms or product lines to mount their own unique data structures and still use the method provided in this application, improving its applicability.

[0078] (5) Create a tree node for the newly created FRR resource in the AVL tree. The key value is the Key mentioned above. The tree node records the FRR resource attribute information such as FRR_ID=100, ref_count, and dependency table (initially empty).

[0079] It should be noted that each FRR resource is maintained by a data structure in the system, and its main fields and functions are as follows: / Example of FRR resource node data structure / typedef struct frr_resource_node_s { AVL_NODE avl_node; / Used to access the global AVL tree, with keys of (main IF, backup IF, prefix, mask). / uint32_t resource_id; / Globally unique FRR resource identifier / / Resource definition core key value / interface_index_t primary_if; / Main input interface index / interface_index_t backup_if; / Alternate Ingress Interface Index / ip_prefix_t source_prefix; / Multicast source routing prefix / uint8_t prefix_len; / Prefix mask length / / Resource Management Information / uint32_t ref_count; / Reference count, the number of MFIB entries bound to this FRR resource. / void product_priv; / Product information pointer, used to carry specific hardware forwarding resources / / Dependencies and State / list_head_t dependent_mfib_list; / MFIB table necklace table that depends on this FRR resource / enum frr_state current_state; / Current status: ACTIVE_PRIMARY (primary active) or ACTIVE_BACKUP (backup active) / / Backup forwarding information / forwarding_action_t backup_actions; / Forwarding action performed when traffic enters from the backup interface. / } frr_resource_node_t.

[0080] The backup actions define how the data plane should handle traffic when it enters the device through a backup inbound interface. This may include specific operations such as rewriting MAC addresses, pushing / popping MPLS labels, and specifying the next hop.

[0081] 4. MFIB entry generation and synchronization After completing the FRR resource creation, an MFIB entry is created for the multicast stream (S, G1). Specifically, switch R5 creates a new entry in the Multicast Forwarding Information Base (MFIB) to guide the forwarding of the (S, G1) stream. This MFIB entry includes the following: Includes (S, G1) identifiers; List of outgoing interfaces (e.g., GE0 / 0 / 23, connecting to downstream receivers); A new field, frr_resource_id, has been added, and this field should be filled with 100.

[0082] In switch R5, MFIB entries are synchronized to the interface boards. For distributed chassis devices, if the primary input interface (GE0 / 0 / 1) is located on interface board A, and the backup input interface (GE0 / 0 / 2) is located on interface board B, then R5 (the main control board) only synchronizes the MFIB entries and FRR resource 100 to interface boards A and B; other interface boards do not need to be synchronized to avoid resource waste. For box-type devices, cross-board synchronization is not required.

[0083] At the same time, add the pointer to the MFIB table entry to the dependency table necklace table of FRR resource ID=100.

[0084] The multiplexing of the second set of streams (S, G2) includes the following steps: 1. Suppose that switch R5 subsequently receives a join request for another group broadcast stream (S, G2) (same source IP, different group address G2), and an entry needs to be created for (S, G2).

[0085] 2. In switch R5, the PIM repeats the above route calculation process and obtains the same primary ingress interface GE0 / 0 / 1, backup ingress interface GE0 / 0 / 2, and source route prefix 192.168.1.0 / 24.

[0086] 3. Switch R5 constructs a Key value based on the primary input interface identifier GE0 / 0 / 1, the backup input interface identifier GE0 / 0 / 2, and the source routing prefix 192.168.1.0 / 24. The Key is searched in the AVL tree and the node FRR_ID=100 is hit.

[0087] 4. Switch R5 does not need to create a new FRR resource. Instead, it directly creates an MFIB entry for (S, G2), sets frr_resource_id=100, and records its outgoing interface list (e.g., GE0 / 0 / 24). The pointer to this MFIB entry is added to the dependency table of FRR resource 100, and the reference count of FRR resource 100 is increased to 2. No new FRR resource entries are added in the hardware; the two multicast streams share the same backup resource.

[0088] In this way, the two multicast streams share the same FRR backup resource, saving hardware entries.

[0089] Fault switching process 1. During data forwarding, if switch R5 detects a link failure on the main input interface GE0 / 0 / 1 (e.g., through Bidirectional Forwarding Detection (BFD) session failure down or interface physical down detection).

[0090] 2. Trigger Switching: Upon detecting an anomaly in the primary input interface associated with FRR resource FRR_ID_100, the system directly writes commands to the hardware chips of interface board A and interface board B using the hardware index (0x1003) stored in product_priv. This switches the primary input interface identifier in the corresponding FRR resource table entry from an active state to an inactive state (i.e., changes GE0 / 0 / 1 in the corresponding FRR resource table entry from ACTIVE_PRIMARY to INACTIVE_PRIMARY), and switches the backup input interface identifier from an inactive state to an active state (i.e., changes GE0 / 0 / 2 from INACTIVE_BACKUP to ACTIVE_BACKUP), thus switching the active state of the primary and backup input interfaces.

[0091] 3. Batch activation: The hardware chip will automatically switch the ingress interface of the two multicast streams to the backup ingress interface GE0 / 0 / 2 simultaneously, based on the valid status of the primary ingress interface and the backup ingress interface in the FRR resources.

[0092] 4. To avoid potential forwarding loops, R5 iterates through the dependency table of FRR resource 100, checking whether the outgoing interface list of each MFIB entry contains the newly enabled backup incoming interface identifier (i.e., GE0 / 0 / 2). If it does, GE0 / 0 / 2 is removed from the outgoing interface list of that MFIB entry.

[0093] In this way, the control plane does not need to traverse and modify every affected MFIB entry, enabling batch failover at the microsecond level.

[0094] 5. Resource Release: When switch R5 receives a notification that all receivers in the multicast group corresponding to multicast stream (S,G1) have refused to receive the multicast data (e.g., all downstream receivers have left, causing the multicast stream to be pruned, or the entry has expired), switch R5 deletes the corresponding MFIB entry and decrements the reference count of FRR resource FRR_ID_100 by 1 (updating it to 1).

[0095] When (S, G2) is also deleted, the reference count is reduced to 0, the corresponding tree node is removed from the AVL tree, and the hardware entry (i.e., the hardware resource pointed to by product_priv) is released through a callback function, completing the full reclamation. If the reference count is not 0, the FRR resource FRR_ID_100 is retained.

[0096] Through the above embodiments, this application effectively solves the problem of wasted hardware resources caused by each multicast stream exclusively occupying backup resources in the existing multicast FRR technology, and significantly improves the multicast service carrying capacity and scalability of network devices.

[0097] The core technical key points of the above embodiments are as follows: First, a global FRR resource pool was established, where multiple multicast flow entries with the same primary inbound interface identifier, backup inbound interface identifier, and source routing prefix are bound to the same FRR resource object, instead of each maintaining its own set of backup information. The lifecycle (creation, reuse, and destruction) of resources is automatically managed through reference counting.

[0098] Second, when the primary input interface fails, it is only necessary to switch the primary input interface identifier in the corresponding FRR resource from an effective state to an invalid state and the backup input interface identifier from an invalid state to an effective state. The data plane forwards the data uniformly according to the state of the FRR resource, realizing batch fast switching of all associated multicast streams. The data plane forwards the data uniformly according to the state of the shared FRR resource, realizing nanosecond-level switching with global effect after a single operation.

[0099] Thirdly, a dependency linked list is maintained inside each FRR resource object, which records all MFIB entries of multicast flows generated based on the FRR resource, so that all affected service flows can be quickly located during fault switching and necessary coordination operations (such as updating the outgoing interface list) can be performed, and the efficiency is much higher than full table scanning.

[0100] In this embodiment, with router R5 as the core, the FRR resource sharing mechanism based on first routing information (primary incoming interface, backup incoming interface, multicast source prefix and mask) is completely presented. FRR resources are managed through an AVL tree, callback functions are used to adapt to different hardware platforms, rapid linkage is realized through the dependency linked list, and inter-board resource occupation is optimized through an intelligent synchronization strategy. When multiple multicast flows share the same primary incoming interface, backup incoming interface, multicast source prefix and mask, only one copy of FRR resource entry needs to be stored in the hardware, which significantly saves hardware resources. In case of a fault, only the state of the resource needs to be updated to realize simultaneous switching of all associated flows, and the switching speed is independent of the number of flows.

[0101] The method provided by the embodiments of the present application has been described above, and the apparatus provided by the embodiments of the present application will be described below: See Figure 4 , Figure 4 which is a structural diagram of the apparatus provided by the embodiments of the present application. As Figure 4 shown, the apparatus is applied to a network device, and comprises: an extraction module 401 and a resource management module 402.

[0102] The extraction module 401 is configured to obtain first routing information from a first routing entry, where the first routing entry is used to indicate routing information of the network device reaching a multicast source that sends a current multicast flow; The resource management module 402 is configured to, if there already exists a fast reroute (FRR) resource matching the first routing information, generate a multicast forwarding information base (MFIB) entry for forwarding the current multicast flow based on the existing FRR resource; if there is currently no FRR resource matching the first routing information, create an FRR resource matching the first routing information, and generate an MFIB entry for forwarding the current multicast flow based on the created FRR resource.

[0103] As an embodiment, the first routing information at least comprises: a primary incoming interface identifier and a backup incoming interface identifier required for a multicast source to send multicast data to a multicast group, as well as a network prefix and a mask of the multicast source; the FRR resource at least comprises: the primary incoming interface identifier, the backup incoming interface identifier, as well as the network prefix and the mask of the multicast source.

[0104] As an example, the FRR resource includes: a primary input interface identifier and a backup input interface identifier; when the primary input interface identifier indicates that the primary input interface is normal, the primary input interface identifier is in a valid state and is used to receive and forward multicast data; when the backup input interface identifier is in an invalid state, it is prohibited from forwarding multicast data. The device also includes a switching module, used to switch the primary input interface identifier from an active state to an inactive state and the backup input interface identifier from an inactive state to an active state when the primary input interface is abnormal, so as to receive and forward multicast data of all multicast streams using the FRR resource via the backup input interface.

[0105] As one embodiment, the FRR resource also includes: a reference count; the reference count is used to indicate the number of multicast streams that are forwarded using the FRR resource; Resource management module 402 is further configured to: when the current multicast stream generates an MFIB entry based on an existing FRR resource, increment the reference count of that FRR resource by a specified value; When the current multicast stream generates an MFIB entry based on a newly created FRR resource, the reference count of that FRR resource is set to a preset initial value; When an MFIB entry generated based on an FRR resource is no longer used to forward multicast streams, the reference count of that FRR resource is reduced by a specified value; when the reference count is reduced to 0, the FRR resource is deleted.

[0106] As an example, no longer forwarding multicast streams using MFIB entries generated based on FRR resources includes at least one of the following: When a rejection notification is received, the rejection notification is sent by each receiver belonging to the same multicast group; or; When the first route information changes and cannot match the FRR resource.

[0107] As one embodiment, the device further includes a loop check module; The loop check module is used to: when the primary input interface identifier changes from a valid state to an invalid state, and the backup input interface identifier changes from an invalid state to a valid state, traverse each MFIB entry generated based on the FRR resource, and if there is an output interface in the MFIB entry that includes the backup input interface identifier, then delete the backup input interface identifier from the output interface.

[0108] As one embodiment, the device also includes a synchronization module: The synchronization module is used to synchronize locally created MFIB entries to the interface boards of the network device. Specifically, if both the primary input interface indicated by the primary input interface identifier and the backup input interface indicated by the backup input interface identifier are physical interfaces, the MFIB entries are synchronized to the interface boards where the primary input interface and the backup input interface are located. If the primary input interface indicated by the primary input interface identifier and / or the backup input interface indicated by the backup input interface identifier are non-physical interfaces, the MFIB entries are synchronized to all interface boards connected to the control board. Furthermore, when creating FRR resources that match the first routing information, the created FRR resources are synchronized to the interface boards of the network devices; wherein, if both the primary incoming interface indicated by the primary incoming interface identifier and the backup incoming interface indicated by the backup incoming interface identifier are physical interfaces, the FRR resources are synchronized to the interface boards where the primary incoming interface and the backup incoming interface are located; if the primary incoming interface indicated by the primary incoming interface identifier and / or the backup incoming interface indicated by the backup incoming interface identifier are non-physical interfaces, the FRR resources are synchronized to all interface boards connected to the control board.

[0109] This concludes the process. Figure 4 Structural description of the device shown.

[0110] See Figure 5 , Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. Figure 5 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0111] Based on the same concept as the above method, this application also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the method disclosed in the above examples of this application.

[0112] For example, the aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For instance, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0113] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0114] This application can be implemented by executing several computer program code flows using an electronic device. The electronic device loads machine-executable instructions into a machine-readable storage medium and then uses its processor to read these machine-executable instructions into memory for execution. A hardware structure diagram of the electronic device, besides... Figure 5 In addition to the processor, memory, network interface, and non-volatile memory shown, electronic devices may also include other hardware depending on their actual functions, which will not be elaborated further.

Claims

1. A fast multicast rerouting method, characterized in that, This method is applied to network devices, and the method includes: First routing information is obtained from the first routing entry, which is used to indicate the routing information of the network device to the multicast source that sends the current multicast stream; the first routing information includes at least: the primary ingress interface identifier, the backup ingress interface identifier required by the multicast source to send multicast data to the multicast group, and the network prefix and mask of the multicast source. If a Fast Rerouting (FRR) resource matching the first routing information already exists, a Multicast Forwarding Table (MFIB) entry for forwarding the current multicast stream is generated based on the existing FRR resource. The FRR resource includes at least: a primary inbound interface identifier, a backup inbound interface identifier, and the network prefix and mask of the multicast source. The matching refers to the primary inbound interface identifier, backup inbound interface identifier, and the network prefix and mask of the multicast source in the first routing information being identical to the primary inbound interface identifier, backup inbound interface identifier, and the network prefix and mask of the multicast source in the FRR resource. If no FRR resource matching the first routing information exists, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource.

2. The method according to claim 1, characterized in that, The FRR resource includes: a primary input interface identifier and a backup input interface identifier; when the primary input interface identifier indicates that the primary input interface is normal, the primary input interface identifier is in a valid state and is used to receive and forward multicast data; when the backup input interface identifier is in an invalid state, it is prohibited from forwarding multicast data. The method further includes: When the primary input interface is abnormal, the primary input interface identifier is switched from an active state to an inactive state, and the backup input interface identifier is switched from an inactive state to an active state, so as to receive and forward multicast data of all multicast streams using the FRR resource via the backup input interface.

3. The method according to claim 1, characterized in that, The FRR resource also includes: a reference count; the reference count is used to indicate the number of multicast streams that are forwarded using the FRR resource. The method further includes: when the current multicast stream generates an MFIB entry based on the existing FRR resource, incrementing the reference count of the FRR resource by a specified value; When the current multicast stream generates an MFIB entry based on the newly created FRR resource, the reference count of the FRR resource is set to a preset initial value; When an MFIB entry generated based on an FRR resource is no longer used to forward multicast streams, the reference count of that FRR resource is reduced by a specified value; when the reference count is reduced to 0, the FRR resource is deleted.

4. The method according to claim 3, characterized in that, The phrase "no longer using MFIB entries generated based on FRR resources to forward multicast streams" includes at least one of the following: When a rejection notification is received, the rejection notification is sent by each receiver belonging to the same multicast group; or; When the first routing information changes and cannot match the FRR resource.

5. The method according to claim 1, characterized in that, The method further includes: when the primary input interface identifier switches from a valid state to an invalid state, and the backup input interface identifier switches from an invalid state to a valid state, traversing each MFIB entry generated based on the FRR resource, and if there is an output interface in an MFIB entry that includes the backup input interface identifier, then deleting the backup input interface identifier from the output interface.

6. The method according to claim 1, characterized in that, The method further includes: The created MFIB entries are synchronized to the interface boards of the network device; wherein, if both the primary input interface indicated by the primary input interface identifier and the backup input interface indicated by the backup input interface identifier are physical interfaces, the MFIB entries are synchronized to the interface boards where the primary input interface and the backup input interface are located; if the primary input interface indicated by the primary input interface identifier and / or the backup input interface indicated by the backup input interface identifier are non-physical interfaces, the MFIB entries are synchronized to all interface boards connected to the control board; Furthermore, when creating the FRR resource matching the first routing information, the created FRR resource is synchronized to the interface board of the network device; wherein, if the primary input interface indicated by the primary input interface identifier and the backup input interface indicated by the backup input interface identifier are both physical interfaces, the FRR resource is synchronized to the interface board where the primary input interface and the backup input interface are located; if the primary input interface indicated by the primary input interface identifier and / or the backup input interface indicated by the backup input interface identifier are non-physical interfaces, the FRR resource is synchronized to all interface boards connected to the control board.

7. A multicast fast rerouting device, characterized in that, This device is used in network equipment, and the device includes: An extraction module is used to obtain first routing information from a first routing entry, wherein the first routing entry is used to indicate the routing information of the network device to the multicast source that sends the current multicast stream; the first routing information includes at least: the primary ingress interface identifier and the backup ingress interface identifier required by the multicast source to send multicast data to the multicast group, as well as the network prefix and mask of the multicast source; The resource management module is used to generate a multicast forwarding table (MFIB) entry for forwarding the current multicast stream based on the existing Fast Rerouting (FRR) resource that matches the first routing information, if such FRR resource already exists. The FRR resource includes at least: a primary inbound interface identifier, a backup inbound interface identifier, and the network prefix and mask of the multicast source. The matching refers to the primary inbound interface identifier, backup inbound interface identifier, and the network prefix and mask of the multicast source in the first routing information being identical to the primary inbound interface identifier, backup inbound interface identifier, and the network prefix and mask of the multicast source in the FRR resource, respectively. If no FRR resource matching the first routing information exists, an FRR resource matching the first routing information is created, and an MFIB entry for forwarding the current multicast stream is generated based on the created FRR resource.

8. An electronic device, characterized in that, The electronic device includes: Processor; and A machine-readable storage medium storing machine-executable instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

9. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-executable instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

Images