WO2012129725A1

WO2012129725A1 - Ethernet ring protection for non-erp compliant links and nodes

Info

Publication number: WO2012129725A1
Application number: PCT/CN2011/000542
Authority: WO
Inventors: Xiang Gao; Yongbo TAN; Wei KANG
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2011-03-30
Filing date: 2011-03-30
Publication date: 2012-10-04

Abstract

An Ethernet ring includes a plurality of participating nodes with adjacent ones of the nodes coupled together via an independent link. At least two of the nodes are ERP protocol compliant and at least one of the nodes is ERP non-compliant node. Failures in the Ethernet ring are mitigated by determining whether a failure detected at a ring port of one of the ERP compliant nodes is a direct failure on the link coupling the ring port to an adjacent one of the nodes or at the adjacent node, or is an indirect failure on another link or at one of the ERP noncompliant nodes. The ring port is blocked if the failure is determined to be direct so that communication at the ring port remains unblocked if the failure is determined to be indirect. An indication is provided for indicating whether the ring port is blocked or unblocked in response to the failure.

Description

ETHERNET RING PROTECTION FOR NON-ERP COMPLIANT LINKS AND NODES

TECHNICAL FIELD

[0001] The embodiments described herein generally relate to Ethernet rings, and particularly relate to providing Ethernet ring protection (ERP) for non-ERP compliant links and nodes participating in Ethernet rings.

BACKGROUND

[0002] The ring topology is commonly adopted in Ethernet networks to provide redundancy. ITU-T recommendation G.8032 defines an Ethernet ring protection (ERP) protocol which provides for automatic protection switching (APS) in an Ethernet ring. The main objectives of ITU-T G.8032 is to provide sub-50msec protection switching on the Ethernet layer, use one of a suite of Ethernet OAM (Operations, Administration, and Management) frames called R-APS messages for protection behavior, and avoid loops by employing a link blocking mechanism.

[0003] R-APS requests control the communication and states of the nodes within the ring. Two basic R-APS messages are specified by ITU-T G.8032: R-APS(SF) and R-APS(NR). The R-APS(SF) message indicates a signal failure condition has occurred within the ring and the R- APS(NR) message indicates the ring has no failures i.e. the ring is in the idle (normal) operation state. The physical topology of the network has all nodes connected in a ring. The ERP protocol guarantees loop avoidance by purposely blocking one of the links. The blocked link is referred to as the RPL (ring protection link). The logical topology of the network has all nodes connected without a loop.

[0004] In general, the ring nodes may be in one of two states: (1) an idle (normal) operation state with no link or node faults detected in the ring; or (2) a protection state with protection switching in effect after identifying a signal fault. In the event of a signal failure, the ring protection feature of ITU-T G.8032 is triggered. A signal failure can be detected in the ring based on physical link loss or the lack of Ethernet OAM CCM (continuity check message) frames at the Layer 2 level which indicates loss of continuity. Link or node failures within the ring are detected by the nodes adjacent the failure. The adjacent nodes block the failed link and report the failure to the ring using an R-APS(SF) message, where (SF) indicates a signal failure condition. The R-APS(SF) message triggers the owner of the RPL to unblock the RPL so that the RPL is now available for communication to ensure proper operation of the ring. Also, all nodes perform FDB (forwarding database) flushing to place the ring in the protection state. All nodes except failures remain connected in the logical topology.

[0005] When the failed link or node recovers, traffic remains blocked on the nodes adjacent the recovered link. The nodes adjacent the recovered link transmit an R-APS(NR) message indicating they have no local request present i.e. there is no signal failure. When the owner of the RPL receives the R-APS(NR) message, the RPL owner node starts a wait timer. Once the wait timer expires, the RPL owner node re-blocks the RPL and transmits an R-APS(NR, RB) message. Nodes receiving this message perform an FDB flush and unblock their previously blocked ports so that the ring is returned to the idle (normal operation) state.

[0006] The ERP protocol works well if all nodes in the Ethernet ring support the ERP protocol. However, if ERP non-compliant nodes participate in the Ethernet ring, a failure may not be detected by the ERP protocol in some cases. For example, Figure 1 shows an access ring and a packet network connected by dual head-end devices (labeled N5 and N6) which do not support the ERP protocol. Commonly, the access ring is an Ethernet ring and the packet network is a core ring such as a Layer 2 or Layer 3 VPN (virtual private network). In this example, the nodes labeled 'ERP NE' are network elements such as Ethernet switches which support the ERP protocol and the nodes labeled 'Non-ERP NE' do not support the ERP protocol. Node N2 is the RPL owner node and ring port P2 is the blocked port of the RPL owner in accordance with ITU-T G.8032. RPL neighbor node N3 blocks its corresponding ring port P3 so that the RPL (between ports P2 and P3) is blocked and therefore cannot be used for communication, ensuring loop avoidance in the ring.

[0007] In Figure 1 , possible failure locations related to ERP non-compliant devices in the ERP ring are marked with an 'X'. This includes failures on links L1 , L2 and L3 and failures at ERP non-compliant nodes N5 and N6.

[0008] If the physical link loss detection method is used for ERP failure detection related to ERP non-compliant devices, then possible failures on links L1 and L2 and at ERP non- compliant nodes N5 and N6 can be detected. However, these failures are detectable only by one ERP ring port (in one ring direction), which is the port adjacent the failure directly, but are not detectable by the other indirect ring port. For example, the failure on link L1 or node N6 can be detected only by ring port P1 of ERP node N1 , whereas the failure on L2 and N5 can be detected only by ring port P4 of ERP node N4. Only one of the ERP compliant ports can detect these failures because a non-compliant ERP device (e.g. N5 or N6) is connected to an ERP compliant device (e.g. N4 or N1) in each case.

[0009] For the ring topology shown in Figure 1 , the ERP devices execute FDB flush during failure protection procedure only once because of the failure detection on a single ring port with the method of physical link loss detection. The benefit of executing FDB flush twice triggered by failure detection on both ring ports, which is described by ITU-T G.8032, is unavailable. For example, for link failure on L1 , the FDB flush on all ERP nodes can only be triggered by an SF message from N1. The term 'FDB' refers to a forwarding database maintained at each ERP node which includes all learned MAC (media access control) addresses of the corresponding port. ERP ring nodes in compliance with ITU-T G.8032 support standard FDB MAC learning, forwarding, flush behavior and port blocking/unblocking mechanisms to ensure proper communication within the ring and prevent loops within the ring by blocking one of the links (either a pre-determined link or a failed link). During normal operation i.e. no failures, the RPL is blocked as described above to ensure loop avoidance. In the event of a failure, the ring port detecting a failure should be blocked, R-APS messages should be sent, the RPL should be unblocked, and an FDB flush should be performed on all ring nodes as needed as explained above. For example, the ERP nodes monitor the ETH layer for discovery and identification of signal failure (SF) conditions, which indicate a failure within the ring.

[0010] In addition, an indirect connection failure for ERP ring ports P1 and P4 on link L3 between ERP non-compliant nodes N5 and N6 cannot be detected at all by the ERP ring. That is, none of the ERP compliant nodes participating in the ring can detect a failure on link L3.

[0011] If Layer 2 OAM CCM frames are used for failure detection related to ERP non- compliant devices, a pair of MEG (maintenance entity group) end point (MEPs) should be configured on the two ERP nodes N1 and N4 in Figure 1 , specifically on ring ports P1 and P4. Then, the CCM frames can detect the failure on the path of L1-N6-L3-N5-L2. In this case, the failure on link L3 can be detected by both ring port P1 and ring port P4. However, according to the ERP protocol, both port P1 and P4 are blocked at any failure on links L1 , L2 and L3 or at nodes N5 and N6. As such, communication between the ERP ring and the packet network in Figure 1 is interrupted even though there is only a single failure e.g. on link L1 or L2.

SUMMARY

[0012] According to embodiments described herein, physical link loss and Layer 2 CCM frame failure detection techniques are both supported in an Ethernet ring including both ERP compliant and ERP non-compliant nodes. Based on the combined detection, failures in the ring can be distinguished as either direct or indirect. A direct failure occurs on a link coupling a ring port of an ERP compliant node to an adjacent node of the ring, or at the adjacent node itself. The adjacent node can be an ERP compliant node or an ERP non-compliant node. An indirect failure occurs on another link or node in the ring, which is not coupled to the ring port that detected the failure. For example, the indirect failure node typically is an ERP non-compliant node participating in the ring. The ERP compliant port is blocked if the failure detected at the port is deemed to be a direct failure. Otherwise, the port remains unblocked to ensure proper communication within the ring and with adjacent network(s) coupled to the ERP ring. A new information element field is defined for the R-APS message which identifies the blocked or unblocked status of a ring port which detects a signal failure. In one embodiment, the field is a NB (Non Blocked) field included in the R-APS message which supports both port statuses i.e. blocked or unblocked.

[0013] According to an embodiment, a method is provided for mitigating failures in an Ethernet ring including a plurality of participating nodes with adjacent ones of the nodes coupled together via an independent link, at least two of the nodes being ERP protocol compliant nodes and at least one of the nodes being an ERP non-compliant node. The method includes determining whether a failure detected at a ring port of one of the ERP compliant nodes is a direct failure on the link coupling the ring port to an adjacent one of the nodes or at the adjacent node, or is an indirect failure on another link or at one of the ERP non-compliant nodes. The method further includes blocking the ring port if the failure is determined to be direct so that communication at the ring port remains unblocked if the failure is determined to be indirect and indicating whether the ring port is blocked or unblocked in response to the direct or indirect failure.

[0014] According to an embodiment of an ERP protocol compliant node for use in an Ethernet ring, the ERP protocol compliant node includes a ring port operable to couple the ERP compliant node to an adjacent node of the Ethernet ring via a link. The ERP protocol compliant node further includes one or more processing circuits operable to determine whether a failure detected at the ring port is a direct failure on the link or at the adjacent node, or is an indirect failure on another link or at an ERP non-compliant node of the Ethernet ring, block the ring port if the failure is determined to be direct so that communication at the ring port remains unblocked if the failure is determined to be indirect, and indicate whether the ring port is blocked or unblocked in response to the failure. [0015] Those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The components in the figures are not necessarily to scale, instead emphasis being placed upon illustrating the principles of the embodiments described herein. Moreover, in the figures, like reference numerals designate corresponding parts. In the drawings:

[0017] Figure 1 illustrates an Ethernet ring with ERP non-compliant nodes coupled to a packet data network.

[0018] Figure 2 illustrates an embodiment of an Ethernet ring with ERP non-compliant nodes coupled to a packet data network.

[0019] Figure 3 illustrates an embodiment of an extended R-APS(SF) message including a ring port blocked/unblocked status identifier.

[0020] Figure 4 illustrates an embodiment of a ring port state transfer diagram.

[0021] Figure 5 illustrates an embodiment of a failure handling procedure implemented within an Ethernet ring having ERP non-complaint nodes.

[0022] Figure 6 illustrates an embodiment of a failure recovery procedure implemented within an Ethernet ring having ERP non-complaint nodes.

DETAILED DESCRIPTION

[0023] Figure 2 illustrates an embodiment of an Ethernet ring 100. The Ethernet ring 100 can be an access ring or any other type of Ethernet ring. The ring 100 is coupled to a packet data network (PDN) 110 or another ring such as a core ring like a Layer 2 VPLS (virtual private LAN service) or Layer 3 VPN (virtual private network). In each case, the Ethernet ring 100 includes a plurality of participating nodes N1-N6. Adjacent nodes have ring ports (P) which are coupled together via respective independent links (L). Some of the nodes are ERP protocol compliant meaning that these nodes are compliant with the ERP protocol disclosed in ITU-T G.8032 and any variants and/or offshoots thereof. One or more other ones of the nodes are ERP non-compliant in that these nodes are non-compliant with the ERP protocol disclosed in ITU-T G.8032. For example, Figure 2 shows the Ethernet ring 100 and the PDN / core network 110 connected by dual head-end devices (labeled N5 and N6) which do not support the ERP protocol.

[0024] The ERP compliant nodes include one or more processing circuits 120 for implementing the ERP protocol-related procedures described herein. The respective processing circuit(s) 120 can include any type of hardware and/or software suitable for implementing these procedures. For example, the respective processing circuit(s) 120 may include one or more baseband processors, microprocessors, microcomputers, digital signal processors (DSPs), special-purpose hardware, such as an application specific integrated circuit (ASIC) and programmable logic devices, controllers, memory, firmware, software, and/or any combination thereof.

[0025] The ERP compliant nodes, via the respective processing circuit(s) 120, combine Layer 1 (physical layer) and Layer 2 (data link layer) error detection techniques at each ring port to provide robust ring protection so that the ERP non-compliant links and nodes participating in the Ethernet ring do not interfere with the protection switching provided by the ERP protocol. In one embodiment, Layer 1 errors can be detected at the ERP compliant ports by detecting Layer 1 physical link loss and Layer 2 errors can be detected at the ring ports by detecting the lack of received Layer 2 Ethernet OA CCM frames.

[0026] The failure detected by any ERP port is distinguished as either a direct failure or an indirect failure. The location of a direct failure lies on the direct link or adjacent device for an ERP compliant node. In Figure 2, some possible failures are represented by an 'X' at the affected link or node. A failure on link L1 or at ERP non-complaint node N6 is determined to be a direct failure at ring port P1 of ERP compliant node N1. On the other hand, the location of an indirect failure lies on any indirect link i.e. any link not directly coupled to an ERP compliant node or at an ERP non-compliant node in the path between the two peer MEP ports. For example, possible failures on links L2 and L3 and at ERP non-compliant node N5 are each determined to be an indirect failure at port P1 of ERP compliant node N1.

[0027] According to ITU-T G.8032, the failed ring port is blocked by the ERP node for a local SF (signal failure) condition. An R-APS(SF) message is then sent to announce the blocked port in the ring. According to the embodiments described herein, differentiating between direct and indirect failures is used as a pre-condition for failed ring port blocking. For the case of a direct failure, the ERP node response behavior is the same as for the SF condition defined in G.8032 i.e. the failed ring port is blocked and the other nodes are correspondingly notified. For the case of an indirect failure, the failed ring port remains unblocked to maintain communication with the PDN/core ring 110. As such, the failed ring port is blocked for a direct failure and unblocked for an indirect failure and thus the communication remains by the unblocked port.

[0028] An R-APS(SF) message is still used to announce the failure. However, additional information indicating the blocked/unblocked status of the ring port is provided in the message using an information field extension. The extended R-APS(SF) message is referred to herein as R-APS(SF.NB), that is R-APS(SF) with an unblocked port.

[0029] Figure 3 illustrates an embodiment of the extended R-APS(SF) message i.e. R- APS(SF,NB). The R-APS information format defined in ITU-T G.8032 includes a Status byte. The first five lower-order bits of the Status byte are reserved bits (Status Reserved) according to ITU-T G.8032.

[0030] In one embodiment, the 5^th (lower end) bit contains the ring port blocked/unblocked (NB) status identifier for the R-APS(SF) message. A logic zero value for the NB status identifier can indicate that the failure detected by the failed ring port is a direct failure and the failed ring port is correspondingly blocked, and a logic one value can indicate that the failure detected by the failed ring port is an indirect failure and the failed ring port remains unblocked. Of course, the opposite bit values for the NB status identifier can be used to indicate the blocked/unblocked status of the failed ring port. Another bit position of the reserved bits could also be used to indicate the failed port status (NB).

[0031] The R-APS information format defined in G.8032 also includes a Request/State field as shown in Figure 3 for indicating whether a signal failure (SF) has occurred. For example, the value Ί011' = SF (signal failure) and the value '0000' = NR (no local request present, i.e. no detected signal failure). Accordingly, the R-APS message is identified by other ERP compliant ports as being R-APS(SF) when Request/State=1011 and NB (Reserved Status bit5)=0, indicating that a signal failure has occurred and the corresponding ring port (i.e. the failed port) is blocked because the failure was determined to be a direct failure. On the other hand, the R- APS message is identified by the other ERP compliant ports as being R-APS(SF.NB) when Request/State=1011 and NB (Reserved Status bit5)=1 , indicating that a signal failure has occurred and the failed ring port is unblocked because the failure was determined to be an indirect failure. Otherwise the received message is an R-APS(NR) message indicating that the sending ERP node has no local request present i.e. there is no detected signal failure.

[0032] Table 1 below summarizes the different relationships between the failure detection techniques (Layer 1 and Layer 2), failure type, failed ring port status, logical state of the blocked/unblocked status identifier (NB) for the failed ring port and corresponding R-APS message type according to an embodiment.

Tablel : Comparisons between conditions for R-APS(SF), R-APS(SF.NB) and R- APS(NR)

[0033] The extended R-APS(SF) message shown in Figure 3 also includes a modified blocked port reference (BPR) field. According to ITU-T G.8032, the BPR field is used to mark on which ring port the failure is detected and the corresponding ring port is blocked. The definition in G.8032 is as follows: a logic zero corresponds to ring link 0 blocked and a logic one corresponds to ring link 1 blocked. According to one embodiment, the BPR field is modified and interpreted in conjunction with the R-APS message type as indicated in Table 2 below.

Table 2: Redefined BPR Field

[0034] Direct and indirect failures can be transferred reciprocally by new failure or recovery detection. In addition, Layer 1 physical link and Layer 2 CCM frame restorations are also combined for the failure recovery detection.

[0035] Figure 4 illustrates a ring port state transfer diagram between the states of normal, direct failure and indirect failure. All triggers and actions for the transfers shown in Figure 4 are described in Table 3 below.

Table3: Triggers and Actions for State Transfer Diagram Shown in Fig

S1 Normal Direct Failure Physical port/link loss Refer to the actions

Failure described according to Figure 5

S2 Normal Indirect Failure CCM frame failure Refer to the actions

Failure but physical port/link described according still alive to Figure 5

S3 Indirect Direct Failure Physical port/link loss Stop R-APS(SF.NB), Failure Failure then block failed ring port and send R- APS(SF)

S4 Indirect Normal Recovery Continuous CCM Refer to the actions Failure frame restoration described according to Figure 6

S5 Direct Indirect Recovery Physical port/link Stop R-APS(SF), Failure Failure restoration but CCM then unblock failed frame failure ring port and send R- APS(SF.NB)

S6 Direct Normal Recovery Physical port/link Refer to the actions Failure restoration and described according

Continuous CCM to Figure 6 frame restoration

[0036] Figure 5 illustrates an embodiment of the failure procedure implemented by the processing circuit(s) 120 included in the respective ERP compliant nodes, based on the exemplary Ethernet ring scenario shown in Figure 2. The failure is a single link failure in this example.

[0037] At state A in Figure 5, the ring 100 operates in the idle (normal operation) state as indicated by the R-APS(NR.RB) messages, which are sent by the RPL owner node N2 periodically. Ethernet OAM CCM frames between a pair of MEPs (on the ring ports P4 and P1) are used for failure detection related to ERP non-compliant devices between ERP nodes N4 and N1 (corresponding to the path N4-L2-N5-L3-N6-L1-N1). ERP non-complaint nodes N5 and N6 are in the monitoring path. There are no detected physical link losses and the two ERP compliant nodes N1 and N4 periodically receive OAM CCM frames. As such, there are no detected signal failures at this point.

[0038] At state B in Figure 5, a signal failure (SF) occurs on link L2.

[0039] At state C in Figure 5, ERP node N4 determines that the failure is a direct failure, for example through physical link loss detection because link L2 is directly coupled to ring port P4 of ERP node N4. ERP node N1 determines that the failure is an indirect failure, for example through the lack of received OAM CCM frames coming from the direction of link L2 because link L2 is an indirect link from the perspective of node N1 i.e. link L2 is not directly coupled to any ring port of node N1. Accordingly, ERP nodes N4 and N1 detect a local signal failure condition (a direct failure for N4 and an indirect failure for N1). After a predetermined hold-off time expires and with no higher priority state, ERP node N4 blocks its failed ring port P4 (port 1 in Figure 5) because the failure is determined to be direct at this port and ERP node N1 does not block its failed ring port P1 (port 0 in Figure 5) because the failure is determined to be indirect at this port. An FDB flush is performed on both ERP nodes N4 and N1.

[0040] At state D in Figure 5, ERP node N4 begins sending periodic R-APS(SF) messages (NB status bit is set to 0) and ERP node N1 begins sending periodic R-APS(SF.NB) messages (NB status bit is set to 1 ). Both kinds of messages include the Node ID (for example '89' for ERP node N4 and '31' for ERP node N1) and BPR (for example port 1 for node N4 and port 0 for node N1) fields on both ring ports, while the SF condition persists.

[0041] At state E in Figure 5, all ERP nodes receiving the R-APS(SF) or R-APS(SF.NB) message from one failed ring port perform an FDB flush. When the RPL owner node N2 and

RPL neighbor node N3 receive the R-APS(SF) or R-APS(SF.NB) message, each respective node unblocks the corresponding end port of the RPL and performs an FDB flush.

[0042] At state F in Figure 5, all ERP nodes receiving the R-APS(SF.NB) or R-APS(SF) message from the other failed ring port perform an FDB flush again because of the node ID and

BPR-based mechanism.

[0043] At state G in Figure 5, a stable SF condition keeps. This state is indicated by R- APS(SF) or R-APS(SF.NB) messages propagating on the Ethernet ring. Further periodic R- APS(SF) or R-APS(SF.NB) messages from N4 or N1 trigger no further action.

[0044] In the failure example shown in Figure 5, one end of the failed path is determined to be a direct failure and the other end is determined to be an indirect failure due to the location of the failure. In this case, during the failure condition, one failed ring port is blocked and the other one remains unblocked as described above.

[0045] If the failure location is at link L3 in Figure 5, then the failures detected by the two closest ERP nodes N4 and N1 are both indirect failures. That is, the failure at ring port 0 of ERP node N1 and at ring port 1 of ERP node N4 are both determined to be indirect failures because the failure lies on an indirect link L3 which is not directly coupled to any ERP compliant node. In this case, both failed ring ports remain unblocked after the failure protection procedure and the logical ring is avoided by the failed link L3 natively. However, the recovery of the failure will temporarily form an undesirable loop if both ring ports remain unblocked. This issue is handled during the recovery procedure described next. According to one embodiment, as soon as the recovery is detected, the failed ring port which has a higher node ID is blocked on the traffic and R-APS channel for ring avoidance during the recovery procedure. As such, ring port 1 of ERP node N4 is blocked in the above example because node N4 has a higher node ID (89) than ERP node N1 (31). Ring port 0 of ERP node N1 remains unblocked during the recovery procedure.

[0046] During the recovery procedure, after the higher node ID port is blocked, the status and handling of the failure at link L3 is managed the same as if one ring port originally detected a direct failure and the other ring port detected an indirect failure. Table 4 below shows the handling of various failure scenarios for the Ethernet ring 100 shown in Figure 2.

Table 4: Indirect Failure Scenarios for Figure 2

[0047] Figure 6 illustrates an embodiment of the failure recovery procedure implemented by the processing circuit(s) 120 included in the respective ERP compliant nodes, based on the exemplary Ethernet ring 100 shown in Figure 2.

[0048] At state A in Figure 6, a stable signal failure (SF) condition is initially present. The stable SF condition corresponds to state G of the failure handling procedure illustrated in Figure 5.

[0049] At state B in Figure 6, the link failure is recovered. An indirect failure recovery can be detected by receiving three continuous CCM frames, for example on ring port P1 of node N1. In the case where both original failed ring ports are unblocked during the failure handling procedure, such as the failure on link L3, the ring port having a higher node ID is first blocked on the traffic and R-APS channel for ring avoidance during the recovery procedure as explained above.

[0050] At state C in Figure 6, ERP nodes N4 and N1 detect the failure recovery and clearing of the SF condition, start respective guard timers and initiate periodical transmission of R- APS(NR) messages on both ring ports. The guard timer prevents the reception of R-APS messages.

[0051] At state D in Figure 6, when the ERP nodes receive an R-APS(NR) message, the Node ID and BPR fields for the corresponding receiving ring port are deleted and the RPL owner node starts a WTR (Wait to Restore) timer. ITU-T G.8032 specifies the use of different timers to avoid race conditions and unnecessary switching operations, such as the WTR timer which is used by the RPL owner node to verify that the ring has stabilized before blocking the RPL after a failure recovery and hold-off timers which are used by the underlying ETH layer to filter out intermittent link faults.

[0052] At state E in Figure 6, when the guard timer expires on ERP nodes N4 and 1 , these nodes may accept newly received R-APS messages. If both failed ring ports have direct failures and are thus blocked, the ERP node with the lower node ID receives an R-APS(NR) message with a higher node ID from the peer end and unblocks its non-failed ring port. If not, namely one ring port is blocked (by a direct failure or by recovery procedure for two unblocked ring ports) and the other ring port is unblocked, the port unblock action is skipped.

[0053] At state F in Figure 6, at expiration of the WTR timer, the RPL owner node N2 blocks its end port of the RPL, sends an R-APS(NR.RB) message with the corresponding Node ID (75' for node N2) and BPR (port 1 for node N2) fields for the node, and performs an FDB flush.

[0054] At state G in Figure 6, when ERP node N4 receives an R-APS(NR, RB) message, the node unblocks its ring port P4 and stops sending R-APS(NR) messages. On the other hand, when the RPL neighbor node N3 receives an R-APS(NR.RB) message, the node blocks its end port of the RPL In addition, ERP nodes N1 to N4 perform an FDB flush in response to receiving an R-APS(NR.RB) message due to the node ID and BPR-based.

[0055] At state H in Figure 6, the Ethernet ring then returns to idle (normal) operation with no detected failures.

[0056] Accordingly, the failure handling and recovery embodiments described herein provide protection of non-ERP nodes in an Ethernet ring, maintain traffic between non-ERP nodes and ERP nodes in the event of a failure condition and accelerate the FDB flush triggering for the detected failure.

[0057] Terms such as "first", "second", and the like, are used to describe various elements, regions, sections, etc. and are also not intended to be limiting. Like terms refer to like elements throughout the description.

[0058] As used herein, the terms "having", "containing", "including", "comprising" and the like are open ended terms that indicate the presence of stated elements or features, but do not preclude additional elements or features. The articles "a", "an" and "the" are intended to include the plural as well as the singular, unless the context clearly indicates otherwise.

[0059] With the above range of variations and applications in mind, it should be understood that the embodiments described herein are not limited by the foregoing description, nor are they limited by the accompanying drawings. Instead, the embodiments described herein are limited only by the following claims and their legal equivalents.

Claims

CLAIMS What is claimed is:

1. A method of mitigating failures in an Ethernet ring including a plurality of participating nodes with adjacent ones of the nodes coupled together via an independent link, at least two of the nodes being Ethernet ring protection (ERP) protocol compliant nodes and at least one of the nodes being an ERP non-compliant node, the method characterized by:

determining whether a failure detected at a ring port of one of the ERP compliant nodes is a direct failure on the link coupling the ring port to an adjacent one of the nodes or at the adjacent node, or is an indirect failure on another link or at one of the ERP non-compliant nodes;

blocking the ring port if the failure is determined to be direct so that communication at the ring port remains unblocked if the failure is determined to be indirect; and indicating whether the ring port is blocked or unblocked in response to the failure.

2. The method of claim 1 , wherein the adjacent node coupled to the ring port at which the failure is detected is ERP non-compliant.

3. The method of claim 1 , wherein the failure is indirect and detected at the ring port by failing to receive one or more continuity check messages at the ring port which indicates a loss of continuity or incorrect network connection.

4. The method of claim 1 , wherein the failure is direct and detected at the ring port by detecting a physical link loss on the link coupling the ring port to the corresponding adjacent node.

5. The method of claim 1 , wherein indicating whether the ring port is blocked or unblocked in response to the failure comprises sending a message to the other ERP compliant nodes in the ring, the message including a first field which indicates a signal failure was detected at the ring port, a second field which identifies the ERP compliant node associated with the ring port, and a third field which indicates whether the ring port is blocked or Unblocked in response to the failure.

6. The method of claim 5, wherein the third field is a bit which is set to a first value if the ring port is blocked and to a second value if the ring port is unblocked.

7. The method of claim 5, wherein the message indicates the link and ring port associated with the failure and whether the ring port is blocked or unblocked.

8. The method of claim 1 , further comprising:

detecting an additional failure at a ring port of a different one of the ERP compliant nodes; and

implementing a failure recovery procedure at both ring ports which detected a failure.

9. The method of claim 8, wherein both ring ports detected an indirect failure and in response are initially unblocked prior to implementing the failure recovery procedure, and wherein implementing the failure recovery procedure at both ring ports comprises blocking one of the ring ports so that the other ring port remains unblocked.

10. The method of claim 9, wherein the ring port having a higher node ID is blocked during the failure recovery procedure.

The method of claim 8, further comprising:

detecting a clearing of the respective failures at both ring ports; and

transmitting messages from both ring ports indicating the respective failures

recovered.

12. The method of claim 1 , wherein the failure is initially determined to be direct and the method further comprises:

determining the direct failure subsequently becomes an indirect failure;

unblocking the previously blocked ring port responsive to determining the failure has become indirect; and

indicating the ring port is now unblocked and the signal failure detected at the ring port is now an indirect failure.

13. The method of claim 1 , wherein the failure is initially determined to be indirect and the method further comprises:

determining the indirect failure subsequently becomes a direct failure;

blocking the previously unblocked ring port responsive to determining the failure has become direct; and

indicating the ring port is now blocked and the signal failure detected at the ring port is now a direct failure.

14. An Ethernet ring protection (ERP) protocol compliant node for use in an Ethernet ring, the ERP protocol compliant node including a ring port operable to couple the ERP compliant node to an adjacent node of the Ethernet ring via a link, the ERP protocol compliant node characterized by: one or more processing circuits operable to determine whether a failure detected at the ring port is a direct failure on the link or at the adjacent node, or is an indirect failure on another link or at an ERP non-compliant node of the Ethernet ring, block the ring port if the failure is determined to be direct so that communication at the ring port remains unblocked if the failure is determined to be indirect, and indicate whether the ring port is blocked or unblocked in response to the failure.

15. The ERP compliant node of claim 14, wherein the adjacent node coupled to the ring port is ERP non-compliant.

16. The ERP compliant node of claim 14, wherein the failure is indirect and the ring port is operable to detect the indirect failure by failing to receive one or more continuity check messages at the ring port which indicates a loss of continuity or incorrect network connection.

17. The ERP compliant node of claim 14, wherein the failure is direct and the ring port is operable to detect the direct failure by detecting a physical link loss on the link.

18. The ERP compliant node of claim 14, wherein the one or more processing circuits are operable to generate a message for other ERP compliant nodes in the ring, the message including a first field which indicates a signal failure was detected at the ring port, a second field which identifies the ERP compliant node associated with the ring port, and a third field which indicates whether the ring port is blocked or unblocked in response to the failure.

19. The ERP compliant node of claim 18, wherein the third field is a bit which is set to a first value if the ring port is blocked and to a second value if the port is unblocked.

20. The ERP compliant node of claim 18, wherein the message indicates the link and ring port associated with the failure and whether the ring port is blocked or unblocked.

21. The ERP compliant node of claim 14, wherein the failure is initially determined to be direct and the one or more processing circuits are operable to determine the direct failure subsequently becomes an indirect failure, unblock the previously blocked ring port responsive to determining the failure has become indirect, and indicate the ring port is now unblocked and the signal failure detected at the ring port is now an indirect failure.

22. The ERP compliant node of claim 14, wherein the failure is initially determined to be indirect and the one or more processing circuits are operable to determine the indirect failure subsequently becomes a direct failure, block the previously unblocked ring port responsive to determining the failure has become direct, and indicate the ring port is now blocked and the signal failure detected at the ring port is now a direct failure.