Shared network ring protection

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

N/A

BACKGROUND OF THE INVENTION

This application relates to sharing a backup network link, particularly in a telecommunications network.

Telecommunications subscribers and telecommunications carriers generate a wide range of digital signals having a wide range of data rates. To carry this digital traffic, telecommunication carriers typically install high-capacity fiber optic links between switching offices and multiplex this digital traffic onto the fiber optic links. Synchronous Optical Network (SONET) is a standard for data transmission over fiber optic networks. SONET is widely used by telecommunications carriers in the United States while a related standard (Synchronous Digital Hierarchy (SDH)) is used in some other countries. These standards define technologies for carrying many signals of different capacities through hierarchical synchronous optical networks. At the lowest level of such a hierarchy, these standards define transport signals. For example, SONET defines a Synchronous Transport Signal—level 1 (STS-1), which operates at a 51.84 Mbps data rate. Higher-level signals (STS-n) are integer multiples of STS-1. The optical counterpart of an STS-n signal is designated an Optical Carrier N (OC-n).

To provide highly reliable service, telecommunication carriers often create rings that interconnect a number of switching offices or other nodes. Each node is connected to the next node on the ring by an OC-n span. In a typical 4-fiber, bi-directional line switched ring (BLSR), four optical fibers extend between, and therefore interconnect, each pair of adjacent nodes. Each optical fiber provides one channel. Two of the fibers form two oppositely-directed, unidirectional “working” channels, and the remaining two fibers form two oppositely-directed, unidirectional “protect” channels. Each channel can carry traffic in either a clockwise or a counter clockwise direction along the ring from a source node to a destination node. The clockwise-oriented working channels collectively form a clockwise working ring. Similarly, the other channels form respective rings, i.e. a counter-clockwise working ring, a clockwise protect ring and a counter-clockwise protect ring.

The protect channels provide a backup capability, which can be used in case of a failure of a working channel, an entire span or a transit node. The protect channels can be used individually or collectively, depending on the failure. If only a working channel of a span fails, the like-directed (i.e., clockwise or counter-clockwise) protect channel along the same span can be used to take over for the failed working channel. A node (typically the node at the receiving end of an optical fiber) detects failures in the channels that terminate at that node. If the node detects a failure in an adjacent working channel or span, the node sends a command to the node at the opposite end of the failed span or channel (the “far node”) requesting that the far node connect (“bridge”) the appropriate working channel to the appropriate protect channel, thus switching network traffic onto the protect channel. This is referred to as “span switching.” Although only one working channel (clockwise or counterclockwise) in a span might have failed, typically both working channels are switched to their respective protect channels. This is commonly referred to as “bi-directional protection switching.”

If an entire span fails, such as a result of a cable cut or a node failure, all the protect channels of the rest of the ring take over for the failed span. In this case, the node that detects the failure requests the far node to bridge each of its working channels to the far node's oppositely-directed protect channel. The node that detects the failure also bridges its working channels to its oppositely-directed protect channels. Thus, the two nodes on opposite sides of the failure loop network traffic from their working channels onto oppositely-directed protect channels. The remaining nodes of the ring enter a pass-through mode, in which they bridge their like-directed protect channels (incoming clockwise protect channel to outgoing clockwise protect channel, etc.). Thus, a continuous path around the ring is restored, albeit a longer path that enters and leaves each of the remaining nodes twice. This is referred to as “ring switching.” Collectively, this self-restoring capability (including span switching and ring switching) is commonly referred to as automatic protection switching (APS).

STS-1 uses a 810-byte transport frame to carry payload and overhead information. The overhead information supports several “channels” (not to be confused with working and protect channels) that are used for operation, administration, maintenance and provisioning (OAM&P) of the network and higher level services. For example, the so-called K1 and K2 bytes provide an automatic protection switching (APS) channel, which enables line-terminating entities (LTEs) to send and receive remote defect indications (RDIs), alarm indication signals (AIS-L) and to implement the automatic protection switching discussed above. For example, nodes of a BLSR ring send commands via the APS channel to request other nodes to perform span switches or ring switches. These “bridge requests” include “forced switch-span” (FS-S) and “forced switch-ring” (FS-R).

Two nodes are said to be “adjacent” if they are connected to each other by a span. Two rings (R1 and R2) are said to be “adjacent” if both rings include two nodes (A and B), and nodes A and B are adjacent to each other on both rings R1 and R2, shown in FIG. 11. (For simplicity, FIG. 11 shows bi-directional links, although each link of a BLSR ring typically consists of two unidirectional channels, each channel carried by a separate optical fiber.)

Although SONET is widely used and robust, it has shortcomings. For example, BLSR rings are required to have a working channel and a protect channel for each direction of network traffic in each span. As noted, in a 4-fiber BLSR ring, each span typically consists of four optical fibers. Thus, in the example of adjacent rings R1 and R2 (above), eight optical fibers extend between nodes A and B, although under normal circumstances four of these optical fibers carry little or no traffic. Some carriers would prefer to use fewer optical fibers between nodes, where adjacent rings overlap. Even in wavelength-division multiplexed (WDM) systems, where several logical channels can share a single optical fiber, half the logical channels carry little or no traffic under normal circumstances. Thus, reducing the number of required logical channels would reduce the required number of optical fibers.

BRIEF SUMMARY OF THE INVENTION

According to one embodiment of the present invention, a shared protect link extends between adjacent nodes that are shared by two or more adjacent BLSR rings. The shared protect link obviates the need for separate protect links between the adjacent nodes for each of the rings. A “composite” BLSR controller resides in each of the adjacent nodes. The composite BLSR controllers coordinate usage of the shared protect link, for example as a result of a span switch or a ring switch request. The composite BLSR controllers also coordinate transmission of signaling information for each of the rings over the common span between the adjacent nodes. In one embodiment, the signaling information is sent over separate channels of the common span. In another embodiment, the signaling information is multiplexed over the shared protect link. The composite BLSR controller can include a standard BLSR controller for each of the adjacent rings and a translator logically between the standard BLSR controllers and the spans.

In one embodiment, each ring is assigned a unique (within the span) ring ID. The communication protocol between the adjacent nodes is modified to tag the signaling information with the appropriate ring ID. For example, according to one embodiment, each span of the ring network is assigned a unique span ID, and an automatic protection switching (APS) message sent between nodes of the network refers to the span ID of an implicated span, rather than referring to the message's source node ID and destination node ID. The span ID occupies fewer bits in the message than a combination of the source node ID and the destination node ID. Consequently, the messages can accommodate the ring ID.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

These and other features, advantages, aspects and embodiments of the present invention will become more apparent to those skilled in the art from the following detailed description of an embodiment of the present invention when taken with reference to the accompanying drawings, in which:

FIG. 1 is a simplified schematic diagram of an exemplary ring network;

FIG. 2 is schematic diagram of K1 and K2 bytes in an automatic protection switching protocol message, according to the prior art;

FIG. 3 is a list of bridge requests codes, according to the prior art;

FIG. 4 is schematic diagram of K1 and K2 bytes, according to an embodiment of the present invention;

FIG. 5 is an exemplary list of additional bridge requests codes, according to an embodiment of the present invention;

FIG. 6 is a block diagram of a BLSR controller, according to an embodiment of the present invention;

FIG. 7 is an exemplary ring map, according to an embodiment of the present invention;

FIG. 8 is a simplified flowchart illustrating operations performed by a BLSR controller, according to an embodiment of the present invention;

FIG. 9 is a simplified flowchart illustrating other operations performed by a BLSR controller, according to an embodiment of the present invention;

FIG. 10 is a block diagram of a BLSR controller, according to another embodiment of the present invention;

FIG. 11 is a simplified schematic diagram of an exemplary ring network that includes two adjacent rings, according to the prior art;

FIG. 12 is a simplified schematic diagram of an exemplary ring network that includes two adjacent rings, according to an embodiment of the present invention;

FIG. 13 is schematic diagram of K1 and K2 bytes, according to another embodiment of the present invention;

FIG. 14 is a block diagram of a BLSR controller, according to another embodiment of the present invention;

FIG. 15 is a simplified schematic diagram of an exemplary ring network that includes three adjacent rings, according to an embodiment of the present invention;

FIG. 16 is a simplified schematic diagram of another exemplary ring network that includes three adjacent rings, according to an embodiment of the present invention;

FIG. 17 is a simplified schematic diagram of an exemplary ring network that includes two adjacent rings with two common spans, according to an embodiment of the present invention;

FIG. 18 is a simplified schematic diagram of an exemplary ring network that includes two adjacent rings with two adjacent spans, according to an embodiment of the present invention; and

FIG. 19 is a block diagram of a BLSR controller, according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

This contents of Provisional Patent Application No. 60/485,543, filed Jul. 8, 2003 and titled “Bidirectional Line Switched Ring Employing Straddling Span Protection and Protocol” are hereby incorporated by reference herein.

Telecommunications carriers and other industries often use optical fibers to carry digital data. These optical fibers are often used to interconnect nodes of a network. To improve the ability of these networks to provide data transport in case of a link or node failure, ring topologies and automatic protection switching (APS) are often employed. FIG. 1 illustrates an exemplary 4-fiber bi-directional line-switched ring (BLSR) 100, in which the present invention can be practiced. The invention can also be practiced in other network architectures, such as 2-fiber networks, mesh networks, etc., as will be evident to those of ordinary skill in the art.

The BLSR ring 100 includes nodes A, B, C, D and E. These nodes are interconnected by spans T, U, V, W and X of optical fiber cable. Each span T-X consists of four optical fibers, such as optical fibers 102, 104, 106 and 108. Each optical fiber carries data in one direction, as indicated by arrowheads on the optical fibers 102-108. (In other applicable architectures, optical fibers carrying bi-directional data can be employed.) Each of these optical fibers provides a channel, over which data can be sent. Two oppositely-directed channels of each span are designated “working” channels, and the other two oppositely-directed channels of each span are designated “protect” channels.

In case of a failure of a working channel, an entire span or a node, data can be switched from one or more working channels to one more protect channels, as is well-known in the art. (See, for example, SONET Bi-directional Line-Switched Ring Equipment Generic Criteria, GR-1230-CORE, Issue 4, Bellcore, December, 1998.) For example, if a node detects a loss of signal (LOS), loss of frame (LOF), a line bit error rate (BER) that exceeds a predetermined threshold, an alarm indication signal (AIS) or another protectable hard failure, the node can send a signal fail-span (SF-S) message (bridge request) to initiate a span switch from the failed working channel to the span's like-directed protect channel. Similarly, if a node or an entire span fails, the node that detects the failure can send a signal fail-ring (SF-R) message to initiate a ring switch.

The bridge requests are sent over K1 and K2 bytes of an automatic protection switching (APS) channel, as is well-known. FIG. 2 illustrates the bit definitions of the K1 and K2 bytes, according to the prior art. Bits 1-4 in K1 encode the bridge request. Since the bridge request field is four bits wide, only 16 unique bridge requests can be defined. FIG. 3 illustrates the prior art definitions of the bridge request codes. Bridge requests have respective implicit priorities, which are used to arbitrate among competing bridge requests in case of multiple concurrent failures in a ring. For example, signal fail-span (SF-S) has a higher priority than signal fail-ring (SF-R). Thus, if a working channel in one span fails, switching its traffic to its corresponding protect channel takes priority over a ring switch, which had previously occurred, for example, as a result of the failure of a different span.

The K2 byte also includes a path bit (bit 5) and a status field (bits 6-8). The path bit indicates whether a bridge request is sent by a source node to a destination node along a short path or along a long path around a ring.

FIG. 2 illustrates the bit definitions of the K1 and K2 bytes, according to the prior art. Bits 1-4 in K1 encode the bridge request. Since the bridge request field is four bits wide, only 16 unique bridge requests can be defined. FIG. 3 illustrates the prior art definitions of the bridge request codes. Bridge requests have respective implicit priorities, which are used to arbitrate among competing bridge requests in case of multiple concurrent failures in a ring. For example, signal fail-span (SF-S) has a higher priority than signal fail-ring (SF-R). Thus, if a working channel in one span fails, switching its traffic to its corresponding protect channel takes priority over a ring switch, which had previously occurred, for example, as a result of the failure of a different span.

The K2 byte also includes a path bit (bit 5) and a status field (bits 6-8). The path bit indicates whether a bridge request is sent by a source nodes to a destination node along a short path or along a long path around a ring.

Each node of a prior-art BLSR ring is provisioned with a node ID. Bits 1-4 in K2 are used to identify the sending node (source node) of a bridge request, and bits 5-8 in K1 are used to identify the intended receiving node (destination node). Since the source node ID and the destination node ID fields in K1 and K2 are each four bits wide, all node IDs must be in the range 0-15. Thus, a BLSR ring according to the prior art can have no more than 16 nodes.

In accordance with the present disclosure, the source and destination node IDs are omitted from the K1 and K2 bytes of a bridge request. Including the source and destination node IDs in the K1 and K2 bytes is needlessly redundant, and therefore wastes bits in the K1 and K2 bytes. Instead of separate source and destination node IDs, the K1 and/or K2 bytes of a bridge request can simply identify the span implicated by the bridge request. Thus, the bridge request lacks an explicit identification of the source and recipient (destination) nodes. Instead of, or in addition to, keeping track of the topology of a network in terms of node IDs, according to an embodiment of the present invention, each node of the network keeps track of the topology in terms of span IDs. In other respects, automatic protection switching, communications among the nodes of a network and other BLSR protocol aspects can remain unchanged.

FIG. 4 shows layouts of the K1 and K2 bytes, according to one embodiment of the present invention. In this embodiment, each span of a network is assigned a span ID between 0 and N. Each node is provisioned with the span IDs of all spans terminating at the node. Typically, each node is also provisioned with information about the other nodes of the network and the span IDs of all spans terminating at each of the other nodes. This and other provisioning (referenced below) can be accomplished by any appropriate mechanism, such as through an operating system (OS), workstation (WS) or other human or automatic interface, as is well known in the art.

When a node sends a bridge request related to a span, the node includes the span's span ID in the K1 and/or K2 bytes. For example, referring back to FIG. 1, if node A detects a signal failure in working channel 106, node A can send a signal fail-span (SF-S) bridge request with the span ID of span X. As noted, node E would have been provisioned with the span IDs (X and W) of the spans that terminate at node E.

When node E receives the bridge request, node E can determine that the bridge request is meant for node E, based on the span ID in the bridge request. Any bridge request that identifies span X can be directed only to node A or to node E, because span X terminates at only nodes A and E. Furthermore, bridge requests can be sent only to adjacent nodes and only concerning spans that terminate at the intended recipient of the bridge request. Thus, a bridge request that identifies span X can be sent by only node A or node E. Since node E did not send the bridge request, node E can unambiguously determine that it must be the intended recipient of the bridge request.

The number of bits in the span ID field of the K1 and/or K2 bytes can be chosen to accommodate the maximum number of nodes that are to be supported in a network. As shown in FIG. 4, the low-order bits of the span ID occupy bits 1-4 of the K2 byte, and the high-order bits of the span ID occupy bits Q to 8 of the K1 byte, where Q is selected to accommodate the maximum number of nodes in the ring. The remaining P bits (where P=Q−1) of the K1 byte are available to store a bridge request code. If four bits are used for the bridge request code (i.e., P=4), eight bits are available for the span ID, thus a span ID of up 255 can be stored in the K1 and K2 bytes, and a network of up to 255 nodes can be supported. All nodes of a network should be provisioned with the value of P (and Q, if P≠Q−1).

If fewer than 128 nodes are to be supported in a network, the span ID field can occupy fewer than eight bits, i.e. Q can be greater than 5. In this case, more than four bits are available for the bridge request field and, consequently, more than sixteen unique bridge request codes can be accommodated in the bridge request field (i.e., bits 1-P of the K1 byte). In one embodiment of the present invention, some or all of the BLSR function requests (such as Clear) that, according to the prior art, must be sent over an out-of-band channel are instead assigned new bridge request codes and can be sent via the K1 byte. FIG. 5 is an exemplary list of new bridge request codes, some or all of which can be added to the prior art list of bridge request codes shown in FIG. 3, depending on the value chosen for P. Additional existing or new BLSR function requests can be added to the list in FIG. 5. Furthermore, the bridge request codes chosen for these functions are a matter of design choice.

The values of P and Q can be chosen to trade off between the number of unique bridge request codes that need to be supported and the number of nodes that need to be supported. If the number of needed bridge request codes and the number of nodes to be supported are such that the bridge request field and the span ID field collectively require fewer than 12 bits, the remaining bits can be used for another purpose, as described in more detail below. In this case, P≠Q−1. That is, a new field is added between the bridge request code and the span ID in K1. Similarly, if the number of needed bridge request codes is less than eight, P can be less than four. Although FIG. 4 shows the high-order bits of the span ID stored in the K1 byte, the placements of the high-order bits and the low-order bits of the span ID can be swapped between the K1 and the K2 bytes. Although not shown in FIG. 4, if more than 255 bridge request codes are required, and fewer than four bits are required to uniquely identify the span IDs, the bridge request field can wrap from the K1 byte onto the K2 byte. Similarly, the placements of other fields in the K1 and K2 bytes are design choices and can be changed without departing from the spirit or scope of the invention. If necessary, the nodes of a network can be provisioned with information about the placements of the fields in K1 and K2.

As described above, in one embodiment of the present invention, the K1 and/or K2 bytes contain a span ID, and nodes of a network issue bridge requests with reference to span IDs. In another embodiment, the K1 and/or K2 bytes of a bridge request contained a destination node ID where the implicated span terminates, instead of the span ID of the span implicated by the bridge request. Thus, the bridge request lacks an explicit identification of the source node. The destination node ID can be stored in bits Q-8 of the K1 byte and/or bits 1-4 of the K2 byte, or elsewhere as discussed above with reference to span IDs. No source node ID need be specified. By referring to the direction from which the bridge request arrived (i.e., clockwise or counterclockwise), the path bit (bit 5) in the K2 byte (FIG. 4) and the destination node ID, a receiving node, including the destination node, can uniquely identify the span implicated by the bridge request. Other aspects of the K1 and K2 bytes, such as the number of bits used for the bridge request and the number of bits used for the destination node ID, are similar to the embodiment in which the K1 and/or K2 bytes contain a span ID. Thus, more than 16 nodes can be supported.

In yet another embodiment, the K1 and/or K2 bytes of a bridge request contain a source node ID, instead of the span ID or the destination node ID. Thus, the bridge request lacks an explicit identification of the destination node. By referring to the direction from which the bridge request arrived, the path bit and the source node ID, a receiving node can uniquely identify the span implicated by the bridge request. In other respects, this embodiment is similar to the two previously discussed embodiments.

Several mechanisms have thus far been disclosed for supporting more than 16 nodes in a network and for constructing, addressing, sending and receiving bridge requests or other messages to or from these nodes. As noted, in one embodiment of the present invention, instead of, or in addition to, keeping track of the topology of a network in terms of node IDs, each node of the network keeps track of the topology in terms of span IDs. In other respects, automatic protection switching, communications among the nodes of a network and other BLSR protocol aspects can remain unchanged.

FIG. 6 illustrates one embodiment of a BLSR controller 600, according to the present invention. Such a BLSR controller 600 can reside in a node of a network. In this embodiment, a translator 602 is disposed in a communication path between a standard BLSR controller 604 and a BLSR ring. Bridge requests sent along the ring refer to span IDs, as shown in FIG. 4, whereas the standard BLSR controller 604 sends and receives requests that include source and destination node IDs, as shown in FIG. 2. The BLSR controller 600 includes a ring map 606 that contains topology information about the ring. The translator 602 uses the ring map 606 to translate bridge requests arriving from the ring, such as bridge requests that include span IDs, into bridge requests that include source and destination node IDs, as shown in FIG. 2. Similarly, the translator 602 uses the ring map 606 to translate bridge requests sent by the standard BLSR controller 604, i.e. bridge requests that refer to source and destination node IDs, into bridge requests that can be sent along the ring, i.e. bridge requests that include span IDs.

FIG. 7 is an exemplary ring map 606 that describes the ring shown in FIG. 1. Each row of the ring map 606 corresponds to a span of the ring. Each row identifies two nodes and a span that extends between the two nodes. For example, the first row corresponds to span T and nodes A and B. As shown in FIG. 1, span T extends between nodes A and B. The rows of the ring map 606 can be ordered according to the occurrences of the spans, as the ring is traversed in a particular direction, such as clockwise, beginning with the current node. The ring map 606 or other data maintained by the BLSR controller 600 can also indicate in which node of the ring this BLSR controller resides.

FIG. 8 is a flowchart illustrating how messages sent by the standard BLSR controller 604 can be translated for transmission along the ring. At 800, the standard BLSR controller 604 sends a message with a source and destination node ID pair. At 802, the translator 602 looks up the node ID pair in the ring map 606 to ascertain the span ID of the span that extends between the nodes. At 804, the translator 602 replaces the source and destination node IDs in the message with the ascertained span ID. At 806, the message is sent along the ring.

FIG. 9 is a flowchart illustrating how messages received by the BLSR controller 600 from the ring can be translated for processing by the standard BLSR controller 604. At 900, a message having a span ID is received from the ring. At 902, the translator 602 looks up the span ID in the ring map 606 to ascertain the endpoints of the corresponding span, i.e. the node IDs of the nodes at which the span terminates. For purposes of illustration, the endpoints will be referred to as nodes “M” and “N.”

At decision box 904, the translator 606 ascertains whether the node, in which the BLSR controller 600 resides, is node M. In other words, the translator 606 determines if the current node is at one end of the span that is implicated by the message. If so, the message was sent to the current node. (The message must have been sent to the current node, because messages can be sent only to adjacent nodes, the implicated span terminates at the current node and the message was not sent by the current node.) If the message was sent to the current node, control passes to 906, where the span ID field in the message is replaced with source node ID=N and destination node ID=M, and at 908 the message is forwarded to the standard BLSR controller for processing.

At decision box 910, the translator 606 ascertains whether the node, in which the BLSR controller 600 resides, is node N. In other words, the translator 606 determines if the current node is at the other end of the span that is implicated by the message. If so, the message was sent to the current node, and control passes to 912, where the span ID field in the message is replaced with source node ID=M and destination node ID=N. At 908, the message is forwarded to the standard BLSR controller 604 for processing.

If the current node is located at neither end of the span implicated by the message, control is passed to decision box 914. In this case, the translator 602 ascertains which node (M or N) is closer to the current node. If node M is closer than node N to the current node, control passes to 912, where the span ID field in the message is replaced with source node ID=M and destination node ID=N. On the other hand, if node M is not closer than node M, control passes to 906, where the span ID field in the message is replaced with source node ID=N and destination node ID=M. In either case, control then passes to 908, where the message is forwarded to the standard controller 604 for processing.

Which node (M or N) is closer to the current node can be determined by searching the ring map 606 (starting with the current node) in a direction opposite the direction from which the received message arrived. The first node thus found (M or N) is the closer node.

Optionally, the standard BLSR controller 604 can be modified to handle more than 16 nodes. This modification involves increasing the size of a table in the standard BLSR controller 604, so the table has at least as many entries as there are nodes in the network. Execution loop limits and other constants may have to be increased to accommodate the larger table size. In addition, the standard BLSR controller 604 is modified to accept larger than 4-bit source and destination node IDs, however the basic logic of the standard BLSR controller 604 remains unchanged.

Optionally, if the bridge request field of the K1 byte (FIG. 4) is larger than four bits, i.e. additional bridge requests commands have been defined, before or instead of forwarding the message to the standard controller at 908, the translator 602 or another component (not shown) of the BLSR controller 600 can process the bridge request in the K1 byte.

The translator 602 also translates provisioning information, such as node ID, and provides this translated information to the standard BLSR controller 604.

FIG. 10 illustrates another embodiment of a BLSR controller 1000, according to the present invention. Such a BLSR controller 1000 can reside within a node of a network. In this embodiment, each working channel and each protect channel terminates at an interface 1002, 1004, 1006 and 1008, respectively. For simplicity, the channels are illustrated as bi-directional channels, although each channel may comprise two unidirectional fiber links. (Optionally, one or more additional interfaces, such as interface 1010, can be included in the BLSR controller 1000, such as for connection to a straddling span.) These interfaces 1002-1010 are each connected to a bus or switching fabric 1012. Control logic 1014, which includes a processor 1016 and memory 1018, is also connected to the bus 1012 and, thereby, controls operation of the interfaces 1002-1010, receives status information from the interfaces and controls other aspects of the BLSR controller 1000. The processor 1016 executes instructions and accesses data stored in the memory 1018 to perform the above-listed functions. This data can include provisioning data provided by a human or another system, as discussed above and below.

Under control of the instructions stored in the memory 1018, the control logic 1014 processes K1 and K2 bytes, including span IDs and bridge requests, received from other nodes of the network. In response to receiving these bridge requests, the control logic 1014 can bridge a selected one of the working channels to a protect channel. (In normal operation, pairs of working links are bridged.) Similarly, the control logic 1014 can bridge one protect channel to the other protect channel. Thus, the BLSR controller 1000 can perform automatic protection switching. Similarly, if the BLSR controller 1000 detects a channel or node failure, the control logic 1014 sends appropriate bridge requests, which includes span IDs according to this embodiment of the present invention, to other nodes of the network to request that those nodes switch spans or rings, as appropriate. As previously noted, bridge request messages can identify an implicated span by its span ID. Alternatively, as noted above, the source node ID (without a destination node ID) or a destination node ID (without a source node ID) can be used to identify the implicated span. Alternatively, the requests can contain both a source node ID and a destination node ID to identify the implicated span.

As noted above, conventional adjacent BLSR rings require separate working and protect links for each ring, even in spans between adjacent nodes that are common among the rings. For example, as shown in FIG. 11, adjacent rings R1 and R2 share adjacent nodes A and B. Two spans (span 1100 and span 1102) interconnect nodes A and B. Span 1100 includes a working link 1104 and a protect link 1106, and span 1102 includes a working link 1108 and a protect link 1110. (For simplicity, the links 1104-1110 are shown as bidirectional links, although each link of a BLSR ring typically consists of two unidirectional channels, each channel carried by a separate optical fiber.)

In the presently disclosed system, as shown in FIG. 12, adjacent rings R1 and R2 share a single protect link 1200 between nodes A and B. Working links 1202 and 1204 extend between nodes A and B. Working link 1202 is part of ring R1, and working link 1204 is part of ring R2. Collectively, the shared protect link 1200 and the two working links 1202 and 1204 form span X. A “composite” BLSR controller (described in more detail below) in node A is connected to the working links 1202 and 1204 and to the shared protect link 1200, as well as to spans T and U. The composite BLSR controller coordinates access to the shared protect link 1200 by the rings R1 and R2 through node A. The composite BLSR controller accepts and generates messages from and to both rings R1 and R2, as though each ring had a dedicated protect link. In other words, the composite BLSR controller presents an appearance to nodes C-E of ring R1 and nodes F-I of ring R2 of two completely independent rings (R1 and R2), each having a separate protect link between nodes A and B. Thus, each ring R1 and R2 appears to have a “virtual” protect link between nodes A and B.

Similarly, a composite BLSR controller in node B is connected to the working links 1202 and 1204 and the shared protect link 1200, as well as to spans V and W. The composite BLSR controller in node B coordinates access to the shared protect link 1200 by the rings R1 and R2 through node B. This composite BLSR controller also presents an appearance to the other nodes of two completely independent rings R1 and R2, each with its own protect link between nodes A and B. The composite controllers in nodes A and B communicate with each other as part of the coordination.

The shared protect link 1200 is available for use on either ring R1 or R2, for example as a result of a ring switch requested by either ring (e.g. due to a failure of a node or a span on one of the rings) or as a result of a span switch requested by node A or node B (e.g. due to a failure of one of the working links 1202 or 1204). If one of the rings R1 or R2 requires use of the shared protect link 1200 and the shared protect link is a available for this use, the composite BLSR controllers in nodes A and B cooperate to use the shared protect link as requested and act as though the virtual protect link for the other ring is locked out.

In a standard 4-fiber BLSR ring, overhead bytes in the protect links (1106 and 1110 in FIG. 11) are used for signaling. For example, the K1 and K2 bytes are used for protection switching and related commands, and (optionally) the data communication channel (DCC), orderwire (E1 and E2), user (F1) and other channels may be used for communicating information, such as ring map, circuit squelching tables, etc. Because this signaling occurs independently on each of the rings R1 and R2, the composite BLSR controllers in nodes A and B should provide independent virtual signaling links between nodes A and B. Several embodiments of such a composite BLSR controller are described below, each of which provides these virtual links in a different way.

In one embodiment, overhead bytes in the working link 1202 and 1204 (FIG. 12) of each ring R1 and R2 are used to carry the respective ring's signaling traffic between nodes A and B. Thus, information that would have been carried via overhead bytes of an actual protect link between adjacent nodes in a traditional BLSR ring is instead carried via overhead bytes of the working link between the adjacent nodes of that ring. This signaling traffic can be carried over the same channel, for example the K1 K2 channel, of the working link as would have carried the signaling traffic over the protect link. Alternatively, another channel of the working link can be used. In another alternative, overhead bytes (such as the equivalent of the K1 and K2 bytes) in a second and/or subsequent STS-1 frame(s) of an OC-n line (where n>1) of the working link 1202 and 1204 of each ring R1 and R2 are used to carry the respective ring's signaling traffic between nodes A and B. These arrangements assume, of course, that each ring has an operational working link between the adjacent nodes. If the working link fails, and a span switch occurs between the adjacent nodes, the signaling is multiplexed over the shared protect link, as described below.

In another embodiment, signaling traffic for one of the rings R1 or R2 is carried over the shared protect link 1200, and signaling traffic for the other ring (or rings, if more than two rings share the shared protect link) is carried over the respective working link of that ring(s). Such an arrangement can be used, for example, if the working link of one of the rings (an “asymmetric ring”) is omitted between nodes A and B.

In another embodiment, the signaling information for both rings R1 and R2 is multiplexed over the shared protect link 1200. This multiplexing can involve a fixed or flexible time-division multiplexing (TDM) arrangement, parallel transmission of different rings' signaling information over different channels, or any other suitable multiplexing arrangement. For example, in one embodiment, overhead bytes (such as the equivalent of the K1 and K2 bytes) in the second and/or subsequent STS-1 frames of an OC-n (n>1) shared protect link 1200 are used to carry the various rings' signaling traffic between nodes A and B.

In one TDM arrangement, a channel of the shared protect link 1200 (such as the K1 K2 channel) is shared on a round-robin basis by the rings R1 and R2. For example, one ring's signaling traffic is sent over the multiplexed channel for a predetermined number (R) of frames, then the other ring's signaling traffic is sent over the multiplexed channel for the next R frames, etc.

Alternatively, the number of frames allocated to each ring's signaling traffic can depend on the status of that ring. For example, a ring that is in the process of affecting a ring switch can be deemed to have a higher priority than the other ring and be allocated a larger number of frames than the other ring. Optionally or in addition, signaling traffic from a ring that is deemed to be in a high priority state can preempt signaling traffic from the other ring, even if all the other ring's frames have not yet been sent.

While one ring's signaling information is being sent over a TDM channel, the receiving composite BLSR controller acts as if it is not receiving any new information over the overhead signaling channels for the other ring. For example, the receiving composite BLSR controller acts as if the most recently received K1 K2 values for the other ring are being repeatedly received for that ring. The receiving composite BLSR controller also acts as if it is receiving idle patterns over the DCC channels for the other ring.

As noted, in some embodiments, signaling information for both rings is multiplexed over a single channel. In other embodiments, signaling information for each ring is sent over a separate channel. In either case, various mechanisms can be used to tag or otherwise distinguish one ring's signaling information from the other ring's signaling information. If the signaling information for each ring is sent over a separate channel, tagging the information is optional. For example, tagging is not necessary if the composite BLSR controllers negotiate an agreement that specifies each ring's channel for carrying signaling information. Alternatively, each channel-to-ring assignment can be provisioned.

Signaling information can be tagged by including ring-identifying information in the signaling information. As noted above, the use of span IDs in the K1 K2 bytes can leave room for additional information in those bytes. As shown in FIG. 13, if the total number of bits required for the bridge request code and the span ID is less than 12, the remaining bit(s) (Q-R) are available to store a ring ID. Thus, each ring R1 and R2 can be assigned a ring ID, and that ring ID can be included in the K1 K2 bytes of signaling information sent over the multiplexed or separate channel(s) to identify which ring's signaling information is being sent. The ring IDs can be provision in the nodes A and B, as previously discussed, or the ring IDs can be automatically assigned by the composite BLSR controllers. For example, the composite BLSR controllers can arbitrarily assign the ring IDs to the rings.

Ring IDs need not, however, be known globally. Ring IDs are local (in scope) to each shared span. That is, each ring ID needs to be unique only in relation to its shared span. For example, as shown in FIG. 16, if ring R2 shares a span (between nodes A and B) with ring R1, nodes A and B use a set of ring IDs to identify rings R1 and R2. Ring R2 also shares a span (between nodes C and D) with ring R3. Nodes A and B can use the same set of ring IDs to identify rings R1 and R2 as nodes C and D use to identify rings R2 and R3 without confusion. Each ring ID is implicitly qualified by the span ID of the span over which it is received, because a node can identify over which span it receives messages containing the ring ID. Thus, ring IDs can be assigned or negotiated locally between the terminal nodes, without a need to coordinate ring IDs with other nodes of the network.

FIG. 14 illustrates an embodiment of a composite BLSR controller 1400. Such a composite BLSR controller 1400 can reside within a common node (such as node A or node B of FIG. 12) of two adjacent rings. Each working channel and each protect channel terminates at an interface 1402, 1404, 1406, 1408, 1410, 1412 and 1414, respectively. For simplicity, the channels are illustrated as bidirectional channels, although each channel may comprise two unidirectional fiber links. The interfaces 1402-1414 are each connected to a bus and/or switching fabric 1416 (hereinafter referred to as a bus). Control logic 1418, which includes a processor 1420 and memory 1422, is also connected to the bus 1416 and, thereby, controls operation of the interfaces 1402-1414, receive status information from the interfaces and controls other aspects of the composite BLSR controller 1400. The processor 1420 executes instructions and accesses data stored in the memory 1422 to perform the above-listed functions. This data includes provisioning data provided by a human or other system, as discussed above.

As noted, the composite BLSR controller in node A (FIG. 12) is connected to span T. This connection is shown in FIG. 14 as connections between interfaces 1402 and 1404 and working and protect links to node E. The composite BLSR controller in node A is also connected to span U. This connection is shown in FIG. 14 as connections between interfaces 1406 and 1408 and working and protect links to node F. The composite BLSR controller in node A is also connected to span X. This connection is shown in FIG. 14 as connections between interfaces 1410, 1412 and 1414 and the two working links and the shared protect link to node B.

Under control of the instructions stored in the memory 1422, the control logic 1418 sends and receives data to and from its counterpart at an adjacent node to coordinate the transmission of signaling information from spans T and U over span X. For example, the control logic 1418 can multiplex the signaling information from spans T and U onto the shared protect link, as described above. Alternatively, the control logic 1418 can send the signaling information over separate channels, as described above. This coordination can include processing ring IDs, as noted above.

The control logic 1418 also detects failures in channels that terminate at the composite BLSR controller, communicates with other nodes of the network to request span and ring switches and, in response to detected failures or to requests from other nodes of the network, bridges network traffic among the working and/or protect links terminating at the composite BLSR controller, as appropriate. Under control of the instructions stored in the memory 1422, the control logic 1418 processes K1 and K2 bytes, including span IDs and bridge requests, received from other nodes of the network. In response to receiving these bridge requests, the control logic 1418 can bridge a selected one of the working links to the shared protect link. (In normal operation, pairs of working links are bridged.) Similarly, the control logic 1418 can bridge or switch a protect link in span T or U to the shared protect link. Thus, the BLSR controller 1400 can perform automatic protection switching. Similarly, if the BLSR controller 1400 detects a link or node failure, the control logic 1418 sends appropriate bridge requests, which includes span IDs according to this embodiment of the present invention, to other nodes of the network to request that those nodes switch spans or rings, as appropriate. As previously noted, bridge request messages can identify an implicated span by its span ID. Alternatively, as noted above, the source node ID (without a destination node ID) or a destination node ID (without a source node ID) can be used to identify the implicated span. Alternatively, the requests can contain both a source node ID and a destination node ID to identify the implicated span.

FIG. 19 illustrates another embodiment of a composite BLSR controller 1900. Such a composite BLSR controller 1900 can reside in a common node of two or more adjacent rings, such as in node A or B (FIG. 12). A translator 1902 is disposed in a communication path between the spans (such as spans T, U and X) terminating at the node and a number of standard BLSR controllers 1904 and 1906. The composite BLSR controller includes one standard BLSR controller 1904 or 1906 for each ring, in which the node is a member. Each standard BLSR controller 1904 or 1906 controls interactions between the node and the corresponding ring (such as R1 or R2). The translator 1902 provides two “virtual” spans, such as virtual spans 1908 and 1910, to each standard BLSR controller 1904-1906. These virtual spans represent the two spans that connect the node to the respective ring. For example, if standard BLSR controller 1904 controls interactions between the node and ring R1, then virtual span 1908 represents span T, and virtual span 1910 represents the working link and the virtual protect link of span X. The virtual spans can represent logical interactions between the translator and the standard controllers 1904 and 1906. For example, standard BLSR controllers interact with hardware, firmware and/or software to send and receive signaling traffic over spans, detect errors in the spans and otherwise interact with and control optical fiber links and their respective interfaces. The translator 1902 can “hook” existing software to monitor and modify these interactions, as described in more detail below.

In one embodiment, the translator 1902 interpose itself between the spans and the standard BLSR controllers 1904 and 1906, so that signaling traffic passes through the translator. Signaling traffic (messages) sent to the node (such as node A) over spans that terminate at the node are monitored by the translator 1902. The translator 1902 forwards some of these messages to selected ones of the standard BLSR controllers 1904-1906 without modifying the messages. The translator 1902 selectively modifies some of the messages before forwarding them, and it intercepts and discards (without forwarding) some of the messages. The translator 1902 also creates messages that it forwards to the standard BLSR controllers 1904-1906, as though these messages were received from other nodes of the network. Similarly, the translator 1902 monitors and selectively modifies messages generated by the standard BLSR controllers 1904-1906 before forwarding them to other nodes, via the respective spans that terminate at the node. The translator 1902 also generates messages, which it forwards to other nodes, as though the messages were sent by the standard BLSR controllers 1904-1906.

In modifying a message, the translator 1902 can, for example, remove a ring ID from the K1 K2 bytes and reformat these bytes into a traditional layout, as shown in FIG. 2. Conversely, the translator 1902 can insert a ring ID into the K1 K2 bytes. Similarly, the translator 1902 can translate a span ID into a corresponding source and destination node ID pair, or visa versa, as discussed above. The translator 1902 can also modify the bridge request code, the source and/or destination node ID, path bit and/or status bits. Such a modification can, for example, make a message appear to have been sent by a particular node or over a particular path (short or long), whereas the message was actually sent over a different path, or by a different node or was generated by the translator 1902.

In another embodiment, the translator 1902 accesses (reads and writes) data, such as status variables, tables, etc., in the standard BLSR controllers 1904 and 1906. In this embodiment, the translator 1904 directly accesses locations within the standard BLSR controllers 1904 and 1906. These locations can be memory locations, for example if the standard BLSR controllers 1904 and 1906 are implemented in software or firmware. These locations can also be hardware registers, for example if the standard BLSR controllers 1904 and 1906 are implemented in firmware or hardware. Thus, the translator 1902 can directly ascertain and modify state information in the standard BLSR controllers 1904 and 1906.

Thus, the translator controls and selectively modifies interactions the standard BLSR controllers 1904-1906 have with the spans and the other nodes. By this mechanism, the translator 1902 can alter the way the standard BLSR controllers 1904-1906 perceive the status of the shared span X (including the shared protect link 1200), as well as the other nodes of the network. The translator 1902 can also alter the way other nodes of the network perceive the shared span (including the shared protect link 1200) and the node on which the composite BLSR controller 1900 resides. For example, the translator 1902 can present an appearance to other nodes, such as nodes E and F, that span X includes both working and protect links for each ring R1 and R2.

By monitoring the signaling traffic, the translator 1902 can ascertain if the shared protect link 1200 is being requested, such as by the node for a span switch or by another node for a ring switch. The composite BLSR controller 1900 stores status information 1912 about the shared protect link 1200 (FIG. 12) in a suitable memory. This status information 1912 can indicate, for example, if the shared protect link 1200 is available for use or if it is currently in use and, if so, for what purpose (span switch, ring switch, etc.), for which ring, a priority of such use relative to other potential requests, etc.

If the shared protect link 1200 is requested, the translator 1902 examines the status information 1912 to ascertain if the shared protect link is available or in use, if not, which ring is currently using it, for what purpose, etc. The translator 1902 then forwards or generates messages to the standard BLSR controller 1904 or 1906 of the requesting ring to request use of the shared protect link 1200. Since the standard BLSR controller 1904 or 1906 maintains its own status information concerning its virtual protect link, the standard BLSR controller can arbitrate the request.

Alternatively, the translator 1902 can arbitrate the request. If the shared protect link 1200 is in use, the translator 1902 ascertains if the priority of the request is sufficient to preempt the current use. If the shared protect link is available (i.e. it is not in use, or the use is preemptable), the translator 1902 sends messages to the appropriate standard BLSR controller 1904 or 1906 (depending on the ring on which the request is being made) to cause the request to be honored.

In response to messages the standard BLSR controller sends indicating that the request was or was not honored, the translator 1902 send messages to the other nodes of the network to indicate that the request was or was not honored.

The translator 1902 also sends messages to the other standard BLSR controller 1904 or 1906 and (where appropriate) to the other nodes of the ring on which the request was not made. These messages simulate unavailability of the virtual protect link in span X and prevent the other standard BLSR controller 1904 or 1906 or other nodes on the other ring from requesting use of their virtual protect link. In one embodiment, the translator 1902 sends lockout protection-span (LP-S) messages to the other standard BLSR controller 1904 or 1906. Other embodiments send other requests to accomplish the same objective, albeit with different priorities and/or other treatments, as described in more detail below.

If and when the need for use of the shared protect link 1200 ends, i.e. the translator 1902 receives a message releasing the virtual protect link in span X, the translator sends messages to end the LP-S condition in the other ring.

As noted, if a request for use of the shared protect link 1200 having a higher priority than the current use is received, the translator 1902 either arbitrates the request (and sends messages to the standard BLSR controller 1904 or 1906 (and to the other nodes, if appropriate) of the ring using the shared protect link to end such use), or the translator forwards the request to the standard BLSR controller 1904 or 1906 for arbitration. If the translator 1902 arbitrates the request, it then sends messages to entities in the requesting ring to enable use of the shared protect link 1200, as described above.

Advantageously, the other (non-common) nodes of the rings can include standard BLSR controllers, because, from their points of view, a real protect link exists in span X for each ring. The other nodes of the rings send and receive bridge requests that are indistinguishable from requests that would be send and received if a real protect link existed in span X for their respective ring.

In another embodiment, instead of sending an LP-S request to effectively prevent other rings from using the shared protect link 1200, the translator 1902 sends signal degrade-protection (SD-P) requests. This request has a lower priority than LP-S, thus it can be preempted by more requests than LP-S. Other commands can be used, depending on a desired preemptability of the use of the shared protect link 1200. For example, the LP-S request produces a form of “first-come, first-served” preemption scheme, whereas the SD-P request produces a form of “last-come, first-served” preemption scheme. Alternatively, a new request code can be defined (as discussed above with reference to FIG. 5) specifically to prevent other rings from using the shared protect link 1200. This approach involves modifying the standard BLSR controllers 1904-1906 to recognize the new request code. The multiple rings sharing the protect span 1200 can be given equal priority with respect to being granted use of the shared protect link. For example, bridge requests from both rings can be prioritized according to the standard BLSR priority hierarchy. Alternatively, the rings sharing the protect span 1200 can be given different priorities with respect to being granted use of the shared protect link. Optionally, different rings can be given different priorities, with respect to being granted use of the shared protect link 1200.

Although composite BLSR controller embodiments have been described in the context of two adjacent rings having two common adjacent nodes, similar composite BLSR controllers can be used in more complex ring topologies by including more interfaces and sizing the ring ID field appropriately (if applicable). Composite BLSR controllers can be used in network topologies that include more than two adjacent rings. For example, FIG. 15 shows a network of three adjacent rings (A-B-C-D-E, A-B-F-G-H and A-B-K-J-I). The common span between nodes A and B includes three working links and one shared protect link. Composite BLSR controllers in nodes A and B multiplex signaling information for the three rings over the shared protect channel or send this information over separate channels, as described above.

A ring can be adjacent to more than one other ring through different pairs of adjacent nodes, as shown in FIG. 16. Ring R2 is adjacent to ring R1 and to ring R3. Composite BLSR controllers in nodes A and B operate as described above to manage the two working links 1600 and the shared protect link 1602 between nodes A and B. In addition, composite BLSR controllers in nodes C and D operate as described above to manage the two working links 1604 and the shared protect link 1606 between nodes C and D.

A ring can share more than one span with an adjacent ring, as shown in FIGS. 17 and 18. In FIG. 17, the span between nodes A and B and the span between nodes C and D are each treated as described above, with reference to the span between nodes A and B in FIG. 12. In FIG. 18, node B includes a composite BLSR controller that includes interfaces for connection to the working links and the shared protect link in the span between nodes A and B. The composite BLSR controller also includes interfaces for connection to the working links and the shared protect link in the span between nodes B and C. In other respects, the BLSR controller operates as described above.

Embodiments of the invention have been described with reference to a 4-fiber BLSR ring, however the invention can also be practiced in other network architectures, such as 2-fiber networks, mesh networks, etc., as will be evident to those of ordinary skill in the art. For example, the present invention was described with reference to a 4-fiber BLSR ring, in which working channels and protect channels are implemented as separate fiber links. In a 2-fiber BLSR ring, working channels and protect channels are implemented as separate sets of time slots on a single fiber-optic link. Nevertheless, spans in 2-fiber BLSR rings can be assigned span IDs.

In a mesh network, at least a portion of the mesh, e.g. a protect path (with or without the working span it protects), is treated as an implied ring. In a mesh network, some protect paths can share spans with each other protect paths. This is analogous to the shared rings described above. Thus, shared protect paths in mesh networks can be handled as described above. For example, if a span is part of two protect paths, and both paths are requested, one of the requests succeeds and the other request fails. As noted above, in some embodiments, the arbitration can be performed by a translator or by a standard controller.

A BLSR controller has been described as including a processor controlled by instructions stored in a memory. Those skilled in the art should readily appreciate that instructions or programs defining the functions of the present invention can be delivered to a processor in many forms, including, but not limited to information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment) or information alterably stored on writable storage media (e.g. floppy disks and hard drives). In addition, while the invention may be embodied in software, the functions necessary to implement the invention may alternatively be embodied in part or in whole using firmware and/or hardware components such as Field Programmable Gate Arrays (FPGSs) or Application Specific Integrated Circuits (ASICs) or other hardware or some combination of hardware, software and/or firmware components.

While the invention is described through the above-described exemplary embodiments, it will be understood by those of ordinary skill in the art that modifications to, and variations of, the illustrated embodiments can be made without departing from the inventive concepts disclosed herein. For example, the invention is described with reference to bridging network traffic onto a protect span or path after a failure. In some cases, the term “switching” is used instead of “bridging,” however the same meaning is intended. Traditionally bridging involves dualcasting network traffic over both the failed link and the protect span or arc. Alternatively, the network traffic can be redirected onto only the protect span or arc. As used herein, including in the claims, switching and bridging both mean dualcasting or redirecting network traffic. While the invention is described in the context of SONET and a BLSR, it applies equally well to SDH and a multiplex section shared protection ring (MS-SPRing), as well as other network standards and proprietary schemes based on, or modified from, these standards. Accordingly, the invention should not be viewed as limited, except by the scope and spirit of the appended claims.

Shared network ring protection

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

CROSS REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)