draft-ietf-mpls-tp-1ton-protection-00.txt		draft-ietf-mpls-tp-1ton-protection-01.txt
	Network Working Group E. Osborne		Network Working Group E. Osborne
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track F. Zhang		Intended status: Standards Track F. Zhang
	Expires: February 7, 2013 ZTE		Expires: August 8, 2013 ZTE
	Y. Weingarten		Y. Weingarten
	August 6, 2012		February 4, 2013
	MPLS-TP 1toN Protection		MPLS-TP 1toN Protection
	draft-ietf-mpls-tp-1ton-protection-00.txt		draft-ietf-mpls-tp-1ton-protection-01.txt
	Abstract		Abstract
	As part of the Transport Profile for Multiprotocol Label Switching		As part of the Transport Profile for Multiprotocol Label Switching
	(MPLS-TP) there is a requirement to support 1:n linear protection for		(MPLS-TP) there is a requirement to support 1:n linear protection for
	transport paths. This requirement is elaborated on in the MPLS-TP		transport paths. This requirement is further elaborated in RFC6372
	Survivability Framework document [SurvivFwk]. The basic protocol for		[SurvivFwk]. The basic protocol for linear protection, specified in
	linear protection was specified in the MPLS-TP Linear Protection		RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This
	document [LinProt] but is limited to 1+1 and 1:1 protection. This		document extends that protocol to address the additional
	document extends the protocol defined there to address the additional		functionality necessary to support scenarios where a single
	functionality necessary to support scenarios of a single protection		protection path is preconfigured to provide protection of multiple
	path preconfigured to provide protection of multiple transport paths		transport paths between two joint endpoints.
	between two joint endpoints.
	This document is a product of a joint Internet Engineering Task Force		This document is a product of a joint Internet Engineering Task Force
	(IETF) / International Telecommunications Union Telecommunications		(IETF) / International Telecommunications Union Telecommunications
	Standardization Sector (ITU-T) effort to include an MPLS Transport		Standardization Sector (ITU-T) effort to include an MPLS Transport
	Profile within the IETF MPLS and PWE3 architectures to support the		Profile within the IETF MPLS and PWE3 architectures to support the
	capabilities and functionalities of a packet transport network as		capabilities and functionalities of a packet transport network as
	defined by the ITU-T.		defined by the ITU-T.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 48		skipping to change at page 1, line 47
	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 February 7, 2013.		This Internet-Draft will expire on August 8, 2013.
	Copyright Notice		Copyright Notice
			Copyright (c) 2013 IETF Trust and the persons identified as the
	Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 8		skipping to change at page 4, line 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 31		8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
	8.2. Informative References . . . . . . . . . . . . . . . . . . 32		8.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Appendix A. PSC state machine tables . . . . . . . . . . . . . . 32		Appendix A. PSC state machine tables . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	The MPLS Transport Profile (MPLS-TP) Requirements document [TPReq]		The MPLS Transport Profile (MPLS-TP) Requirements document [TPReq]
	includes requirements for the necessary survivability tools that are		includes requirements for the necessary survivability tools required
	required for MPLS based transport networks. Network survivability is		for MPLS based transport networks. Network survivability is the
	the ability of a network to recover traffic delivery following		ability of a network to recover traffic delivery following failure,
	failure, or degradation of network resources. Requirement 67 lists		or degradation of network resources. Requirement 67 lists various
	various types of 1:n protection architectures that are required for		types of 1:n protection architectures that are required for MPLS-TP.
	MPLS-TP. The MPLS-TP Survivability Framework [SurvivFwk] is a		The MPLS-TP Survivability Framework [SurvivFwk] is a framework for
	framework for survivability in MPLS-TP networks, and describes		survivability in MPLS-TP networks, and describes recovery elements,
	recovery elements, types, methods, and topological considerations,		types, methods, and topological considerations, focusing on
	focusing on mechanisms for recovering MPLS-TP Label Switched Paths		mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).
	(LSPs).
	Linear protection in mesh networks - networks with arbitrary		Linear protection in mesh networks - networks with arbitrary
	interconnectivity between nodes - is described in Section 4.7 of		interconnectivity between nodes - is described in Section 4.7 of
	[SurvivFwk]. Linear protection provides rapid and simple protection		[SurvivFwk]. Linear protection provides rapid and simple protection
	switching. In a mesh network, linear protection provides a very		switching. In a mesh network, linear protection provides a very
	suitable protection mechanism because it can operate between any pair		suitable protection mechanism because it can operate between any pair
	of points within the network. It can protect against a defect in an		of points within the network. It can protect against a defect in an
	intermediate node, a span, a transport path segment, or an end-to-end		intermediate node, a span, a transport path segment, or an end-to-end
	transport path.		transport path.
	[LinProt] defines a Protection State Coordination (PSC) protocol that		[LinProt] defines a Protection State Coordination (PSC) protocol that
	supports the different 1+1 and 1:1 architectures described in		supports the different 1+1 and 1:1 architectures described in
	[SurvivFwk]. The PSC protocol is a single-phased protocol that		[SurvivFwk]. The PSC protocol is a single-phased protocol that
	allows the two endpoints of the protection domain to coordinate the		allows the two endpoints of the protection domain to coordinate the
	protection switching operation when a switching condition is detected		protection switching operation when a switching condition is detected
	on the transport paths of the protection domain.		on the transport paths of the protection domain.
	This document extends the PSC protocol to allow it to support a		This document extends the PSC protocol to support a protection domain
	protection domain that includes multiple working transport paths that		that includes multiple working transport paths, between common end
	are protected by a single protection transport path. All of the		points, protected by a single protection transport path. The
	working transport paths and the protection transport path share		protection transport path is pre-allocated with resources to
	common end points. The protection transport path is pre-allocated		transport the traffic normally carried by any one of the working
	with resources to transport the traffic normally carried by any one		transport paths. This is the architecture described in [SurvivFwk]
	of the working transport paths. This is the architecture described		as 1:n protection, and is the generalization of the 1:1 protection
	in [SurvivFwk] as 1:n protection, and is the generalization of the		architecture already supported by PSC.
	1:1 protection architecture already supported by PSC.
	1.1. 1:n Protection architecture		1.1. 1:n Protection architecture
	Linear protection switching is a fully allocated survivability		Linear protection switching is a fully allocated survivability
	mechanism. It is fully allocated in the sense that the route and		mechanism in the sense that the route and bandwidth of the protection
	bandwidth of the protection path is reserved for a set of working		path is reserved for a set of working paths. For 1:n protection the
	paths. For 1:n protection the protection path is allocated to		protection path is allocated to protect any one of n working paths
	protect any one of n working paths between the two endpoints of the		between the two endpoints of the protection domain.
	protection domain.
	+-----+ +-----+		+-----+ +-----+
	| |=============================| |		| |=============================| |
	|LER-A| Working Path #1 |LER-Z|		|LER-A| Working Path #1 |LER-Z|
	| | | |		| | | |
	| |=============================| |		| |=============================| |
	| | Working Path #2 | |		| | Working Path #2 | |
	| | | |		| | | |
	| |=============================| |		| |=============================| |
	| | Working Path #3 | |		| | Working Path #3 | |
	skipping to change at page 5, line 50		skipping to change at page 5, line 50
	The different working paths may be disjoint at the intermediary		The different working paths may be disjoint at the intermediary
	points on the path between LER-A and LER-Z and may also have		points on the path between LER-A and LER-Z and may also have
	different resource requirements. In addition, each of the working		different resource requirements. In addition, each of the working
	paths may be assigned a priority that could be used to decide which		paths may be assigned a priority that could be used to decide which
	working path would be protected in cases of conflict (see more on		working path would be protected in cases of conflict (see more on
	this topic in Section 1.5). It is usually advised to arrange these		this topic in Section 1.5). It is usually advised to arrange these
	protection groups in a way that would minimize any potential conflict		protection groups in a way that would minimize any potential conflict
	situation.		situation.
	1:n protection in MPLS supports two modes of operation - locking and		1:n protection in MPLS supports two modes of operation - locking and
	non-locking. Locking mirrors the behavior that is used by many		non-locking. The locking mode mirrors the behavior that is used by
	transport protection mechanisms, and is necessary in some cases but		many transport protection mechanisms, and is necessary in some cases
	may incur increased latency (and thus packet loss), as a result of		but may incur increased latency (and thus packet loss), as a result
	prolonged switching time, in comparison to the non-locking case.		of prolonged switching time, in comparison to the non-locking case.
	Non-locking 1:n can be used in many MPLS networks and has far less		Non-locking 1:n can be used in many MPLS networks and affords a lower
	packet loss as compared to locking, but must be used with care -		rate of packet loss as compared to locking mode, but must be used
	since incorrect use of non-locking can lead to misconnectivity.		with care - since incorrect use of non-locking can lead to
			misconnectivity.
	1.2. Locking operation		1.2. Locking operation
	The high-level functionality of the locking operation mode of 1:n		The high-level functionality of the locking operation mode of 1:n
	protection would follow the following basic steps:		protection would follow the following basic steps:
	o LER-A detects a unidirectional failure of W1 and stops sending		o LER-A detects a unidirectional failure of W1 and stops sending
	traffic on W1.		traffic on W1.
	o LER-A transmits a PSC SF message to LER-Z indicating that W1 has		o LER-A transmits a PSC SF message to LER-Z indicating that W1 has
	skipping to change at page 7, line 10		skipping to change at page 7, line 10
	points verify that both are ready to process the W1 traffic that is		points verify that both are ready to process the W1 traffic that is
	received on P. More detailed information on this mode of operation		received on P. More detailed information on this mode of operation
	will be supplied later in the document when considering different		will be supplied later in the document when considering different
	scenarios.		scenarios.
	1.3. Non-Locking		1.3. Non-Locking
	In non-locking protection operation mode, LER-A switches data traffic		In non-locking protection operation mode, LER-A switches data traffic
	onto P immediately upon failure detection. This minimizes traffic		onto P immediately upon failure detection. This minimizes traffic
	loss, but at the cost of temporary asymmetry of packet flow. At a		loss, but at the cost of temporary asymmetry of packet flow. At a
	high level, it looks like this:		high level, it works like this:
	o LER-A detects the failure of W1 and stops sending traffic on W1.		o LER-A detects the failure of W1 and stops sending traffic on W1.
	o LER-A immediately begins to transport W1's data traffic over the		o LER-A immediately begins to transport W1's data traffic over the
	protection path P.		protection path P.
	o Simultaneously LER-A transmitts a PSC message to LER-Z indicating		o Simultaneously LER-A transmitts a PSC message to LER-Z indicating
	that W1 has failed and is currently being protected in P.		that W1 has failed and is currently being protected in P.
	o LER-Z receives the PSC message from LER-A, switches all W1 data		o LER-Z receives the PSC message from LER-A, switches all W1 data
	traffic to P, and transmits a PSC message to LER-A indicating that		traffic to P, and transmits a PSC message to LER-A indicating that
	W1 is now protected in P.		W1 is now protected in P.
	o LER-A receives the PSC message from LER-Z and needs to take no		o LER-A receives the PSC message from LER-Z and needs to take no
	action, as the protection switch had already been completed.		action, as the protection switch had already been completed.
	In the non-locking case, the packet loss between the endpoints is		In the non-locking case, the packet loss between the endpoints is
	minimized. Packet loss in the A->Z direction is only the failure		minimized. Packet loss may occur in the A->Z direction only for the
	detection time , which is assumed, for this document, to be		duration of the failure detection time , which is assumed, for this
	negligible. Packet loss in the Z->A direction is almost entirely the		document, to be negligible. Packet loss in the Z->A direction is
	result of the one-way propagation delay of the PSC message from LER-A		almost entirely the result of the one-way propagation delay of the
	to LER-Z. Assuming the transport path from A->Z has the same delay		PSC message from LER-A to LER-Z. Assuming the transport path from
	as that from Z->A, it can be said that the packet loss in the non-		A->Z has the same delay as that from Z->A, it can be said that the
	locking case is roughly half that of the locking case.		packet loss in the non-locking case is roughly half that of the
			locking case.
	1.4. Path priority		1.4. Path priority
	As the 1:n architecture requires the ability for one working path to		As the 1:n architecture requires the ability for one working path to
	preempt the traffic of another in the event of multiple failures (see		preempt the traffic of another in the event of multiple failures (see
	Section 1.5), there must be an indication of priority between the		Section 1.5), there must be an indication of priority between the
	different working paths so that an implementation can decide whether		different working paths so that an implementation can decide whether
	a new failure should be allowed to preempt a protection switch		a new failure should be allowed to preempt a protection switch
	already in place. The priority for a given Working path is		already in place. The priority for a given Working path is
	determined by the value used to represent that path in the FPath		determined by the value used to represent that path in the FPath
	skipping to change at page 9, line 34		skipping to change at page 9, line 34
	2.2. Definitions and Terminology		2.2. Definitions and Terminology
	The terminology used in this document is based on the terminology		The terminology used in this document is based on the terminology
	defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk].		defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk].
	In addition, we use the term LER to refer to a MPLS Network Element,		In addition, we use the term LER to refer to a MPLS Network Element,
	whether it is a LSR, LER, T-PE, or S-PE.		whether it is a LSR, LER, T-PE, or S-PE.
	3. Use cases and scenarios		3. Use cases and scenarios
	This section will present some use-cases and scenarios that should		This section presents some use-cases and scenarios that should
	illucidate the use of PSC for 1:n protection.		illucidate the use of PSC for 1:n protection.
	3.1. Non-locking use case: Per-node label space		3.1. Non-locking use case: Per-node label space
	Non-locking protection can be used when the payload that is received		Non-locking protection can be used when the payload that is received
	from the protection path is unambiguous and can be properly forwarded		from the protection path is unambiguous and can be properly forwarded
	without the need to explicitly establish selector and bridge		without the need to explicitly establish selector and bridge
	configuration at the time of failure. One example where this applies		configuration at the time of failure. One example where this applies
	is when the endpoints of the protection domain are using per-platform		is when the endpoints of the protection domain are using per-platform
	label space [RFC3031].		label space [RFC3031].
	In per-node or per-platform label space, the LIB is established on a		In per-node or per-platform label space, the LIB is established on a
	node such that it can properly switch any labeled packet regardless		node such that it can properly switch any labeled packet regardless
	of input interface.		of input interface.
	Consider, as an example, the protection topology as shown in Figure 1		Consider, as an example, the protection topology as shown in Figure 1
	with four working paths - W1, W2, W3, W4 and a single protection		with four working paths - W1, W2, W3, W4 and a single protection
	path, P, that connect between LER-A and LER-Z. Each packet that		path, P, that connect between LER-A and LER-Z. Each packet
	transported from LER-A to LER-Z is labelled by LER-A depending upon		transported from LER-A to LER-Z is labelled by LER-A depending upon
	the path that it is being transmitted over. From there the packet		the path used to transmit the packet. From there the packet will
	will traverse the relevant path and have its label manipulated by the		traverse the relevant path and have its label manipulated by the
	intermediate LSRs until it arrives at LER-Z, at which point, the LER		intermediate LSRs until it arrives at LER-Z, at which point, the LER
	will pop the label for the path used within the protection domain and		will pop the label for the path used within the protection domain and
	process the next label down to determine how to forward the packet		process the next label down to determine how to forward the packet
	payload. The following table gives the label assigned by LER-A and		payload. The following table gives the label assigned by LER-A and
	the one expected by LER-Z for each of the transport paths:		the one expected by LER-Z for each of the transport paths:
	+------+----------------+-----------------+		+------+----------------+-----------------+
	| Path | Label at LER-A | Label for LER-Z |		| Path | Label at LER-A | Label for LER-Z |
	+------+----------------+-----------------+		+------+----------------+-----------------+
	| W1 | 100 | 105 |		| W1 | 100 | 105 |
	skipping to change at page 18, line 22		skipping to change at page 18, line 22
	There are multiple scenarios of preemption depending on where the		There are multiple scenarios of preemption depending on where the
	failures were detected. In addition to the combinations of failure		failures were detected. In addition to the combinations of failure
	directionality and preemption, it is also necessary to consider how		directionality and preemption, it is also necessary to consider how
	these combinations behave in both the locking and non-locking modes		these combinations behave in both the locking and non-locking modes
	of operation.		of operation.
	First consider, the two flavors of preemption due to multiple		First consider, the two flavors of preemption due to multiple
	unidirectional failures.		unidirectional failures.
	The difference between Locking and Non-Locking is that in Non-Locking		The difference between Locking and Non-Locking modes is that a node
	a node can continue to send traffic on the P-LSP during the		can continue to send traffic on the P-LSP during the preemption
	preemption process. The P-LSP contents may momentarily disagree (A		process, when operating in Non-Locking mode. The P-LSP contents may
	may send W1 on P, Z may send W2 on P) but in the non-locking case		momentarily disagree (A may send W1 on P, Z may send W2 on P) but in
	there is no risk of misconnectivity as explained in the previous		the non-locking case there is no risk of misconnectivity as explained
	discussion. For this reason, the identity of the path that the		in the previous discussion. For this reason, the identity of the
	endpoints are selecting incoming traffic from are irrelevant. In a		path that the endpoints are selecting incoming traffic from are
	sense there is no selector; each node is able to properly process		irrelevant. In a sense there is no selector; each node is able to
	arbitrary data on the P-LSP.		properly process arbitrary data on the P-LSP.
	However, WFA state is still necessary in order to ensure that the		However, WFA state is still necessary in order to ensure that the
	endpoints converge on the identity of the working path whose traffic		endpoints converge on the identity of the working path whose traffic
	is being transported on the P-LSP. Failure to converge is a problem		is being transported on the P-LSP. Failure to converge is a problem
	that should be flagged to the operator.		that should be flagged to the operator.
	The scenarios start after the two endpoints have converged on		The scenarios start after the two endpoints have converged on
	protecting a unidirectional SF condition that was detected on W2,		protecting a unidirectional SF condition that was detected on W2,
	when a new SF condition is detected on W1 (with higher priority):		when a new SF condition is detected on W1 (with higher priority):
	skipping to change at page 23, line 31		skipping to change at page 23, line 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV Length | Reserved2 |		| TLV Length | Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Optional TLVs ~		~ Optional TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Format of basic PSC packet with a G-ACh header		Figure 10: Format of basic PSC packet with a G-ACh header
	In regards to the G-ACh Header no changes are suggested in the		In regards to the G-ACh Header no changes are suggested in the
	extensions for 1:n protection, i.e., the channel type field will		extensions for 1:n protection, i.e., the channel type field will
	continue to use the PSC-CT value defined in [LinProt]. The fields		continue to use the PSC-CT value defined in [LinProt]. The PSC
	from the PSC payload which are affected by this document are the Ver		payload fields affected by this document are the Ver field, Reserved1
	field, the Reserved1 field, and the Fpath and Path fields.		field, and the Fpath and Path fields.
	4.2. Changes to PSC Payload		4.2. Changes to PSC Payload
	In order to support 1:n protection there is a need to make one small		In order to support 1:n protection there is a need to make one small
	change to the format of the PSC payload (see Figure 11). In		change to the format of the PSC payload (see Figure 11). In
	particular, we have added a new flag (L), taken from the Reserved1		particular, we have added a new flag (L), taken from the Reserved1
	space, to whether the protection domain is locking or non-locking.		space, that is used to indicate whether the protection domain is
	In addition, the semantics of the FPath and Path field are adjusted		opearting in locking or non-locking mode. In addition, the semantics
	to indicate an index of the multiple working paths. The details of		of the FPath and Path field are adjusted to indicate an index of the
	these changes are supplied in the following subsections.		multiple working paths. The details of these changes are supplied in
			the following subsections.
	Due to the significance of these changes, the value of the Ver field		Due to the significance of these changes, the value of the Ver field
	(in the PSC payload) for 1:n protection domain MUST be set to 2.		(in the PSC payload) for 1:n protection domain MUST be set to 2.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ver|Request|PT |R|L| Reserved1 | FPath | Path |		|Ver|Request|PT |R|L| Reserved1 | FPath | Path |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TLV Length | Reserved2 |		| TLV Length | Reserved2 |
	skipping to change at page 24, line 22		skipping to change at page 24, line 22
	~ Optional TLVs ~		~ Optional TLVs ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Format of 1:n PSC message payload		Figure 11: Format of 1:n PSC message payload
	4.2.1. Locking (L) flag		4.2.1. Locking (L) flag
	The Locking flag is used to indicate that the end-point is configured		The Locking flag is used to indicate that the end-point is configured
	for Locking mode (see Section 1.2).		for Locking mode (see Section 1.2).
	If the value is 1 then the protection-domain is using the locking		If the value is 1 then the protection-domain is operating in locking
	mode		mode
	The Locking flag must be the same on both ends; if the two endpoints		The Locking flag must be the same on both ends; if the two endpoints
	of a protection domain have different L-flag settings, this MUST		of a protection domain have different L-flag settings, this MUST
	raise an error to the network operator		raise an error to the network operator.
	4.2.2. Fault path (FPath) field		4.2.2. Fault path (FPath) field
	The Fpath field indicates which path is identified to be in a fault		The Fpath field indicates which path is identified to be in a fault
	condition or affected by an administrative command. The following		condition or affected by an administrative command. The following
	are the possible values:		are the possible values:
	o 0: indicates that the anomaly condition is on the protection path		o 0: indicates that the anomaly condition is on the protection path
	o 1-128: indicates that the anomaly condition is on a working path		o 1-128: indicates that the anomaly condition is on a working path
	skipping to change at page 25, line 20		skipping to change at page 25, line 20
	o 129-255: for future extensions or experimental use.		o 129-255: for future extensions or experimental use.
	4.3. Changes to PSC Operation		4.3. Changes to PSC Operation
	In all of the following subsections, assume a protection domain		In all of the following subsections, assume a protection domain
	between LER-A and LER-Z, using working paths 1-N and the protection		between LER-A and LER-Z, using working paths 1-N and the protection
	path as shown in figure 1.		path as shown in figure 1.
	A basic premise of this protection architecture is that both		A basic premise of this protection architecture is that both
	endpoints of the protection domain are configured to associate the		endpoints of the protection domain MUST be configured to associate
	indices of the working paths with the proper LSP identifiers. If		the indices of the working paths with the proper LSP identifiers. If
	this condition is not met then the protection scheme will cause		this condition is not met then the protection scheme will cause
	inconsistencies in traffic transmission.		inconsistencies in traffic transmission.
	4.3.1. Basic operation		4.3.1. Basic operation
	Protection of the N working paths is based on the operational		Protection of the N working paths is based on the operational
	principles outlined in [LinProt] and will employ the same basic		principles outlined in [LinProt] and will employ the same basic
	Protection State Coordination Protocol (PSC) outlined in that		Protection State Coordination Protocol (PSC) outlined in that
	document. However, as can be expected, due to certain basic		document. However, as can be expected, due to certain basic
	differences in the architecture of the protection domain, a small set		differences in the architecture of the protection domain, a small set
	skipping to change at page 27, line 33		skipping to change at page 27, line 33
	of the WFA timer SHOULD be configured to allow protection switching		of the WFA timer SHOULD be configured to allow protection switching
	within the normal time constraints. The WFA timer will expire only		within the normal time constraints. The WFA timer will expire only
	if no Acknowledge message was recieved by the LER in WFA state. The		if no Acknowledge message was recieved by the LER in WFA state. The
	WFA Expires local input should have a priority just below that of the		WFA Expires local input should have a priority just below that of the
	WTRExpires signal.		WTRExpires signal.
	4.3.5. Additional PSC State		4.3.5. Additional PSC State
	As described above and demonstrated in the scenarios in Section 3.3,		As described above and demonstrated in the scenarios in Section 3.3,
	there is a need, in some scenarios, for the endpoint that is		there is a need, in some scenarios, for the endpoint that is
	reporting on a trigger for protection-switching to delay the actual		reporting a trigger for protection-switching to delay the actual
	switchover until an acknowledge is received from the far end LER. In		switchover until an acknowledge is received from the far end LER. In
	order to facilitate this wait period it is necessary to define a new		order to facilitate this wait period it is necessary to define a new
	PSC State - Wait for Acknowledge (WFA) state. WFA is used in both		PSC State - Wait for Acknowledge (WFA) state. WFA is used in both
	the Locking and Non-Locking cases. It is more essential to the		the Locking and Non-Locking cases. It is more essential to the
	Locking mode of operation, as agreement is the mechanism to establish		Locking mode of operation, as agreement is the mechanism to establish
	and release the lock on the protection LSP. However, it is necessary		and release the lock on the protection LSP. However, it is necessary
	for the Non-Locking mode as a persistent disagreement on the contents		for the Non-Locking mode as a persistent disagreement on the contents
	of the protection LSP indicates an error in the network devices and		of the protection LSP indicates an error in the network devices and
	WFA is the method used to detect this error.		WFA is the method used to detect this error.
	skipping to change at page 32, line 29		skipping to change at page 32, line 29
	[SurvivFwk]		[SurvivFwk]
	Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol		Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol
	Label Switching Transport Profile Survivability		Label Switching Transport Profile Survivability
	Framework", RFC 6372, Feb 2009.		Framework", RFC 6372, Feb 2009.
	[SecureFwk]		[SecureFwk]
	Fang, L., Niven-Jenkins, B., Mansfield, S., Zhang, R.,		Fang, L., Niven-Jenkins, B., Mansfield, S., Zhang, R.,
	Bitar, N., Daikoku, M., and L. Wang, "MPLS-TP Security		Bitar, N., Daikoku, M., and L. Wang, "MPLS-TP Security
	Framework",		Framework",
	ID draft-ietf-mpls-tp-security-framework-02.txt, Feb 2011.		ID draft-ietf-mpls-tp-security-framework-07.txt, Jan 2013.
	Appendix A. PSC state machine tables		Appendix A. PSC state machine tables
	Note/Disclaimer: This state machine is not currently in sync with the		Note/Disclaimer: This state machine is not currently in sync with the
	text of the document and will be updated in a future revision.		text of the document and will be updated in a future revision.
	The full PSC state machine is described in [LinProt], both in textual		The full PSC state machine is described in [LinProt], both in textual
	and tabular form. This appendix highlights the changes to the basic		and tabular form. This appendix highlights the changes to the basic
	PSC state machine. In the event of a mismatch between these tables		PSC state machine. In the event of a mismatch between these tables
	and the text either in [LinProt] or in this document, the text is		and the text either in [LinProt] or in this document, the text is
End of changes. 23 change blocks.
	79 lines changed or deleted		77 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/