draft-ietf-mpls-tp-ring-protection-06.txt   rfc6974.txt 
Network Working Group Y. Weingarten Internet Engineering Task Force (IETF) Y. Weingarten
Internet-Draft Request for Comments: 6974
Intended status: Informational S. Bryant Category: Informational S. Bryant
Expires: October 31, 2013 Cisco ISSN: 2070-1721 Cisco Systems
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
ZTE Corporation ZTE Corporation
April 29, 2013 X. Dai
July 2013
Applicability of MPLS-TP Linear Protection for Ring Topologies Applicability of MPLS Transport Profile for Ring Topologies
draft-ietf-mpls-tp-ring-protection-06.txt
Abstract Abstract
This document presents an applicability of existing MPLS protection This document presents an applicability of existing MPLS protection
mechanisms, both local and end-to-end, to Multi-Protocol Label mechanisms, both local and end-to-end, to the MPLS Transport Profile
Switching Transport Profile (MPLS-TP) in ring topologies. This (MPLS-TP) in ring topologies. This document does not propose any new
document does not propose any new mechanisms or protocols. mechanisms or protocols. Requirements for MPLS-TP protection
Protection on rings offers a number of opportunities for optimization especially for protection in ring topologies are discussed in
as the protection choices are starkly limited (all traffic traveling "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS
one way around a ring can only be switched to travel the other way on Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372).
the ring), but also suffers from some complications caused by the This document discusses how most of the requirements are met by
limitations of the topology. applying linear protection as defined in RFC 6378 in a ring topology.
Requirements for MPLS-TP protection especially for protection in ring
topologies are discussed in "Requirements of an MPLS Transport
Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
Survivability Framework" (RFC 6372). This document shows how MPLS-TP
linear protection as defined in RFC 6378 can be applied to single
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
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 31, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6974.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 1.2. Scope of the Document . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 2. Point-to-Point (P2P) Ring Protection . . . . . . . . . . . . . 6
2. Point-to-point (P2P) Ring Protection . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. SPME for P2P Protection of a Ring Topology . . . . . . . . 10
2.3. SPME for P2P protection of a ring topology . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping link protection with segment based SPME . . . 13 2.3.2. Wrapping Link Protection with Segment-Based SPME . . . 12
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14 2.3.3. Wrapping Node Protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for link and node protection . . . . . . . . 15 2.3.4. Wrapping for Link and Node Protection . . . . . . . . 14
2.4. Analysis of P2P protection . . . . . . . . . . . . . . . . 16 2.4. Analysis of P2P Protection . . . . . . . . . . . . . . . . 15
2.4.1. Recommendations for protection of P2P paths 2.4.1. Recommendations for Protection of P2P Paths
traversing a ring . . . . . . . . . . . . . . . . . . 17 Traversing a Ring . . . . . . . . . . . . . . . . . . 16
3. Point-to-multipoint protection . . . . . . . . . . . . . . . . 17 3. Point-to-Multipoint Protection . . . . . . . . . . . . . . . . 17
3.1. Wrapping for P2MP LSP . . . . . . . . . . . . . . . . . . 17 3.1. Wrapping for P2MP LSPs . . . . . . . . . . . . . . . . . . 17
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 21 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2. Steering for P2MP paths . . . . . . . . . . . . . . . . . 21 3.2. Steering for P2MP Paths . . . . . . . . . . . . . . . . . 21
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 22 3.2.1. Context Labels . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Walkthrough using context labels . . . . . . . . . . . 24 3.2.2. Walk-Through Using Context Labels . . . . . . . . . . 23
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 25 4. Coordination Protocol . . . . . . . . . . . . . . . . . . . . 26
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been The MPLS Transport Profile (MPLS-TP) has been standardized as part of
standardized as part of a joint effort between the Internet a joint effort between the Internet Engineering Task Force (IETF) and
Engineering Task Force (IETF) and the International Telecommunication the International Telecommunications Union Telecommunications
Union Standardization (ITU-T). These specifications are based on the Standardization Sector (ITU-T). These specifications are based on
requirements that were generated from this joint effort. the requirements that were generated from this joint effort.
The MPLS-TP requirement document [RFC5654] includes a requirement to The MPLS-TP requirement document [RFC5654] includes a requirement to
support a network that may include sub-networks that constitute an support a network that may include subnetworks that constitute an
MPLS-TP ring as defined in the document. However, the document does MPLS-TP ring as defined in the document. However, the document does
not identify any protection requirements specific to a ring topology. not identify any protection requirements specific to a ring topology.
However, the requirements state that specific protection mechanisms The requirements state that specific protection mechanisms applying
applying to ring topologies may be developed if these allow the to ring topologies may be developed if these allow the network to
network to minimize: minimize:
o Number of OAM entities needed to trigger the protection o the number of OAM entities needed to trigger the protection
o Number of elements of recovery needed o the number of elements of recovery needed
o Number of labels required o the number of labels required
o Number of control and management plane transactions during a o the number of control- and management-plane transactions during a
maintenance operation maintenance operation
o Impact of signaling and routing information exchanged during o the impact of signaling and routing information exchanged during
protection, in the presence of a control plane protection, in the presence of a control plane
This document describes how applying a set of basic MPLS-TP linear This document describes how applying a set of basic MPLS-TP linear
protection mechanisms defined in [RFC6378] can be used to provide protection mechanisms defined in [RFC6378] can be used to provide
protection of the data flows that traverse an MPLS-TP ring. These protection of the data flows that traverse an MPLS-TP ring. These
mechanisms provide data flow protection due to any switching trigger mechanisms provide data flow protection due to any switching trigger
within a reasonable time frame and optimize the criteria set out in within a reasonable time frame and optimize the criteria set out in
[RFC5654], as summarized above. This document does not define any [RFC5654], as summarized above. This document does not define any
new protocol mechanisms or procedures. new protocol mechanisms or procedures.
A related topic in [RFC5654] 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 [RFC5654], are used in transport Ring topologies, as defined in [RFC5654], are used in transport
networks. When designing a protection mechanism for a single ring networks. When designing a protection mechanism for a single ring
topology, there is a need to address both - topology, there is a need to address both of the following cases.
1. A point-to-point transport path that either originates at or
enters an MPLS-TP capable ring at one node, the ingress node, and 1. A point-to-point transport path that originates at a ring node or
exits the ring at a single egress node possibly continuing beyond enters an MPLS-TP-capable ring at a single ingress node, and
the ring. exits the ring at a single egress node, and possibly continues
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 originates at multipoint transport path, i.e., the transport path originates at
or enters the MPLS-TP capable ring at the ingress node and exits or enters the MPLS-TP-capable ring at the ingress node and exits
through a number of egress nodes, possibly continuing beyond the through a number of egress nodes, possibly continuing beyond the
ring. ring.
In either of these two situations, there is a need to address the In either of these two situations, there is a need to address the
following different cases - following different cases.
1. One of the ring links causes a fault condition. This could be 1. One of the ring links causes a fault condition. This could be
either a unidirectional or bidirectional fault, and should be either a unidirectional or bidirectional fault, and it 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 it should be detected by the two neighboring ring
nodes.
3. An operator command changes the operational state of a node or a 3. An operator command is issued to a specific ring node; it either
link, or specifically triggers a protection action is issued to a changes the operational state of a node or a link or explicitly
specific ring node. A description of the different operator triggers a protection action. An operator command changes the
commands is found in Section 4.13 of [RFC4427]. Examples of operational state of a node or a link, or specifically triggers a
these commands include Manual Switch, Forced Switch, or Clear protection action is issued to a specific ring node. A
operations. description of the different operator commands is found in
Section 4.13 of [RFC4427]. Examples of these commands include
Manual Switch, Forced Switch, and 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 traverses on the ring. Protection triggers on the traffic that traverses on the ring. Protection triggers on the
transport path prior to the ring ingress node or beyond the egress transport path prior to the ingress node of the ring or beyond the
nodes may be protected by some other mechanism. egress nodes may be protected by some other mechanism.
1.2. Scope of the document 1.2. Scope of the Document
This document addresses the requirements that appear in Section This document addresses the requirements that appear in Section
2.5.6.1 of [RFC5654] on Ring Protection based on the application of 2.5.6.1 of [RFC5654] on ring protection, based on the application of
the linear protection as defined in [RFC6378]. Requirement R93 the linear protection as defined in [RFC6378]. Requirement R93
regarding the support of interconnected rings and protection of regarding the support of interconnected rings and protection of
faults in the interconnection nodes and links is for further study. faults in the interconnection nodes and links is for further study.
In addition, requirement R105 requiring the support of lockout of In addition, requirement R105 requiring the support of lockout of
specific nodes or spans is only supported to the degree that it is specific nodes or spans is only supported to the degree that it is
supported by the linear protection mechanism. supported by the linear protection mechanism.
1.3. Terminology and Notation 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[RFC5921] o MPLS-TP framework [RFC5921]
o MPLS-TP OAM Framework[RFC6371] o MPLS-TP OAM framework [RFC6371]
o MPLS-TP Survivability Framework[RFC6372] o MPLS-TP survivability framework [RFC6372]
The MPLS-TP Framework document [RFC5921] defines a Sub-Path The MPLS-TP framework document [RFC5921] defines a Sub-Path
Maintenance Entity (SPME) construct that can be defined between any Maintenance Entity (SPME) construct that can be defined between any
two Label Switching Routers (LSR) of an MPLS-TP Label Switched Path two Label Switching Routers (LSRs) of an MPLS-TP Label Switched Path
(LSP). This SPME may be configured as a co-routed bidirectional (LSP). This SPME may be configured as a co-routed bidirectional
path. The SPME is defined to allow management and monitoring of any path. The SPME is defined to allow management and monitoring of any
segment of a transport path. This concept will be used extensively segment of a transport path. This concept will be used extensively
throughout the document to support protection of the traffic that throughout the document to support protection of the traffic that
traverses an MPLS-TP ring. traverses an 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
levels however, we only present the levels that are germane to levels; however, we only present the levels that are germane to
the protection mechanism. the protection mechanism.
3. When applicable, the S-bit (signifying that a given label is the 3. When applicable, the S bit (signifying that a given label is the
bottom of the label stack) will be denoted by the string '+S' bottom of the label stack) will be denoted by the string '+S'
within the label. If a label is not shown with '+S' that label within the label. If a label is not shown with '+S' , that label
may or may not be the bottom label in the stack. '+S' is only may or may not be the bottom label in the stack. '+S' is only
shown when it is important to illustrate that a given label is shown when it is important to illustrate that a given label is
definitely the last one in the label stack. definitely the last one in the label stack.
4. The label of the LSP at the ingress point to the ring will be 4. The label of the LSP at the ingress node of the ring will be
denoted by the string "LI" and the label of the LSP that is denoted by the string "LI", and the label of the LSP that is
expected at the egress point from the ring will be denoted by the expected at the egress point from the ring will be denoted by the
string "LE", and "LSE" will denote the label expected at the exit string "LE". "LSE" will denote the label expected at the exit
LSR of a SPME (if it is different from the egress point from the LSR of a SPME (if it is different from the egress point from the
ring, for example as described in Section 2.3). ring, for example, as described in Section 2.3).
5. The label for a SPME will be denoted by Pxi(y) where x and y are 5. The label Pxi(y) in the stack denotes the label that LSR-x would
LSR identifiers and the intention is to the label for LSR-x to use to transport the packet to LSR-y over the SPME whose index is
transmit to LSR-y over the SPME whose index is i. i.
For example - For example:
o the label stack [LI] denotes the label stack received at the o The label stack [LI] denotes the label stack received at the
ingress node of the ring. This may have additional labels after ingress node of the ring. There may be additional labels after
LI, e.g. a PW label however, this is irrelevant to the discussion LI, e.g., a PW label; however, this is irrelevant to the
of the protection scenario. discussion 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, and the second
is the label that would be used by the egress LSR to continue the label is the label that would be used by the egress LSR to
packet on the original LSP. continue to transmit the 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.4. Contributing Authors
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)
Eric Osborne (Cisco)
2. Point-to-point (P2P) Ring Protection 2. Point-to-Point (P2P) Ring Protection
There are two protection architecture mechanisms, that have There are two protection architecture mechanisms -- "Wrapping" and
historically been applied to ring topologies, based on SDH "Steering" -- that have historically been applied to ring topologies,
specifications [G.841], and have been proposed in various forums to based on Synchronous Digital Hierarchy (SDH) specifications [G.841],
perform recovery of a topological ring network - "Wrapping" and and have been proposed in various forums to perform recovery of a
"Steering". The following sub-sections examine these two mechanisms, topological ring network. The following subsections examine these
as applied to an MPLS transport network. 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 nodes 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 node 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 to
data along the path, there is need to "wrap" all data traffic around transmit the data along the path, there is a need to "wrap" all data
the ring, on an alternate data path, until arriving at the node that traffic around the ring, on an alternate data path, until the arrives
is on the opposite side of the fault. When this far-side node also at the node that is on the opposite side of the fault. When this
detects that there is a fault condition on the working path, it can far-side node also detects that there is a fault condition on the
identify that the data traffic that is arriving on the alternate working path, it can identify that the data traffic that is arriving
(protecting) data path is intended for the "broken" data path. on the alternate (protecting) data path is intended for the "broken"
Therefore, again taking a local decision, can wrap the data back onto data path. Therefore, again making a local decision, the far-side
the normal working path until the egress from the ring segment. node can wrap the data back onto the normal working path until the
egress from the ring segment.
Wrapping behavior is similar to MPLS-TE FRR as defined in [RFC4090] Wrapping behavior is similar to MPLS-TE Fast Reroute, as defined in
using either bypass or detour tunnels. Applying this methodology to [RFC4090], which uses either bypass or detour tunnels. Applying Fast
MPLS, it is possible to wrap the traffic of each LSP around the Reroute to MPLS, it is possible to wrap all LSPs using a bypass
failed links via a detour tunnel using a different label for each LSP tunnel and a single label, or to wrap the traffic of each LSP around
or to wrap all LSPs using a bypass tunnel and a single label. the failed links via a detour tunnel using a different label for each
LSP.
___ ######## ___ ######## ___ ___ ######## ___ ######## ___
======>/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
Consider the LSP that is shown in Figure 1 that enters the ring of Consider the LSP that is shown in Figure 1 that enters the ring of
LSRs at LSR-B and exits at LSR-E. The normal working path LSP LSRs at LSR-B and exits at LSR-E. The normal working path LSP
follows through LSRs B-A-F-E. If a fault is detected on the link follows through LSRs B-A-F-E. If a fault is detected on the link
A<->F, then the wrapping mechanism decides that LSR-A would wrap the A<->F, then the wrapping mechanism decides that LSR-A would wrap the
traffic around the ring, on a wrapped data path A-B-C-D-E-F, to traffic around the ring, on a wrapped data path A-B-C-D-E-F, to
arrive at LSR-F (on the far side of the failed link). LSR-F would arrive at LSR-F (on the far side of the failed link). LSR-F would
then wrap the data packets back onto the working path F->E to the then wrap the data packets back onto the working path F->E to the
egress node. In this protection scheme, the traffic will follow the egress node. In this protection scheme, the traffic will follow the
path - 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 LSRs 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). However, coordination of the switchover to the the far end). However, coordination of the switchover to the
protection path would be needed to maintain the traffic on a co- protection path would be needed to maintain the traffic on a co-
routed bidirectional LSP even in cases of a unidirectional fault routed bidirectional LSP even in cases of a unidirectional fault
condition. 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 mis-connectivity or loss of continuity 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
link protection or node protection) needs to be performed (i.e., link protection or node protection) needs to be performed a
a-priori, since the configuration of the proper protection path is priori, since the configuration of the proper protection path is
dependent upon this decision. dependent upon this decision.
o There is a need to define a data-path that traverses the alternate o There is a need to define a data path that traverses the alternate
path around the ring to connect between the two neighbors of the path around the ring to connect between the two neighbors of the
detected fault. If protecting both the links and the nodes of a detected fault. If protecting both the links and the nodes of an
LSP, then, for a ring with N nodes, there is a need for O(2N) LSP, then, for a ring with N nodes, there is a need for O(2N)
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, and later it
transmitted E->F and F->E. This means that there is additional is 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 encountered on the working path. This is the first fault location encountered on the working path. This is
based on the need for wrapping to connect between the neighbors of based on the need for wrapping to connect between the neighbors of
the fault location, and this is not possible in the segmented the fault location, and this is not possible in the segmented
ring. ring.
o The resource pre-allocation for all of the alternate-paths could o The resource pre-allocation for all of the alternate paths could
be problematic [causing massive over subscription of the available be problematic (causing massive over subscription of the available
resources]. However, since most of these alternate paths will not resources). However, since most of these alternate paths will not
be used simultaneously, there is the possibility of allocating '0' be used simultaneously, there is the possibility of allocating
resources and depend on the NMS to allocate the proper resources zero resources and depending on the Network Management System
around the ring, based on actual traffic usage. (NMS) to allocate the proper resources around the ring, based on
actual traffic usage.
o Wrapping also involves a small increase in traffic latency in o Wrapping also involves a small increase in traffic latency in
delivering the packets, as a result of traversing the entire ring, delivering the packets, as a result of traversing the entire ring,
during protection. 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 node of 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).
___ ___ ___ ___ ___ ___
======>/LSR\********/LSR\********/LSR\======> ======>/LSR\********/LSR\********/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 @@@ protection path ### working path @@@ protection path
Figure 2: Steering protection in an MPLS-TP ring Figure 2: Steering Protection in an MPLS-TP Ring
This mechanism bears similarities to linear 1:1 protection [RFC6372]. This mechanism bears similarities to linear 1:1 protection [RFC6372].
The two paths around the ring act as the working and protection The two paths around the ring act as the working and protection
paths. There is need to communicate to the ingress node the need to paths. This requires that the ingress node be informed of the need
switch over to the protection path and there is a need to coordinate to switch over to the protection path, and also that the ingress and
the switchover between the two end-points of the protected domain. egress nodes coordinate the switchover. There is need to communicate
to the ingress node the need to switch over to the protection path
and there is a need to coordinate the switchover between the two
endpoints of the protected 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 [RFC6371], e.g. Remote OAM functionality described in [RFC6371], e.g., Remote Defect
Defect Indication, Alarm reporting. 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. SPME for P2P protection of a ring topology 2.3. SPME for P2P Protection of a Ring Topology
The SPME concept was introduced by [RFC5921] to support management The SPME concept was introduced by [RFC5921] to support management
and monitoring an arbitrary segment of a transport. However, an SPME and monitoring an arbitrary segment of a transport. However, an SPME
is essentially a valid LSP that may be used to aggregate all LSP is essentially a valid LSP that may be used to aggregate all LSP
traffic that traverses the sub-path delineated by the SPME. An SPME traffic that traverses the sub-path delineated by the SPME. An SPME
may be monitored using the OAM mechanisms as described in the MPLS-TP may be monitored using the OAM mechanisms as described in the MPLS-TP
OAM Framework document [RFC6371]. OAM framework document [RFC6371].
When defining an MPLS-TP ring as a protection domain, there is a need When defining an 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 types of transport
path and protection that is being implemented and will be detailed in path and protection that are being implemented. This will be
the following sub-sections. detailed in the following subsections.
Based on this architectural configuration for protection of ring Based on this architectural configuration for protection of ring
topologies, it is possible to limit the number of alternate paths topologies, it is possible to limit the number of alternate paths
needed to protect the data traversing the ring. In addition, since needed to protect the data traversing the ring. In addition, since
we will perform all of the OAM functionality on the SPME configured we will perform all of the OAM functionality on the SPME configured
for the traffic, we can minimize the number of OAM sessions needed to for the traffic, we can minimize the number of OAM sessions needed to
monitor the data traffic of the ring - rather than monitoring each monitor the data traffic of the ring, rather than monitoring each
individual LSP. individual LSP.
In all of the following subsections, we use 1:1 linear protection In all of the following subsections, we use 1:1 linear protection
[RFC6372] [RFC6378] to perform protection switching and coordination [RFC6372] [RFC6378] to perform protection switching and coordination
when a signal fault is detected. The actual configuration of the when a signal fault is detected. The actual configuration of the
SPMEs used may change dependent upon the choice of methodology and SPMEs used may change depending upon the choice of methodology, and
this will be detailed in the following sections. However, in all of this will be detailed in the following sections. However, in all of
these configurations the mechanism will be to transmit the data these configurations, the mechanism will be to transmit the data
traffic on the primary SPME, while applying OAM functionality over traffic on the primary SPME, while applying OAM functionality over
both the primary and the secondary SPME to detect signal fault both the primary and the secondary SPME to detect signal fault
conditions on either path. If a signal fault is detected on the conditions on either path. If a signal fault is detected on the
primary SPME, then the mechanism described in [RFC6378] shall be used primary SPME, then the mechanism described in [RFC6378] shall be used
to coordinate a switch-over of data traffic to the secondary SPME. to coordinate a switchover of data 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] and arrive at LSR-F with [PE1(F)
The SPME label will be popped by LSR-F and the LSP label will be | LE]). The SPME label will be popped by LSR-F, and the LSP label
treated appropriately at LSR-F and forwarded along the LSP, outside will be treated appropriately at LSR-F and forwarded along the LSP,
the ring. This scenario is true for all LSP that are aggregated by outside the ring. This scenario is true for all LSPs that are
this primary SPME. aggregated by this primary SPME.
2.3.1. Path SPME for Steering 2.3.1. Path SPME for Steering
A P2P SPME that traverses part of a ring has two Maintenance Entity A P2P SPME that traverses part of a ring has two Maintenance Entity
Group End Points (MEPs), each one acts as the ingress and egress in Group End Points (MEPs), each one acts as the ingress and egress in
one direction of the bidirectional SPME. Since the SPME is one direction of the bidirectional SPME. Since the SPME is
traversing a ring we can take advantage of another characteristic of traversing a ring, we can take advantage of another characteristic of
a ring - there is always an alternative path between the two MEPs, a ring -- there is always an alternative path between the two MEPs,
i.e. traversing the ring in the opposite direction. This alternative i.e., traversing the ring in the opposite direction. This
SPME can be defined as the protection path for the working path that alternative SPME can be defined as the protection path for the
is configured as part of the LSP and defined as a SPME. working path that 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.
The following figure shows an MPLS-TP ring that is part of a larger The following figure shows an 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 SPMEs through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F). traverses B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___ ___ ___ ___
======>/LSR\********/LSR\********/LSR\======> =====>/LSR\********/LSR\********/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
### primary SPME @@@ secondary SPME ### primary SPME @@@ secondary SPME
Figure 3: An MPLS-TP ring Figure 3: An MPLS-TP Ring
This protection mechanism is identical to application of 1:1 linear This protection mechanism is identical to the application of 1:1
protection[RFC6372] [RFC6378] to the pair of SPMEs. Under normal linear protection [RFC6372] [RFC6378] to the pair of SPMEs. Under
conditions, all LSP data traffic will be transmitted on the working normal conditions, all LSP data traffic will be transmitted on the
SPME. If the linear protection is triggered, by either the OAM working SPME. If the linear protection is triggered by the OAM
indication, an other fault indication trigger, or an operator indication, another fault indication trigger, or an operator command,
command, then the MEPs will select the protection SPME to transmit then the MEPs will select the protection SPME to transmit all LSP
all LSP data packets. 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, i.e. the the stable recovery of the fault condition. Upon recovery, i.e., the
fault condition has cleared and the network is stabilized, 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
[RFC6378]. [RFC6378].
2.3.2. Wrapping link protection 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 SPMEs -- 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 is between those same two LSRs but traverses the
entire ring (except the link that connects the LSRs). In Figure 4 we entire ring (except the link that connects the LSRs). In Figure 4,
show the primary SPME that connects LSR-A & LSR-F over a segment we show the primary SPME that connects LSR-A and 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.
___ ___ ___ ___ ___ ___
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/ \_B_/@@@@@@@@\_A_/########\_F_/
*@ *@ *@ *@
*@ *@ *@ *@
*@ *@ *@ *@
_*@ ___ _*@ _*@ ___ _*@
/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: Segment SPMEs Figure 4: Segment SPMEs
By applying OAM monitoring of these two SPME (at each LSR), it is By applying OAM monitoring of these two SPMEs (at each LSR), it is
possible to affect a wrapping protection mechanism for the LSP possible to effect a wrapping protection mechanism for the LSP
traffic that traverses the ring. The LSR on either side of the traffic that traverses the ring. The LSR on either side of the
segment would identify that there is a fault condition on the link segment would identify that there is a fault condition on the link
and redirect all LSP traffic to the secondary SPME. The traffic and redirect all LSP traffic to the secondary SPME. The traffic
would traverse the ring until arriving at the neighboring (relative would traverse the ring until arriving at the neighboring (relative
to the segment) LSR. At this point, the LSP traffic would be to the segment) LSR. At this point, the LSP traffic would be
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) the top label from the LSP and bottom-of-stack indicator)
2. In the normal case (no protection switching), LSR-A forwards the 2. In the normal case (no protection switching), LSR-A forwards the
packet with label stack [PA1(F)|LSE+S] (i.e. swap the label for packet with label stack [PA1(F) | LSE+S] (i.e., swaps the label
the LSP, to be acceptable to the SPME egress, and push the label for the LSP, to be acceptable to the SPME egress, and pushes the
for the primary SPME from LSR-A to LSR-F). label for the primary SPME from LSR-A to LSR-F).
3. When protection switching is in-effect, LSR-A forwards the packet 3. When protection switching is in effect, LSR-A forwards the packet
with label stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for with label stack [PA2(B) | LSE+S] (i.e., LSR-A pushes the label
the secondary SPME from LSR-A to LSR-F, after swapping the label for the secondary SPME from LSR-A to LSR-F, after swapping the
of the lower level LSP). This will be transmitted along the label of the lower-level LSP). This will be transmitted along
secondary SPME until LSR-E forwards it to LSR-F with label stack the secondary SPME until LSR-E forwards it to LSR-F with label
[PE2(F)|LSE+S]. stack [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 pops the SPME label, process
process the LSP label, and forward the packet to the next point, the LSP label, and forwards 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
Implementation of protection at the node level would be similar to Implementation of protection at the node level would be similar to
the mechanism described in the previous sub-section. The difference the mechanism described in the previous subsection. The difference
would be in the SPMEs that are used. For node protection, the would be in the SPMEs that are used. For node protection, the
primary SPME would be configured between the two LSR that are primary SPME would be configured between the two LSRs that are
connected to the node that is being protected (see SPME between LSR-A connected to the node that is being protected (see the SPME between
and LSR-E through LSR-F in Figure 5), and the secondary SPME would be LSR-A and LSR-E through LSR-F in Figure 5), and the secondary SPME
configured between these same nodes, going around the ring (see would be configured between these same nodes, going around the ring
secondary SPME in Figure 5). (see the secondary SPME in Figure 5).
___ ___ ___ ___ ___ ___
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/ \_B_/@@@@@@@@\_A_/########\_F_/
*@ *# *@ *#
*@ *# *@ *#
*@ *# *@ *#
_*@ ___ _*# _*@ ___ _*#
/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 5: Node-protection SPMEs Figure 5: Node-Protection SPMEs
The protection mechanism would work similarly - based on 1:1 linear The protection mechanism would work similarly -- it would be based on
protection [RFC6372], triggered by OAM functions on both SPMEs, and 1:1 linear protection [RFC6372] and be triggered by OAM functions on
wrapping the data packets onto the secondary SPME at the ingress MEP both SPMEs. It would wrap the data packets onto the secondary SPME
(e.g. LSR-A in the figure) of the SPME and back onto the at the ingress MEP (e.g., LSR-A in the figure) of the SPME and back
continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) onto the continuation of the LSP at the egress MEP (e.g., LSR-E in
of the SPME. the figure) 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 against link or node
failure. In addition, the neighboring LSR, that detects the fault, failure. In addition, the neighboring LSR, that detects the fault,
cannot readily differentiate between a link failure or a node cannot readily differentiate between a link failure or a node
failure. failure.
It would be possible to configure extra SPME to protect both for link It would be possible to configure extra SPMEs to protect both for
and node failures, arriving at a configuration of the ring that is link and node failures, arriving at a configuration of the ring that
shown in Figure 6. Here there are three protection SPME configured: is shown in Figure 6. Here, there are three protection SPMEs
configured:
o Secondary node#1 would be used to divert traffic as a result of an o Secondary node#1 would be used to divert traffic as a result of an
indication that LSR-F is not available, it redirects traffic to be indication that LSR-F is not available; it redirects the traffic
transmitted between LSR-A and LSR-E. to the path between LSR-A and LSR-E.
o Secondary node#2 would be used to divert traffic as a result of an o Secondary node#2 would be used to divert traffic as a result of an
indication that LSR-A is not available, it redirects traffic to be indication that LSR-A is not available; it redirects the traffic
transmitted between LSR-F and LSR-B. to the path between LSR-F and LSR-B.
o Secondary segment would be used to divert traffic as a result of o Secondary segment would be used to divert traffic as a result of
an indication that the segment between LSR-A and LSR-F is not an indication that the segment between LSR-A and LSR-F is not
available, it redirects traffic to be transmitted between LSR-A available; it redirects the traffic to the path between LSR-A and
and LSR-F on the long circuit of the ring. LSR-F on the long circuit of the ring.
Choosing the SPME to use for the wrapping would, however, then However, choosing the SPME to use for the wrapping would then involve
involve considerable effort and could result in the protected traffic considerable effort and could result in the protected traffic not
not sharing the same protection path in both directions. sharing the same protection path in both directions.
___ ++++++++ ___ ___ ___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/ \_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$ $+*@ +*$
$+*@ +*$ $+*@ +*$
$+*@ +*$ $+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$ $+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
$$$$$$$$ $$$$$$$$ $$$$$$$$ $$$$$$$$
*** physical link *** physical link
### primary SPME @@@ secondary node#1 SPME ### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME $$$ secondary node#2 SPME +++ secondary segment SPME
Figure 6: Segment & Node protection SPMEs Figure 6: SPMEs for Protecting Segments and Node
2.4. Analysis of P2P protection 2.4. Analysis of P2P Protection
Analyzing the mechanisms described in the above subsections we can Analyzing steering SPME protection (Section 2.3.1) and wrapping based
point to the following observations (based on a ring with N nodes, on SPME (Sections 2.3.2 or 2.3.3), we can make the following
assumed to be not more than 16): observations (based on a ring with N nodes, where N is not more than
16):
o Number of SPME that need to be configured - for steering SPME o Number of SPMEs that need to be configured
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
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
for link failures or node failures at each point]
o Number of OAM sessions at each node - for steering = O(2N), for For steering: O(2N^2). There are two SPMEs from each ingress
SPME wrapping = 3 LSR to each of the other nodes in the ring.
o Bandwidth requirements - for SPME-based steering: single bandwidth For wrapping: O(2N). (However, the operator must decide a
at each link, for wrapping: double bandwidth at links that are priori whether to protect for link failures or node failures at
between ingress and wrapping node and between second wrapping node each point.)
and egress.
o Special considerations - for SPME based steering: latency of OAM o Number of OAM sessions at each node
detection of fault condition by ingress MEP [using Alarm-reporting
could optimize over using CC-V only], for SPME wrapping: at each For steering: O(2N)
node must decide a priori whether protecting for link or node
failures. To protect for both node and link failures would For wrapping: 3
increase the complexity of deciding which protection path to use,
as well as, violating the co-routedness of the protected traffic. o Bandwidth requirements
For steering: single bandwidth at each link
For wrapping: double bandwidth at links that are between
ingress and wrapping node and between second wrapping node and
egress.
o Special considerations
For steering: latency of OAM detection of fault condition by
ingress MEP. (Using alarm reporting could optimize over using
CC-V only.)
For wrapping: each node must decide a priori whether it is
protecting for link or node failures. To protect for both node
and link failures would increase the complexity of deciding
which protection path to use, as well as violate 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.
It should be pointed out that the number of SPMEs involved in this
protection could be reduced by eliminating each SPME between a pair
of LSRs that is not used as an ingress and egress pair.
It should be pointed out that the number of SPME involved in this 2.4.1. Recommendations for Protection of P2P Paths Traversing a Ring
protection could be reduced by eliminating SPME between pairs of LSR
that are not used as an ingress 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 Based on the analysis presented, while applying linear protection to
effect Wrapping protection to a ring topology is possible as effect wrapping protection in a ring topology is possible as
demonstrated, this does have certain limitations in addressing some demonstrated, there are certain limitations in addressing some of the
of the required behavior. The limitations include: required behavior. The limitations include:
o Need to a-priori configure the protection for link or node o the need to configure a priori whether link or node protection
protection will be provided
o Increased number of SPME that need to be defined o the higher number of SPMEs that need to be defined
o Difficulty in addressing cases of multiple failures in the ring o the difficulty in addressing cases of multiple failures in the
ring
Application of linear protection, based on the use of SPME within the Application of linear protection, based on the use of SPMEs within
ring, to implement a Steering methodology to protect a ring topology the ring, to implement a steering methodology to protect a ring
is rather straight forward, overcomes the limitations listed above, topology is rather straightforward, overcomes the limitations listed
and scales very well. For this and other reasons listed previously, above, and scales very well. For this and other reasons listed
the authors recommend the use of Steering to provide protection of a previously, the authors recommend the use of steering to provide
ring topology when using the mechanisms described in this document protection of P2P paths that traverse a ring topology.
for protection of P2P paths that traverse the ring.
3. Point-to-multipoint protection 3. Point-to-Multipoint Protection
[RFC5654] 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 Point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be A point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be
characterized by a single ingress LSR and multiple egress LSRs. The characterized by a single ingress LSR and multiple egress LSRs. The
following sub-sections will present methods to address the protection following subsections will present methods to address the protection
of the ring-based sections of these LSP. of the ring-based sections of these LSPs.
3.1. Wrapping for P2MP LSP 3.1. Wrapping for P2MP LSPs
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 Multipoint 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.
However, ROM-Wrapping configures protection P2MP LSP, relative to However, ROM-Wrapping configures a protection P2MP LSP, relative to
each node that is considered a failure risk, from the upstream node each node that is considered a failure risk. The protection P2MP LSP
and all egress nodes (for the particular LSP) downstream from the will be routed between the failure risk node's upstream neighbor to
failure risk. all of the egress nodes (for the particular LSP) that are downstream
of the failure risk node.
Referring to Figure 7, it is possible to identify the protected Referring to Figure 7, 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
(protection) LSP (note:the egress nodes are indicated by the curly (protection) LSP. (Note: the egress nodes are indicated by the curly
braces). This protection LSP will be used to wrap the data back braces.) This protection LSP will be used to wrap the data back
around the ring to protect against a failure on link B-C. This around the ring to protect against a failure on link B-C. This
protection LSP is also a P2MP LSP that is configured with egress protection LSP is also a P2MP LSP that is configured with egress
points (at nodes F, D, & C) complementary to the broken working data points (at nodes F, D, and C) complementary to the broken working
path. data path.
| |
| |
V Ingress V Ingress
___ _V_ ___ ___ _V_ ___
/LSR\ /LSR\**************/LSR\ /LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/ <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * * @ * *
@ * * @ * *
@ * XXXX Failure @ * XXXX Failure
@ * * @ * *
@_* ___ __* @_* ___ __*
/LSR\*************/LSR\**************/LSR\ /LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/ \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @ @ @
@ @ @ @
V V V V
*** working LSP @@@ protection LSP *** working LSP @@@ protection LSP
Figure 7: P2MP ROM Wrapping Figure 7: P2MP ROM-Wrapping
Using this mechanism, there is a need to configure a particular Using this mechanism, there is a need to configure a particular
protection LSP for each node on the working LSP. In the table below, protection LSP for each node on the working LSP. In the table below,
"X's Backup" is the backup path activated by node X as a consequence "X's Backup" is the backup path activated by node X as a consequence
of a failure affecting node Y (downstream node with respect to X) or of a failure affecting node Y (downstream node with respect to X) or
link X-Y, and square brackets, in the path,indicate egress nodes. link X-Y. (Note: Braces in the path indicate egress nodes.)
Protected LSP: A->B->{C}->{D}->E->{F} Protected LSP: A->B->{C}->{D}->E->{F}
-- LINK/NODE PROTECTION -- -- LINK/NODE PROTECTION --
A's Backup: A->{F}->E->{D}->{C} A's Backup: A->{F}->E->{D}->{C}
B's Backup: B->A->{F}->E->{D}->{C} B's Backup: B->A->{F}->E->{D}->{C}
C's Backup: C->B->A->{F}->E->{D} C's Backup: C->B->A->{F}->E->{D}
D's Backup: D->C->B->A->{F} D's Backup: D->C->B->A->{F}
E's Backup: E->D->C->B->A->{F} E's Backup: E->D->C->B->A->{F}
It should be noted that ROM-Wrapping is an LSP based protection It should be noted that ROM-Wrapping is an LSP-based protection
mechanism, as opposed to the SPME based protection mechanisms that mechanism, as opposed to the SPME-based protection mechanisms that
are presented in other sections of this draft. While this may seem are presented in other sections of this document. While this may
to be limited in scope, the mechanism may be very efficient for many seem to be limited in scope, the mechanism may be very efficient for
applications that are based on P2MP distribution schemes. While ROM- many applications that are based on P2MP distribution schemes. While
Wrapping can be applied to any network topology, it is particularly ROM-Wrapping can be applied to any network topology, it is
efficient for interconnected ring topologies. particularly efficient for interconnected ring topologies.
3.1.1. Comparison of Wrapping and ROM-Wrapping 3.1.1. Comparison of Wrapping and ROM-Wrapping
It is possible to compare the Wrapping and the ROM-Wrapping It is possible to compare the wrapping and the ROM-Wrapping
mechanisms in different aspects, and show some improvements offered mechanisms in various aspects and show some improvements offered by
by ROM-Wrapping. ROM-Wrapping.
When configuring the protection LSP for Wrapping it is necessary to When configuring the protection LSP for wrapping, it is necessary to
configure for a specific failure: link protection or node protection. configure for a specific failure: link protection or node protection.
If the protection method is configured to protect node failures but If the protection method is configured to protect against node
the actual failure affects a link, this could result in failing to failures, but the actual failure affects a link, this could result in
deliver traffic to the node, when it should be possible to. failing to deliver traffic to the node, when it should be possible to
do so.
ROM-Wrapping however does not have this limitation, because there is ROM-Wrapping, however, does not have this limitation because there is
no distinction between node and link protection. Whether link B-C or no distinction between node and link protection. Whether link B-C or
node C fails, in either case the rerouting will attempt to reach C. node C fails, the rerouting will attempt to reach C. If the failure
If the failure is on the link, the traffic will be delivered to C, is on the link, the traffic will be delivered to C; if the failure is
while if the failure is at node C, the traffic will be rerouted at node C, the traffic will be rerouted correctly until node D, and
correctly until node D, and will be blocked at this point. However, will be blocked at this point. However, all egress nodes up to the
all egress nodes up-to the failure will be able to deliver the failure will be able to deliver the traffic properly.
traffic properly.
A second aspect is the number of hops needed to properly deliver the A second aspect is the number of hops needed to properly deliver the
traffic. Referring to the example shown in Figure 7, where a failure traffic. Referring to the example shown in Figure 7, where a failure
is detected on link B-C, the following table lists the set of nodes is detected on link B-C, the following table lists the set of nodes
traversed by the data in the protection: traversed by the data in the protection:
Basic Wrapping: Basic Wrapping:
A-B B-A-F-E-D-C {C}-{D}-E-{F} A-B B-A-F-E-D-C {C}-{D}-E-{F}
"Upstream" segment backup path "Downstream" segment "Upstream" segment backup path "Downstream" segment
with respect to the with respect to the with respect to the with respect to the
failure failure failure failure
ROM Wrapping: ROM-Wrapping:
A-B B-A-{F}-E-{D}-{C} .. A-B B-A-{F}-E-{D}-{C} ..
"Upstream" segment backup path "Upstream" segment backup path
with respect to the with respect to the
failure failure
Comparing the two lists of nodes, it is possible to see that in this Comparing the two lists of nodes, it is possible to see that in this
particular case the number of hops crossed using the simple Wrapping particular case the number of hops crossed when basic wrapping is
is significantly higher than the number of hops crossed by the used is significantly higher than the number of hops crossed by the
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 greater than or equal to that for 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 in Figure 7, it is possible to consider
some bandwidth utilization considerations. The protected LSP is set the bandwidth utilization. The protected LSP is set up from A to F
up from A to F clockwise and an M Mbps bandwidth is reserved along clockwise and an M Mbps bandwidth is reserved along the path. All
the path. All the protection LSPs are pre-provisioned the protection LSPs are pre-provisioned counterclockwise, each of
counterclockwise, each of them may also have reserved bandwidth M. them may also have reserved bandwidth M. These LSPs share the same
These LSPs share the same bandwidth in a SE (Shared Explicit) bandwidth in a SE (Shared Explicit) style, as described in [RFC2205].
[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, in theory, could be used for
extra traffic [RFC4427]. However, it should be noted that [RFC5654] 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 mechanisms 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 on many of the links. While in the case of ROM-Wrapping, only the
from the ingress node to the node performing the actual wrapping links from the ingress node to the node performing the actual
utilize M bandwidth in both directions, while all other links utilize wrapping utilize M bandwidth in both directions, while all other
M bandwidth only in the counterclockwise direction. links utilize 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
Figure 7. The following table lists the bandwidth utilization on Figure 7. The following table lists the bandwidth utilization on
each link (in units equal to M), for each recovery mechanism and for each link (in units equal to M), for each recovery mechanism and for
each direction (CW=clockwise, CCW=counterclockwise). each direction (CW=clockwise, CCW=counterclockwise).
+----------+----------+--------------+ +----------+----------+--------------+
| | Wrapping | ROM-Wrapping | | | Wrapping | ROM-Wrapping |
+----------+----------+--------------+ +----------+----------+--------------+
| Link A-B | CW+CCW | CW+CCW | | Link A-B | CW+CCW | CW+CCW |
| Link A-F | CCW | CCW | | Link A-F | CCW | CCW |
| Link F-E | CW+CCW | CCW | | Link F-E | CW+CCW | CCW |
| Link E-D | CW+CCW | CCW | | Link E-D | CW+CCW | CCW |
| Link D-C | CW+CCW | CCW | | Link D-C | CW+CCW | CCW |
+----------+----------+--------------+ +----------+----------+--------------+
3.1.2. Multiple Failures Comparison 3.1.2. Multiple Failures Comparison
A further comparison between Wrapping and ROM-Wrapping can be done A further comparison of wrapping and ROM-Wrapping can be done with
with respect to their ability to react to multiple failures. The respect to their ability to react to multiple failures. The wrapping
wrapping recovery mechanism does not have the ability to recover from recovery mechanism does not have the ability to recover from multiple
multiple failures on a ring network, while ROM-Wrapping is able to failures on a ring network, while ROM-Wrapping is able to recover
recover, from some multiple failures. from some multiple failures.
Consider, for example, a double link failure affecting links B-C and Consider, for example, a double link failure affecting links B-C and
C-D shown in Figure 7. The Wrapping mechanism is not able to recover C-D shown in Figure 7. The wrapping mechanism is not able to recover
from the failure because B, upon detecting the failure, has no from the failure because B, upon detecting the failure, has no
alternative paths to reach C. The whole P2MP traffic is lost. The alternative paths to reach C. All the 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 F and D is correctly set up and
and continues delivering traffic. continues delivering traffic.
3.2. Steering for P2MP paths 3.2. Steering for P2MP Paths
When protecting P2MP traffic that uses an MPLS-TP ring as its When protecting P2MP traffic that uses an MPLS-TP ring as its
branching point, i.e. it enters the ring at a head-end node and exits branching point (i.e., the traffic enters the ring at a head-end node
the ring at multiple nodes, we can employ a steering mechanism based and exits the ring at multiple nodes), we can employ a steering
on 1+1 linear protection [RFC6372]. We can configure two P2MP mechanism based on 1+1 linear protection [RFC6372]. We can configure
unidirectional SPME from each node on the ring that traverse the ring two P2MP unidirectional SPMEs from each node on the ring; they
in both directions. These SPME will be configured with an egress at traverse the ring in both directions. These SPMEs will be configured
each ring node. In order to be able to properly direct the LSP with an egress at each ring node. In order to be able to direct the
traffic to the proper egress point for that particular LSP, we need LSP traffic to the proper egress point for that particular LSP, we
to employ context labeling as defined in [RFC5331]. The method for need to employ context labeling as defined in [RFC5331]. The method
using these labels is expanded upon in section 3.2.1. for 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 SPMEs, 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.
When a failure condition is identified, the egress nodes should When a failure condition is identified, the egress nodes should
select the traffic from whichever of the two SPME whose traffic select the traffic from whichever of the two SPMEs whose traffic
arrives at that node, i.e. since one of the two (presumably the arrives at that node, i.e., since one of the two (presumably the
working SPME) will be blocked by the failure. In this way, all working SPME) will be blocked by the failure. In this way, all
egress nodes are able to receive the data traffic. While each node egress nodes are able to receive the data traffic. While each node
detects that there is connectivity from the ingress point, it detects that there is connectivity from the ingress node of the ring,
continues to select the data that is coming from the working SPME. it continues to select the data that is coming from the working SPME.
If a particular node stops receiving the connectivity messages from If a particular node stops receiving the connectivity messages from
the working SPME, it identifies that it must select to read the data the working SPME, it identifies that it must select to read the data
packets from the protection SPME. packets from the protection SPME.
3.2.1. Context labels 3.2.1. Context Labels
Figure 8 shows the two unidirectional P2MP SPME that are configured Figure 8 shows the two unidirectional P2MP SPMEs that are configured
from LSR-A with egress points at all of the nodes on the ring. The from LSR-A with egress points at all of the nodes on the ring. The
clockwise SPME (i.e. A-B-C-D-E-F) is configured as the working SPME, clockwise SPME (i.e., A-B-C-D-E-F) is configured as the working SPME
that will aggregate all traffic for P2MP LSPs that enter the ring at that will aggregate all traffic for P2MP LSPs that enter the ring at
LSR-A and must be sent out of the ring at any subset of the ring LSR-A and must be sent out of the ring at any subset of the ring
nodes. The counter-clockwise SPME (i.e. A-F-E-D-C-B) is configured nodes. The counter-clockwise SPME (i.e., A-F-E-D-C-B) is configured
as the protection SPME. as the protection SPME.
^ ^ ^ ^ ^ ^
_|_ _|_ _|_ _|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\ ----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/ \_A_/========\_B_/========\_C_/
+* <+++++++++*|| +* <+++++++++*||
+* +*|| +* +*||
+* +*|| +* +*||
+* +*|| +* +*||
+*_ ++++++++ ___ +++++++++*|| +*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\ /LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/ \_F_/<=======\_E_/========\_D_/
| | | | | |
V V V V V V
---> connected LSP *** physical link ---> connected LSP *** physical link
=== working SPME +++ protection SPME === working SPME +++ protection SPME
Figure 8: P2MP SPMEs Figure 8: P2MP SPMEs
[RFC5331] defines the concept of context labels. A context- [RFC5331] defines the concept of context labels. A context-
identifying label defines a context label space that is used to identifying label defines a context label space that is used to
interpret the context-specific labels (found directly below the interpret the context-specific labels (found directly below the
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 Label Information Base (LIB). As a node forwarding table, but to a Label Information Base (LIB). As a node
receives an SPME label it examines it, discovers that it is a context receives an SPME label, it examines it, discovers that it is a
label, pops off the SPME label, and looks up the next label down in context label, pops off the SPME label, and looks up the next label
the stack in the LIB indicated by the context label. down in the stack in the LIB 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 to take for
packet. In MPLS-TP protection of ring topologies there are two this packet. In MPLS-TP protection of ring topologies, there are two
context LIBs. One is the context LIB for the working SPME and the context LIBs. One is the context LIB for the working SPME, and the
other is the context LIB for the P-SPME. All context LIBs have a other is the context LIB for the protection SPME. All context LIBs
behavior defined for the end-to-end LSP label but the behavior at have a behavior defined for the end-to-end LSP label, but the
each node may be different in the context of each SPME. behavior at each node may be different in the context of each SPME.
For example, using the ring that is shown in Figure 8, if the working For example, using the ring that is shown in Figure 8, 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), where it's the label used as node-x forwards the packet
node-y. Similarly, for the context-specific labels on the protection to node-y. Similarly, a context-specific label 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 subsection.
Applying 1+1 linear protection, as outlined above, for a P2MP LSP Assume we are applying 1+1 linear protection, as outlined above, for
that enters the ring at LSR-A and has egress points from the ring at a P2MP LSP that enters the ring at LSR-A and has egress points from
LSR-C and LSR-E using the two SPME shown in Figure 8 then a packet the ring at LSR-C and LSR-E using the two SPMEs shown in Figure 8. A
that arrives at LSR-A with a label stack [LI+S] will be forwarded on packet that arrives at LSR-A with a label stack [LI+S] will be
the working SPME with a label stack [CW | WL(A-B)]. The packet forwarded on the working SPME with a label stack [CW | WL(A-B)]. The
should then be forwarded to LSR-C arriving with a label [CW | packet 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, for example on the link C-D, then If a fault condition is detected (for example, on the link C-D), then
the nodes that are beyond the fault point, in this example nodes the nodes that are beyond the fault point (in this example, nodes
LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from LSR-D, LSR-E, and LSR-F), will cease to receive the data packets from
the clockwise (working) SPME. These LSR should then begin to switch the clockwise (working) SPME. Each of these LSRs should then begin
their "selector bridge" and accept the data packets from the to switch its "selector bridge" and accept the data packets from the
protection (counter-clockwise) SPME. At the ingress point, LSR-A, protection (counter-clockwise) SPME. At the ingress point (LSR-A),
all data packets will have been transmitted on both the working SPME all data packets will have been transmitted on both the working SPME
and the protection SPME. Continuing the example, LSR-A will transmit and the protection SPME. Continuing the example, LSR-A will transmit
one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy
to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C
from the working SPME and egress from the ring. LSR-E will receive from the working SPME and egress from the ring. LSR-E will receive
the packet from the protection SPME with stack [CP | PL(F-E)] and the the packet from the protection SPME with stack [CP | PL(F-E)], and
context-sensitive label PL(F-E) will instruct the forwarding function the context-sensitive label PL(F-E) will instruct the forwarding
to send a copy out of the ring with label LE(E) and a second copy to function to send a copy out of the ring with label LE(E) and a second
LSR-D with stack [CP | PL(E-D)]. In this way each of the egress copy to LSR-D with stack [CP | PL(E-D)]. In this way, each of the
points receives the packet from the SPME that is available at that egress points receives the packet from the SPME that is available at
point. 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. Walk-Through 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 walk-through of an example application of the P2MP
protection presented in this section. Referring to Figure 9, there protection presented in this section. Referring to Figure 9, 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 it does not continue
LSR-H. For purposes of protection two P2MP unidirectional SPME are beyond LSR-H. For purposes of protection, two P2MP unidirectional
configured on the ring starting from LSR-B. One of the SPME, the SPMEs are configured on the ring starting from LSR-B. One of the
working SPME, is configured with egress points at each of the LSR - SPMEs, the working SPME, is configured with egress points at each of
C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is the LSRs -- C, D, E, F, G, H, J, K, A. The second SPME, the
configured with egress points at each of the LSR - A, K, J, H, G, F, protection SPME, is configured with egress points at each of the LSRs
E, D, C. -- A, K, J, H, G, F, 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 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 +>> protection SPME egress
Figure 9: P2MP SPMEs Figure 9: 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], and leaves the ring:
[199], at LSR-E with stack [299], and LSR-H with stack [399].
o at LSR-D with stack [199]
o at LSR-E with stack [299]
o at 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 to be configured as a different value at each LSR, for the sake of
example we will suppose a configuration of 200 as the context- this example, we will suppose a configuration of 200 as the context-
identifying label for the working SPME at each of the LSR in the identifying label for the working SPME at each of the LSRs in the
ring, and 400 as the context-identifying label for the protection ring, and 400 as the context-identifying label for the protection
SPME at each LSR. SPME at each LSR.
For the specific connected LSP we configure the following context- For the specific connected LSP, we configure the following context-
specific labels for each context: specific labels:
+------+-----------------------------+------------------------------+ +------+-----------------------------+------------------------------+
| node | W-context(200) | P-context(400) | | node | W-context(200) | P-context(400) |
+------+-----------------------------+------------------------------+ +------+-----------------------------+------------------------------+
| A | 65 {drop packet} | 165 {fwrd w/[400|190]} | | A | 65 {drop packet} | 165 {fwd w/ [400 | 190]} |
| C | 90 {fwrd w/[200|80]} | 190 {drop packet} | | C | 90 {fwd w/ [200 | 80]} | 190 {drop packet} |
| D | 80 {fwrd w/[200|75] + | 180 {egress w/[199]} | | D | 80 {fwd w/ [200 | 75] + | 180 {egress w/ [199]} |
| | egress w/[199]} | | | | egress w/ [199]} | |
| E | 75 {fwrd w/[200|65] + | 175 {fwrd w/[400|180] + | | E | 75 {fwd w/ [200 | 65] + | 175 {fwd w/ [400 | 180] + |
| | egress w/[299]} | egress w/[299]} | | | egress w/ [299]} | egress w/ [299]} |
| F | 65 {fwrd w/[200|55]} | 165 {fwrd w/[400|175]} | | F | 65 {fwd w/ [200 | 55]} | 165 {fwd w/ [400 | 175]} |
| G | 55 {fwrd w/[200|45]} | 155 {fwrd w/[400|165]} | | G | 55 {fwd w/ [200 | 45]} | 155 {fwd w/ [400 | 165]} |
| H | 45 {egress w/[399]} | 145 {fwrd w/[400|155] + | | H | 45 {egress w/ [399]} | 145 {fwd w/ [400 | 155] + |
| | | egress w/[399]} | | | | egress w/ [399]} |
| J | 65 {drop packet} | 165 {fwrd w/[400|145]} | | J | 65 {drop packet} | 165 {fwd w/ [400 | 145]} |
| K | 65 {drop packet} | 190 {fwrd w/[400|165]} | | K | 65 {drop packet} | 190 {fwd w/ [400 | 165]} |
+------+-----------------------------+------------------------------+ +------+-----------------------------+------------------------------+
When a packet arrives on the LSP to LSR-B with stack [99], the When a packet arrives on the LSP to LSR-B with stack [99], the
forwarding function determines that it is necessary to forward the forwarding function determines that it is necessary to forward the
packet to both the working SPME with stack [200|90] and the packet to both the working SPME with stack [200 | 90] and the
protection SPME with stack [400|165]. Each LSR on the SPME will protection SPME with stack [400 | 165]. Each LSR on the SPME will
identify the top label, i.e. 200 or 400, to be the context- identify the top label, i.e., 200 or 400, to be the context-
identifying label and use the next label in the stack to select the identifying label and use the next label in the stack to select the
forwarding action from the specific context table. forwarding action from the specific context table.
Therefore, at LSR-C the packet on the working SPME will arrive with Therefore, at LSR-C, the packet on the working SPME will arrive with
stack [200|90] and the 200 will point to the table in the middle stack [200 | 90], and the 200 will point to the middle column of the
column above. After popping the 200 the next label, i.e. 90, will table above. After popping the 200, the next label, i.e., 90, will
select the forwarding action "fwrd w/[200|80]" and the packet will be select the forwarding action "fwd w/ [200 | 80]", and the packet will
forwarded to LSR-D with stack [200|80]. In this manner, the packet be forwarded to LSR-D with stack [200 | 80]. In this manner, the
will be forwarded along both SPME according to the configured packet will be forwarded along both SPMEs 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 LSR-E, and LSR-H will each be configured with a selector bridge so
input from the working SPME. If any of these egress points identify they will use only the input from the working SPME. If any of these
that there is a connection fault on the working SPME, then the egress points identifies that there is a connection fault on the
selector bridge will cause the LSR to read the input from the working SPME, then the selector bridge will cause the LSR to read the
protection SPME. input from the protection SPME.
4. Coordination protocol 4. Coordination Protocol
The Survivability Framework [RFC6372] indicates that there is a need The survivability framework [RFC6372] indicates that there is a need
to coordinate protection switching between the end-points of a to coordinate protection switching between the endpoints 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 when unidirectional fault detection or
use of operator commands. operator commands are used.
By using the same mechanisms defined in [RFC6378], for linear By using the same mechanisms defined in [RFC6378] for linear
protection, to apply for protection of a single ring topology we are protection to protect a single ring topology, we are able to gain a
able to gain a consistent solution for this coordination between the consistent solution for this coordination between the endpoints of
end-points of the protection domain. The Protection State the protection domain. The Protection State Coordination Protocol
Coordination Protocol that is specified in [RFC6378] provides that is specified in [RFC6378] provides coverage for all the
coverage for all the coordination cases, including support for coordination cases, including support for operator commands, e.g.,
operator commands, e.g. Forced-Switch. Forced Switch.
5. Conclusions and Recommendations 5. Conclusions and Recommendations
Ring topologies are prevalent 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 an MPLS network can be transport paths that traverse a ring within an 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 [RFC6372]. 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 [RFC5921] and of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and
[RFC6371]. For example, [RFC6371]. For example:
o P2P Steering - Configuration of two SPME, from ring ingress to o P2P steering - Configuration of two SPMEs, from the ingress node
ring egress, and 1:1 linear protection of the ring to the egress node of the ring, 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 SPMEs, one
for the protected link and the second using the long route between for the protected link and the second for 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 SPMEs, one
between the two neighbors of the protected node and the second between the two neighbors of the protected node and the second
between these two nodes on the long route, and 1:1 linear between these two nodes on the long route, and 1:1 linear
protection. protection.
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 This document shows that use of the protection architecture and
mechanisms are optimized based on the criteria defined in [RFC5654] mechanisms suggested provides the optimizations needed to justify
for justification of designing a specific protection mechanism for a ring-specific protection as defined in [RFC5654].
ring topology.
Protection of traffic over a ring topology based on the Steering Protection of traffic over a ring topology based on the steering
architecture using basic 1:1 linear protection is a very efficient architecture using basic 1:1 linear protection is a very efficient
implementation for sections of a P2P transport path that traverses a implementation for sections of a P2P transport path that traverses a
ring. Steering should be the preferred mechanism for P2P protection ring. Steering should be the preferred mechanism for P2P protection
in a ring topology since it reduces the extra bandwidth required when in a ring topology since it reduces the extra bandwidth required when
traffic doubles through wrapped protection, and the ability to traffic doubles through wrapped protection, and it provides the
protect both against link and node failures without complicating the ability to protect both against link and node failures without
fault detection or the need to configure multiple protection paths. complicating the fault detection or requiring that multiple
While this is true, the possiblity remains to support either protection paths be configured. While this is true, it's possible to
mechanism while depending upon the OAM functionality [outlined in support either wrapping or steering while depending upon the OAM
[RFC6371] and specified in various documents] and the coordination functionality (outlined in [RFC6371] and specified in various
protocol specified for linear protection in [RFC6378]. documents) and the coordination protocol specified for linear
protection in [RFC6378].
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations 6. Security Considerations
This document does not add any security risks to the network. Any This document does not add any security risks to the network. Any
security considerations are defined in [RFC6378] and their security considerations are defined in [RFC6378], and their
applicability to the information contained in this document follow applicability to the information contained in this document follows
naturally from the applicability of the mechanism defined in that naturally from the applicability of the mechanism defined in that
document. document.
8. Acknowledgements 7. References
The authors would like to acknowledge the strong contributions from 7.1. Normative References
all the people commenting on this draft and making suggestions for
improvements.
9. References [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011.
9.1. Normative References 7.2. Informative References
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [G.841] ITU, "Types and characteristics of SDH network protection
A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378, architectures", ITU-T G.841, October 1998.
October 2011.
9.2. Informative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[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.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[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, August 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements for the Transport Profile of and S. Ueno, "Requirements of an MPLS Transport Profile",
MPLS", RFC 5654, Sept 2009. RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "MPLS-TP Framework", RFC 5921, July 2010. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371, [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Sept 2011. Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile
Framework", RFC 6372, Sept 2011. (MPLS-TP) Survivability Framework", RFC 6372,
September 2011.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Appendix A. Acknowledgements
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specifications", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and The authors would like to acknowledge the strong contributions from
Restoration) Terminology for GMPLS", RFC 4427, March 2006. all the people who commented on this document and made suggestions
for improvements.
[G.841] ITU, "Types and characteristics of SDH network protection Appendix B. Contributors
architectures", ITU-T G.841, October 1998.
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)
Eric Osborne (Cisco)
Authors' Addresses Authors' Addresses
Yaacov Weingarten Yaacov Weingarten
34 Hagefen St. 34 Hagefen St.
Karnei Shomron, 4485500 Karnei Shomron, 4485500
Israel Israel
Phone: Phone:
Email: wyaacov@gmail.com EMail: wyaacov@gmail.com
Stewart Bryant Stewart Bryant
Cisco Cisco Systems
United Kingdom 10 New Square, Bedfont Lakes
Feltham, Middlesex,
TW18 8HA
UK
Email: stbryant@cisco.com EMail: stbryant@cisco.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
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: diego.caviglia@ericsson.com EMail: diego.caviglia@ericsson.com
Francesco Fondelli Francesco Fondelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: francesco.fondelli@ericsson.com EMail: francesco.fondelli@ericsson.com
Marco Corsi Marco Corsi
Altran Altran
Via A. Negrone 1/A Via A. Negrone 1/A
Genova, Sestri Ponente Genova, Sestri Ponente
Italy Italy
Email: corsi.marco@gmail.com EMail: corsi.marco@gmail.com
Bo Wu Bo Wu
ZTE Corporation ZTE Corporation
4F,RD Building 2,Zijinghua Road 4F, RD Building 2, Zijinghua Road
Nanjing, Yuhuatai District Nanjing, Yuhuatai District
P.R.China P.R. China
Email: wu.bo@zte.com.cn EMail: wu.bo@zte.com.cn
Xuehui Dai Xuehui Dai
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Nanjing, Yuhuatai District
P.R.China
Email: dai.xuehui@zte.com.cn EMail: xuehuiwfsy@gmail.com
 End of changes. 231 change blocks. 
674 lines changed or deleted 680 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/