Sunteți pe pagina 1din 9

UNDERSTANDING

ETHERNET RING
PROTECTION SWITCHING
FOR CARRIER NETWORKS
ARMSTRONG MATHIYALAGAN
Assistant Vice President, Technology, Aricent
RAJESH KUMAR SUNDARARAJAN
Assistant Vice President, Product Management, Aricent
EMREEN F. XAVIER
Technical Leader, Aricent
YARLAGADDA KISHORE KUMAR
Principal Systems Engineer, Aricent
1 Understanding Ethernet Ring Protection Switching for Carrier Networks
Loop formation in the ring is avoided by ensuring that, at any
time, trafc may ow through all but one of the links in the ring.
This particular link, through which trafc is normally not allowed
to ow, is called the Ring Protection Link (RPL). Under normal
conditions, when there are no failures in the ring, the RPL is
blocked and therefore does not allow any trafc ow.
The node where the RPL is congured is called the RPL owner.
The port on the RPL owner, to which the RPL is connected, is
called the RPL port. The node, adjacent to the RPL owner node
and connected to the RPL owner node through the RPL, is called
the RPL neighbor. The RPL owner blocks or unblocks the port
connected to the RPL. The RPL neighbor may also participate in
blocking or unblocking its end of the RPL.
INTRODUCTION TO ERPS
The ring is a popular topology employed in networks to provide
redundant path connectivity between nodes. At the same time,
because the ring provides an alternative path between nodes,
loops exist in the network. Therefore, the key to using the ring
topology in networks has been to harness the redundancy when
required while avoiding loops. These very same principles lie at
the core of the ITU-T G.8032 Ethernet Ring Protection Switching
(ERPS) recommendation.
An Ethernet ring consists of ring nodes that form a closed physical
loop. Each ring node is connected to two adjacent Ethernet ring
nodes via a duplex communications facility.
UNDERSTANDING
ETHERNET RING
PROTECTION SWITCHING
FOR CARRIER NETWORKS
Ethernet Ring Protection Switching (ERPS), as dened in the G.8032 recommendation, is an
efort from the ITU-T to provide a highly reliable and stable protection mechanism for Ethernet
ring networks. It helps transport-network operators design resilient networks with very high
quality of service (QoS) characteristics and service level agreements (SLAs). Link failures are a
common occurrence in networking, so many methods exist to improve network reliability in
the event of connectivity loss between network elements. A SONET (Synchronous Optical
Network) or SDH (Synchronous Digital Hierarchy) ring is an example of a self-healing network
technology that provides a high level of protection in data broadband networks. RPR (Resilient
Packet Ring), dened in IEEE 802.17, is another technology for the optimized transport of data
trafc over optical ber ring networks that provides a resilience similar to that of SONET/SDH
rings. With the increasing use of Ethernet in carrier networks, as an alternative to SONET/SDH,
it is necessary to define similar resiliency mechanisms tailored to Ethernet. The G.8032
recommendation from the ITU-T is a practical and economical mechanism to meet this objective.
2 Understanding Ethernet Ring Protection Switching for Carrier Networks
Figure 1 shows the converged ring under normal conditions with
trafc blocked on the RPL.
Figure 2 shows the converged ring under normal conditions with
both the RPL owner and the RPL neighbor blocking trafc to
the RPL.
allowing trafc ow into it, upon failure of any of the other
links or nodes, constitutes protection switching and provides
protection to the trafc between the nodes. This mechanism
for protection switching being handled by the nodes with no
administrator or operator intervention, like with the techniques
described in this paper, is known as Automatic Protection
Switching (APS). When applied to a ring, it becomes Ring-APS
(R-APS)
Each node monitors connectivity to its neighbor through the
link connecting them. The messages for monitoring and
coordination of the APS actions use a dedicated VLAN called
the R-APS VLAN. A node triggers the protection switching
when it encounters one of the following conditions:
> The node detects loss of connectivity on one of the links
connected to it
> An administrator issues an explicit command to block
another link and to move the trafc to the RPL (there are 2
diferent variations of this situation, called Forced Switch and
Manual Switch, which will be covered later in this whitepaper)
> When a previous condition of connectivity loss is corrected
and connectivity is re-established
PROTECTION SWITCHING ON DETECTION OF
CONNECTIVITY LOSS
The nodes on either end of each link send periodic connectivity
check messages to each other. The nodes use the lack of
reception of such connectivity check messages to detect
loss of connectivity. Such a failure of a link, or node, in the
ring, results in traffic being switched (protection switched)
into the RPL. The RPL owner is responsible for unblocking
the RPL, thereby allowing the RPL to be used for trafc. The
failed link is blocked in order to avoid loop formation in the
event that the failed link becomes functional at any time.
In Figure 3, failure of the link between nodes B and C results in
unblocking of the RPL while the ring converges, as shown below.
A
D
C
B
RPL Owner
RPL Link
P1 P2
P2 P1
P1
P2
P2
P1
A
D
C
B
RPL Owner

R
P
L

N
e
i
g
h
b
o
r
RPL Link
P1
P1
P2
P2
P1
P2
P2 P1
A
D
C
B
RPL Link
P1 P2
P2 P1
P1
P2
P2
P1
Figure 1: Loop avoidance by blocking RPL under normal conditions
In Figure 1, nodes A, B, C, and D form a ring. Node A is the RPL owner, and
the RPL port is Port P1 of Node A, and is blocked to avoid the trafc ow.
Figure 2: Loop avoidance by RPL owner and RPL neighbor blocking
RPL under normal conditions
In Figure 2, nodes A, B, C, and D form a ring. Node A is the RPL owner,
and the RPL port in node A is P1. Node B is the RPL neighbor and port P1
in Node B is the RPL neighbor port. Under normal condition, P1 of node
A and P1 of Node B go to a blocking state.
Figure 3: In the event of failure, RPL link opened up to provide connectivity
PROTECTION SWITCHING
In Figure 1 and Figure 2, trafc can ow from any of the nodes to
any other node through any of the links other than the RPL.
The RPL alone does not have any trafc ow. A loop is avoided
by preventing traffic flow to the RPL. The RPL is maintained
ready to be brought into service if any of the other links fail. In the
event that one of the other links fails, or if a node fails and the
connectivity between two other nodes is thereby lost, the RPL
owner and RPL neighbor, after following a protocol, start allowing
trafc ow into the RPL. This action of activating the RPL and
3 Understanding Ethernet Ring Protection Switching for Carrier Networks
Non-Revertive Mode
In the non-revertive mode of operation, when the failed link
recovers, the RPL link remains unblocked and one of the failed
ports remains in a blocked state. In situations where there
is no advantage in immediately reverting to the normal working
transport entities, such a mode is preferred. In this case, a second
trafc interruption is avoided by not reverting the protection switching.
ADMINISTRATOR-INITIATED PROTECTION SWITCHING
A network operator can manually trigger the trafc redirection
instead of it being triggered by a connectivity failure. This is done
by a forced switch or manual switch command, which is useful
in situations like maintenance operations or repair.
When the administrator issues a forced switch or manual switch
command on a specic port at a given node, the node places the
administrator-specied port into a blocked state. Based on the
protocol working, the RPL owner then unblocks the RPL to allow it
thereby allowing the RPL to be used for trafc ow.
Applying a force switch in P2 of Switch D results in the unblocking
of the RPL and the ring converging as shown below.
A
D
C
B
RPL Link
P1 P2
P2 P1
P1
P2
P2
P1
A
D
C
B
RPL Link
P1 P2
P2 P1
P1
P2
P2
P1
RPL Owner
Figure 4: On initiation of force switch by operator, RPL link opens
up to provide connectivity
In the gure above, Nodes A, B, C, and D form a ring. Node A is the RPL
owner, and the RPL port in node A is P1. When the forced switch is
applied on port P2 of Node D, the port is moved to a blocked state and
the RPL port (P1 of Node A) moves to an unblocked state.
Figure 5: Protection switching on signal recovery in non-revertive mode
In the gure above, Nodes A, B, C, and D form a ring. Node A is the RPL owner
and the RPL port in node A is P1. When the link between B and C fails and
then recovers, one of the failed ports (the highest priority port) remains in a
blocked state. The RPL port remains in an unblocked state.
PROTECTION SWITCHING ON RECOVERY FROM
LOSS OF CONNECTIVITY
After a protection switching action, when the failed link has been
repaired, there is once again a potential loop in the network.
This is avoided by the nodes detecting the recovery, and blocking
either the repaired link or the RPL, resulting in two possible
modes of operation for the ring:
> Revertive Mode
> Non-Revertive Mode
Revertive Mode
In the revertive mode of operation, when a failed link recovers,
the RPL is blocked and the failed link is unblocked to start
carrying trafc. Despite it causing an additional momentary
trafc interruption, the revertive mode may be desirable in
situations where the working transport entity resources can
be more optimized.
ERPS IN SUBTENDED (INTERCONNECTED) RINGS
ERPS also supports the protection of services that traverse
through interconnected rings. Interconnected rings can be
formed using single or dual ring nodes, or a multi-ring/ladder
network that consists of conjoined Ethernet rings. For
interconnected rings, the protection mechanism ensures that
no super loop is formed when there is a link failure between the
ring nodes.
The protection mechanism specied in the G.8032/Y.1344
standard protects interconnected rings according to the
following principles:
> R-APS VLANs are not shared across ring interconnections
> Trafc and R-APS channel of each link should be controlled
(for blocking or ushing) by the ERP control process of only
one ring
> Each ring or sub-ring must have its own RPL
The following figure represents an example of a topology
composed of interconnected rings: Ring 1 and Ring 2. The link
between the two interconnected nodes is under the control of
the ERP control processes of the ring that it is congured to be
a part of. In the example below, the ring link between nodes C
and D is under the control of Ring 1. Failure of the link between
the interconnected nodes triggers the protection switching
event on the ring that contains this link. The sub-ring is not
aware of the failure.
4 Understanding Ethernet Ring Protection Switching for Carrier Networks
ETHERNET RING PROTECTION USING RING
INSTANCES FOR LOAD BALANCING
Multiple logical ERP ring instances may be supported over
a single physical ring. For example, traffic belonging to one
VLAN may be routed in one direction while traffic belonging
to a second VLAN may be routed in the opposite direction.
When multiple ring instances are configured in a ring, some
trafc can pass through one path while other trafc can choose
a different path. This division of ring traffic supports load
balancing in the system.
When ring instances are congured for the ring, each ring instance
should have its own RPL owner, RPL neighbor, and R-APS VLAN.
ERPS VERSION 1 AND VERSION 2
The ITU-T rst standardized the G.8032 in 2006. Today it is
known as v1 or version 1 of the standard. Subsequently,
more facilities have been incorporated based on feedback
from network operators and designers. An updated version
of the G.8032 was standardized in 2010, which is now known
as v2 or version 2 of the standard.
Key improvements and enhancements in ERPS version 2
from version 1 include:
> Non-revertive mode of operation (version 1 species only
the revertive mode of operation)
> Forced Switch command for administrators
> Manual Switch command for administrators
> Increased support for ERP instances to protect multiple
logical rings
> Additional methods for minimizing segmentation of
interconnected rings
ERPS AND RSTP
The Rapid Spanning Tree Protocol (RSTP) and its multiple-
instance version Multiple Spanning Tree Protocol (MSTP) are
similar protocols to the ERPS and have been serving enterprise
networks satisfactorily for many years now. From a protocol
perspective, at their core, RSTP and MSTP are based on the
same underlying principles as ERPS: (a) providing alternative
redundant paths in a network and (b) loop avoidance. So how
necessary is ERPS, and can RSTP or MSTP be used instead
because they are already widely deployed?
Both ERPS and STP are loop-avoidance protocols, but the
protection switching performance of ERPS is much better
when compared to STP. RSTP and MSTP were developed for
a more generic topology than a simple ring. The protocol,
therefore, has overheads to deal with complex topologies, and
are unnecessary in a simple ring topology. For these reasons,
RSTP or MSTP need more time to re-build network topology
because they each use various parameters to re-calculate
alternate paths. Because the G.8032 does away with these
overheads, and is specically optimized for ring topologies,
the ERPS protocol provides better protection switching
performance and much greater levels of availability in carrier
networks. ERPS can efficiently and predictably deliver sub-
50-millisecond protection switching, which is not the case
with RSTP or MSTP.
ARICENT ERPS
As part of its comprehensive portfolio of networking products,
Aricent ofers a licensable software implementation of the
G.8032 specication for ERPS. Aricent ERPS is available for
licensing as an individual component that can be easily
integrated into networking products. It is also available as
an integrated part of Aricents industry leading Intelligent
Figure 6: In the gure above, Nodes A, B, C, and D form the main ring. Node C is the RPL owner and the RPL port in node C is P1.
Ring 2 is the sub-ring and consists of ring links B->E->F->C. The RPL port of Ring 2 is P2 of Node E and Node E is the RPL owner.
RPL Link
RPL Link
RPL Owner
RPL Owner
Ring 1 Ring 2
A
D C
B
F
E
P1
P1
P2
P2 P2
P3
P3
P1 P1
P2 P2 P1 P1
P2
5 Understanding Ethernet Ring Protection Switching for Carrier Networks
Figure 7: Aricents ERPS in a Switch Stack Architecture
Switching Solution (ISS) for a variety of networking products
catering to Carrier Ethernet and Metro Ethernet applications.
The software is implemented with clearly dened interfaces
to other components in the switch, including abstraction
layers to the operating system and switching silicon interfaces,
allowing a developer or system integrator to integrate it easily.
In addition to the mechanism in the G.8032 standard, Aricent
ERPS implements multiple additional features and extensions
to build highly scalable, resilient, and fault-tolerant networks.
These include:
> Extensive support for conguration and management
> Extensions to the protocol for highly available redundancy
> Extensions for working on systems composed of multiple
individual switching units
> Extensions for functioning in a distributed environment,
harnessing processing power from multiple CPUs
View http://www.aricent.com/software/g8032-ethernet-
ring-protection-switching-erps.html for an overview of Aricent
ERPS. Network equipment manufacturers can use proven
and tested components like Aricent ERPS to reduce technology
complexity and to optimize product development cycles, thereby
accelerating time to market with reduced costs,
CONCLUSION
Implementation of protection switching allows carrier Ethernet
networks to meet higher levels of fault tolerance, resilience,
and service-level agreement satisfaction. Protection switching
in Ethernet networks with ring topologies can be efficiently
implemented based on the ITU-T G.8032 specication.
Aricents ERPS in a Switch Stack Architecture
Aricent ERPS
OS Abstraction Layer
OS
Hardware Abstraction Layer
Switching Silicon
Driver or Data Path
Connectivity/
Fault Management Example
Multi-board
System Framework
Redundancy Framework Element Management
6 Understanding Ethernet Ring Protection Switching for Carrier Networks
ARMSTRONG MATHIYALAGAN
is Assistant Vice President,
Technology, for Data Communication
products at Aricent, focusing on
routing and switching solutions,
including Aricents ISS. He has
over 18 years of experience in
architecting software for switching,
routing, Carrier and Metro Ethernet.
armstrong.m@aricent.com
EMREEN F. XAVIER
is a Technical Leader for Data
Communication products at
Aricent, focusing on Aricents ISS.
She has over 6 years of experience
in the datacom domain including
development and implementation
of networking protocols.
emreen.xavier@aricent.com
RAJESH KUMAR SUNDARARAJAN
is Assistant Vice President for
Data Communication products
at Aricent, focusing on routing
and switching solutions including
Aricents ISS. He has over 16 years
of industry experience in strategizing
and managing software for
communications.
rajeshkumar.sundararajan
@aricent.com
YARLAGADDA KISHORE KUMAR
is a Principle Systems Engineer
for Data Communication products
at Aricent, focusing on routing
and switching solutions including
Aricents ISS. He has over 11
years of experience in developing
software for switching, routing,
security, Carrier and Metro Ethernet.
yarlagadda.kumar@aricent.com
The Aricent Group is a global innovation and technology services
company that helps clients imagine, commercialize, and evolve
products and services for the connected world. Bringing together the
communications technology expertise of Aricent with the creative
vision and user experience prowess of frog, the Aricent Group
provides a unique portfolio of innovation capabilities that seamlessly
combines consumer insights, strategy, design, software engineering,
and systems integration. The client base includes communications
service providers, equipment manufacturers, independent software
vendors, device makers, and many other Fortune 500 brands. The
companys investors are Kohlberg Kravis Roberts & Co., Sequoia
Capital, The Family Ofce, Delta Partners, and The Canadian Pension
Plan Investment Board.
INNOVATION
SERVICES
FOR THE
CONNECTED
WORLD
aricent.com 2012 Aricent Group. All rights reserved.
All Aricent brand and product names are service marks, trademarks, or
registered marks of Aricent Inc. in the United States and other countries.

S-ar putea să vă placă și