Patent Publication Number: US-9838215-B2

Title: Ethernet ring protection node with node-level redundancy

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     The present patent/application is a continuation of U.S. patent application Ser. No. 14/035,035, filed Sep. 24, 2013, and entitled “ETHERNET RING PROTECTION NODE” the contents of which are incorporated by reference. 
    
    
     TECHNICAL FIELD 
     This invention relates to network nodes and more particularly to systems and methods for nodes supporting data-link-layer, ring-protection-switching protocols. 
     BACKGROUND 
     At the data link layer (layer 2 of the Open Systems Interconnection (OSI) model), switching protection protocols, such as the Spanning Tree Protocol (STP), can be used to prevent the formation of loops by blocking node ports. Loops are problematic because they can overwhelm the bandwidth of a network during the flooding process whereby nodes in the network send out requests, which can get repeated ad infinitum in a loop, to find a new destination node with a Media Access Control (MAC) address not previously encountered by a node in the network. When a failure occurs in a network, such switching protection protocols need to be able to respond and restore service. 
     However, the response time of older switching protection protocols, such as STP, have proved too slow as data-link-layer networks, such as Ethernet networks, have evolved to provide services like video on demand, voice over internet protocol, and internet access. New switching protection protocols have been developed to more quickly respond to failures in the network. Ethernet Ring Protection (ERP) protocols, such as the ERP protocol defined in International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) G. 8032, provide examples of switch protection protocols with dramatically improved recovery times. 
     Although a node supporting an ERP may have more than two ports into/out of the node, the node can satisfy the ring architecture of an ERP ring by connecting to one or more additional nodes within an ERP ring with two ring ports. Additional ports may connect a node participating in the ring to nodes outside of the ring. Since a ring, by definition results in a loop, ERPs may block a link between a designated pair of nodes to prevent such loops. Despite the blocked link between two nodes, all of the nodes in the ring can still communicate with one another by passing information along the remaining backbone of serviceable links in one direction or another, depending on which is shortest. When a failure occurs elsewhere in the ring, the blocked link can be unblocked, since the failure prevents loops by effectively blocking a new link at a new location. Since the previously blocked link is now unblocked, all the nodes in the ring can still communicate with each other across a new backbone of serviceable links, although the directions in which communications are sent and from which they are received may change do to a new location of a new blocked link. 
     However, if a node fails completely with respect to the ring, meaning both ring ports go down, even if additional ports to nodes outside the ring remain serviceable, the ring loses two links. With the loss of two links, it is no longer possible to access every node in the ring. Because both ports that connect the failed node to the ring are down, the failed node can no longer communicate with other nodes in the ring and vice versa. What is more, nodes outside the ring connected to the failed node through one or more additional ports, which may not have failed, can no longer communicate with the ring. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order that the advantages of the invention will be readily understood, a more particular description of the invention will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not, therefore, to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which: 
         FIG. 1  is a schematic block diagram of a network including a ring architecture on which a ring protection protocol is implemented in accordance with an embodiment of the present invention; 
         FIG. 2 a    is a schematic block diagram of ring node implementing a single, ring-protection state machine in accordance with prior art; 
         FIG. 2 b    is a schematic block diagram of a ring node whose two ring ports are each maintained by a separate line card with its own ring-protection state machine, in accordance with an embodiment of the present invention; 
         FIG. 3  is a schematic block diagram of a ring node within a ring implementing a ring protection protocol where one of the ring node&#39;s ring ports has failed, but which still provides access to nodes external to the ring through the remaining ring port under the control of a surviving state machine, in accordance with an embodiment of the present invention; 
         FIG. 4  is a schematic block diagram of a backplane providing communication infrastructure between line cards residing at a common ring node and between two state machines on two such line cards, in accordance with an embodiment of the present invention; 
         FIG. 5  is a schematic block diagram of two state machines at the physical plane becoming transparent at the management plane for seamless interfaces with third-party devices implementing a ring protection protocol, in accordance with an embodiment of the present invention; 
         FIG. 6  is a schematic block diagram of a line card maintaining a front port capable of serving as a ring port and a virtual port, with details about switch infrastructure on the line card and a switch protection module with a state machine used to implement a ring protection protocol, in accordance with an embodiment of the present invention; 
         FIG. 7  is a sequence diagram of interactions between a pair of slots on a ring node, each with a front port serving as a ring port, a virtual port, and a state machine to, among other things, (1) synchronize the state machines, (2) respond to failures on a link used to synchronize the state machines, and (3) prevent a loop when the link recovers, in accordance with an embodiment of the present invention; 
         FIG. 8  is a schematic block diagram of a system progression for (1) a ring architecture implementing a ring protection protocol with a ring node experiencing a failure on an internal link between two state machines, progressing to (2) the ring node blocking a ring port to prevent a loop as the ring protection link for the ring is unblocked, and progressing to (3) the ring node unblocking the ring port after the ring protection link is blocked again, in accordance with an embodiment of the present invention; 
         FIG. 9  is a flow chart of a method for determining whether to respond to a message with a node identification value matching that of a line card/slot receiving the message in an environment where the two ports of a ring node are maintained by two line cards/slots with a common node identification value, in accordance with an embodiment of the present invention; and 
         FIG. 10  is a flow chart of a method for (1) responding to failures on a link between multiple state machines at a common ring node and (2) preventing a loop after the previously failed link is recovered, in accordance with an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. 
     Data-link-layer, ring-protection protocols, such as Ethernet Ring Protection (ERP) protocols may prevent loops, provide greatly improved recovery times in response to network failures, and provide redundancy across their ring architecture by the potential to unblock a ring protection link ordinarily blocked in a default position. Additional redundancy, however, may be provided at the level of individual nodes in the ring architecture. A node participating in a ring architecture may also be networked to large portions of a network external to the ring-architecture portion of the network. The connectivity provided by such a node may be lost where the node fails in the absence of redundancy at the node level to maintain this connectivity. 
     To preserve the many advantages of a ring protection protocol, node-level redundancy may include more than redundant connections, but may also include redundancies of one or more elements implementing the ring protection protocol, such as state machines. Also, to preserve the protection against loops provided by ring protection protocols, the details implementing node-level redundancy may include measures to prevent loops despite any changes arising from the implementation of node-level redundancies. Additionally, to facilitate integration of such a node into a ring of nodes implementing the ring protection protocol, ideally, details of such redundancies would be transparent at the node level. 
     A non-limiting, exemplary embodiment may involve implementing a ring-protection-protocol state machine on each of two different line cards residing at a common ring node. A front port of each line card may provide/maintain one ring port of the two ring ports defined for a ring node by the ring protection protocol. Therefore, if one ring card and/or state machine goes dark a surviving state machine may provide redundant connectivity, and a surviving state machine may provide redundant implementation of the ring protection protocol at the node. 
     To make the multiple state machines transparent, the multiple state machines may be synchronized as one logical state machine. For example, the first ring-protection-protocol state machine on a first line card of the two line cards may be updated to an updated state. A message may then be passed from a first virtual port of the first line card over a backplane of the ring node to a second virtual port of the second line card. The second ring-protection-protocol state machine on the second line card of the two line cards may then also be updated to the updated state in response to the message received at the second virtual port. As a result, the first state machine and the second state machine are synchronized as a common virtual state machine with respect to the ring node. 
     Messages used generally by the ring protection protocol to update the state of nodes in a ring implementing the ring protection protocol may be passed over the backplane to also synchronize multiple state machines at a common node providing the backplane. This backplane link may be monitored for failure. A failure may be addressed with messages used to respond to general ring failures. Furthermore, different roles may be assigned to the different state machines to respond to a recovery of the previously-failed backplane link between the state machines to prevent a loop. For example, while a ring protection link may remain unblocked in response to failure messages sent in response to the failure of the backplane link, one state machine may be assigned to block one of the ring ports of the redundant node to prevent a loop. This ring port may not be unblocked until an indication is received that the ring protection link is again blocked, according to the rings default posture, to prevent another potential loop. 
     Furthermore, state machines may be modified to respond to messages even though the messages may have a common identification node value, indicative that the message may have run their course and may be returning to their originator. State machines may be modified to respond to such matching messages where such messages are received over a virtual port, as opposed to a ring port, indicative of the messages originating with a paired state machine and containing synchronization information. Further details of approaches to achieving node-level redundancy can be informed by networking and ring protection protocol considerations discussed below with respect to  FIG. 1 . 
     Referring to  FIG. 1 , a ring architecture  10  is depicted with multiple nodes  12   a - f  participating in the ring architecture  10 . Additional nodes  12   g - k  may participate in a network with the multiple nodes  12   a - f  of the ring architecture  10 . The network can be a data-layer network (layer 2 of the Open Systems Interconnection (OSI) model), such as, but not necessarily, an Ethernet network. As demonstrated by the focused view of the third node  12   c , individual nodes may be instances of various forms of switches  12   c . Such switches may be classified according to different categories. For example, a group of switches  12  may be categorized as access switches  12 . Another group may be categorized as aggregation switches  12 . 
     Nodes  12  may be connected one to another by links  14   a - k . By way of example and not limitation, one or more of such links  14   a - f  between nodes  12   a - 12   f  in the ring  10  may be Network-to-Network Interfaces (NNI). The links  14   a - k  used to form the ring architecture  10  may be bi-directional links. Also, the links  14   g - k  between a node  12   f  participating in the ring  10  and nodes outside of the ring  12   g - k  may include one or more NNIs and/or User-to-Network Interfaces (UNIs). 
     The multiple nodes  12   a - f  in the ring  10  may implement a ring protection protocol, such as an ERP protocol. Although the ring  10  is made up of six nodes  12   a - f  in  FIG. 1 , many different numbers of nodes  12  may be involved. One, non-limiting example of a ring protection protocol may be found in ITU-T G.8032, but other ring protection protocols are possible. As can be appreciated, the ring structure  10  resulting from the six links  14   a - f  between the six nodes  12   a - f  can provide redundancy. At the same time, the ring structure  10  may also result in a problematic loop. 
     To prevent formation of a loop, a ring protection protocol may designate a particular link  14   a  as a Ring Protection Link (RPL)  14   a . Although the first  12   a  and the second nodes  12   b  may maintain the RPL  14   a , the first  12   a  and the second nodes  12   b  may also block  16   a ,  16   b  the RPL  14   a  to prevent a loop from forming within the ring  10 . In other words, by maintaining the blocked  16  RPL  14   a , redundancy may be preserved. By blocking  16  the RPL  14   a , a loop can be prevented. 
     In the event of a failure at any other link  14   a - f , the first  12   a  and the second nodes  12   b  may remove the blocks  16   a ,  16   b  to the RPL  14   a . Once the blocks  16   a ,  16   b  have been removed from the RPL  14   a  any node  12   a - f  on the ring  10  can still be accessed across a C-shaped backbone even though one of the remaining links  14   b - f  is temporarily down. When the downed link  14  recovers, the first  12   a  and the second nodes  12   b  may again block  16   a ,  16   b  the RPL  14   a  to prevent a loop. 
     Although the RPL  14   a  may have two adjacent nodes  12   a ,  12   b , to avoid confusion, the ring protection protocol may designate one node  12   a  as an Owner RPL (ORPL) node  12   a . In  FIG. 1 , the ORPL node  12   a  is indicated by the bold border outline. Specific functions related to blocking  16   a  and unblocking and/or initiating the blocking  16  and/or unblocking of the RPL  14   a  may be assigned and performed on the basis of a node&#39;s  12   a  status as an ORPL node  12   a.    
     Similarly, specific functions related to blocking  16   b  and unblocking and/or coordinating the blocking  16  and unblocking of the RPL  14   a  may be assigned and performed on the basis of a node&#39;s  12   b  status as an RPL-neighbor node  12   b . In  FIG. 1 , an example RPL-neighbor node  12   b  is indicated by the double-lined border outline. Therefore, in some examples, implementation of a ring protection protocol may involve referencing a position of a node  12  relative to the RPL  14   a  in the ring  10 . 
     As indicated by the exploded view of the fourth node  12   d , two ring ports  18   a ,  18   b  may be defined for ring nodes  12   a - 12   f  supporting the ring protection protocol. One ring port may be referred to as a west port  18   a , and another ring port may be referred to as an east port  18   b . The west port  18   a  and the east port  18   b  of each node  12   a - f  are sufficient to link the nodes  12   a - f  together in a ring structure  10 . Additional ports may connect a ring node  12   f  to client nodes  12   g - k  external to the ring  10 . 
     Referring to  FIG. 2 a   , a ring node  12   d - 1  is provisioned with a single line card  20   a . The line card  20   a  may have at least two front ports  22   a ,  22   b . The line card  20   a  may maintain the west port  18   a  of the ring node  12   d - 1  over the first front port  22   a  and the east port  18   b  over the second front port  22   b . In addition, a state machine  24   a  may reside on the line card  20   a . The state machine  20   a  may increment its state in response to one or more messages about relevant events occurring in the ring  10  received over the west port  18   a  and/or the east port  18   b  and/or events occurring locally with respect to the ring node  12   d - 1 . Throughout this application, the term ‘line card’ can refer to hardware commonly referred to as a line card, but may also refer to other forms of infrastructure capable of maintaining a ring port  18  and/or a state machine  24  and vice versa. 
     The state machine  24   a  may perform such state-dependent actions as sending and responding to messages to coordinate implementation of the ring protection protocol. Additional actions may include blocking  16  and unblocking ports to prevent loops and insure that communication between nodes  12   a - f  in the ring  10  is preserved. The state machine  24   a  may also perform additional actions related to the implementation of the ring protection protocol. 
     However, since both the west port  18   a  and the east port  18   b  are maintained by the line card  20   a , a failure at the line card  20   a  results in a complete failure of the node  12   d - 1 . As discussed above, any traffic from the ring  10  to client nodes  12  external to the ring  10  that passes through the ring node  12   d - 1  will be stymied, as will any traffic from the external, client nodes  12  to the ring  10  because the ring node  12   d - 1  no longer has a port  18  connected to the ring. Additionally, all ring protection protocol functions implemented by the state machine  24   a  will be lost with the line card  20   a  on which the state machine  24   a  is implemented. Therefore, additional measures are desirable to achieve node-level redundancy. 
     Referring to  FIG. 2 b   , a redundant ring node  12   d - 2  capable of node-level redundancy is depicted. The ring node  12   d - 2  may include two line cards  20   b ,  20   c , as opposed to the single line card in  FIG. 2 a   . The first line card  20   b  and the second line card  20   c  may be used to implement the ring node  12   d - 2 . The first line card  20   b  may include a first front port  22   c  and a first state machine  24   b . Similarly, the second line card  20   d  may include a second front port  22   d  and a second state machine  24   c . The depiction of two line cards  20  and two state machines  24  does not limit the principles discussed herein from being applied to ring nodes  12  with greater numbers of line cards and/or state machines  24 , as indicated by the use of such terms as multiple state machines. 
     Additionally, each ring port  18   c ,  18   d  may be maintained by a separate line card  20   b ,  20   c . Thus, the first front port  22   c  of the first line card  20   b  may serve as the first ring port  18   c . Similarly, the second front port  22   d  of the second line card  20   c  may serve as the second ring port  18   d . In  FIG. 2 b   , the first line card  20   b , first front port  22   c , and first state machine  24   b  may be associated with the west port  18   a , and the second line card  20   c , second front port  22   d , and second state machine  24   c  may be associated with the east port  18   b . However, these assignments may be reversed for purposes of interpreting the claims. 
     The first state machine  24   b  and/or the second state machine  24   c  may implement state machines consistent with a ring protection protocol, such as an ERP protocol. Since a separate line card  20   b / 20   c  maintains each of the individual ports  18   c / 18   d , if one of the two line cards  20   b ,  20   c  goes dark, or fails, in part or entirely, traffic on the ring  10  may be redirected to the ring node  12   d - 2  through the remaining line card  20   b / 20   c . Additionally, if one of the two line cards  20   b ,  20   c  fails, even if the failure only shuts down the corresponding state machine  24   b / 24   c  on that line card  20   b / 20   c , a second, redundant state machine  24   b / 24   c  survives to allow the ring node  12   d - 2  to continue to participate in the implementation of the ring protection protocol. As discussed with respect to  FIG. 3  below, this redundancy not only provides node-level redundancy in terms of the ring node&#39;s participation in the ring  10 , but also in terms of the connections between the ring  10  and external client nodes  12   g - k  through the ring node  12   d - 2 . 
     Referring to  FIG. 3 , a ring architecture  10  is depicted with a ring node  12   d - 2  implemented using redundant line cards  20   b ,  20   c  and redundant state machines  24   b ,  24   c  similar to the ring node  12   d - 2  depicted in  FIG. 2 b   . However, one of the line cards  20   c  has gone dark, or failed  26 , causing the east ring port  18   d  to fail. Consequently, the fourth link  14   d  between the fourth line card  12   d  and the fifth line card  12   e  goes down  28 . 
     In accordance with the ring protection protocol, the fourth ring node  12   d  and/or the fifth ring node  12   e  may send out a failure message  30   a ,  30   b  over the third link  14   c  and/or the fifth link  14   e . The failure message(s)  30   a ,  30   b  may be relayed to an ORPL node  12   a  and/or RPL-neighbor node  12   b  which can respond to the failure message(s)  30   a ,  30   b  by unblocking  32   a ,  32   b  the RPL  14   a . In some, but not necessarily all, examples, the unblocking  32   a ,  32   b  of the RPL  14   a  may be coordinated by an ORPL node  12   a . In examples where the ring  10  implements a ring protection protocol consistent with the ring Ethernet protection switching protocol(s) defined by ITU-T G.8032, the failure message(s)  30   a ,  30   b  may be one or more Ring-Automatic Protection Switching (R-APS) Signal Failure (SF) messages, or R-APS(SF) messages. In some examples, the failure message(s)  30   a ,  30   b  may be repeated periodically while the fourth link  14   d  remains down. 
     Although the directions in which traffic is sent from the various nodes  12   a - f  in the ring  10  may change once the RPL  14   a  is unblocked  32 , any node  12   a - f  in the ring  10  may communicate with any other node  12   a - f  in the ring  10  despite the failure  28  that makes the fourth link  14   d  unusable. Furthermore, the additional line card  20   b  used to maintain the west ring port  18   c  may allow traffic to continue between the ring  10  and external client nodes  12   m - 12   p  with additional links  14   m - p  to the ring node  12   d - 2  at which one of the line cards  20   c  has gone dark  26 . 
     For example, traffic previously passing through a ring port  18   c  of the ring node  12   d - 2  maintained by a failed line card  20   c  may be redirected to pass through a remaining ring port  18   c  of the two ring ports  18   b ,  18   c  defined for the ring node  12   d - 2 . The remaining ring port  18   c  may be maintained by the surviving line card  20   b . The redirected traffic may then pass across the backplane of the ring node  12   d - 2  and out one or more additional front ports of the ring node  12   d - 2  to one or more client nodes  12   m - p  external to the ring of nodes  12   a - f  to which the ring node  12   d - 2  pertains. 
     Although the failure  26  at one line card  20   c  may have resulted in the loss of one state machine  24   c , the surviving state machine  24   b  may insure that the ring node  12   d - 2  and the traffic surviving thereon proceeds under ring protection control provided by the surviving state machine  24   b  residing on the surviving line card  20   b . As can be appreciated, traffic may also flow from one or more external client nodes  12   m - p  to the ring  10  across the ring node  12   d - 2  in the opposite direction. As can also be appreciated, the discussions about a failure  26  at a line card  20   c  maintaining the east ring port  18   d  are equally applicable to a scenario where the failure  26  occurs at a line card  20   b  maintaining the west ring port  18   c.    
     Hence, by including a separate state machine  24  for each ring port  18  with a separate state machine  24 , node-level redundancy may be achieved for traffic at the node  12   d - 2  and ring-protection-protocol controls at that line card  20 . Additional details about how traffic may be passed from a surviving ring port  18   c  to one or more external client nodes  12   m - p  is provided with respect to  FIG. 4 . Additionally, with respect to  FIG. 4  a consideration begins of approaches to addressing the implications of introducing a second state machine  24  to a single ring node  12   d - 2 . 
     Referring to  FIG. 4 , a ring node  12   d - 2  is depicted with multiple line cards  20   b - n  and a backplane  34 . The backplane  34  may provide communication infrastructure between multiple line cards  20   b - 20   n  residing at the ring node  12   d - 2 . By way of example and not limitation, a backplane  34  may be switch fabric. However, any number of technologies for supporting communications between line cards  20  are possible. Where the backplane  34  comprises a switch fabric, the switch fabric may be implemented with any number of switch-fabric architectures, from a crossbar, switch-fabric architecture to a shared-memory, switch-fabric architecture. Although  FIG. 4  depicts ten line cards  20   b - n , as can be appreciated, any number of line cards  20  are possible. Also, although the backplane  34  in  FIG. 4  shows interconnections between all line cards  20   b - n , in some examples, the backplane may support communications for a subset of the line cards  20 . 
     As with  FIG. 2 b   , the ring node  12   d - 2  may include a first state machine  24   b  residing on a first line card  20   b , or infrastructure  20   b , maintaining a first ring port  18   c , of two ring ports  18  defined for a layer-two, ring-protection protocol, in terms of a first front port  22   c  on that first line card  20   b . Also, the ring node  12   d - 2  may include a second state machine  24   c  residing on a second line card  20   c , or infrastructure  20   c , maintaining the second ring port  18   d  in terms of a second front port  22   d  on that second line card  20   c . As depicted in  FIG. 4 , one or more additional line cards  20   d - n  may also reside at the ring node  12   d - 2 . These additional line cards  20   d - n  may have one or more additional front ports  22   d - f  linked to one or more client nodes  12   m - p  outside of the ring to which the ring node  12   d - 2  belongs. As can be appreciated, a switch-fabric, or switch-fabric like implementation of the backplane may allow any of the line cards  20   b - n  residing on the ring node  12   d - 2  to carry linked state machines  24 . 
     The one or more additional front ports  22   d - f  may be communicatively coupled to both the first line card  20   b  and the second line card  20   c  over the backlink  34 . Because the backplane  34  can facilitate communication between either the line card  20   b  maintaining the west ring port  18   b  and/or the line card  20   c  maintaining the east ring port  18   c  and the additional line cards  20   h ,  20   k  port  18   b  and the additional front ports  22   d - f  linked to client node(s)  12   m - p  outside of the ring  10 , traffic to and from these client nodes  12   m - p  may be maintained if a line card  20  maintaining one ring port  18  is lost. Additionally, although not depicted in  FIG. 4 , any line card  20  with front ports  22  serving as both a ring port  18  and a port  22  connected to client nodes  12  external to the ring  10  may continue to facilitate traffic with the external, client nodes  12  even when the other line card  20  connected to the other ring port  18  fails. In other words, one or more additional ports  22   d - f  may be communicatively coupled to the first ring port  18   c  and/or the second ring port  18   d  over the backplane  34  and also linked to one or more client nodes  12   m - p  outside of the ring  10  of nodes  12   a - f  participating in the layer-two, ring-protection protocol. 
     Also, including multiple state machines  24  on different line cards  20  at a single node  12  may insure that the node  12  may still be relied upon to implement a ring protection protocol for the ring  10  in which the ring node  12  participates after one state machine  24  fails with the line card  20  on which it resides. However, inasmuch as ring protection protocols rely on state machines  24  implemented at individual nodes  12   a - f  to coordinate and implement ring protection protocols, including multiple state machines  24   b ,  24   c  at a single node  12   d - 2  may result in complications for the ring protection protocol. Furthermore, nodes  12   c ,  12   e  adjacent to the node  12   d - 2  operating the two state machines  24   b ,  24   b , especially if the nodes  12   c ,  12   e  originate with some other party, may interact with that ring node  12   d - 2  as though that ring node  12   d - 2  ran a single state machine  24 , which may result in problems, such as, for example, the possibility of loop generation. 
     Referring to  FIG. 5 , a ring node  12   d - 2  is depicted that, at the physical plane  36 , implements multiple state machines  24   b ,  24   c , which, at the management plane  38 , may be conflated to a single common, or virtual, state machine  40 . An inter-card communication link  42 , or intra-node link  42 , may be implemented over the backplane  34  between a first virtual port  44   a  at the first line card  20   b  and a second virtual port  44   b  at the second line card  20   c . The intra-node link  42 , supported by the backplane  34 , may be designed to provide a unit of state information to the first state machine  24   b  and the second state machine  24   c  so that the first state machine  24   b  and the second state machine  24   c  can maintain a common state. 
     By synchronizing the state of the multiple state machines  24   b ,  24   c  over the backplane  34 , the multiple state machines  24   b ,  24   c  may logically be conflated to a single, common, virtual state machine  40 . Because the multiple state machines  24   b ,  24   c  may logically be conflated, they may become transparent at the management plane  38 . Therefore, a network administrator  46  may be provided with an interface to deal with the ring node  12   d - 2  with multiple state machines  24   b ,  24   c  in the same way as other nodes  12   a - c ,  12   e - f  in the ring  10 , without any additional rules or considerations. 
     Furthermore, because the multiple state machines  24   b ,  24   c  may become transparent to other nodes  12 , including adjacent nodes  12   c ,  12   e , in the ring  10 , other nodes  12  may interact with the ring node  12   d - 2  without making provision for additional considerations. Therefore, one or more of the adjacent nodes  12   c ,  12   e , may be legacy or third-party devices as long as the adjacent nodes  12   c ,  12   e  also implement the ring protection protocol of the ring  10 . Additional details about implementation of a virtual port  44  are discussed with respect to the following figure, together with modules that may be used to synchronize multiple state machines  24  and avoid potential loops that the multiple state machines  24  may engender. 
     Referring to  FIG. 6 , a line card  20  with a front port  22  and a virtual port  44  is depicted. The front port  22  and the virtual port  44  can be connected one to another by switch infrastructure  48 . The switching infrastructure  48  may perform the switching functions for the line card  20 . By way of example, such operations, which may also be understood in terms of functions, may include interfacing with the network, interfacing with the backplane  34 , or switch fabric, packet processing, and/or traffic management. 
     Receiving and transmitting messages, such as R-APS messages, used to coordinate the implementation of a ring protection protocol within a data-layer network may be accomplished with a network interface  50  for one or more front ports  22  and/or a fabric interface  52  for one or more virtual ports  44 . Message, packet, and/or frame, processing may be accomplished, in some embodiments, by means of a separate ingress processor  54  and egress processor  56 , which may further be subdivided in terms of transmit and receive operations. The ingress processor  54  may inspect a message as it would data packets/frames and determine a destination MAC address of the message. 
     The egress processor  56  may encapsulate a message generated at the line card  20  for distribution. Either the ingress processor  54 , the egress processor  56 , or both may be associated with a buffer. The switching infrastructure  48  may include a traffic manager  58  to direct a message. The traffic manager  58  may include memory storing a database  60 , or switch database  60 , with learned entries associating different destination MAC addresses with different ports. The database, or switch database  60 , with learned entries may store a switch table, MAC table, Content Addressable Memory (CAM) table, or the like. Additionally, the traffic manager  58  may include one or more counters/timers  62  and a scheduler, used to schedule placement of messages on different ports through the network interface  50  and/or the fabric interface  52 . The switch infrastructure  48  may be implemented on multiple chips or on a single chip. 
     Additionally, the line card  20  may include a Central Processing Unit (CPU)  70 , a bus  72 , such as a Peripheral Component Interconnect Express (PCIe) bus, and a switch protection module  74 . The switch protection module  74  may provide infrastructure to implement a ring protection protocol. The functions involved in implementing such a ring protection module may be handled by one or more subsets of modules. With respect to the modules discussed herein, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium. 
     With respect to software aspects, any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. In selected embodiments, a computer-readable medium may comprise any non-transitory medium that may contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
     Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. Aspects of the switch protection module  74 , and possibly all of the switch protection module  74 , that are implemented with software may be executed on the CPU  70 . Any hardware aspects of the switch protection module  74  may be implemented to interact directly with the switch protection module  74  and/or ports  22 ,  44 . 
     In some examples, the switch protection module  74  may include a state machine  24 . In certain examples, the state machine  24  may subsume the switch protection module  74 . In other examples, the switch protection module  74  may embody additional functionalities and or modules. In addition to, or as a part of, the functionalities and/or modules set forth in different ring protection protocols, such as ITU-T G.8032, a state machine  24  and/or a switch protection module  74  may include an update module  76 , and internal-blocking module  78 , a messaging module  80 , a master module  82 , a slave module  84 , and/or a preservation module  86 . Depending on the ring protection protocol, any of the modules may be considered as belonging to a state machine  24 , outside the state machine  24  while within a switch protection module  74 , or partially within a state machine  24  and partially outside a state machine  24 , but within the switch protection module  74 . The switch protection module  74  may also include a monitoring module  88  and/or a forwarding module  90 , which also may be considered as belonging in whole or in part to a state machine  24 . In some examples, a forwarding module  90  may be implemented entirely by the switch infrastructure  48 . 
     As discussed in greater detail below, a master module  82  may be mutually exclusive of a slave module  84  for a single state machine  24 , switch protection module  74 , and/or line card  20  and vice versa. A master module  82  may address, perform, or coordinate a set of master-role actions  82  explained below by itself or with other modules and/or functionalities. Similarly, a slave module  84  may address, perform, or coordinate a set of slave-role actions  84  explained below by itself or with other modules and/or functionalities. Examples of ways in which master  82  or slave modules  84 , together with additional modules discussed above may be used to make multiple state machines  24  transparent and prevent potential loops that the multiple state machines  24  might generate are discussed with respect to the following figures. 
     Referring to  FIG. 7 , a series of interactions are depicted between a pair of slots  92   a ,  92   b  at a ring node  12   d - 2  to (1) synchronize multiple state machines  24  over an inter-card/intra-node link  42   a . The interactions may also facilitate a (2) response to a failure  100  on the inter-card link  42   a , coordinating the unblocking  32  of an RPL  14   a , and may (3) prevent a loop from forming upon repair/recovery  108  of the inter-card link  42   a  until the RPL  14   a  can be blocked  16  again. Although these interactions are presented sequentially, there may be variations in the order of some actions. 
     A ring node  12   d - 2  may include a physical chassis with multiple slots  92 , where a slot may receive a line card  20 , or control card, for integration into the implementation of the node  12   d - 2 . Each slot  92  may be assigned a letter or number value. For example, a chassis may have sixteen slots  92  (any number of two or more slots  92  are possible) with two slots  92  reserved for control cards and fourteen slots  92  reserved for line cards  20 . Slot m  92   a  and slot n  92   b , as depicted in  FIG. 7 , may correspond to a thirteenth and a fourteenth slot respectively. A line card  20   b  received by slot m  92   a  may have a first front port  22   c  and a first virtual port  44   a . Similarly, another line card  20   c  received by slot n  92   n  may have a second front port  22   d  and a second virtual port  44   b.    
     As discussed with respect to  FIG. 5 , an inter-card/intra-node link  42   a  may be established between the first virtual port  44   a  and the second virtual port  44   b  over the backlink  34 . To synchronize multiple state machines  24 , a first update module  76   a  of a first state machine  24   b  of a first line card  20   b  may be operable to update the first state machine  24   b  to an updated state based on a unit of state information. Also, a second update module  76   b  of a second state machine  24   c  at a second line card  20   c  may be operable to update the second state machine  24   c  to the updated state based on the same unit of state information. The unit of state information may be provided to the two state machines  24   b ,  24   c  over the intra-node link  42   a . In some examples, the unit of state information may be defined by a proprietary protocol. However, in other examples, the unit of state information may be part of a pre-existing ring protection protocol. 
     In certain examples, the unit of state information may be a state message  94 , such as, without limitation, any of the R-APS messages defined for ITU-T G.3082. In such examples, a state message  94  may arrive at the first ring port  18   c . In response to the state message  94 , a first update module  76   a  of the first state machine  24   b  may update  96  the first state machine  24   b  according to the ring protection protocol implemented by the ring  10 . 
     A forwarding module  90   a  residing on the first line card  20   b , which may, but need not necessarily, be the switch infrastructure  48   a , may forward the state message  94 . The state message  94  may be forwarded from the first front port  22   b  to the first virtual port  44   a  via the switch infrastructure  48  from the network interface  50  to the fabric interface  52  in a manner similar to any other frame/packet whose route involves the switch fabric  34 . The forwarding module  90   a  may forward the state message  94  through the first virtual port  44   a  and over the inter-card communication link  42   a  supported by the backplane  34  to the second state machine  24   c  residing on the second line card  20   c.    
     To synchronize the first and second state machines  24   b ,  24   c , the second update module  76   b  of the second state machine  24   c  may be designed to respond to the state message  94  received at the second virtual port  44   b  according to the ring protection protocol as though the state message  94  were received at the second ring port  22   d . By responding to the state message  94  in this way, the second update module  76   b  may update  98  the second state machine  24   c  to the updated state. As a result, the first state machine  24   b  and the second state machine  24   c  may share a common state for the ring node  12   d - 2 . 
     Another forwarding module  90   b  and/or switch infrastructure  48   b  at the second line card  20   c  may then forward the state message  94  to the front port  22   d  of the second line card  20   c  serving as a ring port  18   d . The state message may then be forwarded to the next node  12   e  to facilitate the coordinated implementation of the ring protection protocol as if the ring node  12   d - 2  with multiple state machines  24   b ,  24   c , was a ring node  12   d - 1  with one state machine  24   a.    
     Synchronizing multiple state machines  24  over an inter-card communication link  42  with state messages  94  used to coordinate a ring protection protocol across multiple nodes  12   a - f  may lead to complications. For example, if there is a failure  100  of the inter-card communication link  42   a , state messages  94 , and other traffic can no longer be relayed across the ring node  12   d - 2 . To address such a failure  100 , a response may be required. 
     One or more monitoring modules  88  may monitor the inter-card communication link  42  from the first virtual port  44   a  of the first line card  20   b  over the backplane  34  to the second virtual port  44   b  of the second line card  20   c  for a failure  100 . A monitoring module  88  may employ Continuity Check Messages (CCM), virtual port failure reports, and or other approaches to detect a failure somewhere along the inter-card communication link  42   a.    
     In response to a failure  100  of the inter-card communication link  42   a , as detected by a monitoring module  88 , one or more internal-port blocking modules  78   a ,  78   b  for the first state machine  24   b  and/or the second state machine  24   c  may block  102 ,  104  a corresponding virtual port  44 , the first virtual port  44   a  where an internal-port blocking module  78   a  belongs to the first state machine  24   b  and the second virtual port  44   b  where an internal-port blocking module  78   b  belongs to the second state machine  24   c . Also, in response to the failure  100 , the first update module  76   a  and the second update module  76   b  may, respectively update the first state machine  24   b  and the second state machine  24   c  from an idle state to a new common state reflecting the failure  100 . 
     After closing  102 ,  104  the first virtual port  44   a  and/or the second virtual port  44   b  in response to the failure  100 , one or more messaging modules  80   a ,  80   b  may send one or more failure messages  106   a ,  106   b . A messaging module  80   a ,  80   b  on the first line card  20   b  and/or the second line card  20   c  may generate and send a failure message  106   a ,  106   b  out at least one of the two ring ports  18   c ,  18   d  of the ring node  12   d - 2 . Such a failure message  106  may indicate a need to open  32  an RPL  14   a  blocked  16  to prevent a loop in a ring  10  of nodes  12   a - f  to which the ring node  12   d - 2  pertains. 
     A failure message  106  may be a message defined by the ring protection protocol to respond to a failure at a link  14  maintained between ring ports  18  of adjacent ring nodes  12  within a ring  10  defined by the ring protection protocol. For example, in examples where the ring protection protocol is consistent with ITU-T G.3082, a failure message  106  may be an R-APS Signal Fail (SF) message, R-APS(SF) message. Although directions of traffic may need to be altered, once the RPL  14   a  is unblocked  32 , traffic can reach the various nodes  12   a - f  in the ring  10  despite the failure  100 . 
     With the repair, or recovery  108 , of the inter-card link  42  a potential for a loop may arise while the RPL  14   a  is unblocked  32 . In averting this potential, transparency of the multiple state machines  24  may be achieved by differentiating roles played by the multiple state machines  24  in terms of their preventative actions. Thus, a set of master-role actions  82  may be performed by either the first state machine  24   b  or the second state machine  24   c . Conversely, a set of slave-role actions  84  may be performed by a state machine  24   b / 24   c  not performing the set of master-role actions  82 . The set of master-role actions  82  may be assigned to the first ring-protection-protocol state machine  24   b  or the second ring-protection-protocol state machine  24   c  according to a predetermined convention. 
     For example, the set of master-role actions  82  may be assigned to a state machine  24  associated with the highest slot value. Along these lines, the set of slave-role actions  84  may be assigned to a state machine  24  with the lowest value. Other conventions are possible, and the foregoing convention may be reversed. As can be appreciated, in examples consistent with  FIG. 7 , slot n  92   b  has the highest value and, therefore, the second state machine  24   c  would be assigned the set of master-role actions  82  according to the first convention. As used herein, the term set can include any number of elements and may include the null set. 
     The set of master-role actions  82  may include blocking  110  a ring port  18   d  corresponding to the state machine  24   c  to which the master-role actions  82  are assigned in response to a recovery  108  of the inter-card communication link  42   b . To prevent a loop while the RPL  14   a  is unblocked  32 , the set of master-role actions  82  may block  110  a front port  22   d  corresponding to a ring port  18   d  before an internal blocking module  78   b  unblocks  112  the corresponding virtual port  22   d  in response to the recovery  108  of the inter-card communication link  42   b.    
     The messaging module  80   b  residing at the line card  20   c  with the state machine  24   c  assigned the set of master-role actions  82  may generate and send a link-up message  114  across the recovered inter-card communication link  42   b  to prompt a state machine  24   b  to unblock  116  a corresponding virtual port  44   a  at a remote end of the inter-card communication link  42   b . In some examples, the messaging module  80   b  may generate the link-up message  114  after the blocking  110  of the corresponding ring port  18   d . By way of example, and not limitation, the messaging module  80   b  may generate the link-up message  114  by setting a Type, Length, and Value (TLV) option field of a CCM message to a predefined value. In response to the link-up message  114 , an internal-port blocking module  78   a , residing at the line card  20   b  with the state machine  24   b  assigned the set of slave-role actions  84 , may unblock  116  the corresponding virtual port  44   a.    
     To return the ring  10  to a normal posture with its backup redundancy, in response to the recovery  108  of the inter-card communication link  14   b , a messaging module  80   a  of the first state machine  24   b  and/or a messaging module  80   b  of the second state machine  24   c  may send a recovery message  118   a ,  118   b  out the first font port  22   c  serving as a first ring port  18   c  and/or the second front port  22   d  serving as the second ring port  18   d  respectively. A recovery message  118  may be defined by the ring protection protocol to respond to a recovery of a link  14  maintained between ring ports  18  of adjacent ring nodes  12   a - f . For example, in examples where the ring protection protocol is consistent with ITU-T G.3082, the recovery message  106  may be an R-APS No Request (NR) message, R-APS(NR) message. 
     According to the ring protection protocol implemented by the ring  10 , the RPL  14   a  may be blocked  16  in response to one or more recovery messages  118 . However, to prevent a loop, an indication  120  that the RPL has been blocked  16  may be required before the switch protection module  74   b /state machine  24   c  assigned the set of master-role actions  82  unblocks  122  the front port  22   d  serving as the corresponding ring port  18   d . Furthermore, the indication  120  may vary depending on a previously assigned ring-level role of the ring node  12   d - 2 . 
     For example, where the ring protection protocol assigns responsibility for maintaining an RPL  14   a  to the ring node  12   d - 2  as owner node (ORPL), as defined by the ring protection protocol for the protection ring  10  to which the ring node  12   d - 2  belongs, the switch protection module  74   b /state machine  24   c  may wait for a restore clock  120   a  to expire. By way of example and not limitation, in some examples consistent with the ring protection protocol defined by ITU-T G.3082, the restore clock  120   a  may be a Wait To Restore (WTR) clock. After restoration of the restore clock  120   a , in accordance with the master-role actions  82   b , the switch protection protocol  74   b /state machine  24   c  may unblock  122  the ring port  18   d  maintained by the line card  20   c  carrying the ring-protection-protocol state machine  24   c  assigned the set of master-role actions  82   a.    
     Conversely, where the ring protection protocol assigns responsibility for maintaining an RPL  14   a  for a ring  10  to which the ring node  12   d - 2  belongs to another node  12   a , as ORPL node, apart from the ring node  12   d - 2 , the switch protection protocol  74   b /state machine  24   c  may wait to receive a blocking message, or root-blocked message  120   b , from the o ORPL node  12   a . By way of example and not limitation, in some examples consistent with the ring protection protocol defined by ITU-T G.3082, the blocking message  120   b  may be an R-APS Root Blocked (RB) message, R-APS (RB) message. After receiving the blocking message  120   b , in accordance with the master-role actions  82   b , the switch protection protocol  74   b /state machine  24   c  may unblock  122  the ring port  18   d  maintained by the line card  20   c  carrying the ring-protection-protocol state machine  24   c  assigned the set of master-role actions  82   a.    
     Once the ring port  18   d  is unblocked  122 , the first update module  76   a  and the second update module  76   b  may, respectively, update the first state machine  24   b  and the second state machine  24   c  from their previous common state back to a shared idle state. Hence, by waiting on an indication  120  that the ORPL node  12   d - 2 / 12   a  has blocked the RPL  14   a  before unblocking  122  the ring port  18   d , another opportunity for a loop can be avoided. The following figure provides a brief overview of ways in which loops may be avoided where a ring node  12   d - 2  is implemented with multiple state machines  24 . 
     Referring to  FIG. 8 , a ring protection system  10  progresses through various stages  10   a - c  to prevent various potential loops. In a first state  10   a , the ring protection system  10  is depicted with the RPL  14   a  blocked  16 , when a first event (1) occurs, namely a failure at  100  at an inter-card communication link  42  at a ring node  12   d - 2  that may be implementing multiple state machines  24  and may be utilizing the inter-card communication link  42  to transparently synchronize the multiple state machines  24 . The ring protection system  10  may then progress to a second stage  10   b  at which the OPRL node  12   a  and/or the neighbor node  12   b  may have (2) unblocked  32  the RPL  14   a , potentially in response to one or more failure messages  106 , such that all links  12   a - f  in the ring can be accessed despite the failure  100 . 
     However, at the second stage  10   b , the inter-card communication link  42  may also (3) have been repaired  108 , and in accordance with the set of master-role actions  82 , the corresponding ring port  18   d  may (4) have been blocked  110  to prevent a loop. In the third stage  10   c , potentially in response to one or more recovery messages  118 , the OPRL node  12   a  and/or the neighbor node  12   b  may have (5) blocked  16  the RPL  14   a . Nevertheless, the switch protection protocol  74   b /state machine  24   c  implementing the set of master-role actions  82   b  may wait to (6) unblock  122  the ring port  18   d  until it has received an indication  120  from the ORPL node  12   a  that the RPL  14   a  has been blocked  16  to avoid the potential for a loop. 
     The flowcharts in  FIGS. 9 and 10  illustrate the architecture, functionality, and/or operation of possible implementations of systems, methods, and computer program products according to certain embodiments of the present invention. In this regard, each block in the flowcharts may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It will also be noted that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. 
     Where computer program instructions are involved, these computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block-diagram block or blocks. 
     These computer program instructions may also be stored in a computer readable medium that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block-diagram block or blocks. 
     The computer program may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operation steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block-diagram block or blocks. 
     It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. In certain embodiments, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Alternatively, certain steps or functions may be omitted if not needed. 
     Referring to  FIG. 9 , a method  200  is depicted for determining whether to respond to a state message  94 . In some ring protection protocols, messages  94  with a node identification value matching that of a line card  20  receiving the message  94 , indicating that they may have completed their circuit of the ring  10  back to their origin, may be discarded. However, in an environment where the two ports  18   c ,  18   d  of a ring node  12   d - 2  are maintained by two line cards  20   b ,  20   c , those line cards  20   b ,  20   c  may share a common node identification value to assist in making them transparent. Therefore, the presence of a common node identification value may occur from a paired line card  20   b / 20   c  and may be important to synchronizing the pair of line cards  20   b ,  20   c , as opposed to an indication that a message  94  has run its course. Therefore, the method  200  provides some examples of how a determination to respond to a message  94  in such an environment may be made. 
     The method  200 , which may be implemented with a preservation module  86 , may include receiving  200  a message  94 . A determination  204  may be made as to whether the message  94  has the same node identification value as the line card  20  receiving the message  94 . If the answer is NO, an update module  76  may make a determination  210  as to whether an update to the state machine  24  is required in light of the message  94 . 
     Conversely, if the answer is YES, the message  94  is a matched message  94 , which may be defined as a message  94  carrying a node identification value assigned to a node  12  providing the message  94  that matches a node identification value assigned to the line card  20  receiving the message  94 . For a matched message  94 , a determination  206  may be made as to whether the message  94  was received from a corresponding virtual port  44 . If the answer is NO, the message  94  may be discarded  208 . In other words, if a matched message  94  arrives at the corresponding ring port  18 , the preservation module  86  may allow the matched message  94  to be discarded  208  without a response from the state machine  24 . 
     However, if the answer to the determination  206  is YES, the method  200  may proceed to the determination  210  as to whether an update to the state machine  24  is required in light of the message  94 . Regardless of the scenario under which the determination  210  is reached as to whether an update is required, the method  200  may  212  update the state machine  24  if the answer is YES. If the answer is NO, the method  200  may forward  214  the message  94 . In other words, the preservation module  86  may preserve the matched message  94  received at the virtual port  44  so that the update module  76  of the corresponding state machine  24  may determine whether  210  whether to update  212  the state machine  24  in response to the matched message  94 . 
     Referring to  FIG. 10 , a method  300  is depicted that (1) responds to a failure  100  on a link  42  that may be utilized to synchronize multiple state machines  24  residing at a common ring node  12 . The method  300  may also (2) prevent one or more loops after the previously failed link  42  is recovered  108 . The method  300  may include detecting  302  a failure  100  on the inter-card link  42  and blocking  304  one or more virtual ports  44  on either end of the link  42  in response. Additionally, the method  300  may involve sending  306  one or more signal failure messages  106  to coordinate implementation of the ring protection protocol within the corresponding ring  10 . 
     After monitoring the failed inter-card communication link  42 , which may be performed in some examples, from a first virtual port  44   a  of the first line card  24   b  over the backplane  34  to the second virtual port  44   b  of the second line card  20   b  for a recovery  108 , a determination  308  may be made as to whether a recovery  108  may have occurred. If the answer is NO, the method  300  may return to sending  306  one or more fail messages  106  then, once again, to the recovery determination  308 . If the answer is YES, the method  300  may proceed to a determination  310  as to whether or not the method  300  is being implemented on a slot  92  at which the set of master-role actions  82  has been assigned. 
     If the answer is NO, the method may wait to receive  312  a link-up message  114 . Upon receiving the link-up message  114 , the corresponding virtual port  44  may be unblocked  314 / 116 . If the answer is YES, the method  300  may proceed by blocking  316 / 110  a front port  22  serving as a ring port  18  maintained by the line card  20  with the ring-protection-protocol state machine  24  assigned the set of master-role actions  82  upon detecting the recovery  108 , or shortly thereafter. The blocking  316 / 110  of a ring port  18  in response to a recovery  108  of the intra-node link  42  after a previous failure  100  may belong to the set of master-role actions  82  assigned to a given state machine  24 . 
     After the unblocking  316 / 110  step, the method  300  may proceed by unblocking  318 / 112  a corresponding virtual port  44  and sending  320  the link-up message  114  received  3312  at the other paired line card  20  at step  312 . A status, or recovery, message  118  may also be sent  322  to prompt a re-blocking  16  of the RPL  14   a . A determination  324  can also be made as to whether an indication  120  of re-blocking  16  obtains, which may be expiration of a restoration timer  120   a  where the method  300  is implemented on an ORPL node  12  and which may be the reception of a root-block message  120   b  where the method  300  is not. 
     If the answer is NO, the method  300  may circle back to sending  322  the status/recovery message  118  and to the RPL-indication determination  324 . If the answer is YES, the method  300  may proceed to unblocking  326 / 122  the front port  22  serving as a ring port  18 , responding to the indication  120  that the RPL  14   a  for a network ring  10  in which the corresponding state machine  24  participates has been restored  32 . 
     The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative, and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.