draft-ietf-mpls-tp-ring-protection-04.txt		draft-ietf-mpls-tp-ring-protection-05.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: August 29, 2013 Cisco		Expires: October 6, 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
	February 25, 2013		April 4, 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-04.txt		draft-ietf-mpls-tp-ring-protection-05.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. Protection		Switching Transport Profile (MPLS-TP) in ring topologies. This
	on rings offers a number of opportunities for optimization as the		document does not propose any new mechanisms or protocols.
	protection choices are starkly limited (all traffic traveling one way		Protection on rings offers a number of opportunities for optimization
	around a ring can only be switched to travel the other way on the		as the protection choices are starkly limited (all traffic traveling
	ring), but also suffers from some complications caused by the		one way around a ring can only be switched to travel the other way on
			the ring), but also suffers from some complications caused by the
	limitations of the topology.		limitations of the topology.
	Requirements for MPLS-TP protection especially for protection in ring		Requirements for MPLS-TP protection especially for protection in ring
	topologies are discussed in "Requirements of an MPLS Transport		topologies are discussed in "Requirements of an MPLS 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 single		linear protection as defined in RFC 6378 can be applied to single
	ring 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
	skipping to change at page 2, line 17		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 August 29, 2013.		This Internet-Draft will expire on October 6, 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 10		skipping to change at page 3, line 10
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4		1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4
	1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5		1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5		1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6
	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 a ring topology . . . . . . . . 10		2.3. SPME for p2p protection of a ring topology . . . . . . . . 10
	2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11		2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 12
	2.3.2. Wrapping link protection with segment based SPME . . . 12		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 . . . . . . . . 14		2.3.4. Wrapping for link and node protection . . . . . . . . 15
	2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15		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 . . . . . . . . . . . . . . . . . . 16
	3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 16		3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 17
	3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 16		3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 17
	3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 18		3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19
	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 . . . . . . . . . . . . . . . . . 21
	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 . . . . . . . . . . . . . . . . . . . . 25
	5. Conclusions and Recommendations . . . . . . . . . . . . . . . 25		5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 26		9.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	9.2. Informative References . . . . . . . . . . . . . . . . . . 27		9.2. Informative References . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		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.
	The MPLS-TP requirement document [RFC5654] includes a requirement to		The MPLS-TP requirement document [RFC5654] includes a requirement to
	skipping to change at page 4, line 33		skipping to change at page 4, line 33
	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 describes how applying a set of basic MPLS-TP linear
	for the protection of the data flows that traverse an MPLS-TP ring.		protection mechanisms defined in [RFC6378] can be used to provide
	These mechanisms are based on existing MPLS and MPLS-TP protection		protection of the data flows that traverse an MPLS-TP ring. These
	mechanisms. These mechanisms provide data flow protection due to any		mechanisms provide data flow protection due to any switching trigger
	switching trigger within a reasonable time frame and optimize the		within a reasonable time frame and optimize the criteria set out in
	criteria set out in [RFC5654], as summarized above.		[RFC5654], as summarized above. This doxument does not define any
			new protocol mechanisms or procedures.
	A related topic in [RFC5654] addresses the required support for		A related topic in [RFC5654] addresses the required support for
	interconnected rings. This topic involves various scenarios that		interconnected rings. This topic involves various scenarios that
	require further study and will be addressed in a separate document,		require further study and will be addressed in a separate document,
	based on the principles outlined in this document.		based on the principles outlined in this document.
	1.1. Problem statement		1.1. Problem statement
	Ring topologies, as defined in [RFC5654], are used in transport		Ring topologies, as defined in [RFC5654], are used in transport
	networks. When designing a protection mechanism for a single ring		networks. When designing a protection mechanism for a single ring
	topology, there is a need to address both -		topology, there is a need to address both -
	1. A point-to-point transport path that enters an MPLS-TP capable		1. A point-to-point transport path that either originates at or
	ring at one node, the ingress node, and exits the ring at a		enters an MPLS-TP capable ring at one node, the ingress node, and
	single egress node possibly continuing beyond the ring.		exits the ring at a 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 originates at
	MPLS-TP capable ring at the ingress node and exits through a		or enters the MPLS-TP capable ring at the ingress node and exits
	number of egress nodes, possibly continuing beyond the ring.		through a 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 -
	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 is issued to a specific ring node. A		3. An operator command that changes the operational state of a node
	description of the different operator commands is found in		or a link, or specifically triggers a protection actionis issued
	Section 4.13 of [RFC4427]. Examples of these commands include		to a specific ring node. A description of the different operator
	Manual Switch, Forced Switch, or Clear operations.		commands is found in Section 4.13 of [RFC4427]. Examples of
			these commands include 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 traverses on 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
	skipping to change at page 7, line 26		skipping to change at page 7, line 31
	The authors would like to acknowledge the following individuals that		The authors would like to acknowledge the following individuals that
	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)
	2. P2P Ring Protection		2. 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 34
	\_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). Coordination of the switchover to the protection path
	would be needed to maintain the traffic on a co-routed bidirectional		would be needed to maintain the traffic on a co-routed bidirectional
	LSP even in cases of a unidirectional fault condition.		LSP even in cases of a unidirectional fault condition.
	skipping to change at page 9, line 14		skipping to change at page 9, line 20
	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)
	alternate paths.		alternate paths.
	o When wrapping, the data is transmitted over some of the links		o When wrapping, the data is transmitted over some of the links
	twice, once in each direction. For example, in the figure above		twice, once in each direction. For example, in the figure above
	the traffic is transmitted both B-->A and then A-->B, later it is		the traffic is transmitted both B->A and then A->B, later it is
	transmitted E-->F and F-->E. This means that there is additional		transmitted E->F and F->E. This means that there is additional
	bandwidth needed for this protection.		bandwidth needed for this protection.
	o If a double-fault situation occurs in the ring, then wrapping will		o If a double-fault situation occurs in the ring, then wrapping will
	not be able to deliver any packets except between the ingress and		not be able to deliver any packets except between the ingress and
	the first fault location encountered on the working path. This is		the first fault location encountered on the working path. This is
	based on the need for wrapping to connect between the neighbors of		based on the need for wrapping to connect between the neighbors of
	the fault location, and this is not possible in the segmented		the fault location, and this is not possible in the segmented
	ring.		ring.
	o The resource pre-allocation for all of the alternate-paths could		o The resource pre-allocation for all of the alternate-paths could
	skipping to change at page 9, line 50		skipping to change at page 10, line 7
	point (to the ring) to the egress point going in opposite directions		point (to the ring) to the egress point going in opposite directions
	around the ring. This is illustrated in Figure 2, where if we assume		around the ring. This is illustrated in Figure 2, where if we assume
	that the traffic needs to enter the ring from node B and exit through		that the traffic needs to enter the ring from node B and exit through
	node F, we could define a primary path through nodes B-A-F, and an		node F, we could define a primary path through nodes B-A-F, and an
	alternate path through the nodes B-C-D-E-F. In steering the		alternate path through the nodes B-C-D-E-F. In steering the
	switching is always performed by the ingress node (node B in		switching is always performed by the ingress node (node B in
	Figure 2). If a fault condition is detected anywhere on the working		Figure 2). If a fault condition is detected anywhere on the working
	path (B-A-F), then the traffic would be redirected by B to the		path (B-A-F), then the traffic would be redirected by B to the
	alternate path (i.e. B-C-D-E-F).		alternate path (i.e. B-C-D-E-F).
			___ ___ ___
			======>/LSR\********/LSR\********/LSR\======>
			\_B_/########\_A_/########\_F_/
			*@ @*
			*@ @*
			*@ @*
			_*@ ___ @*_
			/LSR\********/LSR\********/LSR\
			\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
			===> connected LSP *** physical link
			### working path @@@ protection path
			Figure 2: Steering protection in an MPLS-TP ring
	This mechanism bears similarities to linear 1:1 protection [RFC6372].		This mechanism bears similarities to linear 1:1 protection [RFC6372].
	The two paths around the ring act as the working and protection		The two paths around the ring act as the working and protection
	paths. There is need to communicate to the ingress node the need to		paths. There is need to communicate to the ingress node the need to
	switch over to the protection path and there is a need to coordinate		switch over to the protection path and there is a need to coordinate
	the switchover between the two end-points of the protected domain.		the switchover between the two end-points of the protected domain.
	The following considerations must be taken into account regarding the		The following considerations must be taken into account regarding the
	steering architecture:		steering architecture:
	o Steering relies on a failure detection method that is able to		o Steering relies on a failure detection method that is able to
	skipping to change at page 11, line 23		skipping to change at page 11, line 43
	*@ @*		*@ @*
	*@ @*		*@ @*
	*@ @*		*@ @*
	_*@ ___ @*_		_*@ ___ @*_
	/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: An MPLS-TP ring		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
	skipping to change at page 12, line 33		skipping to change at page 13, line 4
	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
	fault condition has cleared and the network is stabilized, the		fault condition has cleared and the network is stabilized, the
	ingress LSR could switch traffic back to the working SPME, if the		ingress LSR could switch traffic back to the working SPME, if the
	protection domain is configured for revertive behavior.		protection domain is configured for revertive behavior.
	The control of the protection switching, especially for cases of		The control of the protection switching, especially for cases of
	operator commands, would be covered by the protocol defined in		operator commands, would be covered by the protocol defined in
	[RFC6378].		[RFC6378].
	2.3.2. Wrapping link protection with segment based SPME		2.3.2. Wrapping link protection with segment based SPME
	It is possible to use the SPME mechanism to perform segment-based		It is possible to use the SPME mechanism to perform segment-based
	protection. For each link in the ring, we define two SPME - the		protection. For each link in the ring, we define two SPME - the
	first is a SPME between the two LSRs that are connected by the link,		first is a SPME between the two LSRs that are connected by the link,
	and the second SPME between these same two LSRs but traversing the		and the second SPME between these same two LSRs but traversing the
	entire ring (except the link that connects the LSRs). In Figure 3 we		entire ring (except the link that connects the LSRs). In Figure 4 we
	show the primary SPME that connects LSR-A & LSR-F over a segment		show the primary SPME that connects LSR-A & LSR-F over a segment
	connection, and the secondary SPME that connects these same LSRs by		connection, and the secondary SPME that connects these same LSRs by
	traversing the ring in the opposite direction.		traversing the ring in the opposite direction.
	___ ___ ___		___ ___ ___
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_B_/@@@@@@@@\_A_/########\_F_/		\_B_/@@@@@@@@\_A_/########\_F_/
	*@ *@		*@ *@
	*@ *@		*@ *@
	*@ *@		*@ *@
	_*@ ___ _*@		_*@ ___ _*@
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/		\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
	*** physical link		*** physical link
	### primary SPME @@@ secondary SPME		### primary SPME @@@ secondary SPME
	Figure 3: Segment SPMEs		Figure 4: Segment SPMEs
	By applying OAM monitoring of these two SPME (at each LSR), it is		By applying OAM monitoring of these two SPME (at each LSR), it is
	possible to affect a wrapping protection mechanism for the LSP		possible to affect a wrapping protection mechanism for the LSP
	traffic that traverses the ring. The LSR on either side of the		traffic that traverses the ring. The LSR on either side of the
	segment would identify that there is a fault condition on the link		segment would identify that there is a fault condition on the link
	and redirect all LSP traffic to the secondary SPME. The traffic		and redirect all LSP traffic to the secondary SPME. The traffic
	would traverse the ring until arriving at the neighboring (relative		would traverse the ring until arriving at the neighboring (relative
	to the segment) LSR. At this point, the LSP traffic would be		to the segment) LSR. At this point, the LSP traffic would be
	redirected onto the original LSP, quite likely over the neighboring		redirected onto the original LSP, quite likely over the neighboring
	SPME.		SPME.
	skipping to change at page 14, line 13		skipping to change at page 14, line 26
	possibly pushing a SPME label if the next segment is likewise		possibly pushing a SPME label if the next segment is likewise
	protected.		protected.
	2.3.3. Wrapping node protection		2.3.3. Wrapping node protection
	Implementation of protection at the node level would be similar to		Implementation of protection at the node level would be similar to
	the mechanism described in the previous sub-section. The difference		the mechanism described in the previous sub-section. The difference
	would be in the SPMEs that are used. For node protection, the		would be in the SPMEs that are used. For node protection, the
	primary SPME would be configured between the two LSR that are		primary SPME would be configured between the two LSR that are
	connected to the node that is being protected (see SPME between LSR-A		connected to the node that is being protected (see SPME between LSR-A
	and LSR-E through LSR-F in Figure 4), and the secondary SPME would be		and LSR-E through LSR-F in Figure 5), and the secondary SPME would be
	configured between these same nodes, going around the ring (see		configured between these same nodes, going around the ring (see
	secondary SPME in Figure 4).		secondary SPME in Figure 5).
	___ ___ ___		___ ___ ___
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_B_/@@@@@@@@\_A_/########\_F_/		\_B_/@@@@@@@@\_A_/########\_F_/
	*@ *#		*@ *#
	*@ *#		*@ *#
	*@ *#		*@ *#
	_*@ ___ _*#		_*@ ___ _*#
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/		\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
	*** physical link		*** physical link
	### primary SPME @@@ secondary SPME		### primary SPME @@@ secondary SPME
	Figure 4: Node-protection SPMEs		Figure 5: Node-protection SPMEs
	The protection mechanism would work similarly - based on 1:1 linear		The protection mechanism would work similarly - based on 1:1 linear
	protection [RFC6372], triggered by OAM functions on both SPMEs, and		protection [RFC6372], triggered by OAM functions on both SPMEs, and
	wrapping the data packets onto the secondary SPME at the ingress MEP		wrapping the data packets onto the secondary SPME at the ingress MEP
	(e.g. LSR-A in the figure) of the SPME and back onto the		(e.g. LSR-A in the figure) of the SPME and back onto the
	continuation of the LSP at the egress MEP (e.g. LSR-E in the figure)		continuation of the LSP at the egress MEP (e.g. LSR-E in the figure)
	of the SPME.		of the SPME.
	2.3.4. Wrapping for link and node protection		2.3.4. Wrapping for link and node protection
	In the different types of wrapping presented in Section 2.3.2 and		In the different types of wrapping presented in Section 2.3.2 and
	Section 2.3.3, there is a limitation that the protection mechanism		Section 2.3.3, there is a limitation that the protection mechanism
	must a priori decide whether it is protecting for link or node		must a priori decide whether it is protecting for link or node
	failure. In addition, the neighboring LSR, that detects the fault,		failure. In addition, the neighboring LSR, that detects the fault,
	cannot readily differentiate between a link failure or a node		cannot readily differentiate between a link failure or a node
	failure.		failure.
	It would be possible to configure extra SPME to protect both for link		It would be possible to configure extra SPME to protect both for link
	and node failures, arriving at a configuration of the ring that is		and node failures, arriving at a configuration of the ring that is
	shown in Figure 5. Choosing the SPME to use for the wrapping would,		shown in Figure 6. Here there are three protection SPME configured:
	however, then involve considerable effort and could result in the
	protected traffic not sharing the same protection path in both		o Secondary node#1 would be used to divert traffic as a result of an
	directions.		indication that LSR-F is not available, it redirects traffic to be
			transmitted between LSR-A and LSR-E.
			o Secondary node#2 would be used to divert traffic as a result of an
			indication that LSR-A is not available, it redirects traffic to be
			transmitted between LSR-F and LSR-B.
			o Secondary segment would be used to divert traffic as a result of
			an indication that the segment between LSR-A and LSR-F is not
			available, it redirects traffic to be transmitted between LSR-A
			and LSR-F on the long circuit of the ring.
			Choosing the SPME to use for the wrapping would, however, then
			involve considerable effort and could result in the protected traffic
			not sharing the same protection path in both directions.
	___ ++++++++ ___ ___		___ ++++++++ ___ ___
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_B_/@@@@@@@@\_A_/########\_F_/		\_B_/@@@@@@@@\_A_/########\_F_/
	$+*@ +*$		$+*@ +*$
	$+*@ +*$		$+*@ +*$
	$+*@ +*$		$+*@ +*$
	$+*@ ++++++++ ___ ++++++++ +*$		$+*@ ++++++++ ___ ++++++++ +*$
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/		\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
	$$$$$$$$ $$$$$$$$		$$$$$$$$ $$$$$$$$
	*** physical link		*** physical link
	### primary SPME @@@ secondary node#1 SPME		### primary SPME @@@ secondary node#1 SPME
	$$$ secondary node#2 SPME +++ secondary segment SPME		$$$ secondary node#2 SPME +++ secondary segment SPME
	Figure 5: 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
	skipping to change at page 17, line 14		skipping to change at page 17, line 41
	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.
	There is one difference - rather than configuring the protection LSP		However, ROM-Wrapping configures protection p2mp LSP, relative to
	between the end nodes of a failed link (link protection) or between		each node that is considered a failure risk, from the upstream node
	the upstream and downstream node of a failed node (node protection),		and all egress nodes (for the particular LSP) downstream from the
	the improved mechanism configures a protection p2mp LSP from the		failure risk.
	upstream (with respect to the failure) node and all egress nodes (for
	the particular LSP) downstream from the failure.
	Referring to Figure 6, 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. This protection LSP will be used to wrap the data		(protection) LSP (note:the egress nodes are indicated by the curly
	back around the ring to protect against a failure on link B-C. This		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
	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) complimentary 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 17, line 48		skipping to change at page 18, line 26
	@ * *		@ * *
	@_* ___ __*		@_* ___ __*
	/LSR\*************/LSR\**************/LSR\		/LSR\*************/LSR\**************/LSR\
	\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/		\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
	@ @		@ @
	@ @		@ @
	V V		V V
	*** working LSP @@@ protection LSP		*** working LSP @@@ protection LSP
	Figure 6: P2MP ROM Wrapping		Figure 7: P2MP ROM Wrapping
	Using this mechanism, there is a need to configure a particular		Using this mechanism, there is a need to configure a particular
	protection LSP for each node on the working LSP. In the table below,		protection LSP for each node on the working LSP. In the table below,
	"X's Backup" is the backup path activated by node X as a consequence		"X's Backup" is the backup path activated by node X as a consequence
	of a failure affecting node Y (downstream node with respect to X) or		of a failure affecting node Y (downstream node with respect to X) or
	link X-Y, and square brackets, in the path,indicate egress nodes.		link X-Y, and square brackets, in the path,indicate egress nodes.
	Protected LSP: A->B->[C]->[D]->E->[F]		Protected LSP: A->B->{C}->{D}->E->{F}
	---- LINK/NODE PROTECTION----		-- LINK/NODE PROTECTION --
	A's Backup: A->[F]->E->[D]->[C]		A's Backup: A->{F}->E->{D}->{C}
	B's Backup: B->A->[F]->E->[D]->[C]		B's Backup: B->A->{F}->E->{D}->{C}
	C's Backup: C->B->A->[F]->E->[D]		C's Backup: C->B->A->{F}->E->{D}
	D's Backup: D->C->B->A->[F]		D's Backup: D->C->B->A->{F}
	E's Backup: E->D->C->B->A->[F]		E's Backup: E->D->C->B->A->{F}
	It should be noted that ROM-Wrapping is an LSP based protection		It should be noted that ROM-Wrapping is an LSP based protection
	mechanism, as opposed to the SPME based protection mechanisms that		mechanism, as opposed to the SPME based protection mechanisms that
	are presented in other sections of this draft. While this may seem		are presented in other sections of this 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
	skipping to change at page 18, line 49		skipping to change at page 19, line 27
	ROM-Wrapping however does not have this limitation, because there is		ROM-Wrapping however does not have this limitation, because there is
	no distinction between node and link protection. Whether link B-C or		no distinction between node and link protection. Whether link B-C or
	node C fails, in either case the rerouting will attempt to reach C.		node C fails, in either case the rerouting will attempt to reach C.
	If the failure is on the link, the traffic will be delivered to C,		If the failure is on the link, the traffic will be delivered to C,
	while if the failure is at node C, the traffic will be rerouted		while if the failure is at node C, the traffic will be rerouted
	correctly until node D, and will be blocked at this point. However,		correctly until node D, and will be blocked at this point. However,
	all egress nodes up-to the failure will be able to deliver the		all egress nodes up-to the failure will be able to deliver the
	traffic properly.		traffic properly.
	A second aspect is the number of hops needed to properly deliver the		A second aspect is the number of hops needed to properly deliver the
	traffic. Referring to the example shown in Figure 6, where a failure		traffic. Referring to the example shown in Figure 7, where a failure
	is detected on link B-C, the following table lists the set of nodes		is detected on link B-C, the following table lists the set of nodes
	traversed by the data in the protection:		traversed by the data in the protection:
	Basic Wrapping:		Basic Wrapping:
	A-B B-A-F-E-D-C [C]-[D]-E-[F]		A-B B-A-F-E-D-C {C}-{D}-E-{F}
	"Upstream" segment backup path "Downstream" segment		"Upstream" segment backup path "Downstream" segment
	with respect to the with respect to the		with respect to the with respect to the
	failure failure		failure failure
	ROM Wrapping:		ROM Wrapping:
	A-B B-A-[F]-E-[D]-[C] ..		A-B B-A-{F}-E-{D}-{C} ..
	"Upstream" segment backup path		"Upstream" segment backup path
	with respect to the		with respect to the
	failure		failure
	Comparing the two lists of nodes, it is possible to see that in this		Comparing the two lists of nodes, it is possible to see that in this
	particular case the number of hops crossed using the simple Wrapping		particular case the number of hops crossed using the simple Wrapping
	is significantly higher than the number of hops crossed by the		is significantly higher than the number of hops crossed by the
	traffic when ROM-Wrapping is used. Generally, the number of hops for		traffic when ROM-Wrapping is used. Generally, the number of hops for
	basic Wrapping is always higher or at least equal compared to ROM-		basic Wrapping is always higher or at least equal compared to ROM-
	Wrapping. This implies a certain waste of bandwidth on all links		Wrapping. This implies a certain waste of bandwidth on all links
	skipping to change at page 19, line 48		skipping to change at page 20, line 26
	does not require support of such extra traffic.		does not require support of such extra traffic.
	The two recovery mechanism require different protection bandwidths.		The two recovery mechanism require different protection bandwidths.
	In the case of Wrapping, the bandwidth used is M in both directions		In the case of Wrapping, the bandwidth used is M in both directions
	of many of the links. While in case of ROM-Wrapping, only the links		of many of the links. While in case of ROM-Wrapping, only the links
	from the ingress node to the node performing the actual wrapping		from the ingress node to the node performing the actual wrapping
	utilize M bandwidth in both directions, while all other links utilize		utilize M bandwidth in both directions, while all other links utilize
	M bandwidth only in the counterclockwise direction.		M bandwidth only in the counterclockwise direction.
	Consider the case of a failure detected on link B-C as shown in		Consider the case of a failure detected on link B-C as shown in
	Figure 6. The following table lists the bandwidth utilization on		Figure 7. The following table lists the bandwidth utilization on
	each link (in units equal to M), for each recovery mechanism and for		each link (in units equal to M), for each recovery mechanism and for
	each direction (CW=clockwise, CCW=counterclockwise).		each direction (CW=clockwise, CCW=counterclockwise).
	+----------+----------+--------------+		+----------+----------+--------------+
	| | Wrapping | ROM-Wrapping |		| | Wrapping | ROM-Wrapping |
	+----------+----------+--------------+		+----------+----------+--------------+
	| Link A-B | CW+CCW | CW+CCW |		| Link A-B | CW+CCW | CW+CCW |
	| Link A-F | CCW | CCW |		| Link A-F | CCW | CCW |
	| Link F-E | CW+CCW | CCW |		| Link F-E | CW+CCW | CCW |
	| Link E-D | CW+CCW | CCW |		| Link E-D | CW+CCW | CCW |
	skipping to change at page 20, line 24		skipping to change at page 20, line 49
	3.1.2. Multiple Failures Comparison		3.1.2. Multiple Failures Comparison
	A further comparison between Wrapping and ROM-Wrapping can be done		A further comparison between Wrapping and ROM-Wrapping can be done
	with respect to their ability to react to multiple failures. The		with respect to their ability to react to multiple failures. The
	wrapping recovery mechanism does not have the ability to recover from		wrapping recovery mechanism does not have the ability to recover from
	multiple failures on a ring network, while ROM-Wrapping is able to		multiple failures on a ring network, while ROM-Wrapping is able to
	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 6. 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
	skipping to change at page 21, line 10		skipping to change at page 21, line 35
	select the traffic from whichever of the two SPME whose traffic		select the traffic from whichever of the two SPME whose traffic
	arrives at that node, i.e. since one of the two (presumably the		arrives at that node, i.e. since one of the two (presumably the
	working SPME) will be blocked by the failure. In this way, all		working SPME) will be blocked by the failure. In this way, all
	egress nodes are able to receive the data traffic. While each node		egress nodes are able to receive the data traffic. While each node
	detects that there is connectivity from the ingress point, it		detects that there is connectivity from the ingress 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
			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
			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
			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
			as the protection SPME.
	^ ^ ^		^ ^ ^
	_|_ _|_ _|_		_|_ _|_ _|_
	----->/LSR\********/LSR\********/LSR\		----->/LSR\********/LSR\********/LSR\
	\_A_/========\_B_/========\_C_/		\_A_/========\_B_/========\_C_/
	+* <+++++++++*||		+* <+++++++++*||
	+* +*||		+* +*||
	+* +*||		+* +*||
	+* +*||		+* +*||
	+*_ ++++++++ ___ +++++++++*||		+*_ ++++++++ ___ +++++++++*||
	/LSR\********/LSR\********/LSR\		/LSR\********/LSR\********/LSR\
	\_F_/<=======\_E_/========\_D_/		\_F_/<=======\_E_/========\_D_/
	| | |		| | |
	V V V		V V V
	---> connected LSP *** physical link		---> connected LSP *** physical link
	=== working SPME +++ protection SPME		=== working SPME +++ protection SPME
	Figure 7: P2MP SPMEs		Figure 8: P2MP SPMEs
	3.2.1. Context labels
	Figure 7 shows the two unidirectional p2mp SPME that are configured
	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,
	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
	nodes. The counter-clockwise SPME (i.e. A-F-E-D-C-B) is configured
	as the protection SPME.
	[RFC5331] defines the concept of context labels. A context-		[RFC5331] defines the concept of context labels. A context-
	identifying label defines a context label space that is used to		identifying label defines a context label space that is used to
	interpret the context-specific labels (found directly below the		interpret the context-specific labels (found directly below the
	context- identifying label) for a specific tunnel. The SPME label is		context- identifying label) for a specific tunnel. The SPME label is
	a context- identifying label. This means that at each hop the node		a context- identifying label. This means that at each hop the node
	that receives the SPME label uses it to point not directly to a		that receives the SPME label uses it to point not directly to a
	forwarding table, but to a LIB. As a node receives an SPME label it		forwarding table, but to a Label Information Base (LIB). As a node
	examines it, discovers that it is a context label, pops off the SPME		receives an SPME label it examines it, discovers that it is a context
	label, and looks up the next label down in the stack in the LIB		label, pops off the SPME label, and looks up the next label down in
	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 e2e LSP label but the behavior at each node
	may be different in the context of each SPME.		may be different in the context of each SPME.
	For example, using the ring that is shown in Figure 7, if the working		For example, using the ring that is shown in Figure 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 7 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
	the nodes that are beyond the fault point, in this example nodes		the nodes that are beyond the fault point, in this example nodes
	LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from		LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from
	skipping to change at page 23, line 9		skipping to change at page 23, line 42
	This architecture has the added advantages that there is no need for		This architecture has the added advantages that there is no need for
	the ingress node to identify the existence of the mis-connectivity,		the ingress node to identify the existence of the mis-connectivity,
	and there is no need for a return path from the egress points to the		and there is no need for a return path from the egress points to the
	ingress.		ingress.
	3.2.2. Walkthrough using context labels		3.2.2. Walkthrough using context labels
	In order to better demonstrate the use of the context labels we		In order to better demonstrate the use of the context labels we
	present a walkthrough of an example application of the p2mp		present a walkthrough of an example application of the p2mp
	protection presented in this section. Referring to Figure 8, there		protection presented in this section. Referring to Figure 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.
	^ ^ ^ ^		^ ^ ^ ^
	skipping to change at page 23, line 39		skipping to change at page 24, line 25
	/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 8: 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
	be configured as a different value at each LSR, for the sake of this		be configured as a different value at each LSR, for the sake of this
	example we will suppose a configuration of 200 as the context-		example we will suppose a configuration of 200 as the context-
	identifying label for the working SPME at each of the LSR in the		identifying label for the working SPME at each of the LSR in the
	ring, and 400 as the context-identifying label for the protection		ring, and 400 as the context-identifying label for the protection
End of changes. 48 change blocks.
	99 lines changed or deleted		136 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/