WO2008064585A1

WO2008064585A1 - A method, system and resilient packet ring device for avoiding loop after fault recovery

Info

Publication number: WO2008064585A1
Application number: PCT/CN2007/070438
Authority: WO
Inventors: Yilong Zhang; Zhongkai Zhang; Zhifeng He
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-11-27
Filing date: 2007-08-09
Publication date: 2008-06-05
Also published as: CN100464528C; CN1968174A

Abstract

A method, system and resilient packet ring device for avoiding loop appearance after fault recovery. The method includes: fault recovery node sets a delay time and transmits fault recovery notifying message to inter-ring node via two directions of RPR when the fault is recovered; the fault recovery node sets its work state as normal when the delay time has elapsed; inter-ring node sets its work state based on state condition after receiving fault recovery notifying message sent by fault recovery node within delay time, namely inter-ring node judges whether to change its own work state based on its state and other inter-ring nodes' state on RPR. The method, system and device resolves the loop problem when one of two fault positions situated at two sides of inter-ring node is recovered through cooperation between fault recovery node and inter-ring node.

Description

Method, system and elastic packet ring device for avoiding loop after failure recovery

The present invention relates to the field of network communication technologies, and in particular, to a method, a system, and a Resilient Packet Ring (RPR) device for avoiding loops after failure recovery. Background of the invention

As the communication network operators' focus has shifted from the backbone network to the metropolitan area network, the establishment of an efficient and economical multi-service metropolitan transport network has become the common goal of major operators. RPR technology has many advantages, gradually Into the field of metro transport networks, and become one of the hot spots.

RPR technology is a new network architecture designed to meet the requirements of packet metropolitan area networks. RPR is a ring network composed of packet switching nodes. Adjacent nodes are connected by a pair of optical fibers. The network topology is based on two A ring that transmits in the opposite direction.

The packet switching node on the ring network is further divided into a cross-ring node and a non-cross-ring node. Non-cross-ring nodes, when multiple RPR rings intersect, on the RPR ring, but there is no RPR device at the ring intersection. There are three working states: normal state, loopback state wrap, and pass-through state passthrough. A cross-ring node is an RPR device at the intersection of a ring when multiple RPR rings intersect. When the cross-ring node processes the cross-ring service forwarding, it is in the active master state.

Although RPR has many technical advantages such as effective bandwidth multiplexing, fast ring protection switching function, and automatic automatic discovery of topology, with the continuous development of science and technology, people have higher requirements for technology, and the current RPR communication There are still some shortcomings in the technology. These shortcomings will be explained below.

The RPR device carries Layer 2 Ethernet packets in the Ethernet Over RPR mode. The RPR extension frame is forwarded on the RPR ring. As shown in FIG. 1, FIG. 1 is a schematic diagram of a prior art RPR ring network communication. Because the RPR carries Layer 2 Ethernet packets, if two cross-ring nodes are not controlled, loops will occur on the two cross-ring nodes, which is prone to broadcast storms.

Currently, there is a method for preventing a loop from forming a Layer 2 network. The link is cut by the Spanning Tree Protocol (STP) or the Rapid Spanning Tree Protocol (RSTP) to generate a minimum spanning tree without loops. Then, the packets on the Layer 2 Ethernet are forwarded according to the minimum spanning tree to prevent the Layer 2 network communication from forming a loop.

However, there is currently no way to solve the following problems: When two rings in two RPR rings have two failures at the same time, two of them are at the two ends of an RPR cross-ring node, to ensure two Any point between the rings is reachable. Both RPR cross-ring nodes need to be responsible for forwarding the cross-ring service, that is, they are all in the master state. In this case, when one of the fault points is restored, it is easy to form a loop. The cause is explained below, as shown in Figure 2.

In the case where the fault point 1 exists, the working modes of the non-cross-ring node 1 and the non-cross-ring node 2 are both wrap, and no packet will pass at the fault point, and no loop will appear. If the fault point 1 recovers, there is no fault point in the adjacent interval of the non-cross-ring node 1 and the non-cross-ring node 2, then the working modes of the non-cross-ring node 1 and the non-cross-ring node 2 will change to normal, and the recovered fault recovery The node can forward the data message. Since the cross-ring node 1 and the cross-ring node 2 cannot immediately perceive this change without changing the state, they are still in the master state, the cross-ring node 1, the non-cross-ring node 1, the non-cross-ring node 2, and the cross-ring node 2 The non-cross-ring node 4 and the non-cross-ring node 3 form a loop, which easily causes broadcast packets to be cyclically transmitted in the loop, which causes broadcast storms and the like to occur. It should be noted that when a node on the RPR ring fails, the failed node acts as a failure recovery node when the fault is recovered; When the link between two nodes on the RPR ring fails, the two nodes that are aware of the fault closest to the fault are used as the fault recovery point when the link fails to recover. In FIG. 2, non-cross-ring node 1 and non-cross-ring node 2 are failover nodes.

From the above, there is no solution in the prior art that can effectively solve the loop problem that is easy to occur when one of the two fault points located at both ends of the cross-ring node recovers. Summary of the invention

In view of this, the embodiment of the present invention provides a method for avoiding a loop after a fault is recovered, and solves the problem that a loop is easily generated in the case where one of the two fault points located at both ends of the cross-ring node recovers.

The embodiment of the present invention further provides a system for avoiding loops after fault recovery, and solves the problem that loops are likely to occur in the case where one of two fault points located at both ends of the cross-ring node recovers.

The embodiment of the present invention further provides an RPR device that solves the problem that loops are likely to occur in the case where one of the two fault points located at both ends of the cross-ring node recovers.

A method for avoiding a loop after failure recovery, characterized in that the method comprises the following steps:

After the fault is recovered, the fault recovery node sets the delay time and sends a fault recovery notification message to the cross-ring node from the RPR ring. When the delay time expires, the fault recovery node sets the working state to normal.

After receiving the fault recovery notification packet sent by the fault recovery node, the cross-ring node sets the working state of the cross-ring node according to the packet.

A system for avoiding loops after failure recovery, characterized in that the system includes a fault recovery node and a cross-ring node;

Failback node, used to set the delay time after failure recovery, and two from the RPR ring Sends a fault recovery notification message to the cross-ring node in one direction; when the delay time expires, sets its working state to normal;

The cross-ring node is configured to receive a fault recovery notification message sent by the fault recovery node, and set its working state according to the packet.

An RPR device, the RPR device includes: a status module, a delay module, and a message sending module;

a status module, configured to send a delay notification to the delay module, and send a trigger notification to the message sending module; set the working state to normal after receiving the arrival notification sent by the delay module;

a delay module, configured to receive a delay notification sent by the status module, set a delay time, and send a notification to the status module when the delay time expires;

The packet sending module is configured to send a fault recovery notification message to the cross-ring node from the two directions of the RPR ring after receiving the trigger notification of the status module.

An RPR device, the RPR device includes: a message receiving module, and a status module; a message receiving module, configured to receive a fault recovery notification message sent by the fault recovery node, and then send a setting working state notification to the status module;

The status module is configured to receive a setting working state notification sent by the packet receiving module, and set a working state of the cross-ring node.

It can be seen from the above technical solution that the fault recovery node sends a fault recovery notification message to the cross-ring node from the two RPR rings by setting the delay time. After the delay, the working state is set to normal; during the delay period, the cross-ring node Receives a fault recovery notification message sent by the fault recovery node, and sets the working status of the cross-ring node according to the status. Therefore, the problem that the loop is prone to occur when one of the two fault points located at both ends of the cross-ring node recovers is solved, thereby avoiding the occurrence of a broadcast storm or the like. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a schematic diagram of a prior art RPR ring network communication;

Figure 2 is a schematic diagram of a fault point failure recovery loop;

FIG. 3 is a structural diagram of a system in which a loop occurs after fault recovery is avoided in an RPR according to an embodiment of the present invention;

4 is a flowchart of a method for avoiding a loop after a fault is recovered in an RPR according to an embodiment of the present invention;

FIG. 5 is a detailed flowchart of a method for avoiding a loop after failure recovery in an RPR according to an embodiment of the present invention. Mode for carrying out the invention

The present invention will be further described in detail below in conjunction with the specific embodiments.

First, the system provided by the embodiment of the present invention is described in detail. As shown in FIG. 3, FIG. 3 is a structural diagram of a system in which a loop occurs after failure recovery. The system is mainly composed of: a fault recovery node 300 and a cross-ring node 310.

It should be noted that the fault recovery node that appears in the embodiment of the present invention is a non-cross-loop node. The fault recovery node 300 sets a delay time after the fault is recovered, and then sends a fault recovery notification message to the cross-ring node from the two directions of the RPR ring; when the delay time expires, the working state is set to normal„

The cross-ring node 310 receives the fault recovery notification message sent by the fault recovery node, and sets its own working state according to the packet.

The failover node 300 and the cross-ring node 310 are not necessarily adjacent connections, and there may be other non-cross-ring nodes in between.

The structure of the failover node 300 and the cross-ring node 310 will be described below. The fault recovery node 300 may include the following parts: a delay module 301, a text sending module 302, and a status module 303, where

The delay module 301, after receiving the delay notification sent by the status module, sets the delay time, and sends a notification to the status module 303 when the delay time expires.

The purpose of the set delay time is to ensure that the cross-ring node 310 can receive the fault recovery notification message sent by the fault recovery node 300 and process the corresponding state before the state of the fault recovery node is restored.

The length of the delay time can be set according to the number of hops that the fault recovery node is farthest from the two cross-ring nodes. For example, if the hop count is N, the delay time is N*10ms, where 10ms mainly considers the processing delay of each line and each node in the line, which is an empirical value. In addition, this value can also be based on the specific line condition. And different settings for each node device.

The message sending module 302 is configured to send a fault recovery notification message from two directions of the RPR ring after receiving the trigger notification of the status module 303, to notify the cross-ring node 310 that the fault has been recovered.

The fault recovery notification message can be extended based on the existing packet or a new packet type.

The status module 303 is configured to set the working status of the fault recovery node 300, send a delay notification to the delay module 301, and send a trigger notification to the message sending module 302; and receive the arrival notification sent by the delay module 301. When the working state is set to normal; further, the fault recovery node 300 further includes:

The detecting module 304 is configured to: when the working state of the fault recovery node is to be changed to normal, the triggering state module 303 performs the operation of sending the delay notification and sending the trigger notification.

If the detection result is that the working state of the fault recovery node is to be changed to normal, the state module 303 sends a delay notification to the delay module 301, and the delay module 301 starts to set the delay. Time, and the status module 303 sends a trigger notification to the message sending module 302.

The cross-ring node 310 can include the following parts: a message receiving module 311, and a state module 312, where

The message receiving module 311 is configured to receive the fault recovery notification message sent by the fault recovery node 300, and then send a setting working state notification to the status module 312.

The status module 312 receives the set working status notification sent by the message receiving module 311, and sets the working status of the cross-ring node 310.

Further, the cross-ring node 310 further includes a determining module 313:

The determining module 313 is configured to determine the working state of the cross-ring node 310, determine the working state of the cross-ring node connected thereto, and the priority of the two cross-ring nodes; and send the result of the judgment to the status module. 312.

The status module 312 sets the operational status of the cross-loop node 310 based on the result of the determination sent by the determination module 312.

If the cross-ring node 310 is not in the master state, the working state of the cross-ring node is not changed; if the cross-ring node 310 is in the master state, and there is only a cross-ring node of the connected master state on one RPR ring, and the cross-ring node If the priority is low, the cross-ring node is set to other states that are not in the master state;

If the cross-ring node 310 is in the master state, and there is only a cross-ring node of the associated master state on one RPR ring, and the priority of the cross-ring node is high, the working state of the cross-ring node is not changed;

If the cross-ring node 310 is in the master state, and there is no cross-ring node of the associated master state on the two RPR rings, the working state of the cross-ring node is not changed;

Specifically, if the cross-ring node 310 has only the connected master-state cross-ring nodes on one RPR ring, and their priorities are the same, then the device ID can be used to determine who is set to other non-master state. The sequence is in accordance with the regulations. The above is a detailed description of the system provided by the present invention, and the method provided by the present invention will be described below. As shown in FIG. 4, FIG. 4 is a flowchart of a method for avoiding a loop after failure recovery in an RPR. In the case where two rings on two RPR rings have two fault points at the same time, after the fault recovery, the flow shown in FIG. 4 is adopted to avoid the loop problem that may be caused when one of the fault points is recovered, wherein the two The fault points are at each end of a cross-ring node. The process mainly includes:

Step 401: After the fault is recovered, the fault recovery node sets the delay time, and then sends a fault recovery notification from the two directions of the RPR ring to the cross-ring node.

The purpose of setting the delay time is: ensuring that the cross-ring node 310 can receive the fault recovery notification message sent by the fault recovery node 300 and perform correspondingly before the state of the delay recovery node is restored. State processing.

The length of the delay time can be set according to the number of hops that the fault recovery node is farthest from the two cross-ring nodes. For example, if the hop count is N, the delay time is N*10ms, and 10ms here mainly considers the processing delay of the line and each node in the line, which is an empirical value. The hop count of the distance cross-ring node may be determined according to the MAC address information of the cross-ring node and the non-cross-ring node on the RPR ring. In addition, the delay time may also be manually configured in advance in each non-cross-ring node.

The fault recovery notification is used to notify the two cross-ring nodes that the fault is recovered. More preferably, during the delay, in order to avoid the lost fault recovery notification packet, the fault recovery notification packet may be sent multiple times. You can also ask the other party to respond.

Step 402: After receiving the fault recovery notification message sent by the fault recovery node, the cross-ring node sets the working state of the cross-ring node.

Setting the working state of the cross-ring node according to the state of the cross-ring node itself, and The status of other cross-ring nodes, and the priority between them, to set the working state of the cross-ring nodes. There are several situations:

1) If the cross-ring node is not in the master state, the working state of the cross-ring node is not changed.

Because if the cross-ring node is not in the master state, it is not responsible for the forwarding of the cross-ring service, and thus no loop is formed, so the working state of the cross-ring node does not change.

2) If the state of the cross-ring node is the master state, and there is no cross-ring node of the connected master state on both RPR rings, the working state of the cross-ring node is not changed.

Because this situation includes two situations: First, the cross-ring node is the master state, and the other cross-ring node is the other state of the non-master state, then there is no loop formation, so the cross-ring node is not changed. Working status. Second, the two cross-ring nodes are in the master state, but there are fault points between the two cross-ring nodes, that is, there are fault points on both ends of the cross-ring nodes on the two rings, that is, on the two rings. There are four fault points, then when there is a fault point recovery, no loop will be formed, so the working state of the cross-ring node will not be changed.

3) If the cross-ring node is in the master state and there is a cross-ring node with a connected master state on only one RPR ring, and the priority of the cross-ring node is high, the working state of the cross-ring node is not changed.

4) If the cross-ring node is in the master state and there is a cross-ring node with a connected master state on only one RPR ring, and the priority of the cross-ring node is low, the working state of the cross-ring node is set to non- Other states of the master state.

3) and 4) Both cases have a faulty node between the two spanning nodes. Because both spanning nodes are in the master state, it is easy to form a loop as shown in Figure 2 on the ring, so The level sets one of the two cross-ring nodes to the master state, and the other sets the other states to the non-master state, and no loop is formed.

Step 403: After the delay time expires, the fault recovery node sets the working state to Normal

The above is the main flow of the method provided by the present invention. The flow is described in detail below. As shown in FIG. 5, FIG. 5 is a detailed flowchart of a method for avoiding a loop after failure recovery. The process includes the following steps:

Step 501: After the fault is recovered, it is determined whether the working mode of the fault recovery node is to be set to normal. If yes, go to step 502; if no, end the process.

Step 502: The fault recovery node sets a delay time, and then sends a fault recovery notification message to the cross-ring node from two directions of the RPR ring to notify the cross-ring node that the fault has been recovered.

The purpose of the delay time is to ensure that the fault recovery notification message sent by the fault recovery node can be received by the cross-ring node in time and set the working state of the cross-ring node.

The fault recovery notification is used to notify the two cross-ring nodes that the fault is recovered. More preferably, during the delay, in order to avoid the lost fault recovery notification message, the fault recovery notification may be sent multiple times.

The fault recovery notification message can be extended on the existing message base or a new packet type.

Step 503: The cross-ring node receives the fault recovery notification message sent by the fault recovery node. This step is performed by the message receiving module 311 in the system of Fig. 3.

Step 504: Determine whether the cross-ring node is in the master state. If yes, go to step 505; if no, go to step 507.

Step 505: Determine whether the cross-ring node has a connected cross-ring node in the master state on only one RPR ring, and the cross-ring node has a low priority. If yes, go to step 506; if no, go to step 507.

In this step, there are the following cases: if the cross-ring node does not have a connected cross-ring node in the master state on both RPR rings, step 507 is performed;

If the cross-ring node has only a connected master state cross-link on one RPR ring Point, and the cross-ring node has a high priority, step 507 is performed;

If the cross-ring node has a cross-link point of the connected master state on only one RPR ring, and the cross-ring node has a low priority, if yes, go to step 506.

Further, if the cross-ring node has only the connected master state cross-ring nodes on one RPR ring, and their priorities are the same, then the device ID can be used to determine who exits the master state, and the sequence is performed according to regulations. .

Step 506: Set the working state of the cross-ring node to other states that are not in the master state.

Step 507: When the delay time expires, set the working state of the fault recovery node to normal.

As can be seen from the above description, the fault recovery node sends a fault recovery notification message to the cross-ring node from the two RPR rings by setting the delay time. After the delay, the working state is set to normal; during the delay, the cross-ring node receives the fault recovery. The fault recovery notification message sent by the node, and the working state of the cross-ring node is set according to the status. The method and system provided by the present invention solves the loop problem that is prone to occur when one of the two fault points located at both ends of the cross-ring node recovers.

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

Claims

Claim

A method for avoiding a loop after a fault is recovered, the method comprising: after the fault is recovered, the fault recovery node sets a delay time, and sends a fault recovery notification message from two directions of the RRP ring of the elastic packet ring. To the cross-ring node; when the delay time expires, the fault recovery node sets the working state to the normal state normal;

After receiving the fault recovery notification message sent by the fault recovery node, the cross-ring node sets the working status of the cross-ring node.

The method according to claim 1, wherein the determining, by the fault recovery node, the delay time further comprises: determining whether the fault recovery node is to set the working state to normal; if yes, continuing to set the delay time step.

The method according to claim 1, wherein the fault recovery node has two cross-ring nodes on the RPR ring;

The delay time is determined according to the number of hops that the fault recovery node is furthest from the two cross-ring nodes.

The method according to claim 1, wherein the sending the fault recovery notification message to the cross-ring node from the two directions of the RPR ring is: sending the fault recovery notification message multiple times from the two directions of the RPR ring. Give a cross-ring node.

The method according to claim 1, wherein the setting the working state of the cross-ring node comprises: setting an operating state of the cross-ring node according to a current state of the cross-ring node.

The method according to claim 5, wherein the setting the working state of the cross-ring node further comprises: according to the priority of the cross-ring node, and another one connected to the cross-ring node on the RPR ring The working state and priority of the cross-ring node sets the working state of the cross-ring node.

The method according to claim 5, wherein the according to the cross-ring node The current self state setting the working state of the cross-ring node includes: if the cross-ring node is not the master state, the working state of the cross-ring node is not changed.

The method according to claim 6, wherein the setting the working state of the cross-ring node according to the current state of the cross-ring node comprises: if the cross-ring node is currently in the master state, and only one A cross-ring node with a connected master state on the RPR ring, and the cross-ring node has a low priority, and the cross-ring node exits the master state;

If the cross-ring node is currently in the master state, and there is only a cross-ring node of the associated master state on one RPR ring, and the priority of the cross-ring node is high, the state of the cross-link point does not change;

If the cross-ring node is currently in the master state, and there is no cross-ring node of the associated master state on the two RPR rings, the state of the cross-ring node does not change;

If the cross-ring node is currently in the master state, and there is only a cross-ring node of the connected master state on one RPR ring, and the priority of the cross-ring node is the same, the cross-ring node is determined according to the device ID of the cross-ring node. status.

9. A system for avoiding loops after failure recovery in an RPR, characterized in that the system comprises a fault recovery node and a cross-ring node;

The fault recovery node is configured to set a delay time after the fault is recovered, and send a fault recovery notification message to the cross-ring node from two directions of the RPR ring; when the delay time expires, set the working state to normal;

The cross-ring node is configured to receive a fault recovery notification message sent by the fault recovery node, and set a working state according to the packet.

The status module is configured to send a delay notification to the delay module, and send a trigger notification to the message sending module; after receiving the arrival notification sent by the delay module, set the working status to Normal;

The delay module is configured to: after receiving the delay notification sent by the status module, set a delay time, and send a notification to the status module when the delay time expires;

The RPR device according to claim 10, wherein the RPR device further comprises: a detecting module;

The detecting module is configured to: when the working state of the fault recovery node is to be changed to normal, the triggering state module performs the operation of sending the delay notification and sending the trigger notification.

An RPR device, the RPR device comprising: a message receiving module, and a status module;

The message receiving module is configured to receive a fault recovery notification message sent by the fault recovery node, and then send a setting working state notification to the status module;

The RPR device according to claim 13, wherein the RPR device further comprises: a determining module;

The determining module is configured to determine a working state and a priority of the cross-ring node, determine a working state of the cross-ring node connected thereto, and a priority level, and send the result of the judgment to the status module;

The status module is configured to set the working status of the cross-link point according to the result of the judgment sent by the determining module.