draft-ietf-mpls-tp-ring-protection-05.txt   draft-ietf-mpls-tp-ring-protection-06.txt 
Network Working Group Y. Weingarten Network Working Group Y. Weingarten
Internet-Draft Internet-Draft
Intended status: Informational S. Bryant Intended status: Informational S. Bryant
Expires: October 6, 2013 Cisco Expires: October 31, 2013 Cisco
D. Ceccarelli D. Ceccarelli
D. Caviglia D. Caviglia
F. Fondelli F. Fondelli
Ericsson Ericsson
M. Corsi M. Corsi
Altran Altran
B. Wu B. Wu
X. Dai X. Dai
ZTE Corporation ZTE Corporation
April 4, 2013 April 29, 2013
Applicability of MPLS-TP Linear Protection for Ring Topologies Applicability of MPLS-TP Linear Protection for Ring Topologies
draft-ietf-mpls-tp-ring-protection-05.txt 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 Multi-Protocol Label
Switching Transport Profile (MPLS-TP) in ring topologies. This Switching Transport Profile (MPLS-TP) in ring topologies. This
document does not propose any new mechanisms or protocols. document does not propose any new mechanisms or protocols.
Protection on rings offers a number of opportunities for optimization Protection on rings offers a number of opportunities for optimization
as the protection choices are starkly limited (all traffic traveling as the protection choices are starkly limited (all traffic traveling
one way around a ring can only be switched to travel the other way on one way around a ring can only be switched to travel the other way on
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2013. This Internet-Draft will expire on October 31, 2013.
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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6
1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7
2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2. Point-to-point (P2P) Ring Protection . . . . . . . . . . . . . 7
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . 12 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 . . . 13
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14
2.3.4. Wrapping for link and node protection . . . . . . . . 15 2.3.4. Wrapping for link and node protection . . . . . . . . 15
2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 16 2.4. Analysis of P2P protection . . . . . . . . . . . . . . . . 16
2.4.1. Recommendations for protection of p2p paths 2.4.1. Recommendations for protection of P2P paths
traversing a ring . . . . . . . . . . . . . . . . . . 16 traversing a ring . . . . . . . . . . . . . . . . . . 17
3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 17 3. Point-to-multipoint protection . . . . . . . . . . . . . . . . 17
3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 17 3.1. Wrapping for P2MP LSP . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 20 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 21
3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 21 3.2. Steering for P2MP paths . . . . . . . . . . . . . . . . . 21
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 21 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 22
3.2.2. Walkthrough using context labels . . . . . . . . . . . 23 3.2.2. Walkthrough using context labels . . . . . . . . . . . 24
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 25 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 25
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been
standardized as part of a joint effort between the Internet standardized as part of a joint effort between the Internet
Engineering Task Force (IETF) and the International Telecommunication Engineering Task Force (IETF) and the International Telecommunication
Union Standardization (ITU-T). These specifications are based on the Union Standardization (ITU-T). These specifications are based on the
requirements that were generated from this joint effort. requirements that were generated from this joint effort.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
o Number of OAM entities needed to trigger the protection o Number of OAM entities needed to trigger the protection
o Number of elements of recovery needed o Number of elements of recovery needed
o Number of labels required o Number of labels required
o Number of control and management plane transactions during a o Number of control and management plane transactions during a
maintenance operation maintenance operation
o Impact of signaling and routing information exchanged during o Impact of signaling and routing information exchanged during
protection, in presence of 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 doxument 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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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 should be
detected by the neighboring nodes. detected by the neighboring nodes.
2. One of the ring nodes causes a fault condition. This condition 2. One of the ring nodes causes a fault condition. This condition
is invariably a bidirectional fault (although in rare cases of is invariably a bidirectional fault (although in rare cases of
misconfiguration this could be detected as a unidirectional misconfiguration this could be detected as a unidirectional
fault) and should be detected by the two neighboring ring nodes. fault) and should be detected by the two neighboring ring nodes.
3. An operator command that changes the operational state of a node 3. An operator command changes the operational state of a node or a
or a link, or specifically triggers a protection actionis issued link, or specifically triggers a protection action is issued to a
to a specific ring node. A description of the different operator specific ring node. A description of the different operator
commands is found in Section 4.13 of [RFC4427]. Examples of commands is found in Section 4.13 of [RFC4427]. Examples of
these commands include Manual Switch, Forced Switch, or Clear these commands include Manual Switch, Forced Switch, or Clear
operations. 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. Traffic on the transport path traffic that traverses on the ring. Protection triggers on the
prior to the ring ingress node or beyond the egress nodes may be transport path prior to the ring ingress node or beyond the egress
protected by some other mechanism. 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 are 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 as well as it is supported specific nodes or spans is only supported to the degree that it is
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 LSRs of an MPLS-TP LSP. This SPME may be configured as a co- two Label Switching Routers (LSR) of an MPLS-TP Label Switched Path
routed bidirectional path. The SPME is defined to allow management (LSP). This SPME may be configured as a co-routed bidirectional
and monitoring of any segment of a transport path. This concept will path. The SPME is defined to allow management and monitoring of any
be used extensively throughout the document to support protection of segment of a transport path. This concept will be used extensively
the traffic that traverses an MPLS-TP ring. throughout the document to support protection of the traffic that
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
skipping to change at page 6, line 48 skipping to change at page 6, line 49
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 point to 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", and "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). 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 for a SPME will be denoted by Pxi(y) where x and y are
LSR identifiers and the intention is to the label for LSR-x to LSR identifiers and the intention is to the label for LSR-x to
transmit to LSR-y over the SPME whose index is i. transmit to LSR-y over the SPME whose index is 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. This may have 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 discussion
skipping to change at page 7, line 33 skipping to change at page 7, line 34
contributed their insights and advice to this work: contributed their insights and advice to this work:
Nurit Sprecher (NSN) Nurit Sprecher (NSN)
Akira Sakurai (NEC) Akira Sakurai (NEC)
Rolf Winter (NEC) Rolf Winter (NEC)
Eric Osborne (Cisco) Eric Osborne (Cisco)
2. P2P Ring Protection 2. Point-to-point (P2P) Ring Protection
There are two protection architecture mechanisms, that have There are two protection architecture mechanisms, that have
historically been applied to ring topologies, based on SDH historically been applied to ring topologies, based on SDH
specifications [G.841], and have been proposed in various forums to specifications [G.841], and have been proposed in various forums to
perform recovery of a topological ring network - "Wrapping" and perform recovery of a topological ring network - "Wrapping" and
"Steering". The following sub-sections examine these two mechanisms, "Steering". The following sub-sections examine these two mechanisms,
as applied to an MPLS transport network. as applied to an MPLS transport network.
2.1. Wrapping 2.1. Wrapping
skipping to change at page 8, line 29 skipping to change at page 8, line 31
*@ #*@ *@ #*@
*@ #*@ *@ #*@
*@ #*@ *@ #*@
_*@ ___ #*@ _*@ ___ #*@
/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 LSR in the ring - only the
LSRs that detect the fault must wrap the traffic, either onto the LSRs that detect the fault must wrap the traffic, either onto the
wrapped data path (at the near-end) or back to the working path (at wrapped data path (at the near-end) or back to the working path (at
the far-end). Coordination of the switchover to the protection path the far-end). However, coordination of the switchover to the
would be needed to maintain the traffic on a co-routed bidirectional protection path would be needed to maintain the traffic on a co-
LSP even in cases of a unidirectional fault condition. routed bidirectional LSP even in cases of a unidirectional fault
condition.
The following considerations should be taken into account when The following considerations should be taken into account when
considering use of wrapping protection: considering use of wrapping protection:
o Detection of loss-of-continuity or mis-connectivity, should be o Detection of loss-of-continuity or mis-connectivity should be
performed at the link level and/or per LSR when using node-level performed at the link level and/or per LSR when using node-level
protection. Configuration of the protection being performed (i.e. protection. Configuration of the protection being performed (i.e.
link protection or node protection) needs to be performed link protection or node protection) needs to be performed
a-priori, since the configuration of the proper protection path is a-priori, since the configuration of the proper protection path is
dependent upon this decision. dependent upon this decision.
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 a
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)
skipping to change at page 10, line 44 skipping to change at page 10, line 47
Defect Indication, Alarm reporting. Defect Indication, Alarm reporting.
o The process of notifying the ingress node adds to the latency of o The process of notifying the ingress node adds to the latency of
the protection switching process, after the detection of the fault the protection switching process, after the detection of the fault
condition. condition.
o While there is no need for double bandwidth for the data path, o While there is no need for double bandwidth for the data path,
there is the necessity for the ring to maintain enough capacity there is the necessity for the ring to maintain enough capacity
for all of the data in both directions around the ring. for all of the data in both directions around the ring.
2.3. 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
skipping to change at page 11, line 23 skipping to change at page 11, line 26
the following sub-sections. the following sub-sections.
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.
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
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
from LSR-F, we configure two SPME through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
Figure 3: An MPLS-TP ring
In all of the following subsections, we use 1:1 linear protection In all of the following subsections, we use 1:1 linear protection
[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 dependent 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
skipping to change at page 12, line 20 skipping to change at page 11, line 50
pushed at LSR-B and the LSP label will be swapped for the label that pushed at LSR-B and the LSP label will be swapped for the label that
is expected by the egress LSR (i.e. the packet will arrive at LSR-A is expected by the egress LSR (i.e. the packet will arrive at LSR-A
with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]). with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]).
The SPME label will be popped by LSR-F and the LSP label will be The SPME label will be popped by LSR-F and the LSP label will be
treated appropriately at LSR-F and forwarded along the LSP, outside treated appropriately at LSR-F and forwarded along the LSP, outside
the ring. This scenario is true for all LSP that are aggregated by the ring. This scenario is true for all LSP that are aggregated by
this primary SPME. this primary SPME.
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 alternative
SPME can be defined as the protection path for the working path that SPME can be defined as the protection path for the working path that
is configured as part of the LSP and defined as a SPME. is configured as part of the LSP and defined as a SPME.
For each pair of SPMEs that are defined in this way, it is possible For each pair of SPMEs that are defined in this way, it is possible
to verify the connectivity and continuity by applying the MPLS-TP OAM to verify the connectivity and continuity by applying the MPLS-TP OAM
functionality to both the working and protection SPME. If a functionality to both the working and protection SPME. If a
discontinuity or mis-connectivity is detected then the MEPs will discontinuity or mis-connectivity is detected then the MEPs will
become aware of this condition, and could perform a protection switch become aware of this condition, and could perform a protection switch
of all LSPs to the alternate, protection SPME. of all LSPs to the alternate, protection SPME.
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
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
from LSR-F, we configure two SPME through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
Figure 3: An MPLS-TP ring
This protection mechanism is identical to application of 1:1 linear This protection mechanism is identical to application of 1:1 linear
protection[RFC6372] [RFC6378] to the pair of SPMEs. Under normal protection[RFC6372] [RFC6378] to the pair of SPMEs. Under normal
conditions, all LSP data traffic will be transmitted on the working conditions, all LSP data traffic will be transmitted on the working
SPME. If the linear protection is triggered, by either the OAM SPME. If the linear protection is triggered, by either the OAM
indication, an other fault indication trigger, or an operator indication, an other fault indication trigger, or an operator
command, then the MEPs will select the protection SPME to transmit command, then the MEPs will select the protection SPME to transmit
all LSP data packets. all LSP data packets.
The protection SPME will continue to transmit the data packets until The protection SPME will continue to transmit the data packets until
the stable recovery of the fault condition. Upon recovery, i.e. the the stable recovery of the fault condition. Upon recovery, i.e. the
skipping to change at page 16, line 5 skipping to change at page 16, line 22
/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: Segment & Node protection SPMEs
2.4. Analysis of p2p protection 2.4. Analysis of P2P protection
Analyzing the mechanisms described in the above subsections we can Analyzing the mechanisms described in the above subsections we can
point to the following observations (based on a ring with N nodes, point to the following observations (based on a ring with N nodes,
assumed to be not more than 16): assumed to be not more than 16):
o Number of SPME that need to be configured - for steering SPME o Number of SPME that need to be configured - for steering SPME
protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress
LSR to each other node in the ring], for wrapping based on SPME LSR to each other node in the ring], for wrapping based on SPME
either as described in Section 2.3.2 and Section 2.3.3 = O(2N) either as described in Section 2.3.2 and Section 2.3.3 = O(2N)
[however, the operator must decide a priori on whether to protect [however, the operator must decide a priori on whether to protect
skipping to change at page 16, line 35 skipping to change at page 16, line 52
o Special considerations - for SPME based steering: latency of OAM o Special considerations - for SPME based steering: latency of OAM
detection of fault condition by ingress MEP [using Alarm-reporting detection of fault condition by ingress MEP [using Alarm-reporting
could optimize over using CC-V only], for SPME wrapping: at each could optimize over using CC-V only], for SPME wrapping: at each
node must decide a priori whether protecting for link or node node must decide a priori whether protecting for link or node
failures. To protect for both node and link failures would failures. To protect for both node and link failures would
increase the complexity of deciding which protection path to use, increase the complexity of deciding which protection path to use,
as well as, violating the co-routedness of the protected traffic. as well as, violating the co-routedness of the protected traffic.
Based on this analysis, using steering as described in Section 2.3.1 Based on this analysis, using steering as described in Section 2.3.1
would be the recommended protection mechanism due to its simplicity, would be the recommended protection mechanism due to its simplicity.
even though it may involve the use of additional resources (i.e.
SPME) for monitorng the traffic. It should be pointed out that the
number of SPME involved in this 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 It should be pointed out that the number of SPME involved in this
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 to a ring topology is possible as
demonstrated, this does have certain limitations in addressing some demonstrated, this does have certain limitations in addressing some
of the required behavior. The limitations include: of the required behavior. The limitations include:
o Need to a-priori configure the protection for link or node o Need to a-priori configure the protection for link or node
protection protection
o Increased number of SPME that need to be defined o Increased number of SPME that need to be defined
o Difficulty in addressing cases of multiple failures in the ring o 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 SPME within the
ring, to implement a Steering methodology to protect a ring topology ring, to implement a Steering methodology to protect a ring topology
is rather straight forward, overcomes the limitations listed above, is rather straight forward, overcomes the limitations listed above,
and scales very well. For this and other reasons listed previously, and scales very well. For this and other reasons listed previously,
the authors recommend the use of Steering to provide protection of a the authors recommend the use of Steering to provide protection of a
ring topology when using the mechanisms described in this document ring topology when using the mechanisms described in this document
for protection of p2p paths that traverse the ring. for protection of P2P paths that traverse the ring.
3. P2MP 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 p2mp LSP in an MPLS-TP ring would be characterized by a single A Point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be
ingress LSR and multiple egress LSRs. The following sub-sections characterized by a single ingress LSR and multiple egress LSRs. The
will present methods to address the protection of the ring-based following sub-sections will present methods to address the protection
sections of these LSP. of the ring-based sections of these LSP.
3.1. Wrapping for p2mp LSP 3.1. Wrapping for P2MP LSP
When protecting a p2mp ring data path using the wrapping When protecting a P2MP ring data path using the wrapping
architecture, the basic operation is similar to the description architecture, the basic operation is similar to the description
given, as the traffic has been wrapped back onto the normal working given, as the traffic has been wrapped back onto the normal working
path on the far-side of the detected fault and will continue to be path on the far-side of the detected fault and will continue to be
transported to all of the egress points. transported to all of the egress points.
It is possible to optimize the performance of the wrapping mechanism It is possible to optimize the performance of the wrapping mechanism
when applied to p2mp LSPs by exploiting the topology of ring when applied to P2MP LSPs by exploiting the topology of ring
networks. networks.
This improved mechanism, which we call Ring Optimized 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 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, from the upstream node
and all egress nodes (for the particular LSP) downstream from the and all egress nodes (for the particular LSP) downstream from the
failure risk. failure risk.
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) complimentary to the broken working data points (at nodes F, D, & C) complementary to the broken working data
path. path.
| |
| |
V Ingress V Ingress
___ _V_ ___ ___ _V_ ___
/LSR\ /LSR\**************/LSR\ /LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/ <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * * @ * *
@ * * @ * *
skipping to change at page 18, line 48 skipping to change at page 19, line 19
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 draft. While this may seem
to be limited in scope, the mechanism may be very efficient for many to be limited in scope, the mechanism may be very efficient for many
applications that are based on p2mp distribution schemes. While ROM- applications that are based on P2MP distribution schemes. While ROM-
Wrapping can be applied to any network topology, it is particularly Wrapping can be applied to any network topology, it is particularly
efficient for interconnected ring topologies. 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 different aspects, and show some improvements offered
by ROM-Wrapping. by ROM-Wrapping.
When configuring the protection LSP for Wrapping it is necessary to When configuring the protection LSP for Wrapping it is necessary to
skipping to change at page 21, line 7 skipping to change at page 21, line 31
recover, from some multiple failures. recover, 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. The whole P2MP traffic is lost. The
ROM-Wrapping mechanism is able to partially recover from the failure, ROM-Wrapping mechanism is able to partially recover from the failure,
because the backup P2MP LSP to node F and node D is correctly set up because the backup P2MP LSP to node F and node D is correctly set up
and continues delivering traffic. and continues delivering traffic.
3.2. Steering for p2mp paths 3.2. Steering for P2MP paths
When protecting p2mp traffic that uses 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. it enters the ring at a head-end node and exits
the ring at multiple nodes, we can employ a steering mechanism based the ring at multiple nodes, we can employ a steering mechanism based
on 1+1 linear protection [RFC6372]. We can configure two p2mp on 1+1 linear protection [RFC6372]. We can configure two P2MP
unidirectional SPME from each node on the ring that traverse the ring unidirectional SPME from each node on the ring that traverse the ring
in both directions. These SPME will be configured with an egress at in both directions. These SPME will be configured with an egress at
each ring node. In order to be able to properly direct the LSP each ring node. In order to be able to properly direct the LSP
traffic to the proper egress point for that particular LSP, we need traffic to the proper egress point for that particular LSP, we need
to employ context labeling as defined in [RFC5331]. The method for to employ context labeling as defined in [RFC5331]. The method for
using these labels is expanded upon in section 3.2.1. using these labels is expanded upon in section 3.2.1.
For every LSP that enters the ring at a given node the traffic will For every LSP that enters the ring at a given node the traffic will
be sent through both of these SPME, each with its own context label be sent through both of these SPME, each with its own context label
and the context-specific label for the particular LSP. The egress and the context-specific label for the particular LSP. The egress
skipping to change at page 21, line 37 skipping to change at page 22, line 12
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 point, it
continues to select the data that is coming from the working SPME. 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 SPME 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_/
+* <+++++++++*|| +* <+++++++++*||
+* +*|| +* +*||
skipping to change at page 22, line 40 skipping to change at page 23, line 7
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 context
label, pops off the SPME label, and looks up the next label down in label, pops off the SPME label, and looks up the next label down in
the stack in the LIB indicated by the context label. 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 taken for this
packet. In MPLS-TP protection of ring topologies there are two 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 P-SPME. All context LIBs have a
behavior defined for the e2e LSP label but the behavior at each node behavior defined for the end-to-end LSP label but the behavior at
may be different in the context of each SPME. 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, if the working
SPME is configured to have a context-identifying label of CW at each SPME is configured to have a context-identifying label of CW at each
node on the ring and the protection SPME is configured to have a node on the ring and the protection SPME is configured to have a
context-identifying label of CP at each node. For the specific LSP context-identifying label of CP at each node. For the specific LSP
we will designate the context-specific label used on the working SPME we will designate the context-specific label used on the working SPME
as WL(x-y) to be the label used as node-x to forward the packet to as WL(x-y) to be the label used as node-x to forward the packet to
node-y. Similarly, for the context-specific labels on the protection node-y. Similarly, for the context-specific labels on the protection
SPME would be designated PL(x-y). An explicit example of label SPME would be designated PL(x-y). An explicit example of label
values appears in the next sub-section. values appears in the next sub-section.
Applying 1+1 linear protection, as outlined above, for a p2mp LSP Applying 1+1 linear protection, as outlined above, for a P2MP LSP
that enters the ring at LSR-A and has egress points from the ring at that enters the ring at LSR-A and has egress points from the ring at
LSR-C and LSR-E using the two SPME shown in Figure 8 then a packet LSR-C and LSR-E using the two SPME shown in Figure 8 then a packet
that arrives at LSR-A with a label stack [LI+S] will be forwarded on that arrives at LSR-A with a label stack [LI+S] will be forwarded on
the working SPME with a label stack [CW | WL(A-B)]. The packet the working SPME with a label stack [CW | WL(A-B)]. The packet
should then be forwarded to LSR-C arriving with a label [CW | should then be forwarded to LSR-C arriving with a label [CW |
WL(B-C)], where WL(B-C) should instruct the forwarding function to WL(B-C)], where WL(B-C) should instruct the forwarding function to
egress the packet with [LE(C)] and forward a copy to LSR-D with label egress the packet with [LE(C)] and forward a copy to LSR-D with label
stack [CW | WL(C-D)]. stack [CW | WL(C-D)].
If a fault condition is detected, for example on the link C-D, then If a fault condition is detected, for example on the link C-D, then
skipping to change at page 23, line 41 skipping to change at page 24, line 8
point. point.
This architecture has the added advantages that there is no need for This architecture has the added advantages that there is no need for
the ingress node to identify the existence of the mis-connectivity, the ingress node to identify the existence of the mis-connectivity,
and there is no need for a return path from the egress points to the and there is no need for a return path from the egress points to the
ingress. ingress.
3.2.2. Walkthrough using context labels 3.2.2. Walkthrough using context labels
In order to better demonstrate the use of the context labels we In order to better demonstrate the use of the context labels we
present a walkthrough of an example application of the p2mp present a walkthrough of an example application of the P2MP
protection presented in this section. Referring to Figure 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 does not continue beyond
LSR-H. For purposes of protection two p2mp unidirectional SPME are LSR-H. For purposes of protection two P2MP unidirectional SPME are
configured on the ring starting from LSR-B. One of the SPME, the configured on the ring starting from LSR-B. One of the SPME, the
working SPME, is configured with egress points at each of the LSR - working SPME, is configured with egress points at each of the LSR -
C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is
configured with egress points at each of the LSR - A, K, J, H, G, F, configured with egress points at each of the LSR - A, K, J, H, G, F,
E, D, C. E, D, C.
^ ^ ^ ^ ^ ^ ^ ^
^ ^ ^ ^ ^ ^ ^ ^
___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_ ___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
skipping to change at page 24, line 21 skipping to change at page 24, line 35
*+ +*||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], leaves the ring at LSR-D with stack
[199], at LSR-E with stack [299], and LSR-H with stack [399]. [199], at LSR-E with stack [299], and LSR-H with stack [399].
While it is possible for the context-identifying label for the SPME While it is possible for the context-identifying label for the SPME
skipping to change at page 26, line 17 skipping to change at page 26, line 28
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 SPME, from ring ingress to
ring egress, and 1:1 linear protection ring egress, and 1:1 linear protection
o p2p Wrapping for link protection - Configuration of two SPME, one o P2P Wrapping for link protection - Configuration of two SPME, one
for the protected link and the second using the long route between for the protected link and the second using the long route between
the two neighboring nodes, and 1:1 linear protection. the two neighboring nodes, and 1:1 linear protection.
o p2p Wrapping for node protection - Configuration of two SPME, one o P2P Wrapping for node protection - Configuration of two SPME, one
between the two neighbors of the protected node and the second between the two neighbors of the protected node and the second
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 It has been shown that this set of protection architecture and
mechanisms are optimized based on the criteria defined in [RFC5654] mechanisms are optimized based on the criteria defined in [RFC5654]
for justification of designing a specific protection mechanism for a for justification of designing a specific protection mechanism for a
ring topology. 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 the ability to
protect both against link and node failures without complicating the protect both against link and node failures without complicating the
fault detection or the need to configure multiple protection paths. fault detection or the need to configure multiple protection paths.
While this is true, the possiblity remains to support either While this is true, the possiblity remains to support either
mechanism while depending upon the OAM functionality [outlined in mechanism while depending upon the OAM functionality [outlined in
[RFC6371] and specified in various documents] and the coordination [RFC6371] and specified in various documents] and the coordination
protocol specified for linear protection in [RFC6378]. protocol specified for linear protection in [RFC6378].
6. IANA Considerations 6. IANA Considerations
 End of changes. 54 change blocks. 
104 lines changed or deleted 105 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/