WO2010048812A1 - A method and an apparatus for improving the multicast transfer reliability - Google Patents

Abstract

The present invention provides a method and an apparatus for improving the multicast transfer reliability, which belongs to the multicast technical field. The method includes: receiving the joining message transmitted by the first multicast device of the downstream neighbor from the first interface, and starting timing; judging whether receiving the hello message which includes the new ID of the output interface of the first multicast device from the first multicast device during the time arrives at the preset first joining overtime, if yes, continuing timing to the second joining overtime. The apparatus includes: a joining timing module and a delay module. The present invention prolongs the Join message overtime after detecting the restarting of the downstream multicast device, avoids the multicast flow interruption which is caused by the Join message overtime of the upstream neighbor device due to the long restarting process time of the downstream multicast device, and realizes the non-interruption transfer of the multicast data.

Description

 Method and device for improving reliability of multicast forwarding This application claims to be Chinese patent filed on October 30, 2008, with the application number of 200810225324.x, and the invention titled "Method and Device for Improving the Reliability of Multicast Forwarding" Priority of the application, the entire contents of which are incorporated herein by reference.

 Say

Technical field

 The present invention relates to the field of multicast technologies, and in particular, to a method and apparatus for improving multicast forwarding reliability. BACKGROUND OF THE INVENTION

 IP multicast technology enables efficient data transmission from point to point in IP networks. Because multicast technology can effectively save bandwidth control network traffic, reduce server load and reduce network load, it has a wide range of applications in real-time data transmission, multimedia conferencing, gaming and simulation. The IP multicast protocol includes a protocol between the router and the receiver host and a protocol between the router and the router, which are used in combination to construct a multicast forwarding tree from the multicast source to the multicast data receiver. IGMP (Internet Group Management Protocol) is used between the router and the receiver. Protocol Independent Multicast (PIM) is used between the router and the router. PIM uses the reverse path forwarding (RPF) mechanism to implement multicast packet forwarding. The RPF mechanism uses the existing unicast routing information to construct a multicast forwarding tree in the network. That is, PIM can pass any type of single. The broadcast routing protocol generates multicast routing entries for RPF checking. When a multicast packet arrives at the router, the RPF check is performed first. If the RPF check is passed, the multicast routing entry is created to forward the multicast packet. If the RPF check fails, the multicast packet is forwarded. throw away.

PIM-SM (Protocol Independent Multicast Sparse Mode) is the most popular multicast routing protocol used in the ASM (Any-Source Multicast) model. In the PIM-SM model, any sender can be a multicast source. PIM selects a router as a common root node, called an RP (Rendezvous Point). The process of constructing an RPT (Rendezvous Point Tree, a converged tree or a shared tree) is as follows: When a receiver joins a multicast group G, it first informs the directly connected DR (Designated Router) through the IGMP message; After the information of the receiver of the multicast group G, the join message (Join message) is sent hop by hop to the RP direction corresponding to the multicast group; the router that passes through the DR to the RP forms the branch of the RPT. The slave generates a (*, G) entry in its forwarding table, where "*" indicates that it is from any multicast source. RPT takes RP as the root and DR as the leaf. When the multicast data sent to the multicast group G flows through the RP, the data arrives at the DR along the established RPT, and then reaches the receiver. When a receiver does not need the information of the multicast group G, the directly connected DR sends the prune message (Prune message) to the RP in the RP direction of the multicast group. The upstream node receives the information. After the prune message is sent, the interface connected to the downstream node is deleted from the outbound interface list, and the receiver of the multicast group is still in the downstream. If not, the prune message is forwarded to the upstream device.

 The SSM (Source Specific Multicast) model uses the technology of the specified multicast source. The receiver knows the specific location of the multicast source in advance. The SSM can directly establish an SPT (Shortest Path Tree) between the multicast source and the receiver. The shortest path tree), so that multicast data can be forwarded along the shortest path tree.

 When the internal main control board of the router in the multicast forwarding tree is faulty, the active/standby switchover of the main control board is performed. The backup board is re-learned by the Graceful Restart (PIM) technology. Broadcast routing entries, and update multicast forwarding entries. A router that performs an active/standby switchover (called a GR Restarter device) sends a PIM Hello handshake packet carrying the newly generated outbound interface identifier (Generation ID, usually called GenlD) to the upstream and downstream neighbor devices (called the GR Helper device). Triggering the downstream neighbor device to resend the Join message carrying the (S, G) or (*, G) information, so that the router can relearn the new (S, G) or (*, G) entries and update the The status of the downstream interface is forwarded according to the updated forwarding entry. The S is the multicast source and the G is the multicast group. The new GenlD is the re-generate of the current outbound interface of the GR Restarter after the GR Restarter is switched. The identifier is different from the ID in the Hello packet sent before the master/slave switchover occurs.

 After analyzing the above prior art, the inventors found that:

 The PIM sends a Join message to the upstream neighbor device. The device does not send Join to the upstream neighbor device until the device learns the multicast routing entries and multicast forwarding entries. If the learning time is too long, the upstream neighbor device will not receive the Join message for a long time. The JP timer (join/prune timer) times out. The upstream neighbor device will switch to the active/standby switchover. The outbound interface connected to the device is cut off, causing traffic interruption. Summary of the invention

 In order to improve the reliability of the multicast forwarding, the embodiment of the present invention provides a method and device for improving the reliability of multicast forwarding. The technical solution is as follows:

 A method for improving reliability of multicast forwarding, where the method includes:

When the join message sent by the first multicast device of the downstream neighbor is received from the first interface, timing is started; When the timing reaches the preset first joining timeout period, it is determined whether the handshake message containing the new identifier of the outbound interface of the first multicast device is received from the first multicast device during the timing, If yes, the first join timeout period is extended to the second join timeout period.

 An apparatus for improving reliability of multicast forwarding, where the apparatus includes:

 The timing module is configured to start timing when the device receives the join message sent by the first multicast device of the downstream neighbor from the first interface;

 a delay module, configured to determine, when the timing of the joining timing module reaches a preset first joining timeout period, whether the device receives the first group from the first multicast device during the timing The handshake message of the new identifier of the outbound interface of the broadcast device, if yes, the timeout period of the first join is extended to the second join timeout period.

 In the embodiment of the present invention, after detecting that the downstream multicast device is restarted, the timeout period of the Join message is extended, thereby avoiding the GR.

The restart of the Restarter device is too long. As a result, the upstream GR Helper device joins the packet, causing the multicast traffic to be interrupted. The multicast data is forwarded without interruption. DRAWINGS

 In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any inventive labor.

 FIG. 1 is a flowchart of a method for improving multicast forwarding reliability according to an embodiment of the present invention;

 2 is a flowchart of a method for improving multicast forwarding reliability according to an embodiment of the present invention;

 FIG. 3 is a flowchart of a process after receiving a pruning message according to an embodiment of the present invention;

 FIG. 4 is a flowchart of another process after receiving a pruning message according to an embodiment of the present invention;

 FIG. 5 is a schematic diagram of a public network networking provided by an embodiment of the present invention; FIG.

 Figure 6 is a schematic view showing the processing time of R5 in Figure 5;

 FIG. 7 is a schematic diagram of a multicast VPN according to an embodiment of the present invention;

 FIG. 8 is a schematic diagram of an apparatus for improving multicast forwarding reliability according to an embodiment of the present invention; FIG.

 FIG. 9 is another schematic diagram of an apparatus for improving multicast forwarding reliability according to an embodiment of the present invention;

FIG. 10 is still another schematic diagram of an apparatus for improving multicast forwarding reliability according to an embodiment of the present invention. detailed description The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, but not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

 Referring to FIG. 1, an embodiment of the present invention provides a method for improving reliability of multicast forwarding, including:

 101: When receiving the join message sent by the first multicast device of the downstream neighbor from the first interface, start timing; 102: when the time reaches the preset first join timeout period, determine whether the time period is from the first time A multicast device receives the Hello packet containing the new identifier of the outbound interface of the first multicast device. If yes, the first join timeout period is extended to the second join timeout period.

 The first timeout period and the second timeout time in the embodiment of the present invention are both the timeout period of receiving the Join message, that is, the Join message is not received from the first interface after the time is reached. An interface pruning. Referring to FIG. 2, the method for improving the reliability of multicast forwarding provided by the embodiment of the present invention specifically includes:

 201: When receiving the Join message sent by the first multicast device of the downstream neighbor from the first interface, start timing, and specifically, the JP Timer timer may be started to perform timing.

 202: When the timing reaches the preset first joining timeout period, it is determined whether the new identifier (GenID) sent by the first multicast device and sent by the first multicast device is received from the first interface. The Hello packet, the outbound interface is the interface that sends the Join message to the first multicast device. The new identifier is generated temporarily. The identifier of the outbound interface included in the Join message sent by the first multicast device. The difference is that the temporarily generated identifier has changed. If yes, it indicates that the first multicast device is the GR Restarter device. If the restart occurs, such as the active/standby switchover of the main control board, perform 203; otherwise, indicate the first multicast device. Normal, if no restart occurs, execute 204.

 The first join timeout period is the timeout time of the Join message pre-configured on the local multicast device. The value can be set as required, such as 200s, 260s, and so on.

 203: Extend the first joining timeout period to the second joining timeout period, and continue counting until the timing time reaches the second joining timeout period, and if the second joining timeout period is reached, the first interface is not received again. If the Join message of the multicast device is prune, the process ends.

 The extended time can be specified through the command line configuration, such as extending the first join timeout period 260s to the second addition timeout time 300s. In this embodiment, preferably, the extension is performed according to the following relationship:

The difference between the second join timeout time and the first join timeout time is equal to the difference between the time when the Hello message is received and the time when the Join message is received. In this embodiment, the scenario in which the first multicast device is continuously switched is received. After receiving the Hello packet containing the new identifier from the first multicast device, the first multicast device receives the Hello packet again. The newly-identified Hello packet. In this scenario, the extended time can still be obtained according to the above relationship. However, when the Hello packet is received, the Hello packet containing the new identifier of the outbound interface of the first multicast device is received again. time.

 204: Determine whether the Join message sent by the first multicast device is received from the first interface again during the timeout process. If the first multicast device still needs to receive the multicast data, the process ends. The normal multicast data forwarding is continued; otherwise, the preset timeout indicates that the first multicast device no longer wishes to receive the multicast data, and executes 205.

 205: The first interface is prune, and the multicast data is not sent through the first interface, and the process ends.

 Further, in this embodiment, after the local multicast device receives the Join message (201) sent by the first multicast device for the first time in the current period, if the local neighbor device also receives the downlink neighbor from the first interface, The foregoing method may further include the following steps, as shown in FIG. 3, which is specifically as follows:

 301: The local multicast device receives the Prune packet sent by the second multicast device of the downstream neighbor from the first interface in the current period, and starts timing.

 The current period is the time period from the start of the Join message to the first join timeout period (204) in 201, or the time from the start of the Join message to the second join timeout period (203) in 201. segment.

 302: Determine whether the other downstream neighbor multicast device is connected to the first interface except the second multicast device, where the other downstream neighbor multicast device includes the first multicast device, and if yes, execute 303; otherwise, perform 306. .

 303: Determine, before receiving the Prune message, whether the Hello packet sent by the other downstream neighboring multicast device and the new identifier of the outbound interface of the other downstream neighboring multicast device is received from the first interface. To, execute 304; if not, execute 305.

 304: The pruning process is not performed on the first interface, and the process ends.

 305: Perform prune processing on the first interface, specifically, if the timing does not reach the preset prune timeout period, and the other downstream neighbor multicast device receives the other downstream neighbor multicast from the first interface. If the new interface of the device is not prune, the first interface is not prune. If the new interface from the downstream device of the other downstream neighbors is not received from the first interface, Hello packet, and the timing has reached the prune timeout time, the first interface is pruneted, and the process ends.

 The default prune timeout period is the timeout period after the Prune packet is received. If the timeout period is reached, the prune is performed. If the timeout period is not reached, the prune is not performed. The value of this pruning timeout can be configured as needed.

306: After the timeout period reaches the preset prune timeout period, the first interface is pruneted and is not sent through the first interface. Multicast data, then the process ends.

 In this embodiment, the local multicast device may have multiple interfaces, for example, in addition to the first interface, the second interface. When the local multicast device receives the Prune packet from the multicast device of the downstream neighbor from the second interface, the processing procedure of the local multicast device is similar to that of the foregoing 301 to 306. Referring to FIG. 4, the details are as follows:

 401: Start timing when the local multicast device receives the Prune packet sent by the second multicast device of the downstream neighbor from the second interface.

 402: Determine whether the other downstream neighbor multicast device is connected to the second interface except the second multicast device, where the other downstream neighbor multicast device includes the first multicast device, and if yes, execute 403; otherwise, perform 406. .

 403: Determine, before receiving the Prune message, whether the Hello packet sent by the other downstream neighboring multicast device and the new identifier of the outbound interface of the other downstream neighboring multicast device is received from the second interface, if To, execute 404; if not, execute 405.

 404: The second interface is not pruned, and the process ends.

 405: Perform prune processing on the second interface, specifically, if the timing does not reach the preset prune timeout period, and the other downstream neighbor multicast device receives the other downstream neighbor multicast from the second interface. If the new Hello packet of the outbound interface of the device is not prune, the second interface is not prune. If the new interface of the other downstream neighboring multicast device is not received from the second interface, the new identifier of the outbound interface of the other downstream neighboring multicast device is not received. Hello packet, and the timing has reached the pruning timeout time, the second interface is pruned, and then the process ends.

 406: After the preset prune timeout period is reached, the second interface is prune, the multicast data is not sent through the second interface, and the process ends.

 In this embodiment, the Join message can carry (*, G), or carry (S, G), and the Prune message can be carried.

(*, G), or carry (S, G). That is, the foregoing method provided by this embodiment can be applied to the PIM-SM model, and can also be applied to the SSM model, and the technical solution is not limited by the protocol type.

The application of the above method will be specifically described below with reference to the application scenario shown in FIG. 5. Referring to Figure 5, there are five multicast routers in the network, Rl, R2, and R3 are DRs connected to receivers, R4 is upstream neighbors of R1 and R2, and R5 is connected to two downstream neighbors of R3 and R4 through one interface. Connected, and R5 is the first hop router connected to the multicast source. Figure 6 shows the process of receiving the Join message from the downstream neighbor device. At time t0, R5 receives the Join message sent by R4, and starts the time of the current cycle. When the preset Join message timeout time JP time has not reached the previous time t1, it receives the new message sent by R4 due to the restart. The hello packet of the GenID can record the timestamp tl of the Hello packet received by the GenID on the interface. When the timer reaches the timeout time JP Time, that is, at time t2 in the figure, R5 determines whether the interface is recorded. Timestamp of the Hello packet changed to the GenID. If the timestamp is recorded, then Join is added. The packet timeout period is extended from At to time t3, and continues to count until t3. If R5 receives the Join message sent by R4 again before t3, the interface is not pruned. If R5 is not received again before t3 The Join message sent to R4 prune the interface. The time range from tl to t3 is equal to the preset timeout time JP Time of the Join message.

 The foregoing method provided in this embodiment can be applied not only to an ordinary public network but also to a multicast private network (Virtual Private Network). In a multicast VPN, the VPN instance of each PE device is directly connected to the Mtunnel interface. The MTU interface is a virtual Ethernet broadcast interface. If the downstream PE device restarts, the device sends a new GenID to the upstream device through the Mtunnel interface. Hello message. As shown in Figure 7, CE1 is connected to the multicast source, and the downstream neighbor is PE1. PE1 is connected to PE2 and PE3 through the multicast tunnel interface (Mtunnel interface). The downstream neighbor of PE2 is CE2. The downstream neighbors of PE3 are CE3, CE2, and CE3. Connect to the recipient separately. In this scenario, if PE1 is restarted, the Hello message containing the new GenID is sent to CE1. The processing after receiving the CE1 is the same as that of R5 in Figure 5, and is not mentioned here.

 In this embodiment, after the upstream device detects that the downstream GR Restarter device is restarted, the timeout period of the Join message is extended, and the restart time of the GR Restarter device is too long, and the Join message of the upstream GR Helper device times out, causing multicast. When the traffic is interrupted, multicast data is continuously forwarded. After the Prune packet is received, whether the other downstream neighbors are present on the interface and whether the Hello message is received from the new GenID is configured to determine whether the interface is prune. After the Join message is sent, the upstream neighbor will prune the interface connected to the downstream GR Restarter device that is still receiving the multicast data. The GR Restarter cannot receive multicast data after the device restarts. Referring to FIG. 8, an embodiment of the present invention further provides an apparatus for improving reliability of multicast forwarding, including:

 The timing module 801 is configured to start timing when the device receives the adding message sent by the first multicast device of the downstream neighbor from the first interface;

 The delay module 802 is configured to: when the timing module 801 is added to the preset first joining timeout period, determine whether the device receives the new identifier that includes the outbound interface of the first multicast device from the first multicast device during the timing The handshake message, if yes, extends the first join timeout period to the second join timeout period.

 In this embodiment, the difference between the second join timeout period and the first join timeout time is equal to the difference between the time when the handshake message is received and the time when the join message is received.

 Further, referring to FIG. 9, the above apparatus further includes:

The first determining module 803 is configured to determine, after the device receives the join message, the first interface, if the prune message sent by the second multicast device of the downstream neighbor is also received from the first interface, Is there a second multicast device connected to it? Other downstream neighbor multicast devices, the other downstream neighbor multicast devices include a first multicast device;

 The second determining module 804 is configured to: when the first determining module 803 determines that the result is yes, determine whether the device receives the other downstream neighbor multicast device from the first interface before receiving the prune message. A handshake packet containing the new identifier of the outbound interface of the other downstream neighbor multicast device;

 The first processing module 805 is configured to: if the result of the second determining module 804 is received, the first interface is not subjected to the pruning process, and if the result of the second determining module 804 is not received, the The first interface performs pruning processing.

 When the device includes the first judging module 803, the second judging module 804, and the first processing module 805, further, the device may also include:

 The first pruning timing module 806 is configured to start timing when the device receives the pruning message from the first interface. Correspondingly, the first processing module 805 specifically includes:

 The first processing unit is configured to: when the second determination module 804 determines that the result is received, the first interface is not subjected to the pruning process;

 a second processing unit, configured to: when the second judging module 804 determines that the result is not received, if the first pruning timing module 806 does not reach the preset pruning timeout period, and receives other downstream from the first interface. The handshake message sent by the neighboring multicast device that contains the new identifier of the outbound interface of the other downstream neighbors does not prune the first interface. If no other downstream neighbor multicast device is received from the first interface. After the handshake packet with the new identifier of the outbound interface of the other downstream neighboring multicast device is received, and the ping timeout time has expired, the first interface is prune.

 In this embodiment, referring to FIG. 10, the foregoing apparatus further includes:

 The third determining module 807 is configured to: if the device receives the prune message sent by the second multicast device of the downstream neighbor from the second interface, determine whether the second interface is further connected to the second multicast device. Other downstream neighbor multicast devices, the other downstream neighbor multicast devices include a first multicast device;

 The fourth determining module 808 is configured to: when the third determination module 807 determines that the result is yes, determine whether the device receives the inclusion of the other downstream neighbor multicast device from the second interface before receiving the prune message. A handshake message of the new identifier of the outbound interface of the other downstream neighboring multicast device;

 The second processing module 809 is configured to: if the fourth determination module 808 determines that the result is received, the second interface does not perform the pruning process, and if the fourth determination module 808 determines that the result is not received, the second processing module 809 The interface is pruned.

 When the device includes the third determining module 807, the fourth determining module 808, and the second processing module 809, the device further includes:

The second prune timing module 810 is configured to start timing when the device receives the prune message from the second interface. Correspondingly, the second processing module 809 specifically includes: a first processing unit, configured to: when the fourth determination module 808 determines that the result is received, not performing pruning processing on the second interface;

 a second processing unit, configured to: when the fourth determination module 808 determines that the result is not received, if the second pruning timing module does not reach the preset pruning timeout period, and the device receives the other from the second interface The handshake message sent by the downstream neighbor multicast device that contains the new identifier of the outbound interface of the other downstream neighbor multicast device does not prune the second interface. If the device does not receive other downstream neighbor multicast devices from the second interface. The handshake message containing the new identifier of the outbound interface of the other downstream neighbor multicast device is sent, and the second pruning timer module 810 times the prune timeout period, and the second interface is pruned.

 In this embodiment, the Join message may carry (*, G) or carry (S, G), and the Prune message may carry (*, G) or carry (S, G). That is, the foregoing apparatus provided in this embodiment may be applied to the PIM-SM model, or may be applied to the SSM model, and the technical solution is not limited by the type of the protocol.

 The foregoing apparatus provided in this embodiment may be specifically a multicast device, such as a multicast router. The device can be applied not only to an ordinary public network but also to a multicast VPN.

 In this embodiment, after detecting that the downstream first multicast device is restarted, the timeout period of the Join message is extended, and the startup time of the first multicast device is too long, and the Join message of the upstream device times out, causing the group to be caused. The interruption of the broadcast traffic occurs, and the multicast data is continuously forwarded. After the Prune packet is received, whether the other downstream neighbors are present on the interface and whether the Hello message is received from the new GenID is configured to determine whether the interface is prune. After the Join message is sent, the upstream neighbor will prune the interface connected to the downstream GR Restarter device that is still receiving the multicast data. The GR Restarter cannot receive multicast data after the device restarts.

 It will be understood by those skilled in the art that all or part of the steps carried by the method of the foregoing embodiment may be implemented by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, and the program is executed. Including one or a combination of the steps of the method embodiments.

 In addition, each functional unit in each embodiment of the present invention may be integrated into one processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. The integrated modules, if implemented in the form of software functional modules and sold or used as stand-alone products, may also be stored in a computer readable storage medium.

 The above-mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

 The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., which are within the spirit and scope of the present invention, should be included in the protection of the present invention. Within the scope.

Claims

Claim A method for improving the reliability of multicast forwarding, the method comprising:  Receiving a join message sent by the first multicast device of the downstream neighbor from the first interface, and starting timing;  Determining, in the process of the timer reaching the preset first joining timeout period, whether the handshake message including the new identifier of the outbound interface of the first multicast device is received from the first multicast device, and if yes, Then continue to count to reach the second join timeout period.  2. The method for improving multicast forwarding reliability according to claim 1, wherein:  The difference between the second join timeout period and the first join timeout period is equal to the difference between the time when the handshake message is received and the time when the join message is received.  The method for improving the reliability of multicast forwarding according to claim 1, wherein the method further comprises: after receiving the join message, if receiving a downstream neighbor from the first interface The prune message sent by the second multicast device determines whether the other downstream neighbor multicast device other than the second multicast device is connected to the first interface, and the other downstream neighbor multicast device Include the first multicast device;  If yes, determining whether the new identifier of the outbound interface of the other downstream neighboring multicast device sent by the other downstream neighboring multicast device is received from the first interface before receiving the prune message If the handshake packet is received, the first interface is not subjected to the pruning process, and if not received, the first interface is subjected to the pruning process.  The method for improving the reliability of multicast forwarding according to claim 3, wherein the method further comprises: starting timing when receiving the prune message from the first interface;  Performing a pruning process on the first interface, specifically:  If the timing does not reach the preset prune timeout period, and receives a handshake from the first interface that is sent by the other downstream neighboring multicast device and includes a new identifier of the outbound interface of the other downstream neighboring multicast device The packet does not prune the first interface;  If the handshake message of the new identifier of the outbound interface of the other downstream neighboring multicast device sent by the other downstream neighboring multicast device is not received from the first interface, and the timing has reached the pruning The timeout period is used to prun the first interface. The method for improving the reliability of multicast forwarding according to claim 1, wherein the method further comprises: if the prune message sent by the second multicast device of the downstream neighbor is received from the second interface And determining, by the second interface, another downstream neighbor multicast device other than the second multicast device, where the other downstream neighbor multicast device includes the first multicast device; If yes, determining whether the new identifier of the outbound interface of the other downstream neighboring multicast device sent by the other downstream neighboring multicast device is received from the second interface before receiving the prune message If the handshake packet is received, the second interface is not subjected to the pruning process. If not, the second interface is subjected to the pruning process.  The method for improving the reliability of multicast forwarding according to claim 5, wherein the method further comprises: starting timing when receiving the prune message from the second interface;  And performing the pruning process on the second interface, specifically:  If the timing does not reach the preset prune timeout period, and receives a handshake from the second interface that is sent by the other downstream neighboring multicast device and includes a new identifier of the outbound interface of the other downstream neighboring multicast device The packet does not prune the second interface;  If the handshake message of the new identifier of the outbound interface of the other downstream neighboring multicast device sent by the other downstream neighboring multicast device is not received from the second interface, and the timing has reached the pruning After the timeout period, the second interface is pruned.  A device for improving the reliability of multicast forwarding, characterized in that the device comprises:  Adding a timing module, configured to receive a join message sent by the first multicast device of the downstream neighbor from the first interface, and start timing;  a delay module, configured to determine, when the timing of the joining timing module reaches a preset first joining timeout period, whether the device receives the first multicast device from the first multicast device The handshake message of the new identifier of the interface. If yes, continue to time to reach the second join timeout period.  8. The apparatus for improving multicast forwarding reliability according to claim 7, wherein:  The difference between the second join timeout period and the first join timeout period is equal to the difference between the time when the handshake message is received and the time when the join message is received.  The device for improving the reliability of multicast forwarding according to claim 7, wherein the device further comprises: a first determining module, configured to: after the device receives the joining message, if The first interface receives the prune message sent by the second multicast device of the downstream neighbor, and determines whether other downstream neighbor multicasts other than the second multicast device are still connected to the first interface. The device, the other downstream neighbor multicast device includes the first multicast device, and the second determining module is configured to: when the result of the first determining module determines yes, determine that the prune message is received The handshake message of the new identifier of the outbound interface of the other downstream neighboring multicast device sent by the other downstream neighboring multicast device is received from the first interface; a first processing module, configured to: if the result of the determining by the second determining module is received, perform no pruning processing on the first interface, if the result of the second determining module is not received, Performing a pruning process on the first interface. The device for improving the reliability of multicast forwarding according to claim 9, wherein the device further comprises: a first pruning timing module, configured to receive, at the device, the device from the first interface When the prune message is described, the timing is started. The first processing module specifically includes:  a first processing unit, configured to: when the result of the determining by the second determining module is received, perform no pruning processing on the first interface;  a second processing unit, configured to: when the second judging module determines that the result is not received, if the first pruning timing module does not reach a preset pruning timeout period, and from the first interface Receiving, by the other downstream neighboring multicast device, a handshake message including a new identifier of the outbound interface of the other downstream neighboring multicast device, the first interface is not prune, if not from the first interface Receiving, by the other downstream neighboring multicast device, a handshake message including a new identifier of the outbound interface of the other downstream neighboring multicast device, and the timing has reached the prune timeout period, and then prune the The first interface.  The device for improving the reliability of the multicast forwarding according to claim 7, wherein the device further comprises: a third determining module, configured to: if the device receives the second neighbor of the downstream neighbor from the second interface The prune message sent by the multicast device determines whether the other downstream neighbor multicast device other than the second multicast device is connected to the second interface, where the other downstream neighbor multicast devices include Said first multicast device;  a fourth determining module, configured to: when the third determining module determines that the result is yes, determine whether the device receives the other downstream neighbors from the second interface before receiving the prune message A handshake packet sent by the multicast device and containing the new identifier of the outbound interface of the other downstream neighboring multicast device;  a second processing module, configured to: if the result of the determining by the fourth determining module is received, perform no pruning processing on the second interface, if the result of the fourth determining module is not received, Performing a pruning process on the second interface.  The device for improving the reliability of multicast forwarding according to claim 11, wherein the device further comprises: a second pruning timing module, configured to receive, at the device, the second interface When the prune message is described, the timing is started; the second processing module specifically includes:  a first processing unit, configured to: when the result of the determining by the fourth determining module is received, perform no pruning processing on the second interface; a second processing unit, configured to: when the result of the determining by the fourth determining module is not received, if the timing of the second pruning timing module does not reach a preset pruning timeout period, and the device is from the If the second interface receives the handshake message from the other downstream neighboring multicast device that includes the new identifier of the outbound interface of the other downstream neighboring multicast device, the second interface does not prun the second interface, if the device does not And receiving, by the second interface, a handshake message that is sent by the other downstream neighboring multicast device and includes a new identifier of the outbound interface of the other downstream neighboring multicast device, and the second prune timing module has timed up And to the pruning timeout period, the second interface is pruned.