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/