draft-ietf-mpls-tp-ring-protection-03.txt   draft-ietf-mpls-tp-ring-protection-04.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: May 9, 2013 Cisco Expires: August 29, 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
November 5, 2012 February 25, 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-03.txt draft-ietf-mpls-tp-ring-protection-04.txt
Abstract Abstract
This document presents an applicability of linear protection This document presents an applicability of existing MPLS protection
mechanisms for Multi-Protocol Label Switching Transport Profile mechanisms, both local and end-to-end, to Multi-Protocol Label
(MPLS-TP) in ring topologies. Protection on rings offers a number of Switching Transport Profile (MPLS-TP) in ring topologies. Protection
opportunities for optimization as the protection choices are starkly on rings offers a number of opportunities for optimization as the
limited (all traffic traveling one way around a ring can only be protection choices are starkly limited (all traffic traveling one way
switched to travel the other way on the ring), but also suffers from around a ring can only be switched to travel the other way on the
some complications caused by the limitations of the topology. ring), but also suffers from some complications caused by the
limitations of the topology.
Requirements for MPLS-TP protection and specifically for protection Requirements for MPLS-TP protection especially for protection in ring
in ring topologies are discussed in "Requirements of an MPLS topologies are discussed in "Requirements of an MPLS Transport
Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
Survivability Framework" (RFC 6372). This document shows how MPLS-TP Survivability Framework" (RFC 6372). This document shows how MPLS-TP
linear protection as defined in RFC 6378 can be applied to ring linear protection as defined in RFC 6378 can be applied to single
topologies, discusses how most of the requirements are met, and ring topologies, discusses how most of the requirements are met, and
describes scenarios in which the function provided by applying linear describes scenarios in which the function provided by applying linear
protection in a ring topology falls short of some of the protection in a ring topology falls short of some of the
requirements. requirements.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. defined by the ITU-T.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 9, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 . . . . . . . . . . . . . . . . . 5 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7
2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. SPME for p2p protection of ring topologies . . . . . . . . 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 . . . 12 2.3.2. Wrapping link protection with segment based SPME . . . 12
2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14
2.3.4. Wrapping for link and node protection . . . . . . . . 14 2.3.4. Wrapping for link and node protection . . . . . . . . 14
2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 16 traversing a ring . . . . . . . . . . . . . . . . . . 16
3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 16 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 16 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 16
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 18 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 18
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 20 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 20
3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 21 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Walkthrough using context labels . . . . . . . . . . . 23 3.2.2. Walkthrough using context labels . . . . . . . . . . . 23
4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 24 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 24
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 25 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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.
The MPLS-TP requirements [RFC5654] includes a requirement to support The MPLS-TP requirement document [RFC5654] includes a requirement to
a network that may include sub-networks that constitute a MPLS-TP support a network that may include sub-networks that constitute an
ring as defined in the requirements. The requirements 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 However, the requirements state that specific protection mechanisms
aimed at ring topologies may be developed if these allow the network applying to ring topologies may be developed if these allow the
to minimize: network to minimize:
o Number of OAM entities needed to trigger the protection o Number of OAM entities needed to trigger the protection
o Number of elements of recovery needed o Number of elements of recovery needed
o Number of labels required o Number of labels required
o Number of control and management plane transactions during a o Number of control and management plane transactions during a
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 presence of control plane
This document proposes a set of basic mechanisms that could be used This document proposes a set of basic mechanisms that could be used
for the protection of the data flows that traverse a MPLS-TP ring. for the protection of the data flows that traverse an MPLS-TP ring.
These mechanisms are based on existing MPLS and MPLS-TP protection These mechanisms are based on existing MPLS and MPLS-TP protection
mechanisms. We show that these mechanisms provide protection for all mechanisms. These mechanisms provide data flow protection due to any
switching triggers within a reasonable time frame and optimize the switching trigger within a reasonable time frame and optimize the
criteria set out in [RFC5654], as summarized above. criteria set out in [RFC5654], as summarized above.
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 due to their ability to easily support both p2p and p2mp networks. When designing a protection mechanism for a single ring
transport paths. When designing a protection mechanism for a ring
topology, there is a need to address both - topology, there is a need to address both -
1. A point-to-point transport path that enters a MPLS-TP capable 1. A point-to-point transport path that enters an MPLS-TP capable
ring at one node, the ingress node, and exits the ring at a ring at one node, the ingress node, and exits the ring at a
single egress node possibly continuing beyond the ring. single egress node possibly continuing beyond the ring.
2. Where the ring is being used as a branching point for a point-to- 2. Where the ring is being used as a branching point for a point-to-
multipoint transport path, i.e. the transport path enters the multipoint transport path, i.e. the transport path enters the
MPLS-TP capable ring at the ingress node and exits through a MPLS-TP capable ring at the ingress node and exits through a
number of egress nodes, possibly continuing beyond the ring. number of egress nodes, possibly continuing beyond the 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 -
skipping to change at page 5, line 31 skipping to change at page 5, line 31
is invariably a bidirectional fault (although in rare cases of is invariably a bidirectional fault (although in rare cases of
misconfiguration this could be detected as a unidirectional misconfiguration this could be detected as a unidirectional
fault) and should be detected by the two neighboring ring nodes. fault) and should be detected by the two neighboring ring nodes.
3. An operator command is issued to a specific ring node. A 3. An operator command is issued to a specific ring node. A
description of the different operator commands is found in description of the different operator commands is found in
Section 4.13 of [RFC4427]. Examples of these commands include Section 4.13 of [RFC4427]. Examples of these commands include
Manual Switch, Forced Switch, or Clear operations. Manual Switch, Forced Switch, or Clear operations.
The protection domain addressed in this document is limited to the The protection domain addressed in this document is limited to the
traffic that is traversing the ring. Traffic on the transport path traffic that traverses on the ring. Traffic on the transport path
prior to the ring ingress node or beyond the egress nodes may be prior to the ring ingress node or beyond the egress nodes may be
protected by some other mechanism. protected by some other mechanism.
1.2. 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 are for further study.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
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 a MPLS-TP LSP. This SPME may be configured as a co- two LSRs of an MPLS-TP LSP. This SPME may be configured as a co-
routed bidirectional path. The SPME is defined to allow management routed bidirectional path. The SPME is defined to allow management
and monitoring of any segment of a transport path. This concept will and monitoring of any segment of a transport path. This concept will
be used extensively throughout the document to support protection of be used extensively throughout the document to support protection of
the traffic that traverses a MPLS-TP ring. 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 10, line 24 skipping to change at page 10, line 24
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 ring topologies 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 a 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 type of transport
path and protection that is being implemented and will be detailed in path and protection that is being implemented and will be detailed in
the following sub-sections. the following sub-sections.
Based on this architectural configuration for 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 a 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 SPME through the ring (the first SPME
traverses along B-A-F, and the second SPME traverses B-C-D-E-F). traverses along B-A-F, and the second SPME traverses B-C-D-E-F).
___ ___ ___ ___ ___ ___
======>/LSR\********/LSR\********/LSR\======> ======>/LSR\********/LSR\********/LSR\======>
\_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 2: A MPLS-TP ring Figure 2: 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
skipping to change at page 20, line 33 skipping to change at page 20, line 33
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 6. The Wrapping mechanism is not able to recover C-D shown in Figure 6. 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 a 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.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
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 end-points of a
protected bidirectional domain. The coordination is necessary for protected bidirectional domain. The coordination is necessary for
particular cases, in order to maintain the co-routed nature of the particular cases, in order to maintain the co-routed nature of the
bidirectional transport path. The particular cases where this bidirectional transport path. The particular cases where this
becomes necessary include cases of unidirectional fault detection and becomes necessary include cases of unidirectional fault detection and
use of operator commands. use of operator commands.
By using the same mechanisms defined in [RFC6378], for linear By using the same mechanisms defined in [RFC6378], for linear
protection, to apply for protection of ring topologies we are able to protection, to apply for protection of a single ring topology we are
gain a consistent solution for this coordination between the end- able to gain a consistent solution for this coordination between the
points of the protection domain. The Protection State Coordination end-points of the protection domain. The Protection State
Protocol that is specified in [RFC6378] provides coverage for all the Coordination Protocol that is specified in [RFC6378] provides
coordination cases, including support for operator commands, e.g. coverage for all the coordination cases, including support for
Forced-Switch. operator commands, e.g. 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 a 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
skipping to change at page 26, line 40 skipping to change at page 26, line 40
applicability to the information contained in this document follow applicability to the information contained in this document follow
naturally from the applicability of the mechanism defined in that naturally from the applicability of the mechanism defined in that
document. document.
8. Acknowledgements 8. Acknowledgements
The authors would like to acknowledge the strong contributions from The authors would like to acknowledge the strong contributions from
all the people commenting on this draft and making suggestions for all the people commenting on this draft and making suggestions for
improvements. improvements.
9. Informative References 9. References
9.1. Normative References
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378,
October 2011.
9.2. Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, Aug 2008. RFC 5331, Aug 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
skipping to change at page 27, line 19 skipping to change at page 27, line 28
[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, "MPLS-TP Framework", RFC 5921, July 2010.
[RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371, [RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371,
Sept 2011. Sept 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability
Framework", RFC 6372, Sept 2011. Framework", RFC 6372, Sept 2011.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378,
October 2011.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
Specifications", RFC 2205, September 1997. Specifications", RFC 2205, September 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for GMPLS", RFC 4427, March 2006. Restoration) Terminology for GMPLS", RFC 4427, March 2006.
[G.841] ITU, "Types and characteristics of SDH network protection [G.841] ITU, "Types and characteristics of SDH network protection
architectures", ITU-T G.841, October 1998. architectures", ITU-T G.841, October 1998.
 End of changes. 28 change blocks. 
50 lines changed or deleted 56 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/