U.S. patent application number 10/887249 was filed with the patent office on 2005-02-24 for shared network ring protection.
Invention is credited to Kam, Anthony C. K., Patel, Naimish, Xie, Raymond Y., Yang, Tao.
Application Number | 20050041601 10/887249 |
Document ID | / |
Family ID | 34079141 |
Filed Date | 2005-02-24 |
United States Patent
Application |
20050041601 |
Kind Code |
A1 |
Kam, Anthony C. K. ; et
al. |
February 24, 2005 |
Shared network ring protection
Abstract
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. Each ring can be assigned a ring ID. The
communication protocol between the adjacent nodes can be modified
to tag the signaling information with the appropriate ring ID. 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.
Inventors: |
Kam, Anthony C. K.;
(Arlington, MA) ; Xie, Raymond Y.; (Westford,
MA) ; Yang, Tao; (Acton, MA) ; Patel,
Naimish; (Boston, MA) |
Correspondence
Address: |
WEINGARTEN, SCHURGIN, GAGNEBIN & LEBOVICI LLP
TEN POST OFFICE SQUARE
BOSTON
MA
02109
US
|
Family ID: |
34079141 |
Appl. No.: |
10/887249 |
Filed: |
July 8, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60485543 |
Jul 8, 2003 |
|
|
|
Current U.S.
Class: |
370/258 |
Current CPC
Class: |
H04J 3/1611 20130101;
H04J 3/14 20130101 |
Class at
Publication: |
370/258 |
International
Class: |
H04L 012/28 |
Claims
What is claimed is:
1. A method of multiplexing signaling information from a plurality
of rings onto a single channel, comprising: assigning a ring
identifier to each of the plurality of rings; tagging a message
containing signaling information from one of the plurality of rings
with a ring identifier of the one of the plurality of rings; and
sending the message over the single channel.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit under 35 U.S.C. .sctn.
119(e) of Provisional Patent Application No. 60/485,543, filed Jul.
8, 2003 and titled "Bidirectional Line Switched Ring Employing
Straddling Span Protection and Protocol."
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
[0002] N/A
BACKGROUND OF THE INVENTION
[0003] This application relates to sharing a backup network link,
particularly in a telecommunications network.
[0004] 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).
[0005] 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.
[0006] 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."
[0007] 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).
[0008] 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).
[0009] 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.)
[0010] 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
[0011] 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.
[0012] 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
[0013] 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:
[0014] FIG. 1 is a simplified schematic diagram of an exemplary
ring network;
[0015] FIG. 2 is schematic diagram of K1 and K2 bytes in an
automatic protection switching protocol message, according to the
prior art;
[0016] FIG. 3 is a list of bridge requests codes, according to the
prior art;
[0017] FIG. 4 is schematic diagram of K1 and K2 bytes, according to
an embodiment of the present invention;
[0018] FIG. 5 is an exemplary list of additional bridge requests
codes, according to an embodiment of the present invention;
[0019] FIG. 6 is a block diagram of a BLSR controller, according to
an embodiment of the present invention;
[0020] FIG. 7 is an exemplary ring map, according to an embodiment
of the present invention;
[0021] FIG. 8 is a simplified flowchart illustrating operations
performed by a BLSR controller, according to an embodiment of the
present invention;
[0022] FIG. 9 is a simplified flowchart illustrating other
operations performed by a BLSR controller, according to an
embodiment of the present invention;
[0023] FIG. 10 is a block diagram of a BLSR controller, according
to another embodiment of the present invention;
[0024] FIG. 11 is a simplified schematic diagram of an exemplary
ring network that includes two adjacent rings, according to the
prior art;
[0025] 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;
[0026] FIG. 13 is schematic diagram of K1 and K2 bytes, according
to another embodiment of the present invention;
[0027] FIG. 14 is a block diagram of a BLSR controller, according
to another embodiment of the present invention;
[0028] 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;
[0029] 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;
[0030] 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;
[0031] 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
[0032] FIG. 19 is a block diagram of a BLSR controller, according
to another embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.noteq.Q-1).
[0047] 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.
[0048] 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.noteq.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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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."
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] The translator 602 also translates provisioning information,
such as node ID, and provides this translated information to the
standard BLSR controller 604.
[0063] 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.
[0064] 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.
[0065] 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.)
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
* * * * *