draft-ietf-mpls-tp-ring-protection-02.txt   draft-ietf-mpls-tp-ring-protection-03.txt 
Network Working Group Y. Weingarten Network Working Group Y. Weingarten
Internet-Draft Internet-Draft
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: October 31, 2012 Cisco Expires: May 9, 2013 Cisco
N. Sprecher
Nokia Siemens Networks
D. Ceccarelli D. Ceccarelli
D. Caviglia D. Caviglia
F. Fondelli F. Fondelli
Ericsson Ericsson
M. Corsi M. Corsi
Altran Altran
B. Wu B. Wu
X. Dai X. Dai
ZTE Corporation ZTE Corporation
April 29, 2012 November 5, 2012
Applicability of MPLS-TP Linear Protection for Ring Topologies Applicability of MPLS-TP Linear Protection for Ring Topologies
draft-ietf-mpls-tp-ring-protection-02.txt draft-ietf-mpls-tp-ring-protection-03.txt
Abstract Abstract
This document presents an applicability statement to address the This document presents an applicability of linear protection
requirements for protection of ring topologies for Multi-Protocol mechanisms for Multi-Protocol Label Switching Transport Profile
Label Switching Transport Profile (MPLS-TP) Label Switched Paths (MPLS-TP) in ring topologies. Protection on rings offers a number of
(LSP) on multiple layers. The MPLS-TP Requirements document opportunities for optimization as the protection choices are starkly
specifies specific criteria for justification of dedicated protection limited (all traffic traveling one way around a ring can only be
mechanism for particular topologies, including optimizing the number switched to travel the other way on the ring), but also suffers from
of OAM entities needed, minimizing the number of labels for some complications caused by the limitations of the topology.
protection paths, minimizing the number of recovery elements in the
network, and minimizing the number of control and management Requirements for MPLS-TP protection and specifically for protection
transactions necessary. The document proposes a methodology for ring in ring topologies are discussed in "Requirements of an MPLS
protection based on existing MPLS-TP survivability mechanisms, Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
specifically those defined in MPLS-TP Linear Protection, without the Survivability Framework" (RFC 6372). This document shows how MPLS-TP
need for specification of new constructs or protocols. linear protection as defined in RFC 6378 can be applied to ring
topologies, discusses how most of the requirements are met, and
describes scenarios in which the function provided by applying linear
protection in a ring topology falls short of some of the
requirements.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. defined by the ITU-T.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 15 skipping to change at page 2, line 17
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2012. This Internet-Draft will expire on May 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7
2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. P2P ring protection using SPME . . . . . . . . . . . . . . 10 2.3. SPME for p2p protection of ring topologies . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12 2.3.2. Wrapping link protection with segment based SPME . . . 12
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14
2.3.4. Wrapping for link and node protection . . . . . . . . 14 2.3.4. Wrapping for link and node protection . . . . . . . . 14
2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 14 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15
3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1. Recommendations for protection of p2p paths
3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15 traversing a ring . . . . . . . . . . . . . . . . . . 16
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 16
3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 18
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2.2. Walkthrough using context labels . . . . . . . . . . . 22 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 20
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 21
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24 3.2.2. Walkthrough using context labels . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been
standardized as part of a joint effort between the Internet standardized as part of a joint effort between the Internet
Engineering Task Force (IETF) and the International Telecommunication Engineering Task Force (IETF) and the International Telecommunication
Union Standardization (ITU-T). These specifications are based on the Union Standardization (ITU-T). These specifications are based on the
requirements that were generated from this joint effort. requirements that were generated from this joint effort.
The requirements for MPLS-TP [TPReqs] indicates a requirement to The MPLS-TP requirements [RFC5654] includes a requirement to support
support a network that may include sub-networks that constitute a a network that may include sub-networks that constitute a MPLS-TP
MPLS-TP ring as defined in the requirements. The requirements ring as defined in the requirements. The requirements document does
document does not identify any protection requirements specific to a not identify any protection requirements specific to a ring topology.
ring topology. However, the requirements state that specific However, the requirements state that specific protection mechanisms
protection mechanisms aimed at ring topologies may be developed if aimed at ring topologies may be developed if these allow the network
these allow the network to optimize: to minimize:
o Number of OAM entities needed to trigger the protection o Number of OAM entities needed to trigger the protection
o Number of elements of recovery needed o Number of elements of recovery needed
o Number of labels required o Number of labels required
o Number of control and management plane transactions during a o Number of control and management plane transactions during a
recovery operation maintenance operation
o Impact of signaling and routing information exchanged, in presence o Impact of signaling and routing information exchanged during
of control plane protection, in presence of control plane
This document will propose a set of basic mechanisms that could be This document proposes a set of basic mechanisms that could be used
used for the protection of the data flows that traverse a MPLS-TP for the protection of the data flows that traverse a MPLS-TP ring.
ring. The mechanism is based on existing MPLS and MPLS-TP protection These mechanisms are based on existing MPLS and MPLS-TP protection
mechanisms. We show that this mechanism provides the ability to mechanisms. We show that these mechanisms provide protection for all
protect all of the basic conditions within a reasonable time frame switching triggers within a reasonable time frame and optimize the
and does optimize the criteria set out in [TPReqs] as summarized criteria set out in [RFC5654], as summarized above.
above.
A related topic in [TPReqs] addresses the required support for A related topic in [RFC5654] addresses the required support for
interconnected rings. This topic involves various scenarios that interconnected rings. This topic involves various scenarios that
require further study and will be addressed in a separate document, require further study and will be addressed in a separate document,
based on the principles outlined in this document. based on the principles outlined in this document.
1.1. Problem statement 1.1. Problem statement
Ring topologies, as defined in [TPReqs], are used in transport Ring topologies, as defined in [RFC5654], are used in transport
networks due to their ability to easily support both p2p and p2mp networks due to their ability to easily support both p2p and p2mp
transport paths. When designing a protection mechanism for a ring transport paths. When designing a protection mechanism for a ring
topology, there is a need to address both - topology, there is a need to address both -
1. A point-to-point transport path that enters a MPLS-TP capable 1. A point-to-point transport path that enters a MPLS-TP capable
ring at one node, the ingress node, and exits the ring at a ring at one node, the ingress node, and exits the ring at a
single egress node possibly continuing beyond the ring. single egress node possibly continuing beyond the ring.
2. Where the ring is being used as a branching point for a point-to- 2. Where the ring is being used as a branching point for a point-to-
multipoint transport path, i.e. the transport path enters the multipoint transport path, i.e. the transport path enters the
MPLS-TP capable ring at the ingress node and exits through a MPLS-TP capable ring at the ingress node and exits through a
skipping to change at page 5, line 27 skipping to change at page 5, line 27
either a unidirectional or bidirectional fault, and should be either a unidirectional or bidirectional fault, and should be
detected by the neighboring nodes. detected by the neighboring nodes.
2. One of the ring nodes causes a fault condition. This condition 2. One of the ring nodes causes a fault condition. This condition
is invariably a bidirectional fault (although in rare cases of is invariably a bidirectional fault (although in rare cases of
misconfiguration this could be detected as a unidirectional misconfiguration this could be detected as a unidirectional
fault) and should be detected by the two neighboring ring nodes. fault) and should be detected by the two neighboring ring nodes.
3. An operator command is issued to a specific ring node. A 3. An operator command is issued to a specific ring node. A
description of the different operator commands is found in description of the different operator commands is found in
Section 4.12 of [RFC4427]. Examples of these commands include Section 4.13 of [RFC4427]. Examples of these commands include
Manual Switch, Forced Switch, or Clear operations. Manual Switch, Forced Switch, or Clear operations.
The protection domain addressed in this document is limited to the The protection domain addressed in this document is limited to the
traffic that is traversing the ring. Traffic on the transport path traffic that is traversing the ring. Traffic on the transport path
prior to the ring ingress node or beyond the egress nodes may be prior to the ring ingress node or beyond the egress nodes may be
protected by some other mechanism. protected by some other mechanism.
1.2. Terminology and Notation 1.2. Scope of the document
This document addresses the requirements that appear in Section
2.5.6.1 of [RFC5654] on Ring Protection based on the application of
the linear protection as defined in [RFC6378]. Requirement R93
regarding the support of interconnected rings and protection of
faults in the interconnection nodes and links are for further study.
In addition, requirement R105 requiring the support of lockout of
specific nodes or spans is only supported as well as it is supported
by the linear protection mechanism.
1.3. Terminology and Notation
The terminology used in this document is based on the terminology The terminology used in this document is based on the terminology
defined in the MPLS-TP framework documents: defined in the MPLS-TP framework documents:
o MPLS-TP Framework[TPFwk] o MPLS-TP Framework[RFC5921]
o MPLS-TP OAM Framework[OAMFwk] o MPLS-TP OAM Framework[RFC6371]
o MPLS-TP Survivability Framework[SurvivFwk] o MPLS-TP Survivability Framework[RFC6372]
The MPLS-TP Framework document [TPFwk] defines a Sub-Path Maintenance The MPLS-TP Framework document [RFC5921] defines a Sub-Path
Entity (SPME) construct that can be defined between any two LSRs of a Maintenance Entity (SPME) construct that can be defined between any
MPLS-TP LSP. This SPME may be configured as a co-routed two LSRs of a MPLS-TP LSP. This SPME may be configured as a co-
bidirectional path. The SPME is defined to allow management and routed bidirectional path. The SPME is defined to allow management
monitoring of any segment of a transport path. This concept will be and monitoring of any segment of a transport path. This concept will
used extensively throughout the document to support protection of the be used extensively throughout the document to support protection of
traffic that traverses a MPLS-TP ring. the traffic that traverses a MPLS-TP ring.
In addition, we describe the use of the label stack in connection In addition, we describe the use of the label stack in connection
with the redirecting of data packets by the protection mechanism. with the redirecting of data packets by the protection mechanism.
The following syntax will be used to describe the contents of the The following syntax will be used to describe the contents of the
label stack: label stack:
1. The label stack will be enclosed in square brackets ("[]") 1. The label stack will be enclosed in square brackets ("[]")
2. Each level in the stack will be separated by the '|' character. 2. Each level in the stack will be separated by the '|' character.
It should be noted that the label stack may contain additional It should be noted that the label stack may contain additional
skipping to change at page 7, line 5 skipping to change at page 7, line 15
of the protection scenario. of the protection scenario.
o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label
for LSR-B to transmit the data packet to LSR-G, the second label for LSR-B to transmit the data packet to LSR-G, the second label
is the label that would be used by the egress LSR to continue the is the label that would be used by the egress LSR to continue the
packet on the original LSP. packet on the original LSP.
o If "LE" were the bottom label in the stack, then the label stack o If "LE" were the bottom label in the stack, then the label stack
would be shown as [PB1(G)|LE+S]. would be shown as [PB1(G)|LE+S].
1.3. Contributing Authors 1.4. Contributing Authors
Akira Sakurai (NEC), Rolf Winter (NEC) The authors would like to acknowledge the following individuals that
contributed their insights and advice to this work:
Nurit Sprecher (NSN)
Akira Sakurai (NEC)
Rolf Winter (NEC)
2. P2P Ring Protection 2. P2P Ring Protection
Classically there are two protection architecture mechanisms for ring There are two protection architecture mechanisms, that have
topologies, based on SDH specifications [G.841], that have been historically been applied to ring topologies, based on SDH
proposed in various forums to perform recovery of a topological ring specifications [G.841], and have been proposed in various forums to
network - "wrapping" and "steering". The following sub-sections will perform recovery of a topological ring network - "Wrapping" and
examine these two mechanisms. "Steering". The following sub-sections examine these two mechanisms,
as applied to an MPLS transport network.
2.1. Wrapping 2.1. Wrapping
Wrapping is defined as a local protection architecture. This Wrapping is defined as a local protection architecture. This
mechanism is local to the LSRs that are neighbors to the detected mechanism is local to the nodes that are neighbors to the detected
fault. When a fault is detected (either a link or node failure), the fault. When a fault is detected (either a link or node failure), the
neighboring LSR can identify that the fault would prevent forwarding neighboring node can identify that the fault would prevent forwarding
of the data along the data path. Therefore, in order to continue the of the data along the data path. Therefore, in order to continue the
data along the path, there is need to "wrap" all data traffic around data along the path, there is need to "wrap" all data traffic around
the ring, on an alternate data path, until arriving at the LSR that the ring, on an alternate data path, until arriving at the node that
is on the opposite side of the fault. When this LSR also detects is on the opposite side of the fault. When this far-side node also
that there is a fault condition on the LSP, it can identify that the detects that there is a fault condition on the working path, it can
data traffic that is arriving on the alternate (protecting) data path identify that the data traffic that is arriving on the alternate
is intended for the "broken" LSP. Therefore, again taking a local (protecting) data path is intended for the "broken" data path.
decision, can wrap the data back onto the normal working path until Therefore, again taking a local decision, can wrap the data back onto
the egress from the ring segment. Wrapping behavior is similar to the normal working path until the egress from the ring segment.
MPLS-TE FRR as defined in [RFC4090] using either bypass or detour
tunnels. It would be possible to wrap each LSP arounf the failed Wrapping behavior is similar to MPLS-TE FRR as defined in [RFC4090]
links via a detour tunnel using a different label for each LSP or to using either bypass or detour tunnels. Applying this methodology to
wrap all the LSPs using a bypass tunnel and a single label. MPLS, it is possible to wrap the traffic of each LSP around the
failed links via a detour tunnel using a different label for each LSP
or to wrap all LSPs using a bypass tunnel and a single label.
___ ######## ___ ######## ___ ___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\ ======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/ \_B_/@@@@@@@@\_A_/ \_F_/
*@ #* *@ #*@
*@ #* *@ #*@
*@ #* *@ #*@
_*@ ___ #*_ _*@ ___ #*@
/LSR\********/LSR\********/LSR\======> /LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link ===> connected LSP *** physical link
### working path @@@ wrapped data path ### working path @@@ wrapped data path
Figure 1: Wrapping protection for p2p path Figure 1: Wrapping protection for p2p path
In this figure we have a ring with a LSP that enters the ring at Consider the LSP that is shown in Figure 1 that enters the ring of
LSR-B and exits at LSR-E. The normal working path follows through LSRs at LSR-B and exits at LSR-E. The normal working path LSP
B-A-F-E. If a fault is detected on the link A<-->F, then the follows through LSRs B-A-F-E. If a fault is detected on the link
wrapping mechanism decides that LSR-A would wrap the traffic around A<-->F, then the wrapping mechanism decides that LSR-A would wrap the
the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on traffic around the ring, on a wrapped data path A-B-C-D-E-F, to
the far side of the failed link). LSR-F would then wrap the data arrive at LSR-F (on the far side of the failed link). LSR-F would
packets back onto the working path F-->E to the egress node. In this then wrap the data packets back onto the working path F-->E to the
protection scheme, the traffic will follow the path - egress node. In this protection scheme, the traffic will follow the
B-A-B-C-D-E-F-E. path - B-A-B-C-D-E-F-E.
This protection scheme is simple in the sense that there is no need This protection scheme is simple in the sense that there is no need
for coordination between the different LSR in the ring - only the for coordination between the different LSR in the ring - only the
LSRs that detect the fault must wrap the traffic, either onto the LSRs that detect the fault must wrap the traffic, either onto the
wrapped data path (at the near-end) or back to the working path (at wrapped data path (at the near-end) or back to the working path (at
the far-end). Coordination would only be needed to maintain co- the far-end). Coordination of the switchover to the protection path
routed bidirectional traffic even in cases of a unidirectional fault would be needed to maintain the traffic on a co-routed bidirectional
condition. LSP even in cases of a unidirectional fault condition.
The following considerations should be taken into account when The following considerations should be taken into account when
considering use of wrapping protection: considering use of wrapping protection:
o Detection of loss-of-continuity or mis-connectivity, should be o Detection of loss-of-continuity or mis-connectivity, should be
performed at the link level and/or per LSR when using node-level performed at the link level and/or per LSR when using node-level
protection. Configuration of the protection being performed (i.e. protection. Configuration of the protection being performed (i.e.
link protection or node protection) needs to be performed link protection or node protection) needs to be performed
a-priori, since the configuration of the proper protection path is a-priori, since the configuration of the proper protection path is
dependent upon this decision. dependent upon this decision.
skipping to change at page 8, line 47 skipping to change at page 9, line 20
alternate paths. alternate paths.
o When wrapping, the data is transmitted over some of the links o When wrapping, the data is transmitted over some of the links
twice, once in each direction. For example, in the figure above twice, once in each direction. For example, in the figure above
the traffic is transmitted both B-->A and then A-->B, later it is the traffic is transmitted both B-->A and then A-->B, later it is
transmitted E-->F and F-->E. This means that there is additional transmitted E-->F and F-->E. This means that there is additional
bandwidth needed for this protection. bandwidth needed for this protection.
o If a double-fault situation occurs in the ring, then wrapping will o If a double-fault situation occurs in the ring, then wrapping will
not be able to deliver any packets except between the ingress and not be able to deliver any packets except between the ingress and
the first fault location. This is based on the need for wrapping the first fault location encountered on the working path. This is
to connect between the neighbors of the fault location, and this based on the need for wrapping to connect between the neighbors of
is not possible in the segmented ring. the fault location, and this is not possible in the segmented
ring.
o The resource allocation for the alternate-paths could be o The resource pre-allocation for all of the alternate-paths could
problematic, since most of these alternate paths will not be used be problematic [causing massive over subscription of the available
simultaneously. One possibility could be to allocate '0' resources]. However, since most of these alternate paths will not
be used simultaneously, there is the possibility of allocating '0'
resources and depend on the NMS to allocate the proper resources resources and depend on the NMS to allocate the proper resources
around the ring. around the ring, based on actual traffic usage.
o Wrapping also involves greater latency in delivering the packets, o Wrapping also involves a small increase in traffic latency in
as a result of traversing the entire ring. This could be very delivering the packets, as a result of traversing the entire ring,
restrictive for large rings. during protection.
2.2. Steering 2.2. Steering
The second common scheme for ring protection, steering, takes The second common scheme for ring protection, steering, takes
advantage of the ring topology by defining two paths from the ingress advantage of the ring topology by defining two paths from the ingress
point (to the ring) to the egress point going in opposite directions point (to the ring) to the egress point going in opposite directions
around the ring. This is illustrated in Figure 2, where if we assume around the ring. This is illustrated in Figure 2, where if we assume
that the traffic needs to enter the ring from node B and exit through that the traffic needs to enter the ring from node B and exit through
node F, we could define a primary path through nodes B-A-F, and an node F, we could define a primary path through nodes B-A-F, and an
alternate path through the nodes B-C-D-E-F. In steering the alternate path through the nodes B-C-D-E-F. In steering the
switching is always performed by the ingress node (node B in switching is always performed by the ingress node (node B in
Figure 2). If a fault condition is detected anywhere on the working Figure 2). If a fault condition is detected anywhere on the working
path (B-A-F), then the traffic would be redirected by B to the path (B-A-F), then the traffic would be redirected by B to the
alternate path (i.e. B-C-D-E-F). alternate path (i.e. B-C-D-E-F).
This mechanism bears similarities to linear 1:1 protection This mechanism bears similarities to linear 1:1 protection [RFC6372].
[SurvivFwk]. The two paths around the ring act as the working and The two paths around the ring act as the working and protection
protection paths. There is need to communicate to the ingress node paths. There is need to communicate to the ingress node the need to
the need to switch over to the protection path and there is a need to switch over to the protection path and there is a need to coordinate
coordinate the switchover between the two end-points of the protected the switchover between the two end-points of the protected domain.
domain.
The following considerations must be taken into account regarding the The following considerations must be taken into account regarding the
steering architecture: steering architecture:
o Steering relies on a failure detection method that is able to o Steering relies on a failure detection method that is able to
notify the ingress node of the fault condition. This may involve notify the ingress node of the fault condition. This may involve
different OAM functionality described in [OAMFwk], e.g. Remote different OAM functionality described in [RFC6371], e.g. Remote
Defect Indication, Alarm reporting. Defect Indication, Alarm reporting.
o The process of notifying the ingress node adds to the latency of o The process of notifying the ingress node adds to the latency of
the protection switching process, after the detection of the fault the protection switching process, after the detection of the fault
condition. condition.
o While there is no need for double bandwidth for the data path, o While there is no need for double bandwidth for the data path,
there is the necessity for the ring to maintain enough capacity there is the necessity for the ring to maintain enough capacity
for all of the data in both directions around the ring. for all of the data in both directions around the ring.
2.3. P2P ring protection using SPME 2.3. SPME for p2p protection of ring topologies
The SPME concept was introduced by [TPFwk] to support management and The SPME concept was introduced by [RFC5921] to support management
monitoring an arbitrary segment of a transport. However, an SPME is and monitoring an arbitrary segment of a transport. However, an SPME
essentially a valid LSP that may be used to aggregate all LSP traffic is essentially a valid LSP that may be used to aggregate all LSP
that traverses the sub-path delineated by the SPME. An SPME may be traffic that traverses the sub-path delineated by the SPME. An SPME
monitored using the OAM mechanisms as described in the MPLS-TP OAM may be monitored using the OAM mechanisms as described in the MPLS-TP
Framework document [OAMFwk]. OAM Framework document [RFC6371].
When defining a MPLS-TP ring as a protection domain, there is a need When defining a MPLS-TP ring as a protection domain, there is a need
to design a protection mechanism that protects all the LSPs that to design a protection mechanism that protects all the LSPs that
cross the MPLS-TP ring. For this purpose, we associate a (working) cross the MPLS-TP ring. For this purpose, we associate a (working)
SPME with the segment of the transport path that traverses the ring. SPME with the segment of the transport path that traverses the ring.
In addition, we configure an alternate (protecting) SPME that In addition, we configure an alternate (protecting) SPME that
traverses the ring in the opposite direction around the ring. The traverses the ring in the opposite direction around the ring. The
exact selection of the SPMEs is dependent on the type of transport exact selection of the SPMEs is dependent on the type of transport
path and protection that is being implemented and will be detailed in path and protection that is being implemented and will be detailed in
the following sub-sections. the following sub-sections.
Based on this architectural configuration for ring protection, it is Based on this architectural configuration for protection of ring
possible to limit the number of alternate paths needed to protect the topologies, it is possible to limit the number of alternate paths
data traversing the ring. In addition, since we will perform all of needed to protect the data traversing the ring. In addition, since
the OAM functionality on the SPME configured for the traffic, we can we will perform all of the OAM functionality on the SPME configured
minimize the number of OAM sessions needed to monitor the data for the traffic, we can minimize the number of OAM sessions needed to
traffic of the ring - rather than monitoring each individual LSP. monitor the data traffic of the ring - rather than monitoring each
individual LSP.
The following figure shows a MPLS-TP ring that is part of a larger The following figure shows a MPLS-TP ring that is part of a larger
MPLS-TP network. The ring could be used as a network segment that MPLS-TP network. The ring could be used as a network segment that
may be traversed by numerous LSPs. In particular, the figure shows may be traversed by numerous LSPs. In particular, the figure shows
that for all LSPs that connect to the ring at LSR-B and exit the ring that for all LSPs that connect to the ring at LSR-B and exit the ring
from LSR-F, we configure two SPME through the ring (the first SPME from LSR-F, we configure two SPME through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F). traverses along B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___ ___ ___ ___
======>/LSR\********/LSR\********/LSR\======> ======>/LSR\********/LSR\********/LSR\======>
skipping to change at page 11, line 6 skipping to change at page 11, line 26
_*@ ___ @*_ _*@ ___ @*_
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link ===> connected LSP *** physical link
### primary SPME @@@ secondary SPME ### primary SPME @@@ secondary SPME
Figure 2: A MPLS-TP ring Figure 2: A MPLS-TP ring
In all of the following subsections, we use 1:1 linear protection In all of the following subsections, we use 1:1 linear protection
[SurvivFwk] [LinProtect] to perform protection switching and [RFC6372] [RFC6378] to perform protection switching and coordination
coordination when a signal fault is detected. The actual when a signal fault is detected. The actual configuration of the
configuration of the SPMEs used may change dependent upon the choice SPMEs used may change dependent upon the choice of methodology and
of methodology and this will be detailed in the following sections. this will be detailed in the following sections. However, in all of
However, in all of these configurations the mechanism will be to these configurations the mechanism will be to transmit the data
transmit the data traffic on the primary SPME, while applying OAM traffic on the primary SPME, while applying OAM functionality over
functionality over both the primary and the secondary SPME to detect both the primary and the secondary SPME to detect signal fault
signal fault conditions on either path. If a signal fault is conditions on either path. If a signal fault is detected on the
detected on the primary SPME, then the mechanism described in primary SPME, then the mechanism described in [RFC6378] shall be used
[LinProtect] shall be used to coordinate a switch-over of data to coordinate a switch-over of data traffic to the secondary SPME.
traffic to the secondary SPME.
Assuming that the SPME is implemented as an hierarchical LSP, packets Assuming that the SPME is implemented as an hierarchical LSP, packets
that arrive at LSR-B with a label stack [LI] will have the SPME label that arrive at LSR-B with a label stack [LI] will have the SPME label
pushed at LSR-B and the LSP label will be swapped for the label that pushed at LSR-B and the LSP label will be swapped for the label that
is expected by the egress LSR (i.e. the packet will arrive at LSR-A is expected by the egress LSR (i.e. the packet will arrive at LSR-A
with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]). with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]).
The SPME label will be popped by LSR-F and the LSP label will be The SPME label will be popped by LSR-F and the LSP label will be
treated appropriately at LSR-F and forwarded along the LSP, outside treated appropriately at LSR-F and forwarded along the LSP, outside
the ring. This scenario is true for all LSP that are aggregated by the ring. This scenario is true for all LSP that are aggregated by
this primary SPME. this primary SPME.
skipping to change at page 11, line 47 skipping to change at page 12, line 18
is configured as part of the LSP and defined as a SPME. is configured as part of the LSP and defined as a SPME.
For each pair of SPMEs that are defined in this way, it is possible For each pair of SPMEs that are defined in this way, it is possible
to verify the connectivity and continuity by applying the MPLS-TP OAM to verify the connectivity and continuity by applying the MPLS-TP OAM
functionality to both the working and protection SPME. If a functionality to both the working and protection SPME. If a
discontinuity or mis-connectivity is detected then the MEPs will discontinuity or mis-connectivity is detected then the MEPs will
become aware of this condition, and could perform a protection switch become aware of this condition, and could perform a protection switch
of all LSPs to the alternate, protection SPME. of all LSPs to the alternate, protection SPME.
This protection mechanism is identical to application of 1:1 linear This protection mechanism is identical to application of 1:1 linear
protection[SurvivFwk] [LinProtect] to the pair of SPMEs. Under protection[RFC6372] [RFC6378] to the pair of SPMEs. Under normal
normal conditions, all LSP data traffic will be transmitted on the conditions, all LSP data traffic will be transmitted on the working
working SPME. If the linear protection is triggered, by either the SPME. If the linear protection is triggered, by either the OAM
OAM indication, an other fault indication trigger, or an operator indication, an other fault indication trigger, or an operator
command, then the MEPs will select the protection SPME to transmit command, then the MEPs will select the protection SPME to transmit
all LSP data packets. all LSP data packets.
The protection SPME will continue to transmit the data packets until The protection SPME will continue to transmit the data packets until
the stable recovery of the fault condition. Upon recovery, the the stable recovery of the fault condition. Upon recovery, i.e. the
fault condition has cleared and the network is stabilized, the
ingress LSR could switch traffic back to the working SPME, if the ingress LSR could switch traffic back to the working SPME, if the
protection domain is configured for revertive behavior. protection domain is configured for revertive behavior.
The control of the protection switching, especially for cases of The control of the protection switching, especially for cases of
operator commands, would be covered by the protocol defined in operator commands, would be covered by the protocol defined in
[LinProtect]. [RFC6378].
2.3.2. Wrapping with segment based SPME 2.3.2. Wrapping link protection with segment based SPME
It is possible to use the SPME mechanism to perform segment-based It is possible to use the SPME mechanism to perform segment-based
protection. For each link in the ring, we define two SPME - the protection. For each link in the ring, we define two SPME - the
first is a SPME between the two LSRs that are connected by the link, first is a SPME between the two LSRs that are connected by the link,
and the second SPME between these same two LSRs but traversing the and the second SPME between these same two LSRs but traversing the
entire ring (except the link that connects the LSRs). In Figure 3 we entire ring (except the link that connects the LSRs). In Figure 3 we
show the primary SPME that connects LSR-A & LSR-F over a segment show the primary SPME that connects LSR-A & LSR-F over a segment
connection, and the secondary SPME that connects these same LSRs by connection, and the secondary SPME that connects these same LSRs by
traversing the ring in the opposite direction. traversing the ring in the opposite direction.
skipping to change at page 13, line 9 skipping to change at page 13, line 37
redirected onto the original LSP, quite likely over the neighboring redirected onto the original LSP, quite likely over the neighboring
SPME. SPME.
Following the progression of the label stack through this switching Following the progression of the label stack through this switching
operation (for a LSP that enters the ring at LSR B and exits the ring operation (for a LSP that enters the ring at LSR B and exits the ring
at LSR E): at LSR E):
1. The data packet arrives at LSR-A with label stack [L1+S] (i.e. 1. The data packet arrives at LSR-A with label stack [L1+S] (i.e.
top label from the LSP and bottom-of-stack indicator) top label from the LSP and bottom-of-stack indicator)
2. In the normal case (no switching), LSR-A forwards the packet with 2. In the normal case (no protection switching), LSR-A forwards the
label stack [PA1(F)|LSE+S] (i.e. swap the label for the LSP, to packet with label stack [PA1(F)|LSE+S] (i.e. swap the label for
be acceptable to the SPME egress, and push the label for the the LSP, to be acceptable to the SPME egress, and push the label
primary SPME from LSR-A to LSR-F). for the primary SPME from LSR-A to LSR-F).
3. When switching is in-effect, LSR-A forwards the packet with label 3. When protection switching is in-effect, LSR-A forwards the packet
stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for the with label stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for
secondary SPME from LSR-A to LSR-F, after swapping the label of the secondary SPME from LSR-A to LSR-F, after swapping the label
the lower level LSP). This will be transmitted along the of the lower level LSP). This will be transmitted along the
secondary SPME until LSR-E forwards it to LSR-F with label stack secondary SPME until LSR-E forwards it to LSR-F with label stack
[PE2(F)|LSE+S]. [PE2(F)|LSE+S].
4. When the packet arrives at LSR-F, it will pop the SPME label, 4. When the packet arrives at LSR-F, it will pop the SPME label,
process the LSP label, and forward the packet to the next point, process the LSP label, and forward the packet to the next point,
possibly pushing a SPME label if the next segment is likewise possibly pushing a SPME label if the next segment is likewise
protected. protected.
2.3.3. Wrapping node protection 2.3.3. Wrapping node protection
skipping to change at page 14, line 6 skipping to change at page 14, line 33
_*@ ___ _*# _*@ ___ _*#
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link *** physical link
### primary SPME @@@ secondary SPME ### primary SPME @@@ secondary SPME
Figure 4: Node-protection SPMEs Figure 4: Node-protection SPMEs
The protection mechanism would work similarly - based on 1:1 linear The protection mechanism would work similarly - based on 1:1 linear
protection [SurvivFwk], triggered by OAM functions on both SPMEs, and protection [RFC6372], triggered by OAM functions on both SPMEs, and
wrapping the data packets onto the secondary SPME at the ingress MEP wrapping the data packets onto the secondary SPME at the ingress MEP
(e.g. LSR-A in the figure) of the SPME and back onto the (e.g. LSR-A in the figure) of the SPME and back onto the
continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) continuation of the LSP at the egress MEP (e.g. LSR-E in the figure)
of the SPME. of the SPME.
2.3.4. Wrapping for link and node protection 2.3.4. Wrapping for link and node protection
In the different types of wrapping presented in Section 2.3.2 and In the different types of wrapping presented in Section 2.3.2 and
Section 2.3.3, there is a limitation that the protection mechanism Section 2.3.3, there is a limitation that the protection mechanism
must a priori decide whether it is protecting for link or node must a priori decide whether it is protecting for link or node
skipping to change at page 15, line 5 skipping to change at page 15, line 31
$$$ secondary node#2 SPME +++ secondary segment SPME $$$ secondary node#2 SPME +++ secondary segment SPME
Figure 5: Segment & Node protection SPMEs Figure 5: Segment & Node protection SPMEs
2.4. Analysis of p2p protection 2.4. Analysis of p2p protection
Analyzing the mechanisms described in the above subsections we can Analyzing the mechanisms described in the above subsections we can
point to the following observations (based on a ring with N nodes, point to the following observations (based on a ring with N nodes,
assumed to be not more than 16): assumed to be not more than 16):
o Number of SPME that need to be configured - for steeing SPME o Number of SPME that need to be configured - for steering SPME
protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress
LSR to each other node in the ring], for wrapping based on SPME LSR to each other node in the ring], for wrapping based on SPME
either as described in Section 2.3.2 and Section 2.3.3 = O(2N) either as described in Section 2.3.2 and Section 2.3.3 = O(2N)
[however, the operator must decide a priori on whether to protect [however, the operator must decide a priori on whether to protect
for link failures or node failures at each point] for link failures or node failures at each point]
o Number of OAM sessions at each node - for steering = O(2N), for o Number of OAM sessions at each node - for steering = O(2N), for
SPME wrapping = 3 SPME wrapping = 3
o Bandwidth requirements - for SPME-based steering: single bandwidth o Bandwidth requirements - for SPME-based steering: single bandwidth
skipping to change at page 15, line 36 skipping to change at page 16, line 15
as well as, violating the co-routedness of the protected traffic. as well as, violating the co-routedness of the protected traffic.
Based on this analysis, using steering as described in Section 2.3.1 Based on this analysis, using steering as described in Section 2.3.1
would be the recommended protection mechanism due to its simplicity, would be the recommended protection mechanism due to its simplicity,
even though it may involve the use of additional resources (i.e. even though it may involve the use of additional resources (i.e.
SPME) for monitorng the traffic. It should be pointed out that the SPME) for monitorng the traffic. It should be pointed out that the
number of SPME involved in this protection could be reduced by number of SPME involved in this protection could be reduced by
eliminating SPME between pairs of LSR that are not used as an ingress eliminating SPME between pairs of LSR that are not used as an ingress
and egress pair. and egress pair.
2.4.1. Recommendations for protection of p2p paths traversing a ring
Based on the analysis presented, while applying linear protection to
effect Wrapping protection to a ring topology is possible as
demonstrated, this does have certain limitations in addressing some
of the required behavior. The limitations include:
o Need to a-priori configure the protection for link or node
protection
o Increased number of SPME that need to be defined
o Difficulty in addressing cases of multiple failures in the ring
Application of linear protection, based on the use of SPME within the
ring, to implement a Steering methodology to protect a ring topology
is rather straight forward, overcomes the limitations listed above,
and scales very well. For this and other reasons listed previously,
the authors recommend the use of Steering to provide protection of a
ring topology when using the mechanisms described in this document
for protection of p2p paths that traverse the ring.
3. P2MP protection 3. P2MP protection
[TPReqs] requires that ring protection must provide protection for [RFC5654] requires that ring protection must provide protection for
unidirectional point-to-multipoint paths through the ring. Ring unidirectional point-to-multipoint paths through the ring. Ring
topologies provide a ready platform for supporting such data paths. topologies provide a ready platform for supporting such data paths.
A p2mp LSP in an MPLS-TP ring would be characterized by a single A p2mp LSP in an MPLS-TP ring would be characterized by a single
ingress LSR and multiple egress LSRs. The following sub-sections ingress LSR and multiple egress LSRs. The following sub-sections
will present methods to address the protection of the ring-based will present methods to address the protection of the ring-based
sections of these LSP. sections of these LSP.
3.1. Wrapping for p2mp LSP 3.1. Wrapping for p2mp LSP
When protecting a p2mp ring data path using the wrapping When protecting a p2mp ring data path using the wrapping
architecture, the basic operation is similar to the description architecture, the basic operation is similar to the description
given, as the traffic has been wrapped back onto the normal working given, as the traffic has been wrapped back onto the normal working
path on the far-side of the detected fault and will continue to be path on the far-side of the detected fault and will continue to be
transported to all of the egress points. transported to all of the egress points.
It is possible to optimize the performance of the wrapping mechanism It is possible to optimize the performance of the wrapping mechanism
when applied to p2mp LSPs by exploiting the topology of ring when applied to p2mp LSPs by exploiting the topology of ring
networks. networks.
This improved mechanism, which we call Ring Optimized Multicast This improved mechanism, which we call Ring Optimized Multipoint
Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. Wrapping (ROM-Wrapping), behaves much the same as classical wrapping.
There is one difference - rather than configuring the protection LSP There is one difference - rather than configuring the protection LSP
between the end nodes of a failed link (link protection) or between between the end nodes of a failed link (link protection) or between
the upstream and downstream node of a failed node (node protection), the upstream and downstream node of a failed node (node protection),
the improved mechanism configures a protection p2mp LSP from the the improved mechanism configures a protection p2mp LSP from the
upstream (with respect to the failure) node and all egress nodes (for upstream (with respect to the failure) node and all egress nodes (for
the particular LSP) downstream from the failure. the particular LSP) downstream from the failure.
Referring to Figure 6, it is possible to identify the protected Referring to Figure 6, it is possible to identify the protected
(working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup (working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup
skipping to change at page 18, line 32 skipping to change at page 19, line 32
traffic when ROM-Wrapping is used. Generally, the number of hops for traffic when ROM-Wrapping is used. Generally, the number of hops for
basic Wrapping is always higher or at least equal compared to ROM- basic Wrapping is always higher or at least equal compared to ROM-
Wrapping. This implies a certain waste of bandwidth on all links Wrapping. This implies a certain waste of bandwidth on all links
that are crossed in both directions. that are crossed in both directions.
Considering the ring network previously seen, it is possible to do Considering the ring network previously seen, it is possible to do
some bandwidth utilization considerations. The protected LSP is set some bandwidth utilization considerations. The protected LSP is set
up from A to F clockwise and an M Mbps bandwidth is reserved along up from A to F clockwise and an M Mbps bandwidth is reserved along
the path. All the protection LSPs are pre-provisioned the path. All the protection LSPs are pre-provisioned
counterclockwise, each of them may also have reserved bandwidth M. counterclockwise, each of them may also have reserved bandwidth M.
These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP] These LSPs share the same bandwidth in a SE (Shared Explicit)
style. [RFC2205] style.
The bandwidth reserved counterclockwise is not used when the The bandwidth reserved counterclockwise is not used when the
protected LSP is properly working and could, in theory, be used for protected LSP is properly working and could, in theory, be used for
extra traffic [RFC4427]. However, it should be noted that [TPReqs] extra traffic [RFC4427]. However, it should be noted that [RFC5654]
does not require support of such extra traffic. does not require support of such extra traffic.
The two recovery mechanism require different protection bandwidths. The two recovery mechanism require different protection bandwidths.
In the case of Wrapping, the bandwidth used is M in both directions In the case of Wrapping, the bandwidth used is M in both directions
of many of the links. While in case of ROM-Wrapping, only the links of many of the links. While in case of ROM-Wrapping, only the links
from the ingress node to the node performing the actual wrapping from the ingress node to the node performing the actual wrapping
utilize M bandwidth in both directions, while all other links utilize utilize M bandwidth in both directions, while all other links utilize
M bandwidth only in the counterclockwise direction. M bandwidth only in the counterclockwise direction.
Consider the case of a failure detected on link B-C as shown in Consider the case of a failure detected on link B-C as shown in
skipping to change at page 19, line 36 skipping to change at page 20, line 36
alternative paths to reach C. The whole P2MP traffic is lost. The alternative paths to reach C. The whole P2MP traffic is lost. The
ROM-Wrapping mechanism is able to partially recover from the failure, ROM-Wrapping mechanism is able to partially recover from the failure,
because the backup P2MP LSP to node F and node D is correctly set up because the backup P2MP LSP to node F and node D is correctly set up
and continues delivering traffic. and continues delivering traffic.
3.2. Steering for p2mp paths 3.2. Steering for p2mp paths
When protecting p2mp traffic that uses a MPLS-TP ring as its When protecting p2mp traffic that uses a MPLS-TP ring as its
branching point, i.e. it enters the ring at a head-end node and exits branching point, i.e. it enters the ring at a head-end node and exits
the ring at multiple nodes, we can employ a steering mechanism based the ring at multiple nodes, we can employ a steering mechanism based
on 1+1 linear protection [SurvivFwk]. We can configure two p2mp on 1+1 linear protection [RFC6372]. We can configure two p2mp
unidirectional SPME from each node on the ring that traverse the ring unidirectional SPME from each node on the ring that traverse the ring
in both directions. These SPME will be configured with an egress at in both directions. These SPME will be configured with an egress at
each ring node. In order to be able to properly direct the LSP each ring node. In order to be able to properly direct the LSP
traffic to the proper egress point for that particular LSP, we need traffic to the proper egress point for that particular LSP, we need
to employ context labeling as defined in [RFC5331]. The method for to employ context labeling as defined in [RFC5331]. The method for
using these labels is expanded in section 3.2.1. using these labels is expanded upon in section 3.2.1.
For every LSP that enters the ring at a given node the traffic will For every LSP that enters the ring at a given node the traffic will
be sent through both of these SPME, each with its own context label be sent through both of these SPME, each with its own context label
and the context-specific label for the particular LSP. The egress and the context-specific label for the particular LSP. The egress
nodes should select the traffic that is arriving on the working SPME. nodes should select the traffic that is arriving on the working SPME.
In case there is a failure condition, the egress nodes should select When a failure condition is identified, the egress nodes should
the traffic from whichever of the SPME that is arrives at that node, select the traffic from whichever of the two SPME whose traffic
i.e. since one of the two (presumably the working SPME) will be arrives at that node, i.e. since one of the two (presumably the
blocked by the failure. In this way, all egress nodes are able to working SPME) will be blocked by the failure. In this way, all
receive the data traffic. While each node detects that there is egress nodes are able to receive the data traffic. While each node
connectivity from the ingress point, it continues to select the data detects that there is connectivity from the ingress point, it
that is coming from the working SPME. If a particular node stops continues to select the data that is coming from the working SPME.
receiving the connectivity messages from the working SPME, it If a particular node stops receiving the connectivity messages from
identifies that it must switch its selector to read the data packets the working SPME, it identifies that it must select to read the data
from the protection SPME. packets from the protection SPME.
^ ^ ^ ^ ^ ^
_|_ _|_ _|_ _|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\ ----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/ \_A_/========\_B_/========\_C_/
+* <+++++++++*|| +* <+++++++++*||
+* +*|| +* +*||
+* +*|| +* +*||
+* +*|| +* +*||
+*_ ++++++++ ___ +++++++++*|| +*_ ++++++++ ___ +++++++++*||
skipping to change at page 21, line 4 skipping to change at page 22, line 4
context- identifying label) for a specific tunnel. The SPME label is context- identifying label) for a specific tunnel. The SPME label is
a context- identifying label. This means that at each hop the node a context- identifying label. This means that at each hop the node
that receives the SPME label uses it to point not directly to a that receives the SPME label uses it to point not directly to a
forwarding table, but to a LIB. As a node receives an SPME label it forwarding table, but to a LIB. As a node receives an SPME label it
examines it, discovers that it is a context label, pops off the SPME examines it, discovers that it is a context label, pops off the SPME
label, and looks up the next label down in the stack in the LIB label, and looks up the next label down in the stack in the LIB
indicated by the context label. indicated by the context label.
The label below this context-identifying label should be used by the The label below this context-identifying label should be used by the
forwarding function of the node to decide the actions taken for this forwarding function of the node to decide the actions taken for this
packet. In MPLS-TP ring protection there are two context LIBs. One packet. In MPLS-TP protection of ring topologies there are two
is the context LIB for the working SPME and the other is the context context LIBs. One is the context LIB for the working SPME and the
LIB for the P-SPME. All context LIBs have a behavior defined for the other is the context LIB for the P-SPME. All context LIBs have a
e2e LSP label but the behavior at each node may be different in the behavior defined for the e2e LSP label but the behavior at each node
context of each SPME. may be different in the context of each SPME.
For example, using the ring that is shown in Figure 7, if the working For example, using the ring that is shown in Figure 7, if the working
SPME is configured to have a context-identifying label of CW at each SPME is configured to have a context-identifying label of CW at each
node on the ring and the protection SPME is configured to have a node on the ring and the protection SPME is configured to have a
context-identifying label of CP at each node. For the specific LSP context-identifying label of CP at each node. For the specific LSP
we will designate the context-specific label used on the working SPME we will designate the context-specific label used on the working SPME
as WL(x-y) to be the label used as node-x to forward the packet to as WL(x-y) to be the label used as node-x to forward the packet to
node-y. Similarly, for the context-specific labels on the protection node-y. Similarly, for the context-specific labels on the protection
SPME would be designated PL(x-y). An explicit example of label SPME would be designated PL(x-y). An explicit example of label
values appears in the next sub-section. values appears in the next sub-section.
If we apply the 1+1 linear protection scheme outlined above for an Applying 1+1 linear protection, as outlined above, for a p2mp LSP
p2mp LSP that enters the ring at LSR-A and has egress points from the that enters the ring at LSR-A and has egress points from the ring at
ring at LSR-C and LSR-E using the two SPME shown in Figure 7 then a LSR-C and LSR-E using the two SPME shown in Figure 7 then a packet
packet that arrives at LSR-A with a label stack [LI+S] will be that arrives at LSR-A with a label stack [LI+S] will be forwarded on
forwarded on the working SPME with a label stack [CW | WL(A-B)]. The the working SPME with a label stack [CW | WL(A-B)]. The packet
packet should then be forwarded to LSR-C arriving with a label [CW | should then be forwarded to LSR-C arriving with a label [CW |
WL(B-C)], where WL(B-C) should instruct the forwarding function to WL(B-C)], where WL(B-C) should instruct the forwarding function to
egress the packet with [LE(C)] and forward a copy to LSR-D with label egress the packet with [LE(C)] and forward a copy to LSR-D with label
stack [CW | WL(C-D)]. stack [CW | WL(C-D)].
If a fault condition is detected, then some of the nodes will cease If a fault condition is detected, for example on the link C-D, then
to receive the packets from the clockwise (working) SPME. These LSR the nodes that are beyond the fault point, in this example nodes
should then begin to switch their selector bridge to accept the data LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from
packets from the protection SPME. At the ingress point the packet the clockwise (working) SPME. These LSR should then begin to switch
will be transmitted on both the working SPME and the protection SPME. their "selector bridge" and accept the data packets from the
Continuing the example, if there is a failure on the link between protection (counter-clockwise) SPME. At the ingress point, LSR-A,
LSR-C and LSR-D then LSR-A will transmit one copy of the data to all data packets will have been transmitted on both the working SPME
LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP and the protection SPME. Continuing the example, LSR-A will transmit
| PL(A-F)]. The packet will arrive at LSR-C from the working SPME one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy
and egress from the ring. LSR-E will receive the packet from the to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C
protection SPME with stack [CP | PL(F-E)] and the context-sensitive from the working SPME and egress from the ring. LSR-E will receive
label PL(F-E) will instruct the forwarding function to send a copy the packet from the protection SPME with stack [CP | PL(F-E)] and the
out of the ring with label LE(E) and a second copy to LSR-D with context-sensitive label PL(F-E) will instruct the forwarding function
stack [CP | PL(E-D)]. In this way each of the egress points receive to send a copy out of the ring with label LE(E) and a second copy to
the packet from the SPME that is available at that point. LSR-D with stack [CP | PL(E-D)]. In this way each of the egress
points receives the packet from the SPME that is available at that
point.
This architecture has the added advantages that there is no need for This architecture has the added advantages that there is no need for
the ingress node to identify the existence of the mis-connectivity, the ingress node to identify the existence of the mis-connectivity,
and there is no need for a return path from the egress points to the and there is no need for a return path from the egress points to the
ingress. ingress.
3.2.2. Walkthrough using context labels 3.2.2. Walkthrough using context labels
In order to better demonstrate the use of the context labels we In order to better demonstrate the use of the context labels we
present a walkthrough of an example application of the p2mp present a walkthrough of an example application of the p2mp
protection presented in this section. Referring to Figure 8, there protection presented in this section. Referring to Figure 8, there
is a p2mp LSP that traverses the ring, entering the ring at LSR-B and is a p2mp LSP that traverses the ring, entering the ring at LSR-B and
branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond
LSR-H. For purposes of protection two p2mp unidirectional SPME are LSR-H. For purposes of protection two p2mp unidirectional SPME are
configured on the ring starting from LSR-B. One of the SPME, the configured on the ring starting from LSR-B. One of the SPME, the
working SPME, is configured with egress points at each of the LSR - working SPME, is configured with egress points at each of the LSR -
C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is
configured with egress points at each of the LSR - A, K, J, H, G, F, configured with egress points at each of the LSR - A, K, J, H, G, F,
E, D, C. E, D, C.
^ ^ ^ ^ ^ ^ ^ ^ ^
_|_ xxxxxxxxx_|_ xxxxxxxxxX|_xxxxxxxxxX|_ xxxxxxxx_|_ ^ ^ ^ ^
___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/ \_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
*+ <+++++++++ +++++++ ++++++++*||x *+ <+++++++++ +++++++ ++++++++*||x
*+ +*||x *+ +*||x
*+ +*||x *+ +*||x
*+ +*||x *+ +*||x
_*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x _*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/ \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
| | | |Xxxxxxxxxx | + + + +Xxxxxxxxxx +
V V V V V v v v v v
v v v v v
xxx p2mp LSP (X LSP egress) *** physical link xxx p2mp LSP (X LSP egress) *** physical link
=== working SPME +++ protection SPME === working SPME +++ protection SPME
+>> protection SPME egress
Figure 8: P2MP SPMEs Figure 8: P2MP SPMEs
For this example we suppose that the LSP traffic enters the ring at For this example we suppose that the LSP traffic enters the ring at
LSR-B with the label stack [99], leaves the ring at LSR-D with stack LSR-B with the label stack [99], leaves the ring at LSR-D with stack
[199], at LSR-E with stack [299], and LSR-H with stack [399]. [199], at LSR-E with stack [299], and LSR-H with stack [399].
While it is possible for the context-identifying label for the SPME While it is possible for the context-identifying label for the SPME
be configured as a different value at each LSR, for the sake of this be configured as a different value at each LSR, for the sake of this
example we will suppose a configuration of 200 as the context- example we will suppose a configuration of 200 as the context-
skipping to change at page 23, line 48 skipping to change at page 24, line 48
will be forwarded along both SPME according to the configured will be forwarded along both SPME according to the configured
behavior in the context tables. However, the egress points at LSR D, behavior in the context tables. However, the egress points at LSR D,
E, & H, will all be configured with a selector bridge to only use the E, & H, will all be configured with a selector bridge to only use the
input from the working SPME. If any of these egress points identify input from the working SPME. If any of these egress points identify
that there is a connection fault on the working SPME, then the that there is a connection fault on the working SPME, then the
selector bridge will cause the LSR to read the input from the selector bridge will cause the LSR to read the input from the
protection SPME. protection SPME.
4. Coordination protocol 4. Coordination protocol
The Survivability Framework [SurvivFwk] indicates that there is a The Survivability Framework [RFC6372] indicates that there is a need
need to coordinate protection switching between the end-points of a to coordinate protection switching between the end-points of a
protected bidirectional domain. The coordination is necessary for protected bidirectional domain. The coordination is necessary for
particular cases, in order to maintain the co-routed nature of the particular cases, in order to maintain the co-routed nature of the
bidirectional transport path. The particular cases where this bidirectional transport path. The particular cases where this
becomes necessary include cases of unidirectional fault detection and becomes necessary include cases of unidirectional fault detection and
use of operator commands. use of operator commands.
By using the same mechanisms defined in [LinProtect], for linear By using the same mechanisms defined in [RFC6378], for linear
protection, to apply for ring protection we are able to gain a protection, to apply for protection of ring topologies we are able to
consistent solution for this coordination between the end-points of gain a consistent solution for this coordination between the end-
the protection domain. The Protection State Coordination Protocol points of the protection domain. The Protection State Coordination
that is specified in [LinProtect] provides coverage for all the Protocol that is specified in [RFC6378] provides coverage for all the
coordination cases, including support for operator commands, e.g. coordination cases, including support for operator commands, e.g.
Forced-Switch. Forced-Switch.
5. Conclusions and Recommendations 5. Conclusions and Recommendations
Ring topologies are prevelant in traditional transport networks and Ring topologies are prevalent in traditional transport networks and
will continue to be used for various reasons. Protection for will continue to be used for various reasons. Protection for
transport paths that traverse a ring within a MPLS network can be transport paths that traverse a ring within a MPLS network can be
provided by applying an appropriate instance of linear protection, as provided by applying an appropriate instance of linear protection, as
defined in [SurvivFwk]. This document has shown that for each of the defined in [RFC6372]. This document has shown that for each of the
traditional ring protection architectures there is an application of traditional ring protection architectures there is an application of
linear protection that provides efficient coverage, based on the use linear protection that provides efficient coverage, based on the use
of the Sub-Path Maintenance Entity (SPME), defined in [TPFwk] and of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and
[OAMFwk]. For example, [RFC6371]. For example,
o p2p Steering - Configuration of two SPME, from ring ingress to o p2p Steering - Configuration of two SPME, from ring ingress to
ring egress, and 1:1 linear protection ring egress, and 1:1 linear protection
o p2p Wrapping for link protection - Configuration of two SPME, one o p2p Wrapping for link protection - Configuration of two SPME, one
for the protected link and the second using the long route between for the protected link and the second using the long route between
the two neighboring nodes, and 1:1 linear protection. the two neighboring nodes, and 1:1 linear protection.
o p2p Wrapping for node protection - Configuration of two SPME, one o p2p Wrapping for node protection - Configuration of two SPME, one
between the two neighbors of the protected node and the second between the two neighbors of the protected node and the second
skipping to change at page 24, line 49 skipping to change at page 25, line 49
o p2mp Wrapping - it is possible to optimize the performance of the o p2mp Wrapping - it is possible to optimize the performance of the
wrapping by configuring the proper protection path to egress the wrapping by configuring the proper protection path to egress the
data at the proper branching nodes. data at the proper branching nodes.
o p2mp Steering - by combining 1+1 linear protection and o p2mp Steering - by combining 1+1 linear protection and
configuration of the SPME based on context-sensitive labeling of configuration of the SPME based on context-sensitive labeling of
the protection path. the protection path.
It has been shown that this set of protection architecture and It has been shown that this set of protection architecture and
mechanisms are optimized based on the criteria defined in [TPReqs] mechanisms are optimized based on the criteria defined in [RFC5654]
for justification of designing a specific protection mechanism for a for justification of designing a specific protection mechanism for a
ring topology. This thereby aleviates the necessity to create a new ring topology.
mechanism or protocol to support the protection of ring topologies.
By basing the simple p2p ring protection on basic 1:1 linear Protection of traffic over a ring topology based on the Steering
protection there is a very efficient way of implementing Steering architecture using basic 1:1 linear protection is a very efficient
protection for the sections of a transport path that traverses the implementation for sections of a p2p transport path that traverses a
ring. Steering should be the preferred mechanism for ring protection ring. Steering should be the preferred mechanism for p2p protection
since it reduces the extra bandwidth required when traffic doubles in a ring topology since it reduces the extra bandwidth required when
through wrapped protection, and the ability to protect both against traffic doubles through wrapped protection, and the ability to
link and node failures without complicating the fault detection or protect both against link and node failures without complicating the
the need to configure multiple protection paths. While this is true, fault detection or the need to configure multiple protection paths.
the possiblity remains to support either mechanism while depending While this is true, the possiblity remains to support either
upon the OAM functionality [outlined in [OAMFwk] and specified in mechanism while depending upon the OAM functionality [outlined in
various documents] and the coordination protocol specified for linear [RFC6371] and specified in various documents] and the coordination
protection in [LinProtect]. protocol specified for linear protection in [RFC6378].
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
To be added in future version. This document does not add any security risks to the network. Any
security considerations are defined in [RFC6378] and their
applicability to the information contained in this document follow
naturally from the applicability of the mechanism defined in that
document.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank all members of the teams (the Joint The authors would like to acknowledge the strong contributions from
Working Team, the MPLS Interoperability Design Team in IETF and the all the people commenting on this draft and making suggestions for
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and improvements.
specification of MPLS Transport Profile.
9. Informative References 9. Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, Aug 2008. RFC 5331, Aug 2008.
[TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
"Requirements for the Transport Profile of MPLS", and S. Ueno, "Requirements for the Transport Profile of
RFC 5654, April 2009. MPLS", RFC 5654, Sept 2009.
[TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Framework", RFC 5921, May 2010. Berger, "MPLS-TP Framework", RFC 5921, July 2010.
[OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM [RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371,
Framework", RFC 6371, May 2010. Sept 2011.
[SurvivFwk] [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability
Sprecher, N. and A. Farrel, "MPLS-TP Survivability Framework", RFC 6372, Sept 2011.
Framework", RFC 6372, June 2010.
[LinProtect] [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378,
and Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378, October 2011.
October 2009.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specifications", RFC 2205, September 1997. Specifications", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for GMPLS", RFC 4427, March 2006. Restoration) Terminology for GMPLS", RFC 4427, March 2006.
[G.841] ITU, "Types and characteristics of SDH network protection [G.841] ITU, "Types and characteristics of SDH network protection
architectures", ITU-T G.841, October 1998. architectures", ITU-T G.841, October 1998.
Authors' Addresses Authors' Addresses
skipping to change at page 27, line 4 skipping to change at page 28, line 4
Israel Israel
Phone: Phone:
Email: wyaacov@gmail.com Email: wyaacov@gmail.com
Stewart Bryant Stewart Bryant
Cisco Cisco
United Kingdom United Kingdom
Email: stbryant@cisco.com Email: stbryant@cisco.com
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: nurit.sprecher@nsn.com
Danielle Ceccarelli Danielle Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Diego Caviglia Diego Caviglia
Ericsson Ericsson
 End of changes. 81 change blocks. 
267 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/