U.S. patent application number 12/581944 was filed with the patent office on 2010-07-01 for method and system for ring topology discovery and forwarding database flush nullification.
This patent application is currently assigned to NORTEL NETWORKS LIMITED. Invention is credited to Bashar ABDULLAH, Marc HOLNESS, Marc Andre ROCHON.
Application Number | 20100165834 12/581944 |
Document ID | / |
Family ID | 42284837 |
Filed Date | 2010-07-01 |
United States Patent
Application |
20100165834 |
Kind Code |
A1 |
HOLNESS; Marc ; et
al. |
July 1, 2010 |
METHOD AND SYSTEM FOR RING TOPOLOGY DISCOVERY AND FORWARDING
DATABASE FLUSH NULLIFICATION
Abstract
A method and system for rerouting data in a communication
network ring. The ring includes a plurality of nodes and a
plurality of links. Each node includes a first port and a second
port. Each first port is connected to a neighboring second port
through a link of the plurality of links. The topology of the
communication network ring is discovered and a forwarding database
table is populated with static entries according to the discovered
topology. Upon receiving notice of a failed link, which includes a
source address of a node adjacent to the failed link, the topology
and the source address of the node adjacent to the failed link is
used to reconfigure the forwarding database table. Data is
forwarded using the reconfigured forwarding database table without
flooding the ring.
Inventors: |
HOLNESS; Marc; (Nepean,
CA) ; ABDULLAH; Bashar; (Ottawa, CA) ; ROCHON;
Marc Andre; (Gatineau, CA) |
Correspondence
Address: |
CHRISTOPHER & WEISBERG, P.A.
200 EAST LAS OLAS BOULEVARD, SUITE 2040
FORT LAUDERDALE
FL
33301
US
|
Assignee: |
NORTEL NETWORKS LIMITED
Saint-Laurent
CA
|
Family ID: |
42284837 |
Appl. No.: |
12/581944 |
Filed: |
October 20, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12347362 |
Dec 31, 2008 |
|
|
|
12581944 |
|
|
|
|
Current U.S.
Class: |
370/225 |
Current CPC
Class: |
H04L 45/28 20130101;
H04L 12/437 20130101 |
Class at
Publication: |
370/225 |
International
Class: |
G06F 11/00 20060101
G06F011/00 |
Claims
1. A method for rerouting data in a communication network ring, the
ring including a plurality of nodes, each node including a first
port and a second port, each first port connected to a second port
of a neighboring node through a link of the plurality of links, the
method comprising: discovering a topology of the communication
network ring; populating static entries in a forwarding database
table according to the discovered topology; receiving notice of a
failed link, the notice including a source address of a node
adjacent to the failed link; using the topology and the source
address of the node adjacent to the failed link to reconfigure the
forwarding database table; and forwarding data using the
reconfigured forwarding database table.
2. The method of claim 1, wherein discovering the topology of the
communication network ring comprises: receiving at least one of a
ring topology request and a response to the ring topology request
from at least one node on the ring, the at least one of the ring
topology request and the response to the ring topology request
including an identification of the at least one node and a hop
count needed to reach the at least one node; forwarding the at
least one of the ring topology request and the response to the ring
topology request to at least one neighboring node on the ring
through the first port; and determining the topology based on the
identification of the at least one node, the hop count, and an
identification of the first port.
3. The method of claim 2, wherein the ring topology request is a
Ring Automated Protection Switching message, the Ring Automated
Protection Switching message including a type-length-value element,
the method further comprising: receiving a ring topology request at
the first port and the second port; modifying each ring topology
request by adding an identification of a receiving node to the
type-length-value element and incrementing the node count; and
forwarding each modified ring topology request to the neighboring
node through the other of the first port and the second port than
the port on which the ring topology request was received.
4. The method of claim 2, wherein the at least one ring topology
request is a Ring Automated Protection Switching message, the
method further comprises: creating the at least one ring topology
request by adding a type-length-value element to the Ring Automated
Protection Switching message, the type-length-value element
including a node signature for an originating node and the hop
count; and initializing the hop count.
5. The method of claim 4, wherein the ring topology request is
forwarded through the first port and the second port, and further
wherein receiving at least one response to the ring topology
request comprises: receiving a response at first port and the
second port, each response having been forwarded through the ring
from the other of the first port and the second port from which the
response was received, each response including a total node count
of all the nodes in the ring and an identification of each node in
the ring arranged in an order of processing.
6. The method of claim 2, further comprising creating the ring
topology request in response to detecting a failure of a link
connected to the other of the first port and the second port from
which the response was received the transmitting port.
7. The method of claim 2, wherein the ring topology request is a
LinkTrace message, the LinkTrace message including a time-to-live
value, the method further comprising: inserting a ring identifier
into the LinkTrace message, the ring identifier being a group
address used to keep the ring topology request local to the ring;
receiving a plurality of LinkTrace responses, each LinkTrace
response originated by one of the nodes of the plurality of nodes
of the ring, each LinkTrace response including an identification of
the originating node; and wherein the indication of a node count
needed for the ring topology request to reach the at least one
responding node is a time-to-live value.
8. The method of claim 7, wherein the node count needed for the
ring topology request to reach the at least one responding node is
equal to one half of a difference between the time-to-live value of
the LinkTrace message and the time-to-live value of the LinkTrace
response.
9. The method of claim 2, wherein the ring topology request is a
continuity check message, the continuity check message including a
listing of identifications of nodes having previously received
continuity check message, the method further comprising: receiving
the ring topology request at one of the first port and the second
port; modifying the ring topology request by appending an
identification of a receiving node to listing of identifications of
nodes having previously received continuity check message and
incrementing the node count; and forwarding the modified ring
topology request to the neighboring node through the other of the
first port and the second port on which the ring topology request
was received.
10. The method of claim 2, wherein the ring topology request is a
continuity check message, the method further comprising: receiving
a modified ring topology request through the other of the first
port and the second port on which the ring topology request was
transmitted, the modified ring topology request including a listing
of identifications of nodes having previously received continuity
check message in an order of processing and a total node count of
all nodes on the ring.
11. A node of a communication network ring, the ring including a
plurality of nodes, the node comprising: a first port and a second
port, each first port connected to a second port of a neighboring
node through a link, each port operable to receive and transmit
data; and a processor electrically connected to each port, the
processor operates to: determine a topology of the ring; populate
static entries in a forwarding database table according to the
topology; and responsive to receiving notice of a failed link, the
notice including a source address of a node adjacent to the failed
link, the processor further operates to: use the topology and the
source address of the node adjacent to the failed link to
reconfigure the forwarding database table; and forward data using
the reconfigured forwarding database table.
12. The node of claim 11, wherein at least one of the first port
and the second port receives at least one of a ring topology
request and a response to the ring topology request from at least
one other node on the ring, the at least one of the ring topology
request and the response to the ring topology request including an
identification of the at least one other node and a hop count
needed to reach the at least one other node, the other of the first
port and the second port than the port on which the at least one of
a ring topology request and a response to the ring topology request
was received is operable to forward the at least one of a ring
topology request and a response to the ring topology request to at
least one neighboring node on the ring.
13. The node of claim 12, wherein the processor determines the
topology based on the identification of the at least one node, the
hop count, and an identification of the forwarding port.
14. The node of claim 12, wherein the ring topology request is a
Ring Automated Protection Switching message, the Ring Automated
Protection Switching message including a type-length-value element,
each port further receives a ring topology request; and the
processor further: modifies each ring topology request by adding an
identification of a receiving node to the type-length-value element
and incrementing the node count; and forwards the modified ring
topology request to the neighboring node through the other of the
first port and the second port than the port on which the ring
topology request was received.
15. The node of claim 12, wherein the at least one ring topology
request is a Ring Automated Protection Switching message, the
processor further creates the at least one ring topology request
by: adding a type-length-value element to the Ring Automated
Protection Switching message, the type-length-value element
including a node signature for the node and the hop count; and
initializing the hop count.
16. The node of claim 15, wherein the ring topology request is
forwarded through both ports, receiving at least one response to
the ring topology request comprises: receiving a response at each
of the first port and the second port, each response having been
forwarded through the ring from the opposite port, each response
including a total node count of all the nodes in the ring and an
identification of each node in the ring arranged in an order of
processing.
17. The node of claim 12, wherein the ring topology request is a
LinkTrace message, the LinkTrace message including a time-to-live
value, the processor further inserts a ring identifier into the
LinkTrace message, the ring identifier being a group address
insuring that the ring topology request remains local to the ring;
and at least one of the first port and the second port further
receives a plurality of LinkTrace responses, each LinkTrace
response originated by one of the nodes of the plurality of nodes
of the ring, each LinkTrace response including an identification of
the originating node; and wherein the indication of a hop count
needed for the ring topology request to reach the at least one
responding node is a time-to-live value.
18. The node of claim 17, wherein the hop count needed for the ring
topology request to reach the at least one responding node is equal
to one half of a difference between the time-to-live value of the
LinkTrace message and the time-to-live value of the LinkTrace
response.
19. The node of claim 12, wherein the ring topology request is a
continuity check message, at least one port further receives a
modified ring topology request through the other of the first port
and the second port on which the ring topology request was
transmitted, the modified ring topology request including a listing
of identifications of nodes having previously received continuity
check message in an order of processing and a total node count of
all the nodes on the ring.
20. A system for rerouting data in a communication network ring,
the system comprising: a plurality of nodes interconnected in a
ring configuration, each node including: a first port and a second
port, each port operable to receive and transmit data; and a
processor electrically connected to each port, the processor
operating to: determine a topology of the ring; populate static
entries in a forwarding database table according to the topology;
and responsive to receiving notice of a failed link, the notice
including a source address of a node adjacent to the failed link,
the processor further operating to: use the topology and the source
address of the node adjacent to the failed link to reconfigure the
forwarding database table; and forward data using the reconfigured
forwarding database table.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a Continuation of U.S. patent
application Ser. No. 12/347,362 entitled "Ring Topology Discovery
Mechanism" filed Dec. 31, 2008, the entirety of which is
incorporated herein by reference.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
[0002] n/a
FIELD OF THE INVENTION
[0003] The present invention relates generally to communication
networks, and more specifically to a method and system for ring
topology discovery in a communication network.
BACKGROUND OF THE INVENTION
[0004] Ethernet Ring Protection ("ERP"), as standardized according
to International Telecommunication Union ("ITU") specification
ITU-T G.8032, defines an effort to provide sub-50 ms protection for
Ethernet traffic in a ring topology while simultaneously ensuring
that no loops are formed at the Ethernet layer. Using the ERP
standard, there is a central node called the Ring Protection Link
("RPL") owner node which blocks one of the ports, known as the RPL
port, to ensure that no loop forms for the Ethernet traffic. Ring
Automated Protection Switching ("R-APS") messages are used to
coordinate the activities of switching the RPL link on or off.
Ethernet Shared Protection Ring ("E-SPRing") is one instantiation,
i.e. one embodiment, of the ERP standard.
[0005] Any failure along the ring triggers an R-APS Signal Fail
message, also known as a Failure Indication Message ("FIM"), along
both directions from the nodes adjacent to the failed link after
these nodes have blocked the port facing the failed link. On
obtaining this message, the RPL owner node unblocks the RPL port.
Because at least one link has failed somewhere in the ring, that
there can be no loop formation in the ring. During the recovery
phase, when the failed link gets restored, the nodes adjacent to
the restored link send RAPS No Request messages, also known as a
Recovery Indication Messages ("RIM"). Upon obtaining a RIM message,
the RPL owner blocks the RPL port and sends an R-APS OK message,
which causes all other nodes, other than the RPL owner node in the
ring to unblock all blocked ports.
[0006] The E-SPRing protocol is robust enough to work for
unidirectional failure and in case of multiple failures in the
ring. However, there is currently no mechanism provided by the
E-SPRing protocol, i.e., ITU-T G.8032, to determine the actual Ring
Topology, i.e., the nodes and links that form the ring.
[0007] Ring topology is required to perform ring topology
validation. In other words, when a service provider provisions
and/or configures a ring, a tool is needed to validate that the
actual configuration is what was expected. In addition, if/when a
ring failure occurs, the service provider or repair technician has
no convenient means to determine exactly where the fault
occurs.
[0008] Additionally, when a fault or topology change occurs, each
node temporarily clears or "flushes" its current Forwarding
Database ("FDB"), a table which contains the routing configuration
from the point of view of the current node. If data arrives at a
node for forwarding during the time interval between the FDB
flushing and establishing a new FDB, the node does not know exactly
how to forward the data. In this case, the node simply "floods" the
ring by forwarding the data through each port resulting in poorer
ring bandwidth utilization during a ring protection and recovery
event.
[0009] Therefore, what is needed is a method and system for
discovering the topology composition of Ethernet rings and to
update data forwarding tables upon Protection and Recover switching
without flooding the network.
SUMMARY OF THE INVENTION
[0010] The present invention advantageously provides a method,
apparatus and system for automatically rerouting data in a
communication network ring when a link in the ring fails.
Additionally, an automatic topology mechanism may be used to
reconfigure the forward database tables upon notification of a
failed or recovered link without flooding the communication network
ring.
[0011] In accordance with one aspect of the present invention, a
method is provided for rerouting data in a communication network
ring. The ring includes a plurality of nodes and a plurality of
links. Each node includes a first port and a second port. Each
first port is connected to a neighboring second port through a link
of the plurality of links. The topology of the communication
network ring is discovered and a forwarding database table is
populated with static entries according to the discovered topology.
Upon receiving notice of a failed link, which includes a source
address of a node adjacent to the failed link, the topology and the
source address of the node adjacent to the failed link is used to
reconfigure the forwarding database table. Data is forwarded using
the reconfigured forwarding database table.
[0012] In accordance with another aspect of the present invention,
a node of a communication network ring includes a first port, a
second port and a processor. The ring includes a plurality of
nodes. Each first port is connected to a neighboring second port
through a link. Each of the first port and the second port are
operable to receive and transmit data. The processor is
electrically connected to each port. The processor operates to
determine the topology of the ring and to populate a forwarding
database table with static entries according to the topology.
Responsive to receiving notice of a failed link, which includes a
source address of a node adjacent to the failed link, the processor
further operates to use the topology and the source address of the
node adjacent to the failed link to reconfigure the forwarding
database table. Data is forwarded using the reconfigured forwarding
database table.
[0013] In accordance with yet another aspect of the present
invention, a system for rerouting data a communication network ring
includes a plurality of nodes interconnected in a ring
configuration. Each node includes a first port, a second port and a
processor. Each port is operable to receive and transmit data. The
processor is electrically connected to each port. The processor
operates to determine the topology of the ring and populate a
forwarding database table with static entries according to the
topology. Responsive to receiving notice of a failed link, which
includes a source address of a node adjacent to the failed link,
the processor further operates to use the topology and the source
address of the node adjacent to the failed link to reconfigure the
forwarding database table, refrain from flooding the ring and
forward data using the reconfigured forwarding database table.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] A more complete understanding of the present invention, and
the attendant advantages and features thereof, will be more readily
understood by reference to the following detailed description when
considered in conjunction with the accompanying drawings
wherein:
[0015] FIG. 1 is a block diagram of an exemplary Ethernet ring
utilizing a ring discovery mechanism constructed in accordance with
the principles of the present invention;
[0016] FIG. 2 is a block diagram of an exemplary E-SPRing node
constructed in accordance with the principles of the present
invention;
[0017] FIG. 3 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by an RPL owner node during a NORMAL
state according to the principles of the present invention;
[0018] FIG. 4 is an exemplary Ethernet Ring Topology Discovery
("ETD") Type-Length Value ("TLV") field constructed in accordance
with the principles of the present invention;
[0019] FIG. 5 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by each tandem node on an E-SPRing ring
during a NORMAL state according to the principles of the present
invention;
[0020] FIG. 6 is a control diagram of an exemplary Ethernet ring
topology discovery mechanism operating during a NORMAL state
according to the principles of the present invention;
[0021] FIG. 7 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by a node adjacent to a fault during a
PROTECT state according to the principles of the present
invention;
[0022] FIG. 8 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by each tandem node on an E-SPRing ring
during a PROTECT state according to the principles of the present
invention;
[0023] FIG. 9 is a control diagram of an exemplary Ethernet ring
topology discovery mechanism operating during a PROTECT state
according to the principles of the present invention;
[0024] FIG. 10 is a block diagram of an exemplary Ethernet ring
using an alternative automatic discovery mechanism constructed in
accordance with the principles of the present invention;
[0025] FIG. 11 is an exemplary Ring Trace Message constructed in
accordance with the principles of the present invention;
[0026] FIG. 12 is an exemplary Ring Trace Reply Message constructed
in accordance with the principles of the present invention;
[0027] FIG. 13 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by an originating node according to an
alternative embodiment of the present invention;
[0028] FIG. 14 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by a responding node according to an
alternative embodiment of the present invention;
[0029] FIG. 15 is a block diagram of an exemplary Ethernet ring
using another alternative automatic discovery mechanism constructed
in accordance with the principles of the present invention;
[0030] FIG. 16 is an exemplary Continuity Check Message ("CCM")
Ring Trace Type-Length Value ("TLV") field constructed in
accordance with the principles of the present invention;
[0031] FIG. 17 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by an originating node according to the
principles of an alternative embodiment of the present
invention;
[0032] FIG. 18 is a flowchart of an exemplary Ethernet ring auto
discovery process performed by a responding node according to the
principles of an alternative embodiment of the present
invention;
[0033] FIG. 19 is a flowchart of an exemplary Ethernet ring auto
discovery process according to the principles of an alternative
embodiment of the present invention;
[0034] FIG. 20 is a flowchart of an exemplary Ethernet ring
topology discovery process according to the principles of an
alternative embodiment of the present invention;
[0035] FIG. 21 is a block diagram of an exemplary Ethernet ring
during a NORMAL state;
[0036] FIG. 22 is a block diagram of an exemplary Ethernet ring
responding to a failure event by flooding the network;
[0037] FIG. 23 is a block diagram of an exemplary Ethernet ring
responding to a failure event by rerouting only a broken link
according to the principles of the present invention;
[0038] FIG. 24 is a block diagram of an exemplary E-SPRing ring
showing forwarding tables constructed in accordance with the
principles of the present invention; and
[0039] FIG. 25 is a block diagram of an exemplary E-SPRing forward
database flushing nullification mechanism constructed in accordance
with the principles of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0040] Before describing in detail exemplary embodiments that are
in accordance with the present invention, it is noted that the
embodiments reside primarily in combinations of apparatus
components and processing steps related to implementing a system
and method for automatically discovering ring topology in an
Ethernet-Shared Protection Ring and using the topology to prevent
forward database flushing. Accordingly, the system and method
components have been represented where appropriate by conventional
symbols in the drawings, showing only those specific details that
are pertinent to understanding the embodiments of the present
invention so as not to obscure the disclosure with details that
will be readily apparent to those of ordinary skill in the art
having the benefit of the description herein.
[0041] As used herein, relational terms, such as "first" and
"second," "top" and "bottom," and the like, may be used solely to
distinguish one entity or element from another entity or element
without necessarily requiring or implying any physical or logical
relationship or order between such entities or elements.
[0042] Embodiments of the present invention provide different
mechanisms that may be used in coordination with the Ethernet Ring
Protection ("ERP") protocol defined by ITU-T G.8032 to determine
the ring topology. Ring topology is used for general operations,
administration and maintenance ("OAM") functions such as, but not
limited to ring topology confirmation and ring topology fault
discovery.
[0043] One embodiment of the present invention extends ITU-T G.8032
Ethernet Ring Automated Protection Switching ("R-APS") messages
over the ring to optionally piggyback topology information. This
mechanism specifies how each ring node embeds unique ring node
signature information in various R-APS messages. The R-APS messages
provide a cumulative view of ring node signatures, allowing each
ring node to determine the overall ring topology.
[0044] Another embodiment of the present invention utilizes per hop
IEEE 802.1ag or ITU-T Y.1731 continuity check protocol messages
over the ring. This mechanism introduces a G.8032 R-APS message,
which is a type of continuity check message ("CCM") that circulates
the ring. At each hop, a ring node inserts a ring node signature in
the R-APS CCM being circulated around the ring.
[0045] Yet another embodiment of the present invention utilizes the
IEEE 802.1ag or ITU Y.1731 Linktrace protocol over the ring. This
mechanism extends and leverages the 802.1ag/Y.1731 LinkTrace
protocol by using the time-to-live parameters returned in Link
Trace Reply ("LTR") messages to determine the relative position of
each node in the ring, i.e., number of hops away from a requesting
node.
[0046] Using the ring topology discovery mechanisms, an embodiment
of the present invention prevents the need to flush the ring node
Forwarding Databases ("FDBs") during a protection and recovery
switch. When the ring is supported over an encapsulated network, as
defined by IEEE specification 802.1ah, also known as "MAC in MAC,"
ring nodal extensions may be applied such that no flushing of the
FDB is required, thereby significantly improving the overall
bandwidth utilization of the ring.
[0047] Referring now to the drawing figures in which like reference
designators refer to like elements, there is shown in FIG. 1 an
exemplary communication network 10 arranged in an E-SPRing
configuration which advantageously employs automatic ring topology
discovery in accordance with the principles of the present
invention. Exemplary communication network 10 is hereinafter
referenced as "E-SPRing ring" 10. E-SPRing ring 10 includes an
array of nodes 12a, 12b, 12c, 12d, and 12e (referred to
collectively as nodes 12) arranged in a ring configuration. Each
node 12 includes two forwarding ports designated as p1 14 and p2
16, respectively. In a ring configuration, each node 12 is
connected to only two other nodes 12 with port p1 of any node 12
connected to port p2 of its neighboring node 12. Ports p1 14 and p2
16 may also be known as an "East" port and a "West" port,
respectively. In network 10, node 12a is the Ring Protection Link
("RPL") owner node as its port p1 14 is the RPL port.
[0048] The nodes 12 may include wireless access points, routers,
switches, gateways or any other device commonly known to support
bridging functions in a communication network. Each node 12 may
also be connected to one or more client devices (not shown) and
routes data packets between client devices along the ring using
commonly used communication protocols such as Transmission Control
Protocol/Internet Protocol ("TCP/IP"), Ethernet, etc. Of note,
although several of the figures show four, five or six nodes 12, it
is understood that the amount of nodes 12 shown are solely to aid
explanation. A network 10, constructed in accordance with the
principles of the present invention, may have any number of nodes
12, as long as the nodes are interconnected in a ring
configuration.
[0049] In FIG. 1, the E-SPRing ring 10 is shown operating in a
"Normal State" as specified in ITU-T G.8032. In this mode, the RPL
owner node 12a initiates transmission of an R-APS "OK" message from
each of its ports 14, 16. The R-APS "OK" message is forwarded
through the ring in a clockwise direction from port p1 14 along
path 18. Eventually, the R-APS "OK" message is received back at the
RPL owner node 12a at port p2 16. Likewise, another R-APS "OK"
message is forwarded through the ring in a counter-clockwise
direction from port p2 16 along path 20 and is eventually received
back at the RPL owner node 12a at port p1 14.
[0050] Referring now to FIG. 2, an exemplary node 12 includes a
communication interface 22 communicatively coupled to a controller
24. The communication interface 22 may be wired, wireless, or any
combination thereof The communication interface 22 interacts with
two ports, p1 14 and p2 16, to transfer data packets between the
network nodes 12 and client devices (not shown) using known
communication protocols, e.g., Ethernet, Wi-Fi, etc. The controller
24 controls the processing of information and the operation of the
network node 12 in a well-known manner. The controller 24 is also
coupled to a non-volatile memory 26.
[0051] The non-volatile memory 26 includes a data memory 28 and a
program memory 30. Examples of non-volatile memory include, but are
not limited to, a hard drive, a memory stick, an Electrically
Erasable Programmable Read-Only Memory ("EEPROM"), a flash memory,
etc. Additionally, instead of or in addition to non-volatile
memory, the data memory 28 may be included as some form of volatile
memory, e.g., RAM. The program memory 30 contains a route director
32 which determines the routing topology of the E-SPRing ring 10
and maintains two state topology tables: an active state topology
table 34 and a normal state topology table 36. The operation of the
route director 32 is discussed in more detail below. The data
memory 28 stores data files such as the active state topology table
34, the normal state topology table 36, forwarding database ("FDB")
tables 37 and various other user data files (not shown).
[0052] The normal state topology table 36 contains the topology of
the E-SPRing ring 10 when there are no faults on the ring 10. This
table 36 coincides with the "Normal State" specified in ITU-T
G.8032. The normal state topology table 36 is only updated when an
"OK" message is received on both ports, p1 14 and p2 16. Otherwise,
the values in the table 36 are persistent.
[0053] The active state topology table 34 contains the topology
change in the E-SPRing ring 10 when at least one or more faults
have occurred or are in recovery. These conditions coincide with
the "Protect State" and "Pending State" specified in ITU-T G.8032.
The purpose of the active state topology table 34 is to facilitate
advanced topology reporting, and to reduce potential processing in
maintaining topology information. In the absence of faults, the
active state topology table 34 is ignored.
[0054] The FDB tables 37 instruct each node 12 as to which port 14,
16 to use to forward data to other nodes in the ring 10. The FDB
tables 37 are not to be confused with the topology tables 34,
36.
[0055] Referring now to FIG. 3, an exemplary operational flowchart
is provided that describes steps performed by a route director 32
of an RPL owner node 12a for automatically discovering the ring
topology when the ring 10 is operating in a Normal State. The route
director 32 introduces an Ethernet Ring Topology Discovery ("ETD")
type-length-value ("TLV") element to carry Ethernet Ring node
information and a node count. The route director 32 of the RPL
owner node 12a initiates an R-APS "OK" message, such as one
specified by the guidelines according to ITU-T G.8032 (step S102).
The route director 32 updates the active state topology table 34
(step S104) and adds node information, also referred to as a
signature, to the ETD TLV (step S106). The signature is a set of
one or more attributes that uniquely identifies a node on the
Ethernet Ring ring 10.
[0056] An exemplary Ethernet Ring Topology Discovery TLV 38,
constructed in accordance with the principles of the present
invention, is provided in FIG. 4. The new ETD TLV 38 is composed of
a Type field 40 (1 octet), Length field 42 (2 octets), an optional
Node count 44 (1 octet) and one or more Signature fields 46 (m
octets). The Length field 42 indicates the size of the TLV 38 in
octets, not including the Type 40 and Length fields 42. The Node
count 44, if specified, indicates the number of Signature fields 46
in the TLV 38. The Signature field 46 should contain, at a minimum,
a Ring unique node identifier, such as a nodal MAC address, or node
identifier. The Signature field 46 may optionally contain
additional nodal information, such as one or more of the following
(but not limited to): a text label, nodal state, port(s) state, RPL
owner, fault condition, configuration information.
[0057] Returning to FIG. 3, the route director 32 of the RPL owner
node 12a sets the node count equal to zero (step S108), inserts the
new ETD TLV 38 into an R-APS "OK" message (step S110), and forwards
the message out both ports, such as one specified by ITU-T G.8032.
R-APS messages with the new ETD TLV can follow the same forwarding
and loop avoidance procedures defined by the ITU-T G.8032
specification
[0058] The exemplary operational flowchart of FIG. 5 describes
steps performed by each remaining, or tandem, node of the Ethernet
Ring ring 10 when the ring 10 is operating in a Normal State. Each
node receives an R-APS "OK" message at one of its ports 14, 16
(step S114), wherein the R-APS "OK" message has been forwarded to
the node by its neighboring node. The route director 32 of the
receiving node extracts the topology contents of the ETD TLV 38 and
uses that information to update its normal state topology table 36
(step S116). The route director 32 appends the signature of the
current node to the received ETD TLV 38 (step S118) and increments
the node count by one (step S120) before forwarding the R-APS "OK"
message out of the "mate" ring port, i.e., the port that did not
receive the message, such as one defined by ITU-T G.8032 (step
S122). It should be noted that each receiving node repeats the
process of FIG. 5 twice for each automatic discovery request
initiated by the RPL owner node 12a, each receiving node receives
an R-APS "OK" message at each of its two ports 14, 16. Given that
the ring 10 has a fixed topology, the sequence of nodes 12 that
tandem an R-APS message with the ETD TLV 38 sourced by a given node
indicates the relative distance from the source node, i.e., the
node count in the ETD TLV 38.
[0059] FIG. 6 is a control diagram illustrating an exemplary
Ethernet ring topology discovery mechanism operating during a
NORMAL state using the processes defined in FIGS. 3 and 5. In FIG.
6, node A 12a is the RPL owner node, thus its port p1 is blocked.
Node A 12a initiates R-APS "OK" messages containing nodal
information and transmits these messages out both ports along paths
18 and 20. Nodal information originating or appended at each node
12 is shown in FIG. 6 in chart form. Charts 48a, 48b, 48c, 48d and
48e (referenced collectively as chart 48) contain information added
at each node 12 along path 18. Charts 50a, 50b, 50c, 50d and 50e
(referenced collectively as chart 50) contain information added at
each node 12 along path 20. When each node 12 has received an R-APS
"OK" message at both ports 14, 16, then each node 12 in the ring 10
has a complete topology of the entire ring 10.
[0060] The methodology described above in relation to an E-SPRing
NORMAL state may be similarly applied to detect a fault in the
ring. Referring now to FIGS. 7-9, the use of the ETD TLV 38
mechanism may also be used in the PROTECT and PENDING states in
conjunction with Failure Indication Messages ("FIM") and Recovery
Indication Messages ("RIM"), respectively. In FIG. 7, an exemplary
operational flowchart is provided that describes steps performed by
a route director 32 of a node 12 adjacent to a failed link for
automatically discovering the ring topology when the ring 10 enters
into a PROTECT State.
[0061] Beginning at step S124, the route director 32 of each node
adjacent to a failed link initiates an R-APS "FIM" message, such as
one specified in ITU-T G.8032. In the control flow diagram of FIG.
9, node C 12c and node D 12d are adjacent to failed link 52, thus
both node C 12c and node D 12d follow the process outlined in FIG.
7. The route director 32 updates the active state topology table to
reflect the failed link 52 (step S126), adds the signature of the
node to the ETD TLV 38 (step S128), and sets the node count field
44 of the ETD TLV 38 equal to zero (step S130). The route director
32 inserts the ETD TLV 38 into the
[0062] "FIM" message (step S132) and the communication interface 22
forwards the "FIM" message out the port opposite the fault, e.g.,
failed link 52, such as one specified by ITU-T G.8032 (step
S134).
[0063] Turning now to FIG. 8, an exemplary operational flowchart is
provided that describes steps performed by a route director 32 of
each tandem node 12 of the Ethernet Ring ring 10, i.e., all nodes
not adjacent to a failed link, for automatically discovering the
ring topology when the ring 10 enters into a PROTECT State. Each
node receives an R-APS "FIM" message at one of its ports 14, 16
(step S136), wherein the R-APS "FIM" message has been forwarded to
the node by its neighboring node. The route director 32 of the
receiving node extracts the topology contents of the ETD TLV 38 and
uses that information to update its active state topology table 34
(step S138). The route director 32 appends the signature of the
current node to the received ETD TLV 38 (step S140) and increments
the node count by one (step S142). If the receiving node is the RPL
owner node (step S144), the communication interface 22 temporarily
removes the block from the RPL port (step S146). The communication
interface 22 forwards the R-APS "FIM" message out of the "mate"
ring port, i.e., the port that did not receive the message, such as
one defined by ITU-T G.8032 (step S146).
[0064] FIG. 9 is a control diagram illustrating an exemplary
Ethernet ring topology discovery mechanism operating during a
PROTECT state using the processes defined in FIGS. 7 and 8. In FIG.
9, the link 52 between node C 12c and node D 12d has failed,
therefore, both node C 12c and node D 12d initiate R-APS "FIM"
messages containing nodal information and transmit these messages
out the port opposite the failed link 52, i.e., port p1 for node C
12c and port p2 for node D 12d, along paths 18 and 20. Nodal
information originating or appended at each node 12 is shown in
FIG. 9 in chart form. Charts 54a, 54b, 54c and 54e (referenced
collectively as chart 54) contain information added at each node 12
along path 18. Charts 56a, 56b, 56d and 56e (referenced
collectively as chart 50) contain information added at each node 12
along path 20. When each tandem node 12b, 12a, 12e has received an
R-APS "FIM" message at both ports 14, 16, and each originating node
12c, 12d have received an R-APS "FIM" message at the port opposite
failed link 52, then each node 12 in the ring 10 has a complete
topology of the entire ring 10.
[0065] When the failed link 52 has been reestablished, the
procedures of FIGS. 7 and 8 are primarily performed once again upon
entering a "PENDING" state, except that the nodal information
provided in an ETD TLV of a "FIM" message, is now sent in a "RIM"
message. In other words, the nodes originally initiating
transmission of "FIM" messages originate "RIM" messages and forward
these messages out the port opposite the previously failed link 52.
It should be noted that the RPL owner node reestablishes a block on
the RPL port once it has received "RIM" messages on both of its
ports.
[0066] Although described above in relation to the E-SPRing
protocol, application of this mechanism and the R-APS message
extensions may be applied to any Ring based protocol.
[0067] Referring now to FIG. 10, an alternative embodiment of the
present invention provides another mechanism for automatic ring
topology discovery. In this embodiment, the IEEE 802.1ag Linktrace
protocol is utilized over the Ethernet Ring to determine the ring
topology. This mechanism inserts an R-APS Virtual Local Area
Network Identifier ("VID") 60 into each LinkTrace message, i.e.,
ETH-LTM, to identify the ring, as shown in the exemplary LTM 58 of
FIG. 11. The utilization of the R-APS VID in the message ensures
that LinkTrace information is collected for the designated Ethernet
Ring. The Ethernet Ring reserved group address is used as the
Destination Address ("DA") and designated in the group address
field 62. The utilization of the Ethernet Ring reserved group
address ensures that all related LinkTrace messages stay local to
the ring. It should be noted that under the currently proposed IEEE
802.1ag protocol, the Target MAC 64 is specified as a unicast
address. However, to implement this mechanism, the Target MAC
address 64 should be a group address, i.e. a multicast address.
[0068] This embodiment advantageously uses the Time-to-Live ("TTL")
field 66 of the LTM 58 to determine the relative distance of each
node 12 in the Ethernet Ring 10 from an originating node. An
initiating node, e.g., node F 12f in FIG. 10, sends the LTM 58 out
each of its ports 14, 16. All other nodes 12 in the ring 10 respond
back to the originating node, through the same port in which the
LTM 58 was received, with a LinkTrace Reply ("LTR") message, and
forward the LTM 58 to the next node in the ring 10 through the mate
port. An exemplary LTR message 70 is provided in FIG. 12. It should
be noted that the values of the R-VLAN field 60 and the Group
address field 62 of the LTR 70 are the same as in the original LTM
58; however, the value of the MAC address of source device field 68
changes to reflect the receiving node. Each node 12 decrements the
value of TTL field 66 when either an LTM 58 or an LTR 70 arrives at
the node 12. Because the ring topology is fixed, the value of the
TTL field 66, along with the MAC Address of the source device 68,
is used to determine the position of each node 12 in the ring
10.
[0069] An originating node creates an LTM 58 and transmits the LTM
58 out both ports 14, 16. When the neighboring nodes receive the
LTM 58, each node decrements the TTL value, creates a LTR 70 having
the same TTL value as the current LTM 58, transmits the LTR 70
through the same port that received the LTM 58, and forwards the
LTM 58 on to the next neighboring node in the ring 10. When a
non-originating node receives an LTR 70 from a neighboring node, it
decrements the TTL value and forwards the LTR 70 through the
opposite (mate) port, back toward the originating node.
[0070] Referring now to FIGS. 13 and 14, exemplary operational
flowcharts are provided which describe steps performed by the ring
nodes 12 to automatically discover the ring topology. FIG. 13
details steps performed by an initiating node. The initiating node
creates a LTM and transmits the LTM through each port (step S150).
In response to the LTM, the initiating node receives an LTR from
another node in the ring (step S152). The initiating node
decrements the current TTL value of the LTR (step S154), and
calculates the distance of the node sending the LTR from the
originating node (step S156), i.e., the "hop count (H)" according
to the equation:
H=(TTL.sub.LTM-TTL.sub.LTR)/2. (1)
[0071] When all of the nodes in the ring have responded (step
S158), the initiating node determines the overall ring topology
using the hop count, the MAC address of the source device and the
port through which the LTR was received (step S160).
[0072] FIG. 14 details steps performed by each remaining node of
the ring. A node receives a message through one of its ports (step
S162) and decrements the TTL value (step S164). If the message is a
LTR (step S166), the node simply forwards the message out the mate
port to the next neighboring port (step S168). If the message is a
LTM (step S166), the node creates a LTR, sets the TTL value of the
LTR equal to the present TTL value of the LTM and transmits the LTR
back through the receiving port (step S170). If the node is the
last node in the ring (step S172), the process ends. However, if
there are other remaining nodes in the ring (step S172), the node
forwards the message out the mate port to the next neighboring port
(step S168).
[0073] As an example, referring back to FIG. 10, node F 12f
originates an LTM message 58 having a TTL value of 255 and forwards
the LTM 58 to node E 12e and node A 12a. Node A 12a receives the
LTM 58, decrements the TTL value to 254, creates an LTR 70 having a
TTL value of 254, and forwards the LTR 70 back to node F 12f. As
node A 12a is the RPL owner node, it is the "last" node in the
ring, node A 12a has now completed its task. When node F 12f
receives the LTR 70 from node A 12a, it decrements the TTL value to
253 and determines the hop count for node A 12a, e.g.,
H=(255-253)/2=1. Thus, node F 12f knows that node A 12a is 1 hop
away through port p1.
[0074] When node E 12e receives the LTM 58, it replies in the same
fashion as node A 12a, but also forwards the LTM 58 on to
neighboring node D 12d. As above, node F 12f now knows that node E
12e is 1 hop away through port p2. When node D 12d receives the LTM
58, it decrements the TTL value again (TTL=253), returns a LTR 70
to node E 12e having a TTL value that is equal to the current TTL
value, i.e., 253, and forwards the LTM 58 to node C 12c. When node
E 12e receives the LTR 70 from node D 12d, it decrements the TTL
value (TTL=252) and forwards the LTR 70 on to node F 12f. Again,
node F 12f decrements the TTL value (TTL=251) and calculates the
hop count (H=(255-251)/2=2). This process continues until node F
12f has discovered every node in the ring and determined the
position of each node.
[0075] Referring now to FIG. 15, another alternative embodiment of
the present invention provides another mechanism for automatic ring
topology discovery. In this embodiment, messages such as the IEEE
802.1 ag tag continuity check messages ("CCM") are used to
determine the ring topology. Given that the ring is a fixed
topology, the sequence of nodes that transmit a CCM sourced by a
given node indicates the relative hop distances. This mechanism
employs a special "Auto Discovery" CCM ("AD_CCM") for use by
intermediate nodes forwarding a CCM sourced by a given node. The
intermediate nodes append a signature, such as the MAC address of
the intermediate node, before transmitting the AD_CCM to the next
node. As the listing of signatures in the AD_CCM grows, the
topology of the ring is revealed. A representation of the signature
listing 72 for each node 12 is shown in FIG. 15 beside its
corresponding node 12. In other words, listing 72a corresponds to
node A 12a, listing 72b corresponds to node B 12b, etc.
[0076] A RingTrace TLV within the AD_CCM contains the listing of
nodes discovered on the ring. An exemplary RingTrace TLV 74 is
shown in FIG. 16. Each a node adds its signature 76 to the
RingTrace TLV 74 upon receipt, increments the node count 78 value,
and forwards the special CCM to the neighboring node through the
mate port. When the special CCM completes the routing through the
ring 10 and returns to the originating node, the listing contains
all nodes in the ring and the position of each node.
[0077] Referring now to FIGS. 17-20, exemplary operational
flowcharts are provided which describe steps performed by the ring
nodes 12 to automatically discover the ring topology according to
this alternative embodiment of the present invention. FIG. 17 is a
flowchart of an exemplary Ethernet ring auto discovery process
performed by an originating node. The originating node periodically
transmits an AD_CCM through the ring to verify the topology. Thus,
if the time frame for sending an AD_CCM has passed (step S174),
i.e. (currentTime-TxTime).gtoreq.period, the originating node
transmits an AD_CCM to a neighboring node (step S176) and resets
the transmit time to the current time (step S178).
[0078] Referring to FIG. 18, an exemplary operational flowchart is
provided which describes steps performed by each receiving node 12
in the ring. The process begins when a node 12 receives a message
("RxMsg") from a transmitting node (step S179), and checks to see
if the received message is a special auto-discovery CCM ("AD_CCM")
(step S180). If the received message is not an AD_CCM (step 5180,
"NO" branch), the node 12 simply waits to receive the next message.
If the received message is an AD_CCM (step 5180, "YES" branch), the
node 12 checks to see if the AD_CCM was originated by the current
node (step S182), i.e., the Source Address in the AD_CCM is the
Address of the current node. If the message was not originated by
the current node, the node performs an auto-discovery routine (step
5184) according to the steps shown in FIG. 19, and dispatches the
AD_CCM out the mate port to the next node in the ring (step S186).
However, if the message was originated by the current node (step
S182), the node removes the message from the ring (step S188) and
computes the topology of the ring from the TLV information in the
message as shown in FIG. 20 (step S190). The message is then
discarded (step S192) and the process loops back to await the next
message.
[0079] Turning now to the auto-discovery routine shown in FIG. 19,
the receiving node appends its Media Access Control ("MAC") address
to the list of signatures in the RingTrace TLV of the AD_CCM (step
S194) and increments the node count value in the RingTrace TLV by
one (step S196). The node recomputes the cyclic redundancy check
("CRC") for the AD_CCM (step S198).
[0080] Referring now to FIG. 20, an operational flowchart is
provided which describes exemplary steps of a topology routine
performed by the originating node upon receipt of the AD_CCM after
cycling through the other nodes of the ring. The variable "X" is
used as an index into the topology TLV that represents the node
currently being processed in the message. As the process begins
with the first node listed in the TLV, the value of X is reset to
"1" (step S200). The node checks the node count in the TLV to
determine if there is more than one node, namely itself, on the
ring (step S202). In other words, if there is only 1 (or 0) node
reported in the message then the "ring" only contains the
originating node, so do nothing
[0081] If there are more nodes remaining in the TLV (step S202),
i.e., 2 or more nodes reported in the TLV, and if the current node
being processed is in the second half of the reported nodes (step
S204), then the current node is added to the topology database as
existing out the port from which the message was transmitted (step
S206), i.e., Address=AD_CCM source address, VID=AD_CCM VID, and
Port=AD_CCM Tx port. The index value is incremented to go to the
next reported node in the TLV (step S208). If there are more nodes
in the TLV (step S202), continue ("NO" branch), otherwise stop and
report the discovered topology ("YES" branch"). Returning to
decision block S204, if the current node being processed is in the
first half of the reported nodes, the node is added to the topology
database as existing out the port from which the message was
received (step S210), i.e., Address=AD_CCM source address,
VID=AD_CCM VID, and Port=AD_CCM Rx port. As before, the index value
is incremented to go to the next reported node in the TLV (step
S208), and if there are more nodes in the TLV (step S202), continue
("NO" branch), otherwise stop and report the discovered topology
("YES" branch").
[0082] The embodiments described above may be used in combination
with a method of Protection and Recovery switching that prevents
flooding of the ring without flushing the forwarding tables 37.
FIGS. 21-23 illustrate the flooding problem which occurs as a
result of flushing the forwarding tables 37. Referring to FIG. 21,
a ring network 10 having four nodes 12a, 12b, 12c, 12d is shown.
Forwarding tables 37 for each node instruct the node 12 as to which
port to use when forwarding data to every other node in the ring.
Thus, in accordance with the forwarding tables, the active
communication links 80a, 80b, 80c, 80d are established between
neighboring nodes 12. Communication traffic travelling between node
A 12a and node B 12b flows along path 82a; traffic travelling
between node B 12b and node C 12c flows along path 82b; traffic
travelling between node C 12c and node D 12d flows along path 82c;
and traffic travelling between node D 12d and node A 12a flows
along path 82d.
[0083] FIG. 22 illustrates a scenario wherein communication link
80c between node C 12c and node D 12d is broken. As traffic can no
longer flow directly between node C 12c and node D 12d, all
communication paths 82a, 82b, 82c, 82d are rerouted to bypass the
broken link 80c. Immediately after the break 84 occurs, the
forwarding tables for each node 12 are flushed. Because each node
12 no longer "knows" to which node 12 traffic is to be forwarded,
all nodes 12 momentarily "flood" the ring with traffic by sending
data to all other nodes 12 in the ring 10. Thus, assuming each
communication path 82 originally occupied a bandwidth of x, during
this flooding time, each communication path 82 has to support a
bandwidth of 4x, i.e., all the traffic from each node 12. In this
example, flushing the forwarding tables results in a 300% increase
in bandwidth demand. Generally, in the worst case scenario where
traffic is evenly distributed across a ring having N nodes, the
increase in bandwidth demand is (N-1)*100%.
[0084] When the forwarding tables 37 have been reconstructed to
account for the break 84, as shown in FIG. 23, the original
communication paths 82a, 82b, 82d are reestablished, with only path
82c between node C 12c and node D 12d being rerouted around the
ring 10.
[0085] Referring now to FIG. 24, a block diagram of an E-SPRing
ring 10 is provided which shows the forwarding database tables 37
for each node 12 in the ring 10. The forwarding database tables 37
contain a broadband destination address ("BDA") of each node 12 in
the ring 10, as well as which port to use when sending data to the
corresponding destination node. These static entries in the
forwarding database tables 37 are populated by an E-SPRing control
entity after executing some type of ring discovery process, such as
one of the embodiments of an automatic ring topology discovery
process described above.
[0086] When a failure occurs, as shown in FIG. 25, in accordance
with the principles of the present invention, instead of flushing
the forwarding database tables 37 entries for each node, all ring
nodes 12 are notified of the failure via an R-APS Failure
Indication Message ("FIM"). Each FIM contains the address of the
source node adjacent to the failure. All the E-SPRing nodes 12
recompute the target ring node BDA-to-port associations based on
the known topology and source node, and begin forwarding data
according to the new configuration. As a result of this
reconfiguration, no flooding occurs over the ring due to protection
and recovery switching. Thus, the overall bandwidth utilization of
the ring is significantly improved.
[0087] The present invention can be realized in hardware, software,
or a combination of hardware and software. Any kind of computing
system, or other apparatus adapted for carrying out the methods
described herein, is suited to perform the functions described
herein.
[0088] A typical combination of hardware and software could be a
specialized or general purpose computer system having one or more
processing elements and a computer program stored on a storage
medium that, when loaded and executed, controls the computer system
such that it carries out the methods described herein. The present
invention can also be embedded in a computer program product, which
comprises all the features enabling the implementation of the
methods described herein, and which, when loaded in a computing
system is able to carry out these methods. Storage medium refers to
any volatile or non-volatile storage device.
[0089] Computer program or application in the present context means
any expression, in any language, code or notation, of a set of
instructions intended to cause a system having an information
processing capability to perform a particular function either
directly or after either or both of the following a) conversion to
another language, code or notation; b) reproduction in a different
material form.
[0090] In addition, unless mention was made above to the contrary,
it should be noted that all of the accompanying drawings are not to
scale. Significantly, this invention can be embodied in other
specific forms without departing from the spirit or essential
attributes thereof, and accordingly, reference should be had to the
following claims, rather than to the foregoing specification, as
indicating the scope of the invention.
* * * * *