Protection Switching in Packet Transport Rings

Christian Addeo

Alcatel-Lucent Optics R&D

Vimercate, Italy Christian .Addeo@alcatel-Iucent.com

Abstract-Transport networks are currently evolving from

traditional circuit switching technologies toward packet switching

tech nologies.

Multi Protocol Label Switching (MPLS) Transport Profile

(MPLS-TP) is an emerging technology addressing the need for

packet transport networks.

Protection Switching in Packet Transport Rings is an important

area of work in the context of MPLS-TP in order to support the

packet transport reliability requirements given the widespread

adoption of ring topologies in metro transport networks.

This paper reviews the use cases for MPLS-TP ring protection

switching, how one of the proposed mechanisms, namely MPLS­

TP Ring Protection Switching (MRPS), can address these

requirements and some possible enhancements to the MRPS base

mechanism.

Keywords - transport networks; packet transport networks; MPLS; MPLS-TP; protection switching; shared protection; SPRing; MRPS

I. INTRODUCTION

Transport networks are currently evolving from traditional time division mUltiplexing (TDM) circuit switching (e.g., SONET/SDH) toward packet switching to cope with the increased volume of packet traffic and services to be transported. In order to support such a network evolution, packet transport network technologies must continue to provide the same levels of reliability, availability and manageability that service providers have come to expect from circuit-based transport infrastructures.

The Multi Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is an emerging technology, being jointly developed by ITU-T and IETF, to support the requirements for packet transport networks.

The deployment of ring network topologies is very common in transport networks, especially in the metro areas. In order to meet the levels of network reliability which are required for packet transport networks, support of protection switching mechanisms in ring topology is a strong requirement for MPLS-TP.

While the standardization work on MPLS-TP ring protection is not yet completed, the need for a solution in this area is an emerging topic.

978-1-4673-1391-9/12/$3l.00 ©2012 IEEE

Italo Busi

Alcatel-Lucent Optics R&D

Vimercate, Italy Italo.Busi@alcatel-lucent.com

Section II provides a quick overview of the standardization activity in this area as well as the description of the use cases, including a real network scenario, where one of the proposals on table for standardization, which is named MPLS-TP Ring Protection Switching (MRPS), is demanded.

Section III reviews the MRPS base mechanism, as described in the MRPS Internet-Draft [1].

Some insights on possible enhancements to the based protection mechanism, which are still under discussion among the co-authors of the MRPS Internet-Draft [1], are presented in sections IV, V and VI.

One possible enhancement, described in section IV, is the simplification of the label allocation scheme aimed at reducing the costs of operating the network. A second improvement, described in section V, is the bandwidth allocation policies on MRPS. A third area of evolution, described in section VI, is the possibility to support dual-node ring interconnections without impacting the operations of the other nodes along the ring, to address the real network scenario (composed of interconnected rings) while allowing a phased introduction/standardization of the technology.

This paper is not intended to pre-j udge the evolution of the MRPS Internet-Draft [1] nor the evolution of the ring protection standardization activities in IETF or ITU-T. This paper is also not intended to provide any comparative information between MRPS and competing solutions addressing the need for MPLS-TP resiliency in ring topologies.

The intent of this paper is to provide information about the MRPS solution, including possible protocol enhancements; the MRPS real performances as measured using commercial products; as well as operators' use cases which are driving the deployment of MRPS in production networks.

II. USE CASES

The most common transport network topology for Metro Networks is interconnected rings. At least two metro levels are typically deployed in a ring fashion: the metro access rings that collect traffic from the users, through access nodes, and the metro aggregation rings that collect traffic from multiple metro access rings, through aggregation nodes, toward the metro core or the backbone networks.

simplifications that the packet-based nature of MPLS-TP allows.

This solution is currently required by those operators which are looking for an ad-hoc protection mechanism for ring topology.

In particular, a recent business case for MRPS, requested by a tier-l transport network operator, envisions the following high-density reference network scenario:

• 20 aggregation rings of, in average, 5 aggregation nodes

• An aggregation nodes is connected, in average, to 6 Figure I. Typical Topology in Metro Transport Networks access ring

Ring and interconnected ring topology can be seen as a special case of a general partial mesh topology. As a consequence any mechanism defmed for any topology (e.g. linear protection switching) can be used also in ring and interconnected ring topologies. Some operators have preferred to adopt this approach.

However, because of the widespread adoption of ring topology, some other operators are requesting a solution which can be tailored to support protection switching in ring topology.

The following aspects are considered important by those operators requesting ring protection switching:

• The operational simplicity of operating a single Automatic Protection Switching (APS) to coordinate protection switching actions for all the connections along the ring (instead of multiple APS instances, one for each connection);

• The possibility to protect, with a 1: 1 architecture, both point-to-point and point-to-multipoint connections at the same time and using the same protection switching mechanism;

• The sharing of the protection bandwidth that results in lower bandwidth consumption when the traffic is not hubbed.

The standardization work on MPLS-TP ring protection is still at an early stage. The IETF MPLS WG has recently adopted an Internet-Draft [4] which describes the applicability of MPLS-TP linear protection switching in a ring topology. The paper in [8] also defmes some enhancements to the mechanisms described in [4] aimed at protecting point-to­multipoint MPLS-TP LSPs over interconnected rings.

An alternative solution, i.e. the MRPS, has also been proposed in IETF [1]. A similar approach has also been proposed in ITU-T and currently described in an ITU-T draft G.8132 Recommendation [2].

MRPS is a carrier-grade and scalable protection switching solution. It targets protection switching hit :S 50 ms, assuming a reference ring with 16 nodes, less than 1200 km of fiber. The solution in MRPS is aimed to be operated in a similar manner as SDH Multiplex Section Shared Ring Protection (MS­SPRing), defined in G.841 [3], while keeping some

• 116 access rings of, in average, 10 access nodes (around 1,200 access nodes in total)

In order to address the market requirements behind these use cases, A Icate I-Lucent has already implemented a demonstration version of the MRPS protection scheme within the 1850TSS platform. An internal test has been performed proving the capability of protecting one thousand LSPs over a four node ring topology within the 50ms target time (an actual worst-case switching time of 16ms has been measured).

III. RING PROTECTION OVERVIEW

MRPS, as defined in [1] and [2], is an MPLS-TP Section layer protection. The MPLS-TP section can rely on diverse physical technologies, e.g. Ethernet, SDH and OTH. The section layer failures triggering the MRPS protection switch can be detected by the MPLS-TP section OAM or reported by a server layer OAM.

MRPS is a two-fiber equivalent scheme. It considers two MPLS-TP ports per each ring node that are commonly named -W (West) and -E (East).

The MRPS scheme, here described, applies the Wrapping protection architecture. The node that detects a failure informs the remote node adjacent to the failure and both switch the normal traffic transmitted on the failed section to the opposite direction (away from the failure). This traffic travels the long way around the ring to the other switching node where it is switched back onto the working direction. The two switching nodes are said to be in switching state, whereas the other ring nodes in pass-through state.

Link failure between NE_B

and NE_ C lead to wrap

traffic in those two NEs.

They are in switching state

Figure 2. Nodes in switching state apply the wrapping mechanism. (Note that the solid and dotted pattern links show the normal and the protecting

traffic bandwidths in the two link directions, respectively)

The MRPS scheme, here described, applies the Revertive operation mode. The service always returns to (or remain on) the working connection if the switch requests are terminated.

The MRPS supports the Hold Off Time (HoT), to avoid protection switching cascade when also the server network layer can provide resilience, and the Wait-To-Restore (WTR) time, to avoid flapping of the protection switching in case of unstable failure.

The MRPS requires that the nodes in the ring communicate through an APS protocol. It allows conveying the switching requests due to failure detection, WTR and administrative commands (e.g. Lockout of Protection, Forced Switch, Manual Switch).

Figure 3. A per-MRPS APS state machine is instantiated in each ring node and the APS protocol messages are exchanged between each couple of

adjacent ring nodes

The MRPS implementation solution, here described, defmes a set of protection LSP segments, one per each ring span. In normal condition, the protection LSP segments are open and do not carry user plane traffic. In switching condition, the protection LSP segments are stitched together in pass-through nodes and terminated in the switching nodes where the traffic, normally transmitted to the failed span, is tunneled through the protection LSP, which works as a hierarchical LSP.

Red segments represent the protection LSP segments in the two section directions.

For simplicity sake, those segments will be pictured as a circular Protection LSP in

the next figures.

In switching condition, the protection LSP segments are stitched together in pass­through nodes (NE_A, NEJ,

NE_E, NE_C) and terminated in the switching nodes (NE_B

and NE_C)

Figure 4. A Protection LSP, working as a hierarchial LSP, is used to carry the protected traffic in the switching condition

Normal traffic, whose working direction is clockwise, is protected in the counter-clockwise direction, and vice versa.

This needs to be taken into account when calculating the protecting bandwidth.

The main advantage of using protection LSP as a hierarchical LSP is the scalability in the pass-through nodes. They simply swap the protection LSP labeled packets independently on the number of the protected traffic LSPs that are tunneled through it.

A. Link Failure

The figure below shows three link failure scenarios for a unidirectional normal traffic LSP: the failure affects the link between two ring intermediate nodes, the link close to the ingress ring node and the link close to the egress ring node of the LSP, respectively.

Figure 5. Link failure scenarios

B. Node Failure

MRPS also recovers a node failure, as described in Figure 6. The nodes adjacent to the failed node detect the failure and perform the protection switch. Obviously traffic, for which the failed node is the ingress or egress ring node, cannot be recovered.

Figure 6. Node failure scenario

C. Multiple Failures

MRPS also recovers multiple link or node failures as long as there is connectivity on the ring between the traffic ingress and egress ring nodes.

Multiple failures can result in ring segmentation, which can cause traffic loops in the segmented sub-rings. Anyway they do

not tear down the ring. In fact, if the traffic loop includes neither its ingress or egress ring node, the traffic packets are discarded due to Time-To-Live (TTL) expiration. If the traffic loop includes its ingress ring node only, the traffic packets are discarded due to the unexpected label received at the ingress node, because the transmitted traffic label that is looped back is not configured in the ingress node as receipt.

Figure 7. Multiple failures scenarios

D. Service Support

MRPS recovers LSPs which can be used to protect services carried over an MPLS-TP ring. Both point-to-point Pseudowire (PW) services and multipoint Ethernet services are supported.

A point-to-point PW service is implemented, following the architecture defmed in RFC 3985 [5], by a PW mapped on an MRPS protected LSP setup between the ingress and egress nodes of the ring that perform the PE functions defmed in [5].

A mUltipoint Ethernet service is implemented, following the Virtual Private LAN Service (VPLS) services architecture defmed in RFC 4762 [7], by a full mesh of hub PWs, mapped on a mesh of MRPS protected LSPs between switching instances located in some ring nodes that perform the VPLS PE functions defined in [7].

MRPS works for the VPLS as a server layer protection mechanism. So its protection switching does not affect the VPLS operation from functional viewpoint, even if it can change the ring port, from which the hub PW packets are received.

The following figure considers a VPLS service with three PE. In protection condition, the figure shows the two directions of a MRPS-protected bidirectional hub PW over LSP without showing the protection LSPs in which they are tunneled during protection switching evens.

Access ports

Access ports Access ports

Figure 8. An example of VPLS service over ring topology. Yellow circles represent switch instances of that VPLS service with relevant

access ports and the colored arrows represent the bidirectional PWs interconnecting those VPLS switch instances.

Figure 9. An example of MRPS protected VPLS service. In switching condition, the VPLS PWs are wrapped as occurs for p2p services.

IV. LABEL MANAGEMENT

MRPS requires two label assignment policy rules.

First, the same LSP label value is used on each working direction along the ring to designate a given MRPS-protected LSP. As a consequence, the label swapping operations on each intermediate node along the working path will set the outgoing label to the same LSP label.

This rule is mandatory to recover, with the same protection switching actions, any failure scenarios where the switching nodes are not adjacent (e.g. node failure or multiple failures scenarios), without the need to configure different label swapping operations for different failure scenarios. The normal traffic LSP label, which is tunneled into the protection LSP in the first switching node, should identify the protected LSP in whichever remote switching node where it is looked up after having popped the protection LSP label.

Figure 10. Label assignment policy: same LSP label along the ring

Second, an LSP label value that is used to designate a given MRPS-protected LSP on the ring must be considered not reusable in all nodes of the ring. Otherwise, misconnection can occur in some failure scenarios, as shown below.

The consequence of these rules is that an MRPS-protected LSP is assigned an LSP label which is not used by any node on the ring and that it will never be used by all the nodes on the ring to identify any other LSP.

Traffic lSP

Figure I I. Label assignement policy: unique LSP label in the ring

V. BANDWIDTH MANAGEMENT AND CONFIGURATION

The bandwidth on ring links is shared between the normal and the protected traffic: for example, clockwise, part of the bandwidth is used for carrying normal traffic, another part for carrying the protected traffic (whose working direction is counter-clockwise). Part of the bandwidth can also be dedicated to carry unprotected traffic LSPs.

So the CIR of the protection LSP segments in all ring nodes, clockwise, should be set to the sum of the CIRs of the normal traffic LSPs in the most loaded section counter­clockwise. The upper limit is half of the section physical capacity.

The protection scheme algorithm itself is unaware of the QoS aspects, so traffic engineering policy should be taken into account to properly manage the ring.

The following figure demonstrates the described policy by an example that calculates the used protection LSP segments CIR in different failure scenarios affecting three unidirectional normal traffic LSPs (working clockwise, CIR=lOOMbps each). The protection LSP segments counter-clockwise result to be dimensioned 300Mbps.

300

300

Figure 12. Bandwidth management and configuration policy

VI. RING INTERCONNECTION

As discussed in section II, transport networks commonly consist of mUltiple interconnected rings that can share one or more nodes and links.

The simplest solution is to interconnect the two rings using a Single Node Ring Interconnection (SNRI). The node interconnecting two rings in this scheme is called SNRI node. In this case, independent MRPS instances are used to protect failures within each ring. SNRI nodes will participate to each MRPS instance for each ring they support.

As each ring is operated and protected independently, the SNRI node will behave as a normal egress node for the ring the traffic is extracted from and as a normal ingress node for the ring the traffic is inserted to. In particular, while the LSP labels are not swapped along each ring, the SNRI performs an LSP label swap operation when the traffic moves from one ring to another to allow independent LSP label allocation policies on each interconnected ring.

This approach allows independent operations and protection on each ring thus simplifying the operational complexity of the overall network (especially when a lot of rings need to be interconnected).

SNRI improves the overall network availability because it can protect against multiple failures in the network. Up to one single failure (excluding SNRI node failures) per interconnected ring can always be recovered; multiple failures on one or more rings can be recovered as long as they do not isolate the ingress/egress ring nodes. The SNRI node represents a single point of failure. While in many use cases the availability of the SNRI node is sufficiently high and it does not adversely impact the overall network availability, there are some use cases where node redundancy at the interconnection point between two rings is required.

In these use cases, the objective is to also recover failures that prevent the traffic exchange between the two interconnected rings through one of the two redundant nodes,

when a secondary path is available through the other redundant node. The redundancy scheme is here called Dual Node Ring Interconnection (DNRI) and the two redundant nodes are called DNRI nodes.

DNRI is intended to further improve the overall network availability without increasing the operational costs. DNRI still allows each ring to be operated and protected by MRPS.

The DNRI leverages both the node redundancy and the reaction of the MRPS instances of the affected rings that activate the secondary path available through the redundant node.

Figure 13. Multi-ring topology with DNRl: examples of failure scenarios

An example describing how the DNRI works, involving Node E and Node D as DNRI nodes, is depicted in Figure 13 above: a blue bi-directional LSP is protected by two MRPS instances, one for each ring, and by DNRI across the rings.

Any failure within each ring is protected by the ring's MRPS instance and the primary DNRI node (e.g., node E) is always used to forward the traffic from one ring into the other (and vice versa). When the primary DNRI node fails, the MRPS instances of the two interconnected rings forward the traffic to/from the secondary interconnecting node (e.g., node D) which then forwards it from/to one ring to/from the other ring. It is worth noting that different LSPs crossing the same two interconnected rings, can use different primary DNRI nodes.

This basic DNRI mechanism further improves overall network availability because it can recover all the failure scenarios recovered by SNRI as well as the failure of one of the two interconnecting nodes.

One possible further improvement to the basic DNRI mechanism would allow also recovering failures scenarios causing the isolation of the primary DNRI node in one ring.

The advantage of this approach is that MRPS development, standardization and deployment can be easily phased.

In a first phase, it would be possible to start deploying MRPS protected interconnected rings with two physical interconnecting nodes of which only one is actually acting as SNRI node. DNRI can be later deployed via software or firmware upgrades of the two interconnecting nodes with no impact on all the other nodes in the ring.

VII. CONCLUSION

This paper has described the use cases for MPLS-TP Ring Protection Switching (MRPS) as well as the base mechanisms as defmed in the Individual Internet-Draft [1].

This paper has also discussed possible further enhancements to the MRPS base mechanisms in the area of label and bandwidth allocation as well as in the area of supporting ring interconnection, especially when node redundancy is required.

ACKNOWLEDGMENT

Defmition and implementation of MPLS-TP Ring Protection Switching providing the capability to offer sub-50 ms protection switching with bandwidth sharing on MPLS-TP rings is an important value of Optical Packet Transport networks, possible in our work only thanks to engineering people working with passion and energy inside Optics R&D in Alcatel-Lucent premises in Vimercate (Italy). The authors thank them for the professional contribution on this activity and paper.

The authors of this papers would like to gratefully acknowledge the co-authors of the MRPS individual Internet-Draft [1], for the useful technical discussions on this topic.

REFERENCES

[1] H. van Helvoort, J. Ryoo, et aI., "MPLS-TP Ring Protection Switching (MRPS)", draft-helvoort-mpls-tp-ring-protection-switching-Ol (work in progress), April 2011

[2] TTU-T Draft Recommendation G.8132, "MPLS-TP Shared Protection Ring (MT-SPRing)", May 2009

[3] TTU-T Recommendation G.841, 'Types and characteristics of SOH network protection architectures", October 1998

[4] Y. Weingarten, et aI., "Applicability of MPLS-TP Linear Protection for Ring Topologies", draft-ietf-mpls-tp-ring-protection-Ol (work in progress), February 2012

[5] S. Bryant, P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005

[6] M. Bocci, S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009

[7] M. Lasserre, V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LOP) Signaling", RFC 4762, January 2007

[8] J. Zhang, S. Ruepp, M.S. Berger, and H. Wessing, "Protection fro MPLS-TP Multicast Services", 7th International Workshop on the Design of Reliable Communication Networks, October 2009