draft-ietf-mpls-tp-psc-itu-00.txt		draft-ietf-mpls-tp-psc-itu-01.txt
	MPLS Working Group J. Ryoo, Ed.		MPLS Working Group J. Ryoo, Ed.
	Internet-Draft ETRI		Internet-Draft ETRI
	Updates: 6378 (if approved) E. Gray, Ed.		Updates: 6378 (if approved) E. Gray, Ed.
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: May 31, 2014 H. van Helvoort		Expires: July 23, 2014 H. van Helvoort
	Huawei Technologies		Huawei Technologies
	A. D'Alessandro		A. D'Alessandro
	Telecom Italia		Telecom Italia
	T. Cheung		T. Cheung
	ETRI		ETRI
	E. Osborne		E. Osborne
	Cisco Systems, Inc.		Cisco Systems, Inc.
	November 27, 2013		January 19, 2014
	MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's		MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
	Requirements		Operational Expectations of SDH, OTN and Ethernet Transport Network
	draft-ietf-mpls-tp-psc-itu-00.txt		Operators
			draft-ietf-mpls-tp-psc-itu-01.txt
	Abstract		Abstract
	This document introduces alternate ways to perform certain operations		This document describes alternate mechanisms to perform some of the
	defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear		sub-functions of MPLS Transport Profile (MPLS-TP) linear protection
	Protection", and also defines additional behaviors. This set of		defined in RFC 6378, and also defines additional mechanisms. The
	modified and additional behaviors together with the protocol defined		purpose of these alternate and additional mechanisms is to provide
	in RFC6378 meets the ITU-T's protection switching requirements.		operator control and experience that more closely models the behavior
			of linear protection seen in other transport networks.
	This document introduces capabilities and modes. A capability is an		This document also introduces capabilities and modes for linear
	individual behavior. The capabilities of a node are advertised using		protection. A capability is an individual behavior, and a mode is a
	the method given in this document. A mode is a particular		particular combination of capabilities. Two modes are defined in
	combination of capabilities. Two modes are defined in this document:		this document: Protection State Coordination (PSC) mode and Automatic
	Protection State Coordination (PSC) mode and Automatic Protection		Protection Switching (APS) mode.
	Switching (APS) mode.
	This document describes the behavior of the PSC protocol including		This document describes the behavior of the PSC protocol including
	priority logic and state machine when all the capabilities associated		priority logic and state machine when all the capabilities associated
	with the APS mode are enabled.		with the APS mode are enabled.
	This document updates RFC6378 in that the capability advertisement		This document updates RFC 6378 in that the capability advertisement
	method defined here is an addition to that document.		method defined here is an addition to that document.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 31, 2014.		This Internet-Draft will expire on July 23, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 5
	3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Capability 1: Priority Modification . . . . . . . . . . . . . 5		4. Capability 1: Priority modification . . . . . . . . . . . . . 6
	4.1. Motivations for swapping priorities of FS and SF-P . . . 5		4.1. Motivations for swapping priorities of FS and SF-P . . . 6
	4.2. Motivation for raising the priority of Clear SF . . . . . 6		4.2. Motivation for raising the priority of SFc . . . . . . . 7
	4.3. Motivation for introducing Freeze command . . . . . . . . 6		4.3. Motivation for introducing Freeze command . . . . . . . . 7
	4.4. Updates to the PSC RFC . . . . . . . . . . . . . . . . . 6		4.4. Modifications to RFC 6378 . . . . . . . . . . . . . . . . 7
	5. Capability 2: Modification of Non-revertive Operation . . . . 7		5. Capability 2: Modification of non-revertive operation . . . . 8
	6. Capability 3: Support of Manual Switch to Working Command . . 7		6. Capability 3: Support of MS-W command . . . . . . . . . . . . 8
	6.1. Motivation for adding Manual Switch to Working . . . . . 7		6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8
	6.2. Terms modified to support MS-W . . . . . . . . . . . . . 8		6.2. Terms modified to support MS-W . . . . . . . . . . . . . 9
	6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8		6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9
	6.4. Equal priority resolution for MS . . . . . . . . . . . . 8		6.4. Equal priority resolution for MS . . . . . . . . . . . . 9
	7. Capability 4: Support of protection against Signal Degrade . 9		7. Capability 4: Support of protection against SD . . . . . . . 10
	7.1. Motivation for supporting protection against Signal		7.1. Motivation for supporting protection against SD . . . . . 10
	Degrade . . . . . . . . . . . . . . . . . . . . . . . . . 9		7.2. Terms modified to support SD . . . . . . . . . . . . . . 10
	7.2. Terms modified to support SD . . . . . . . . . . . . . . 9		7.3. Behavior of protection against SD . . . . . . . . . . . . 10
	7.3. Behavior of protection against SD . . . . . . . . . . . . 9
	7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11		7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11
	8. Capability 5: Support of Exercise Command . . . . . . . . . . 12
	9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13		8. Capability 5: Support of EXER command . . . . . . . . . . . . 13
	9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 13		9. Capabilities and modes . . . . . . . . . . . . . . . . . . . 14
	9.1.1. Sending the Capabilities TLV . . . . . . . . . . . . 14		9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
	9.1.2. Receiving the Capabilities TLV . . . . . . . . . . . 14		9.1.1. Sending the Capabilities TLV . . . . . . . . . . . . 15
			9.1.2. Receiving the Capabilities TLV . . . . . . . . . . . 15
	9.1.3. Handling Capabilities TLV errors . . . . . . . . . . 15		9.1.3. Handling Capabilities TLV errors . . . . . . . . . . 15
	9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16		9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16
	9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16		9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16
	9.3. Backward compatibility . . . . . . . . . . . . . . . . . 16		9.3. Backward compatibility . . . . . . . . . . . . . . . . . 17
	10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17		10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17
	10.1. Request field in PSC protocol message . . . . . . . . . 17		10.1. Request field in PSC protocol message . . . . . . . . . 17
	10.2. Priorities of local inputs and remote requests . . . . . 17		10.2. Priorities of local inputs and remote requests . . . . . 18
	11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19		10.3. Acceptance and retention of local inputs . . . . . . . . 20
	11.1. State transition by local inputs . . . . . . . . . . . . 21		11. State Transition Tables in APS Mode . . . . . . . . . . . . . 21
	11.2. State transition by remote messages . . . . . . . . . . 22		11.1. State transition by local inputs . . . . . . . . . . . . 23
	12. Security considerations . . . . . . . . . . . . . . . . . . . 24		11.2. State transition by remote messages . . . . . . . . . . 25
	13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24		11.3. State transition for 1+1 unidirectional
	13.1. PSC Request Field . . . . . . . . . . . . . . . . . . . 24		protection . . . . . . . . . . . . . . . . . . . . . . . 27
	13.2. PSC TLV . . . . . . . . . . . . . . . . . . . . . . . . 25		12. Provisioning mismatch and protocol failure
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		in the APS mode . . . . . . . . . . . . . . . . . . . . . . . 28
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		13. Security considerations . . . . . . . . . . . . . . . . . . . 28
	15.1. Normative References . . . . . . . . . . . . . . . . . . 25		14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
	15.2. Informative References . . . . . . . . . . . . . . . . . 25		14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 29
	Appendix A. An example of out-of-service scenarios . . . . . . . 26		14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 29
			14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 29
			15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
			16.1. Normative References . . . . . . . . . . . . . . . . . . 30
			16.2. Informative References . . . . . . . . . . . . . . . . . 30
			Appendix A. An example of out-of-service scenarios . . . . . . . 31
	Appendix B. An example of sequence diagram showing		Appendix B. An example of sequence diagram showing
	the problem with the priority level of Clear SF . . 27		the problem with the priority level of SFc . . . . . 32
	Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 28		Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		Appendix D. Operation examples of the APS mode . . . . . . . . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document introduces alternate ways to perform certain operations		Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP)
	defined in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear		are described in RFC 6378 [RFC6378] to meet the requirements
	Protection", and also defines additional behaviors. This set of		described in RFC 5654 [RFC5654].
	modified and additional behaviors together with the protocol defined
	in [RFC6378] meets the ITU-T's protection switching requirements.
	Alternative behaviors are defined for the following capabilities:		This document describes alternate mechanisms to perform some of the
			sub-functions of linear protection, and also defines additional
			mechanisms. The purpose of these alternate and additional mechanisms
			is to provide operator control and experience that more closely
			models the behavior of linear protection seen in other transport
			networks, such as Synchronous Digital Hierarchy (SDH), Optical
			Transport Network (OTN) and Ethernet transport networks. Linear
			protection for SDH, OTN, and Ethernet transport networks are defined
			in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031
			[G8031], respectively.
			The reader of this document is assumed to be familiar with RFC 6378.
			The alternative mechanisms described in this document are for the
			following capabilities:
	1. Priority modification,		1. Priority modification,
	2. non-revertive behavior modification,		2. non-revertive behavior modification,
	and the following capabilities have been added to define additional		and the following capabilities have been added to define additional
	behaviors:		mechanisms:
			3. support of Manual Switch to Working path (MS-W) command,
	3. support of Manual Switch to Working (MS-W) command,
	4. support of protection against Signal Degrade (SD), and		4. support of protection against Signal Degrade (SD), and
	5. support of Exercise command.		5. support of Exercise (EXER) command.
	Priority modification includes priority swapping between Signal Fail		Priority modification includes priority swapping between Signal Fail
	on the Protection path (SF-P) and Forced Switch (FS), and raising the		on Protection path (SF-P) and Forced Switch (FS), and raising the
	priority level of Clear SF.		priority level of Clear Signal Fail (SFc).
	Non-revertive behavior is modified to align with the behavior defined		Non-revertive behavior is modified to align with the behavior defined
	in [RFC4427] as well as to meet the ITU-T's protection switching		in RFC 4427 [RFC4427] as well as to follow the behavior of linear
	requirements.		protection seen in other transport networks.
	Support of Manual Switch to Working (MS-W) command to revert traffic		Support of MS-W command to revert traffic to the working path in non-
	to the working path in non-revertive operation is covered in this		revertive operation is covered in this document.
	document.
	Support of protection switching protocol against Signal Degrade (SD)		Support of protection switching protocol against SD is covered in
	is covered in this document. The specifics for the method of		this document. The specifics for the method of identifying SD is out
	identifying SD is out of the scope of this document similarly to SF		of the scope of this document similarly to Signal Fail (SF) for RFC
	for [RFC6378].		6378.
	Support of Exercise command to test if the Protection State		Support of EXER command to test if the Protection State Coordination
	Coordination (PSC) communication is operating correctly is also		(PSC) communication is operating correctly is also covered in this
	covered in this document. More specifically, the Exercise tests and		document. More specifically, EXER command tests and validates the
	validates the linear protection mechanism and PSC protocol including		linear protection mechanism and PSC protocol including the aliveness
	the aliveness of the Local Request logic, the PSC state machine and		of the priority logic, the PSC state machine and the PSC message
	the PSC message generation and reception, and the integrity of the		generation and reception, and the integrity of the protection path,
	protection path, without triggering the actual traffic switching.		without triggering the actual traffic switching.
	This document introduces capabilities and modes. A capability is an		This document introduces capabilities and modes. A capability is an
	individual behavior, The capabilities of a node are advertised using		individual behavior. The capabilities of a node are advertised using
	the method given in this document. A mode is a particular		the method given in this document. A mode is a particular
	combination of capabilities. Two modes are defined in this document:		combination of capabilities. Two modes are defined in this document:
	PSC mode and Automatic Protection Switching (APS) mode.		PSC mode and Automatic Protection Switching (APS) mode.
	This document describes the behavior of the PSC protocol including		This document describes the behavior of the PSC protocol including
	priority logic and state machine when all the capabilities associated		the priority logic and the state machine when all the capabilities
	with the APS mode are enabled.		associated with the APS mode are enabled.
	This document updates [RFC6378] in that the capability advertisement		This document updates RFC 6378 in that the capability advertisement
	method defined here is an addition to that document. For an existing		method defined here is an addition to that document. For an existing
	implementation of [RFC6378], it is recommended to be updated with the		implementation of RFC 6378, it is recommended to be updated with the
	bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability		bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability
	adevertisement in this document.		advertisement in this document.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Acronyms		3. Acronyms
	This document uses the following acronyms:		This document uses the following acronyms:
	APS Automatic Protection Switching		APS Automatic Protection Switching
			DNR Do-not-Revert
	EXER Exercise		EXER Exercise
	FS Forced Switch		FS Forced Switch
			LER Label Edge Router
	LO Lockout of protection		LO Lockout of protection
	MS Manual Switch		MS Manual Switch
	MS-P Manual Switch to Protection		MS-P Manual Switch to Protection path
	MS-W Manual Switch to Working		MS-W Manual Switch to Working path
	MPLS-TP MPLS Transport Profile		MPLS-TP MPLS Transport Profile
	NR No Request		NR No Request
	OC Operator Clear		OC Operator Clear
			OTN Optical Transport Network
	PSC Protection State Coordination		PSC Protection State Coordination
	RR Reverse Request		RR Reverse Request
	SD Signal Degrade		SD Signal Degrade
	SD-P Signal Degrade on the Protection path		SDH Synchronous Digital Hierarchy
	SD-W Signal Degrade on the Working path		SD-P Signal Degrade on Protection path
			SD-W Signal Degrade on Working path
	SF Signal Fail		SF Signal Fail
	SFc Clear Signal Fail		SFc Clear Signal Fail
	SF-P Signal Fail on the Protection path		SFDc Clear Signal Fail or Degrade
	SF-W Signal Fail on the Working path		SF-P Signal Fail on Protection path
			SF-W Signal Fail on Working path
	WTR Wait to Restore		WTR Wait to Restore
	4. Capability 1: Priority Modification		4. Capability 1: Priority modification
	In this document, the priorities of Forced Switch (FS) and Signal		In this document, the priorities of FS and SF-P are swapped and the
	Fail on the Protection path (SF-P) are swapped and the priority of		priority of Clear SF (SFc) is raised. In addition to the priority
	Clear SF (SFc) is raised. In addition to the priority modification,		modification, this document introduces the use of Freeze command in
	this document introduces the use of a Freeze command in Appendix C.		Appendix C. The reasons for these changes are explained in the
	The reasons for these changes are explained in the following sub-		following sub-sections from technical and network operational
	sections from technical and network operational aspects.		aspects.
	4.1. Motivations for swapping priorities of FS and SF-P		4.1. Motivations for swapping priorities of FS and SF-P
	Defining the priority of FS higher than that of Signal Fail on the		Defining the priority of FS higher than that of SF-P can result in a
	Protection path (SF-P) can result in a situation where the protected		situation where the protected traffic is taken out-of-service.
	traffic is taken out-of-service. Setting the priority of any input		Setting the priority of any input that is supposed to be signaled to
	that is supposed to be signalled to the other end to be higher than		the other end to be higher than that of SF-P can result in
	that of SF-P can result in unpredictable protection switching state,		unpredictable protection switching state, when the protection path
	when the protection path has failed and consequently the PSC		has failed and consequently the PSC communication stopped. An
	communication stopped. An example of the out-of-service scenarios is		example of the out-of-service scenarios is shown in Appendix A.
	shown in Appendix A
	According to Section 2.4 of [RFC5654] it MUST be possible to operate
	an MPLS-TP network without using a control plane. This means that
	external switch commands, e.g., FS, can be transferred to the far end
	only by using the PSC communication channel and should not rely on
	the presence of a control plane.
	As the priority of SF-P has been higher than FS in optical transport		According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to
	networks and Ethernet transport networks, for network operators it is		operate an MPLS-TP network without using a control plane. This means
	important that the MPLS-TP protection switching preserves the network		that external switch commands, e.g., FS, can be transferred to the
	operation behavior to which network operators have become accustomed.		remote Label Edge Router (LER) only by using the PSC communication
	Typically, the FS command is issued before network maintenance jobs,		channel and should not rely on the presence of a control plane.
	(e.g., replacing optical cables or other network components). When
	an operator pulls out a cable on the protection path by mistake, the
	traffic should be protected and the operator expects this behavior
	based on his/her experience on the traditional transport network
	operations.
	4.2. Motivation for raising the priority of Clear SF		As the priority of SF-P has been higher than FS in other transport
			networks, such as SDH, OTN and Ethernet transport networks, for
			network operators it is important that the MPLS-TP protection
			switching preserves the network operation behavior to which network
			operators have become accustomed. Typically, FS command is issued
			before network maintenance jobs, (e.g., replacing optical cables or
			other network components). When an operator pulls out a cable on the
			protection path by mistake, the traffic should be protected and the
			operator expects this behavior based on his/her experience on the
			traditional transport network operations.
	The priority level of SFc defined in [RFC6378] can cause traffic		4.2. Motivation for raising the priority of SFc
	disruption when a node that has experienced local signal fails on
	both working and protection paths is recovering from these failures.		The priority level of SFc defined in RFC 6378 [RFC6378] can cause
			traffic disruption when a node that has experienced local signal
			fails on both the working and the protection paths is recovering from
			these failures.
	An example of sequence diagram showing the problem with the priority		An example of sequence diagram showing the problem with the priority
	level of SFc as defined in [RFC6378] is shown in Appendix B.		level of SFc as defined in RFC 6378 is shown in Appendix B.
	4.3. Motivation for introducing Freeze command		4.3. Motivation for introducing Freeze command
	With the priority swapping between FS and SF-P, the traffic is always		With the priority swapping between FS and SF-P, the traffic is always
	moved back to the working path when SF-P occurs in Protecting		moved back to the working path when SF-P occurs in Protecting
	Administrative state. In the case that network operators need an		administrative state. In the case that network operators need an
	option to control their networks so that the traffic can remain on		option to control their networks so that the traffic can remain on
	the protection path even when the PSC communication channel is		the protection path even when the PSC communication channel is
	broken, the Freeze command, which is a local command (i.e., not		broken, the Freeze command, which is a local command (i.e., not
	signalled to the other end) can be used. The use of the Freeze		signaled to the other end) can be used. The use of the Freeze
	command is described in Appendix C.		command is described in Appendix C.
	4.4. Updates to the PSC RFC		4.4. Modifications to RFC 6378
	The list of local requests in order of priority should be modified as		The list of local requests in order of priority SHALL be modified as
	follows:		follows:
	(from higher to lower)		(from higher to lower)
	o Clear Signal Fail/Degrade		o Clear Signal Fail
	o Signal Fail on the Protection path		o Signal Fail on Protection path
	o Forced Switch		o Forced Switch
	o Signal Fail on the Working path		o Signal Fail on Working path
	The change of the PSC control logic including state machine due to		The change of the PSC Control logic including the state machine due
	this priority modification is incorporated in the PSC control logic		to this priority modification is incorporated in the PSC Control
	description when all the capabilities are enabled in Section 10 and		logic description in Section 10 and Section 11 when all the
	Section 11.		capabilities are enabled.
	5. Capability 2: Modification of Non-revertive Operation		5. Capability 2: Modification of non-revertive operation
	Non-revertive mode of protection switching is defined in [RFC4427].		Non-revertive mode of protection switching is defined in RFC 4427
	In this mode, the traffic does not return to the working path when		[RFC4427]. In this mode, the traffic does not return to the working
	switch-over requests are terminated.		path when switch-over requests are terminated.
	However, PSC protocol defined in [RFC6378] supports this operation		However, PSC protocol defined in RFC 6378 [RFC6378] supports this
	only when recovering from a defect condition, but does not operate as		operation only when recovering from a defect condition, but does not
	non-revertive when an operator's switch-over command such as Forced		operate as non-revertive when an operator's switch-over command such
	Switch or Manual Switch is cleared. To be aligned with legacy		as FS or Manual Switch (MS) is cleared. To be aligned with legacy
	transport network behavior and [RFC4427], a node should go into the		transport network behavior and RFC 4427, a node should go into the
	Do-not-Revert (DNR) state not only when a failure condition on a		Do-not-Revert (DNR) state not only when a failure condition on the
	working path is cleared but also when an operator command requesting		working path is cleared but also when an operator command requesting
	switch-over is cleared.		switch-over is cleared.
	The change of the PSC control logic including state machine due to		The change of the PSC Control logic including the state machine due
	the modification of non-revertive operation is incorporated into the		to the modification of non-revertive operation is incorporated into
	PSC control logic description when all the capabilities are enabled		the PSC Control logic description in Section 10 and Section 11 when
	in Section 10 and Section 11.		all the capabilities are enabled.
	6. Capability 3: Support of Manual Switch to Working Command		6. Capability 3: Support of MS-W command
	6.1. Motivation for adding Manual Switch to Working		6.1. Motivation for adding MS-W
	Changing the non-revertive operation introduces necessity of a new		Changing the non-revertive operation introduces necessity of a new
	operator command to revert traffic to the working path when in Do-		operator command to revert traffic to the working path when in the
	not-Revert (DNR) state. When the traffic is on the protection path		DNR state. When the traffic is on the protection path in the DNR
	in DNR state, a Manual Switch to Working (MS-W) command is issued to		state, a Manual Switch to Working (MS-W) command is issued to switch
	switch the normal traffic back to the working path. According to		the normal traffic back to working path. According to
	Section 4.3.3.6 (Do-not-Revert State) in [RFC6378], "to revert back		Section 4.3.3.6 (Do-not-Revert State) in RFC 6378 [RFC6378], "to
	to Normal state, the administrator SHALL issue a Lockout of		revert back to Normal state, the administrator SHALL issue a Lockout
	protection (LO) command followed by a Clear command." However, using		of protection (LO) command followed by a Clear command." However,
	LO command introduces the potential risk of an unprotected situation		using LO command introduces the potential risk of an unprotected
	while the Lockout of protection is in effect.		situation while the LO is in effect.
	Manual Switch-over for recovery LSP/span command, defined in		Manual Switch-over for recovery LSP/span command, defined in RFC 4427
	[RFC4427] and also defined in [RFC5654], Requirement 83, as one of		[RFC4427] and also defined in RFC 5654 [RFC5654], Requirement 83, as
	the mandatory external commands, should be used for this purpose, but		one of the mandatory external commands, should be used for this
	is not included in [RFC6378]. Note that the "Manual Switch-over for		purpose, but is not included in RFC 6378. Note that the "Manual
	recovery LSP/span" command is the same as MS-W command.		Switch-over for recovery LSP/span" command is the same as MS-W
			command.
	6.2. Terms modified to support MS-W		6.2. Terms modified to support MS-W
	The term "Manual Switch" and its acronym "MS" used in [RFC6378] are		The term "Manual Switch" and its acronym "MS" used in RFC 6378 are
	replaced respectively by "Manual Switch to Protection" and "MS-P" by		replaced respectively by "Manual Switch to Protection path" and
	this document to avoid confusion with "Manual Switch to Working" and		"MS-P" by this document to avoid confusion with "Manual Switch to
	its acronym "MS-W".		Working path" and its acronym "MS-W".
	Also, the term "Protecting administrative state" used in [RFC6378] is		Also, the term "Protecting administrative state" used in RFC 6378 is
	replaced by "Switching administrative state" by this document to		replaced by "Switching administrative state" by this document to
	include the case where traffic is switched back to the working path		include the case where traffic is switched back to the working path
	by administrative Manual Switch to Working command.		by administrative MS-W command.
	6.3. Behavior of MS-P and MS-W		6.3. Behavior of MS-P and MS-W
	The MS-P and MS-W commands SHALL have the same priority. If one of		The MS-P and MS-W commands SHALL have the same priority. If one of
	these commands is already issued and accepted, and the other command		these commands is already issued and accepted, then the other command
	that is issued afterwards SHALL be ignored. If two LERs are		that is issued afterwards SHALL be ignored. If two LERs are
	requesting opposite operations simultaneously, i.e. one LER is		requesting opposite operations simultaneously, i.e. one LER is
	sending MS-P while the other LER is sending MS-W, the MS-W SHALL be		sending MS-P while the other LER is sending MS-W, the MS-W SHALL be
	considered to have a higher priority than MS-P, and MS-P SHALL be		considered to have a higher priority than MS-P, and MS-P SHALL be
	ignored.		ignored and cancelled.
	Two commands, MS-P and MS-W are represented by the same Request Field		Two commands, MS-P and MS-W are represented by the same Request Field
	value, but differentiated by the FPath value. When traffic is		value, but differentiated by the FPath value. When traffic is
	switched to the protection path, the FPath field SHALL indicate that		switched to the protection path, the FPath field SHALL indicate that
	the working path is being blocked (i.e., FPath set to 1), and the		the working path is being blocked (i.e., FPath set to 1), and the
	Path field SHALL indicate that user data traffic is being transported		Path field SHALL indicate that user data traffic is being transported
	on the protection path (i.e., Path set to 1). When traffic is		on the protection path (i.e., Path set to 1). When traffic is
	switched to the working path, the FPath field SHALL indicate that the		switched to the working path, the FPath field SHALL indicate that the
	protection path is being blocked (i.e., FPath set to 0), and the Path		protection path is being blocked (i.e., FPath set to 0), and the Path
	field SHALL indicate that user data traffic is being transported on		field SHALL indicate that user data traffic is being transported on
	the working path (i.e., Path set to 0).		the working path (i.e., Path set to 0).
	6.4. Equal priority resolution for MS		6.4. Equal priority resolution for MS
	[RFC6378] defines only one rule for equal priority condition in		RFC 6378 defines only one rule for equal priority condition in
	Section 4.3.2 as "The remote message from the far-end LER is assigned		Section 4.3.2 as "The remote message from the remote LER is assigned
	a priority just below the similar local input." In order to support		a priority just below the similar local input." In order to support
	the manual switch behavior described in Section 6.3, additional rules		the manual switch behavior described in Section 6.3, additional rules
	for equal priority resolution are required. Since the support of		for equal priority resolution are required. Since the support of
	protection against signal degrades also requires a similar equal		protection against signal degrade also requires a similar equal
	priority resolution, the rules are described in Section 7.4.		priority resolution, the rules are described in Section 7.4.
	The change of the PSC control logic including state machine due to		The change of the PSC Control logic including the state machine due
	the support of MS-W command is incorporated into the PSC control		to the support of MS-W command is incorporated into the PSC Control
	logic description when all the capabilities are enabled in Section 10		logic description in Section 10 and Section 11 when all the
	and Section 11.		capabilities are enabled
	7. Capability 4: Support of protection against Signal Degrade		7. Capability 4: Support of protection against SD
	7.1. Motivation for supporting protection against Signal Degrade		7.1. Motivation for supporting protection against SD
	In MPLS-TP survivability framework [RFC6372], fault conditions		In MPLS-TP survivability framework [RFC6372], fault conditions
	include both Signal Fail (SF) and Signal Degrade (SD) that can be		include both SF and SD that can be used to trigger protection
	used to trigger protection switching.		switching.
	[RFC6378], which defines the Protection State Coordination (PSC)		RFC 6378 [RFC6378], which defines the protection switching protocol
	protocol, does not specify how the SF and SD are declared and		for MPLS-TP does not specify how the SF and SD are detected, and
	specifies the protection switching protocol associated with SF only.		specifies the protection switching protocol associated with SF only.
	The protection switching protocol associated with SD is covered in		The PSC protocol associated with SD is covered in this document, and
	this document, and the specifics for the method of identifying SD is		the specifics for the method of identifying SD is out of the scope of
	out of the scope of PSC protocol similarly to how to detect SF and		the protection protocol similar to the facts that how SF is detect
	how MS and FS commands are initiated in a management system and		and how MS and FS commands are initiated in a management system and
	signalled to PSC.		signaled to protection switching are out of its scope.
	7.2. Terms modified to support SD		7.2. Terms modified to support SD
	Clear Signal Fail (SFc) includes the clearance of a degraded		Instead of SFc, Clear Signal Fail or Degrade (SFDc) is used to
	condition in addition to the clearance of a failure condition		indicate the clearance of either a degraded condition or a failure
			condition.
	The second paragraph of Section 4.3.3.2 Unavailable State in		The second paragraph of Section 4.3.3.2 Unavailable state in RFC 6378
	[RFC6378] shows the intention of including Signal Degrade on the		shows the intention of including Signal Degrade on Protection path
	Protection path (SD-P) in the Unavailable state. Even though the		(SD-P) in the Unavailable state. Even though the protection path can
	protection path can be partially available under the condition of the		be partially available under the condition of SD-P, this document
	Signal Degrade on the Protection path, this document follows the same		follows the same state grouping as RFC 6378 for SD-P.
	state grouping as [RFC6378] for SD on the protection path.
	The bullet item "Protecting failure state" in Section 3.6. PSC		The bullet item "Protecting failure state" in Section 3.6 in RFC 6378
	Control States in [RFC6378] includes the degraded condition in		includes the degraded condition in Protecting failure state. This
	Protection Failure state. This document follows the same state		document follows the same state grouping as RFC 6378 for Signal
	grouping as [RFC6378] for Signal Degrade on the Working path (SD-W).		Degrade on Working path (SD-W).
	7.3. Behavior of protection against SD		7.3. Behavior of protection against SD
	In order to maintain the network operation behavior to which		In order to maintain the network operation behavior to which
	transport network operators have become accustomed, the priorities of		transport network operators have become accustomed, the priorities of
	SD-P and SD-W are defined to be equal as in other transport networks,		SD-P and SD-W are defined to be equal as in other transport networks,
	such as OTN and Ethernet. Once a switch has been completed due to		such as SDH, OTN and Ethernet transport networks. Once a switch has
	Signal Degrade on one path, it will not be overridden by Signal		been completed due to SD on one path, it will not be overridden by SD
	Degrade on the other path (first come, first served behavior), to		on the other path (first come, first served behavior), to avoid
	avoid protection switching that cannot improve signal quality and		protection switching that cannot improve signal quality.
	flapping.
	Signal Degrade (SD) indicates that the transmitting end point has		SD indicates that the transmitting end point has identified a
	identified a degradation of the signal, or integrity of the packet		degradation of the signal, or integrity of the packet transmission on
	transmission on either the working or protection path. The FPath		either the working path or the protection path. The FPath field
	field SHALL identify the path that is reporting the degrade condition		SHALL identify the path that is reporting the degrade condition
	(i.e., if protection path, then FPath is set to 0; if working path,		(i.e., if the protection path, then FPath is set to 0; if the working
	then FPath is set to 1), and the Path field SHALL indicate where the		path, then FPath is set to 1), and the Path field SHALL indicate
	data traffic is being transported (i.e., if working path is selected,		where the data traffic is being transported (i.e., if the working
	then Path is set to 0; if protection path is selected, then Path is		path is selected, then Path is set to 0; if the protection path is
	set to 1).		selected, then Path is set to 1).
	The Wait to Restore (WTR) timer is used when the protected domain is		The Wait to Restore (WTR) timer is used when the protected domain is
	configured for revertive behavior and started at the node that		configured for revertive behavior and started at the node that
	recovers from a local degraded condition on the working path.		recovers from a local degraded condition on the working path.
	If the detection of a SD depends on the presence of user data		Protection switching against SD is always provided by a selector
	packets, such a condition declared on the working path is cleared		bridge duplicating user data traffic and feeding it to both the
	following protection switching to the protection path if a selector		working path and the protection path under SD condition. When a
	bridge is used, possibly resulting in flapping. To avoid flapping,		local or remote SD occurs on either the working path or the
	the selector bridge should duplicate the user data traffic and feed		protection path, the LER SHALL duplicate user data traffic and SHALL
	it to both working and protection paths under SD condition. In		feed to both the working path and the protection path. The packet
	revertive mode, when WTR timer expires the packet duplication will be		duplication SHALL continue as long as any SD condition exists in the
	stopped and the user data traffic will be transported on the working		protected domain, and SHALL stop when there is no SD condition.
	path only. In non-revertive mode, when SD is cleared the packet		Additionally, the packet duplication SHALL continue in the WTR state
	duplication will be stopped and the user data traffic will be		in revertive mode. In non-revertive mode, the packet duplication
	transported on the protection path only.		SHALL stop when there is no SD condition.
	When multiple SDs are detected simultaneously, either as local or
	remote requests on both working and protection paths, the SD on the
	standby path (the path from which the selector does not select the
	user data traffic) is considered as having higher priority than the
	SD on the active path (the path from which the selector selects the
	user data traffic). Therefore, no unnecessary protection switching
	is performed and the user data traffic continues to be selected from
	the active path.
	In the preceding paragraph, "simultaneously" relates to the		The selector bridge with the packet duplication under SD condition,
	occurrence of SD on both the active and standby paths at input to the		which is a non-permanent bridge, is considered to be a 1:1 protection
	Protection State Control Logic in Figure 1 of [RFC6378] at the same		architecture.
	time, or as long as a SD request has not been acknowledged by the
	remote end in bidirectional protection switching. In other words,
	when a local node that has transmitted a SD message receives a SD
	message that indicates a different value of data path (Path) field
	than the value of the Path field in the transmitted SD message, both
	the local and the remote SD requests are considered to occur
	simultaneously.
	7.4. Equal priority resolution		7.4. Equal priority resolution
	In order to support the manual switch behavior described in		In order to support the manual switch behavior described in
	Section 6.3 and the protection against Signal Degrade described in		Section 6.3 and the protection against Signal Degrade described in
	Section 7.3, the rules to resolve the equal priority requests are		Section 7.3, the rules to resolve the equal priority requests are
	required.		required.
	For local inputs with same priority, such as MS and SD, first-come,		For the equal priority local inputs, such as MS and SD, first-come,
	first-served rule is applied. Once a local input is determined as		first-served rule is applied. Once a local input is determined as
	the highest priority local input, then a subsequent equal priority		the highest priority local input, then a subsequent equal priority
	local input requesting a different action, i.e., the same PSC Request		local input requesting a different action, i.e., the action results
	Field but different FPath value, to the PSC control logic will not be		in the same PSC Request Field but different FPath value, will not be
	presented to the PSC control logic as the highest local request.		presented to the PSC Control logic as the highest local request.
	Furthermore, in the case of MS, the subsequent MS local input		Furthermore, in the case of MS command, the subsequent local MS
	requesting a different action will be cancelled.		command requesting a different action will be cancelled.
	The remote message from the far-end LER is assigned a priority just
	below the similar local input. For example, a remote Forced Switch
	would have a priority just below a local Forced Switch but above a
	local Signal Fail on working input assuming that the priority
	modification is in place as in Section 4.4
	However, if the LER is in a remote state due to a remote message, a		If the LER is in a remote state due to a remote SD (or MS) message, a
	subsequent local input having the same priority but requesting		subsequent local input having the same priority but requesting
	different action to the control logic, will be considered as having		different action to the PSC Control logic, will be considered as
	lower priority than the remote message, and will be ignored. For		having lower priority than the remote message, and will be ignored.
	example, if the LER is in remote Unavailable state due to a remote		If the LER is in remote Switching administrative state due to a
	SD-P, then subsequent local SD-W input will be ignored. Likewise, if		remote MS-P, then subsequent local MS-W SHALL be ignored and
	the LER is in remote Switching administrative state due to a remote		automatically cancelled. If the LER is in remote Unavailable state
	MS-P, then subsequent local MS-W will be ignored and automatically		due to a remote SD-P, then subsequent local SD-W input will be
	cancelled.		ignored. However, the local SD-W SHALL appear in the Local Request
			logic as long as the SD condition exists, but SHALL NOT be the top
			priority global request, which determines the state transition at the
			PSC Control logic.
	It should be noted that there is a reverse case where one LER		There is a case where one LER receives a local input and the other
	receives a local input and the other LER receives, simultaneously, an		LER receives, simultaneously, a local input with the same priority
	input with the same priority but requesting different action. In		but requesting different action. In this case, each of the two LERs
	this case, each of the two LERs receives a subsequent remote message		receives a subsequent remote message having the same priority but
	having the same priority but requesting different action, while the		requesting different action, while the LER is in a local state due to
	LER is in a local state due to the local input. In this case, a		the local input. When this case happens, a priority must be set for
	priority must be set for the inputs with the same priority regardless		the inputs with the same priority regardless of its origin (local
	of its origin (local input or remote message). For example, one LER		input or remote message).
	receives SD-P as a local input and the other LER receives SP-W as a
	local input, simultaneously. Likewise, one LER receives MS-P as a
	local input and the other LER receives MS-W as a local input,
	simultaneously.
	When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be		When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be
	considered as having higher priority than MS-P at both LERs.		considered as having higher priority than MS-P at both LERs.
	When SD-W and SD-P occur simultaneously at both LERs, In this case,		When SD-W and SD-P occur simultaneously at both LERs, the SD on the
	the SD on the standby path (the path from which the selector does not		standby path (the path from which the selector does not select the
	select the user data traffic) is considered as having higher priority		user data traffic) is considered as having higher priority than the
	than the SD on the active path (the path from which the selector		SD on the active path (the path from which the selector selects the
	selects the user data traffic) regardless of its origin (local or		user data traffic) regardless of its origin (local or remote
	remote message). Therefore, no unnecessary protection switching is		message). Therefore, no unnecessary protection switching is
	performed and the user data traffic continues to be selected from the		performed and the user data traffic continues to be selected from the
	active path. Giving the higher priority to the SD on the standby		active path.
	path SHALL also be applied to the Local Request logic when two SDs
	for different paths happen to be presented to the Local Request logic
	exactly at the same time.
	The change of the PSC control logic including state machine due to		In the preceding paragraphs, the "simultaneously" refers to the case
	the support of protection against SD is incorporated into the PSC		a sent SD (or MS) request has not been confirmed by the remote end in
	control logic description when all the capabilities are enabled in		bidirectional protection switching. When a local node that has
	Section 10 and Section 11.		transmitted a SD message receives a SD (or MS) message that indicates
			a different value of data path (Path) field than the value of the
			Path field in the transmitted SD (or MS) message, both the local and
			the remote SD requests are considered to occur simultaneously.
	8. Capability 5: Support of Exercise Command		The change of the PSC Control logic including the state machine due
			to the support of protection against SD is incorporated into the PSC
			Control logic description in Section 10 and Section 11 when all the
			capabilities are enabled.
	Exercise is a command to test if the PSC communication is operating		8. Capability 5: Support of EXER command
	correctly. More specifically, the Exercise is to test and validate
	the linear protection mechanism and PSC protocol including the
	aliveness of the Local Request logic, the PSC state machine and the
	PSC message generation and reception, and the integrity of the
	protection path, without triggering the actual traffic switching. It
	is used while the working path is either carrying the traffic or not.
	It is lower priority than any "real" switch request. It is only
	valid in bidirectional switching, since this is the only place where
	one can get a meaningful test by looking for a response.
	This command is documented in R84 of [RFC5654] and it has been		EXER is a command to test if the PSC communication is operating
	identified as a requirement from ITU-T.		correctly. More specifically, EXER is to test and validate the
			linear protection mechanism and PSC protocol including the aliveness
			of the Local Request logic, the PSC state machine and the PSC message
			generation and reception, and the integrity of the protection path,
			without triggering the actual traffic switching. It is used while
			the working path is either carrying the traffic or not. It has lower
			priority than any "real" switch request. It is only valid in
			bidirectional switching, since this is the only place where one can
			get a meaningful test by looking for a response.
			This command is documented in R84 of RFC 5654 [RFC5654].
	A received EXER message indicates that the remote end point is		A received EXER message indicates that the remote end point is
	operating under an operator command to validate the protection		operating under an operator command to validate the protection
	mechanism and PSC protocol including the aliveness of the Local		mechanism and PSC protocol including the aliveness of the Local
	Request logic, the PSC state machine and the PSC message generation		Request logic, the PSC state machine and the PSC message generation
	and reception, and the integrity of the protection path, without		and reception, and the integrity of the protection path, without
	triggering the actual traffic switching. The valid response to EXER		triggering the actual traffic switching. The valid response to EXER
	message will be an Reverse Request (RR) with the corresponding FPath		message is an Reverse Request (RR) with the corresponding FPath and
	and Path numbers. The near end will signal a Reverse Request (RR)		Path numbers. The local LER SHALL signal a RR only in response to an
	only in response to an EXER command from the far end.		EXER command from the remote LER.
	When Exercise commands are input at both ends, an EXER, instead of		When Exercise commands are input at both ends, an EXER, instead of
	RR, is transmitted from both ends.		RR, SHALL be transmitted from both ends.
	The following PSC Requests should be added to PSC Request field to		The following PSC Requests SHALL be added to PSC Request field to
	support Exercise:		support Exercise:
	(TBD2) Exercise - indicates that the transmitting end point is		(3) Exercise - indicates that the transmitting end point is
	exercising the protection channel and mechanism. FPath and Path		exercising the protection channel and mechanism. FPath and Path
	are set to the same value of the NR, RR or DNR request that EXER		are set to the same value of the No Request (NR), RR or DNR
	replaces.		request that EXER replaces.
	(TBD1) Reverse Request - indicates that the transmitting end point		(2) Reverse Request - indicates that the transmitting end point is
	is responding to an EXER command from the far end. FPath and Path		responding to an EXER command from the remote LER. FPath and Path
	are set to the same value of the NR, RR or DNR request that EXER		are set to the same value of the NR or DNR request that RR
	replaces.		replaces.
	The priority of Exercise should be inserted between the priorities of		The priority of Exercise SHALL be inserted between the priorities of
	WTR Expires and No Request.		WTR Expires and No Request.
	9. Capabilities and Modes		9. Capabilities and modes
	9.1. Capabilities		9.1. Capabilities
	A Capability is an individual behavior whose use is signalled in a		A Capability is an individual behavior whose use is signaled in a
	Capabilities TLV, which is placed in Optional TLVs field inside PSC		Capabilities TLV, which is placed in Optional TLVs field inside the
	messages shown in Figure 2 of [RFC6378]. The format of the		PSC message shown in Figure 2 of RFC 6378 [RFC6378]. The format of
	Capabilities TLV is:		the Capabilities TLV is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = Capabilities | Length |		| Type = Capabilities | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value = Options |		| Value = Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The value of the Type field is TBD3 pending IANA allocation.		Figure 1: Format of Capabilities TLV
	The value of the Length field is the length of the Options Value, and		The value of the Type field is TBD pending IANA allocation.
	is in octets.
	The Value of the Capabilities TLV can be any length, as long as it is		The value of the Length field is the length of the Flags field in
	a multiple of 4 octets. The length of the Value field MUST be the		octets. The length of the Flags field MUST be a multiple of 4 octets
	minimum required to signal all the required capabilities. Section 4		and MUST be the minimum required to signal all the required
	to Section 8 discuss five capabilities that are signalled using the 5		capabilities.
	most significant bits; if a node wishes to signal these five
	capabilities, it MUST send an Options Value of 4 octets. A node		Section 4 to Section 8 discuss five capabilities that are signaled
	would send an Options Value greater than 4 octets only if it had more		using the five most significant bits; if a node wishes to signal
	than 32 Capabilities to indicate. All unused bits MUST be set to		these five capabilities, it MUST send a Flags field of 4 octets. A
	zero.		node would send a Flags field greater than 4 octets only if it had
			more than 32 Capabilities to indicate. All unused bits MUST be set
			to zero.
	If the bit assigned for an individual capability is set to 1, it		If the bit assigned for an individual capability is set to 1, it
	indicates the sending node's intent to use that capability in the		indicates the sending node's intent to use that capability in the
	protected domain. If a bit is set to 0, the sending node does not		protected domain. If a bit is set to 0, the sending node does not
	intend to use the indicated capability in the protected domain. Note		intend to use the indicated capability in the protected domain. Note
	that it is not possible to distinguish between the intent not to use		that it is not possible to distinguish between the intent not to use
	a capability and a node's complete non-support (i.e. lack of		a capability and a node's complete non-support (i.e., lack of
	implementation) of a given capability.		implementation) of a given capability.
	This document defines five specific capabilities that are described		This document defines five specific capabilities that are described
	from Section 4 to Section 8. Each capability is assigned bit as		from Section 4 to Section 8. Each capability is assigned bit as
	follows:		follows:
	0x80000000: priority modification		0x80000000: priority modification
	0x40000000: modification of non-revertive behavior		0x40000000: non-revertive behavior modification
			0x20000000: support of MS-W command
	0x20000000: support of Manual Switch to Working (MS-W) command		0x10000000: support of protection against SD
	0x10000000: support of protection against Signal Degrade (SD)		0x08000000: support of EXER command
	0x08000000: support of Exercise command		If all the five capabilities should be used, an LER SHALL set
			0xF8000000 in the Flags field.
	9.1.1. Sending the Capabilities TLV		9.1.1. Sending the Capabilities TLV
	PSC sends messages in response to external events and in periodic		PSC sends messages in response to external events and in periodic
	retransmission of current status. It may be expensive to send and to		retransmission of current status. It may be expensive to send and to
	parse an Capabilities TLV attached to a packet intended to trigger a		parse an Capabilities TLV attached to a packet intended to trigger a
	protection switch or other real- time behavior. However, if a node		protection switch or other real-time behavior. However, if a node
	does not periodically send its Capabilities TLV, the receiving node		does not periodically send its Capabilities TLV, the receiving node
	cannot discriminate a deliberate omission of the Capabilities TLV for		cannot discriminate a deliberate omission of the Capabilities TLV for
	performance reasons from an accidental omission due to an		performance reasons from an accidental omission due to an
	implementation issue. To guard against this, a node MUST include its		implementation issue. To guard against this, a node MUST include its
	Capabilities TLV in every PSC message that it sends.		Capabilities TLV in every PSC message that it sends.
	9.1.2. Receiving the Capabilities TLV		9.1.2. Receiving the Capabilities TLV
	A node MUST establish a receive timer for the Capabilities TLV. By		A node MUST establish a receive timer for the Capabilities TLV. By
	default this MUST be 3.5 times the periodic retransmission timer of		default this MUST be 3.5 times the periodic retransmission timer of
	five seconds - i.e., 17.5 seconds. Both the periodic retransmission		five seconds - i.e., 17.5 seconds. Both the periodic retransmission
	time and the timeout SHOULD be configurable by the operator. When a		time and the timeout SHOULD be configurable by the operator. When a
	node receives a Capabilities TLV it resets the timer to 17.5 seconds.		node receives a Capabilities TLV it resets the timer to 17.5 seconds.
	If the timer expires, the node behaves as in Section 9.1.3.		If the timer expires, the node behaves as in Section 9.1.3.
	[Editor's note: In other packet transport protection technologies,
	Failure of Protocol defect (dFOP) is declared when no protocol
	message is received on the protection path during at least 3.5 times
	the periodic message transmission interval (i.e., at least 17.5
	seconds) and there is no defect on the protection transport entity.
	As the "Capabilities TLV" is included in the PSC message, this error
	of not receiving the Capabilities TLV can be covered by dFOP. To be
	discussed.]
	When a node receives a Capabilities TLV it MUST compare it to its		When a node receives a Capabilities TLV it MUST compare it to its
	most recent transmitted Capabilities TLV. If the two are equal, the		most recent transmitted Capabilities TLV. If the two are equal, the
	protected domain is said to be running in the mode indicated by that		protected domain is said to be running in the mode indicated by that
	set of capabilities (see Section 9.2). If the sent and received		set of capabilities (see Section 9.2). If the sent and received
	Capabilities TLVs are not equal, this indicates a capabilities		Capabilities TLVs are not equal, this indicates a capabilities
	mismatch. When this happens, the node MUST alert the operator and		mismatch. When this happens, the node MUST alert the operator and
	MUST behave as in Section 9.1.3.		MUST behave as in Section 9.1.3.
	9.1.3. Handling Capabilities TLV errors		9.1.3. Handling Capabilities TLV errors
	This section covers the two possible errors - a TLV timeout and a TLV		This section covers the two possible errors - a TLV timeout and a TLV
	mismatch - and the error handling procedures in both cases.		mismatch - and the error handling procedures in both cases.
	9.1.3.1. Capabilities TLV Timeout		9.1.3.1. Capabilities TLV Timeout
	If the Capabilities TLV receive timer expires, a node is said to have		If the Capabilities TLV receive timer expires and there is no defect
	timed out. When this happens, the node MUST alert the operator and		on the protection path, the node MUST alert the operator and MUST
	MUST behave as in Section 9.1.3.3.		behave as in Section 9.1.3.3.
	9.1.3.2. Capabilities TLV Mismatch		9.1.3.2. Capabilities TLV Mismatch
	If the sent and received Capabilities TLVs are not equal, this		If the sent and received Capabilities TLVs are not equal, this
	indicates a capabilities mismatch. When this happens, the node MUST		indicates a capabilities mismatch. When this happens, the node MUST
	alert the operator and MUST behave as in Section 9.1.3.3. A node MAY		alert the operator and MUST behave as in Section 9.1.3.3. A node MAY
	retain the received TLV for logging, alert or debug purposes.		retain the received TLV for logging, alert or debug purposes.
	9.1.3.3. Handling Capabilities TLV error conditions		9.1.3.3. Handling Capabilities TLV error conditions
	When a node enters in Capabilities protocol error conditions, the		When a node enters in Capabilities protocol error conditions, the
	following actions MUST be taken:		following actions MUST be taken:
	1. Indicate the error condition (e.g., either mismatch or timeout)		1. Indicate the error condition (e.g., either mismatch or timeout)
	to the operator by the usual alert mechanisms (e.g., syslog).		to the operator by the usual alert mechanisms (e.g., syslog).
	2. Not make any state transitions based on the contents of any PSC		2. Not make any state transitions based on the contents of any PSC
	Messages		messages
	To expand on point 2 - assume node A is receiving NR(0,0) from its		To expand on point 2 - assume node A is receiving NR(0,0) from its
	PSC peer node Z and is also receiving a mismatched set of		PSC peer node Z and is also receiving a mismatched set of
	capabilities (e.g., received 0x4, transmitted 0x5). If node Z		capabilities (e.g., received 0x20000000, transmitted 0xA0000000). If
	detects a local SF-W and wants to initiate a protection switch (that		node Z detects a local SF-W and wants to initiate a protection switch
	is, by sending SF(1,1)), node A MUST NOT react to this input by		(that is, by sending SF(1,1)), node A MUST NOT react to this input by
	changing its state. A node MAY increase the severity or urgency of		changing its state. A node MAY increase the severity or urgency of
	its alarms to the operator, but until the operator resolves the		its alarms to the operator, but until the operator resolves the
	mismatch in the Capabilities TLV the protected domain will likely		mismatch in the Capabilities TLV the protected domain will likely
	operate in an inconsistent state.		operate in an inconsistent state.
	9.2. Modes		9.2. Modes
	A Mode is a given set of Capabilities. Modes are shorthand;		A Mode is a given set of Capabilities. Modes are shorthand;
	referring to a set of capabilities by their individual values or by		referring to a set of capabilities by their individual values or by
	the name of their mode does not change the protocol behavior. This		the name of their mode does not change the protocol behavior. This
	document defines two modes - PSC and APS.		document defines two modes - PSC and APS.
	9.2.1. PSC Mode		9.2.1. PSC Mode
	PSC Mode is defined as the lack of any Capabilities - that is, a		PSC Mode is defined as the lack of any Capabilities - that is, a
	Capabilities set of 0x0. It is the behavior specified in RFC6378.		Capabilities set of 0x0. It is the behavior specified in RFC 6378.
	There are two ways to declare PSC Mode. A node can send a		There are two ways to declare PSC Mode. A node can send a
	Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.		Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.
	This is further explored in Section 9.3.		This is further explored in Section 9.3.
	9.2.2. APS Mode		9.2.2. APS Mode
	APS Mode is defined as the use of all of the five specific		APS Mode is defined as the use of all the five specific capabilities,
	capabilities, which are described from Section 4 to Section 8 in this		which are described from Section 4 to Section 8 in this document.
	document. APS Mode is indicated with a Value of 0xF8000000.		APS Mode is indicated with the Flags value of 0xF8000000.
	9.3. Backward compatibility		9.3. Backward compatibility
	As defined in Section 9.2.1, PSC Mode is indicated either with a		As defined in Section 9.2.1, PSC Mode is indicated either with a
	Capabilities TLV of 0x0 or the lack of Capabilities TLV. This is to		Capabilities TLV of 0x0 or the lack of Capabilities TLV. This is to
	allow backward compatibility between two nodes - one which can send		allow backward compatibility between two nodes - one which can send
	the Capabilities TLV, and one which cannot.		the Capabilities TLV, and one which cannot.
	[RFC6378] does not define how to handle an unrecognized TLV. There		RFC 6378 does not define how to handle an unrecognized TLV. There
	may be some implementations that silently discard an unrecognized		may be some implementations that silently discard an unrecognized
	TLV, and some that take more drastic steps like refusing to allow PSC		TLV, and some that take more drastic steps like refusing to allow PSC
	to operate. Thus, a node which has the ability to send and receive		to operate. Thus, a node which has the ability to send and receive
	the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode		the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode
	Capabilities TLV and send no Capabilities TLV at all. An		Capabilities TLV and send no Capabilities TLV at all. An
	implementation MUST be configurable between these two choices.		implementation MUST be configurable between these two choices.
	One question that arises from this dual definition of PSC Mode is,		One question that arises from this dual definition of PSC Mode is,
	what happens if a node which was sending a non-null Capabilities TLV		what happens if a node which was sending a non-null Capabilities TLV
	(e.g., APS Mode) sends PSC packets without any Capabilities TLV?		(e.g., APS Mode) sends PSC packets without any Capabilities TLV?
	This case is handled as follows:		This case is handled as follows:
	If a node has never, during the life of a PSC session, received a		If a node has never, during the life of a PSC session, received a
	Capabilities TLV from a neighbour, the lack of a Capabilities TLV is		Capabilities TLV from its peer, the lack of a Capabilities TLV is
	treated as receipt of a PSC Capabilities TLV. This allows for		treated as receipt of a PSC Capabilities TLV. This allows for
	interop between nodes which support the PSC Mode TLV and nodes which		interoperability between nodes which support the PSC Mode TLV and
	do not, and are thus implicitly operating in PSC Mode.		nodes which do not, and are thus implicitly operating in PSC Mode.
	If a node has received a non-null Capabilities TLV (e.g., APS Mode)		If a node has received a non-null Capabilities TLV (e.g., APS Mode)
	during the life of a PSC session and then receives a PSC packet with		during the life of a PSC session and then receives a PSC packet with
	no Capabilities TLV, the receiving node MUST treat the lack of		no Capabilities TLV, the receiving node MUST treat the lack of
	Capabilities TLV as simply a lack of refresh. That is, the receipt		Capabilities TLV as simply a lack of refresh. That is, the receipt
	of a PSC packet with no Capabilities TLV simply does not reset the		of a PSC packet with no Capabilities TLV simply does not reset the
	receive timer defined in Section 9.1.2.		receive timer defined in Section 9.1.2.
	10. PSC Protocol in APS Mode		10. PSC Protocol in APS Mode
	This section and Section 11 defines the behavior of PSC protocol when		This section and Section 11 define the behavior of PSC protocol when
	all of the aforementioned capabilities are enabled, i.e., APS mode.		all of the aforementioned capabilities are enabled, i.e., APS mode.
	10.1. Request field in PSC protocol message		10.1. Request field in PSC protocol message
	The values of "Request" field in the PSC protocol message, which is		The values of "Request" field in PSC protocol message, which is shown
	shown in Figure 2 of [RFC6378], are defined as follows:		in Figure 2 of RFC 6378 [RFC6378], are redefined as follows:
	(14) Lockout of protection		(14) Lockout of protection
	(12) Forced Switch		(12) Forced Switch
	(10) Signal Fail		(10) Signal Fail
	(7) Signal Degrade		(7) Signal Degrade
	(5) Manual Switch		(5) Manual Switch
	(4) Wait-to-Restore		(4) Wait-to-Restore
	(TBD2) Exercise		(3) Exercise
	(TBD1) Reverse Request		(2) Reverse Request
	(1) Do-not-Revert		(1) Do-not-Revert
	(0) No Request		(0) No Request
	10.2. Priorities of local inputs and remote requests		10.2. Priorities of local inputs and remote requests
	Based on the description in Section 3 and Section 4.3.2 in [RFC6378],		Based on the description in Section 3 and Section 4.3.2 in RFC 6378,
	the priorities of multiple outstanding local inputs are evaluated in		the priorities of multiple outstanding local inputs are evaluated in
	Local Request logic unit, where the highest priority local request is		the Local Request logic, where the highest priority local input
	determined. This high-priority local request is passed to the PSC		(highest local request) is determined. This highest local request is
	Control logic, that will determine the higher priority input (top		passed to the PSC Control logic, that will determine the higher
	priority global request) between the highest priority local input and		priority input (top priority global request) between the highest
	the last received remote message. When a remote message comes to the		local request and the last received remote message. When a remote
	PSC Control logic, the top priority global request is determined		message comes to the PSC Control logic, the top priority global
	between this remote message and the highest priority local input		request is determined between this remote message and the highest
	which is present. The top priority global request is used to		local request which is present. The top priority global request is
	determine the state transition, which is described in Section 11.		used to determine the state transition, which is described in
			Section 11.
	The priorities for both local and remote requests are defined as		The priorities for both local and remote requests are defined as
	follows from highest to lowest:		follows from highest to lowest:
	o Operator Clear (Local only)		o Operator Clear (Local only)
	o Lockout of protection (Local and Remote)		o Lockout of protection (Local and Remote)
	o Clear Signal Fail/Degrade (Local only)		o Clear Signal Fail or Degrade (Local only)
	o Signal Fail on Protection path (Local and Remote)		o Signal Fail on Protection path (Local and Remote)
	o Forced Switch (Local and Remote)		o Forced Switch (Local and Remote)
	o Signal Fail on Working path (Local and Remote)		o Signal Fail on Working path (Local and Remote)
	o Signal Degrade on either Protection path or Working path (Local		o Signal Degrade on either Protection path or Working path (Local
	and Remote)		and Remote)
	skipping to change at page 18, line 40		skipping to change at page 19, line 20
	o WTR (Remote only)		o WTR (Remote only)
	o Exercise (Local and Remote)		o Exercise (Local and Remote)
	o Reverse Request (Remote only)		o Reverse Request (Remote only)
	o Do-Not-Revert (Remote only)		o Do-Not-Revert (Remote only)
	o No Request (Remote and Local)		o No Request (Remote and Local)
	The remote request from the far-end LER is assigned a priority just		Note that the "Local only" requests are not signaled to the remote
			LER. Likewise, the "Remote only" requests do not exist in the Local
			Request logic as local inputs. For example, the priority of WTR only
			applies to the received WTR message, which is generated from the
			remote LER. The remote LER that is running the WTR timer in the WTR
			state has no local request.
			The remote request from the remote LER is assigned a priority just
	below the same local request. However, for the equal priority		below the same local request. However, for the equal priority
	requests, such as Signal Degrade on either Working or protection and		requests, such as SD and MS, the following equal priority resolution
	Manual Switch to either Protection or Working path, the following		rules are defined:
	equal priority resolution rules are defined:
	o If two local inputs having same priority but requesting different		o If two local inputs having the same priority but requesting
	action come to the Local Request logic, then the input coming		different action come to the Local Request logic, then the input
	first SHALL be considered to have a higher priority than the other		coming first SHALL be considered to have a higher priority than
	coming later (first-come, first-served).		the other coming later (first-come, first-served).
	o If the LER receives both a local input and a remote message with		o If the PSC Control logic has both the highest local request and a
	the same priority and requesting the same action, i.e., the same		remote message with the same priority and requesting the same
	PSC Request Field and the same FPath value, then the local input		action, i.e., the same PSC Request Field and the same FPath value,
	SHALL be considered to have a higher priority than the remote		then the local input SHALL be considered to have a higher priority
	message.		than the remote message.
	o If the LER receives both a local input and a remote message with		o If the PSC Control logic has both the highest local request and a
	the same priority but requesting different actions, i.e., the same		remote message with the same priority but requesting different
	PSC Request Field but different FPath value, then the first-come,		action and the remote message exists when the highest local
	first-served rule SHALL be applied. If the remote message comes		request comes to the PSC Control logic, the highest local request
	first, then the state SHALL be a remote state and subsequent local		is ignored and the remote Request SHALL be the top priority global
	input is ignored. However, if the local input comes first, the		request.
	first-come, first-served rule cannot be applied and must be viewed
	as simultaneous condition. This is because the subsequent remote
	message will not be an acknowledge of the local input by the far-
	end node. In this case, the priority SHALL be determined by rules
	for each simultaneous condition.
	o If the LER receives both MS-P and MS-W requests as both local		o If the PSC Control logic has both the highest local request and a
	input and remote message and the LER is in a local Switching		remote message with the same priority but requesting different
	administrative state, then the MS-W request SHALL be considered to		action and the highest local request exists when the remote
	have a higher priority than the MS-P request.		message comes to the PSC Control logic, the top priority global
			request SHALL be determined by the following rules for each
			simultaneous condition:
	o If the LER receives both SD-P and SD-W requests as both local		o For simultaneous MS requests, the MS-W request SHALL be considered
	input and remote message and the LER is in a local state, then the		to have a higher priority than the MS-P request. The LER that has
	SD on the standby path (the path from which the selector does not		local MS-W request SHALL maintain the local MS-W request as the
	select the user data traffic) SHALL be considered as having higher		top priority global request, but the other LER that has local MS-P
	priority than the SD on the active path (the path from which the		request SHALL clear the MS-P command and internally generate
	selector selects the user data traffic) regardless of its origin		"Operator Clear" request.
	(local or remote message). This rule of giving the higher
	priority to the SD on the standby path SHALL also be applied to		o For simultaneous SD requests, the SD on the standby path (the path
	the Local Request logic when two SDs for different paths happen to		from which the selector does not select the user data traffic)
	be presented to the Local Request logic exactly at the same time.		SHALL be considered as having higher priority than the SD on the
			active path (the path from which the selector selects the user
			data traffic) regardless of its origin (local or remote message).
			The LER that has the SD on the standby path SHALL maintain the
			local SD on the standby path request as the top priority global
			request. The other LER that has local SD on the active path SHALL
			use the remote SD on the standby path as the top priority global
			request to lookup the state transition table. The differentiation
			of the active and standby paths is based upon which path had been
			used for the user data traffic at the time just before an LER
			selected its local SD as the top priority global request.
			No Request is another exception to the rule of assigning a remote
			request a priority just below the same local request. Since a
			received NR message needs to be used in the state transition table
			lookup when there is no outstanding local request, the received
			remote NR request SHALL be the top priority global request when there
			is no request in the local LER.
			10.3. Acceptance and retention of local inputs
			A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W,
			SHALL be accepted and retained persistently in the Local Request
			logic as long as the defect condition exists. If there is any higher
			priority local input than the local defect input, the higher priority
			local input is passed to the PSC Control logic as the highest local
			request, but the local defect input cannot be removed but remains in
			the Local Request logic. When the higher priority local input
			disappears, the local defect will become the highest local request if
			the defect condition still exists.
			Operator Clear command, SFDc and WTR Expires are not persistent.
			Once they appear to the Local Request logic and complete the
			operation, they SHALL be disappeared.
			Operator LO, FS, MS, and EXER commands SHALL be rejected if there is
			any higher priority local input in the Local Request logic. If a new
			operator command is accepted, any previous lower-priority local
			operator command SHALL be cancelled. When any higher priority remote
			request is received, a lower-priority local operator command SHALL be
			cancelled. The cancelled operator command is forgotten and will
			never return, unless the operator reissues the command.
	11. State Transition Tables in APS Mode		11. State Transition Tables in APS Mode
	When there is a change in the highest-priority local request or in		When there is a change in the highest local request or in remote PSC
	remote PSC messages, the top priority global request is evaluated and		messages, the top priority global request SHALL be evaluated and the
	the state transition tables are looked up in PSC control logic. The		state transition tables SHALL be looked up in the PSC Control logic.
	following rules are applied to the operation related to the state		The following rules are applied to the operation related to the state
	transition table lookup.		transition table lookup.
	o If the top priority global request, which determines the state		o If the top priority global request, which determines the state
	transition, is the highest priority local input, the local state		transition, is the highest local request, the local state
	transition table SHALL be used to decide the next state of the		transition table in Section 11.1 SHALL be used to decide the next
	LER. Otherwise, remote messages state transition table SHALL be		state of the LER. Otherwise, remote messages state transition
	used.		table in Section 11.2 SHALL be used.
	o If in remote state, the highest local defect condition (SF-P,		o If in remote state, the highest local defect condition (SF-P,
	SF-W, SD-P or SD-W) SHALL always be reflected in the Request Field		SF-W, SD-P or SD-W) SHALL always be reflected in the Request Field
	and Fpath.		and Fpath.
	o Operator Clear command, Clear SF/SD (SFc) and WTR Expires are not
	persistent. Once they appear to the local priority logic and
	complete the operation, they will be disappeared.
	o For the LER currently in the local state, if the top priority		o For the LER currently in the local state, if the top priority
	global request is changed to OC or SFc causing the next state to		global request is changed to OC or SFDc causing the next state to
	be Normal, WTR or DNR, then all the local and remote requests		be Normal, WTR or DNR, then all the local and remote requests
	should be re-evaluated as if the LER is in the state specified in		should be re-evaluated as if the LER is in the state specified in
	the footnotes to the state transition tables, before deciding the		the footnotes to the state transition tables, before deciding the
	final state. This re-evaluation is an internal operation confined		final state. This re-evaluation is an internal operation confined
	within the local LER, and PSC messages are generated according to		within the local LER, and PSC messages are generated according to
	the final state.		the final state.
	o The WTR timer is started only when the LER which has recovered		o The WTR timer is started only when the LER which has recovered
	from a local failure/degradation enters the WTR state. An LER		from a local failure/degradation enters the WTR state. An LER
	which is entering into the WTR state due to a remote WTR message		which is entering into the WTR state due to a remote WTR message
	does not start the WTR timer.		does not start the WTR timer. The WTR timer is stopped when any
			local or remote request triggers the state change out of the WTR
			state.
	The extended states, as they appear in the table, are as follows:		The extended states, as they appear in the table, are as follows:
	N Normal state		N Normal state
	UA:LO:L Unavailable state due to local LO command		UA:LO:L Unavailable state due to local LO command
	UA:P:L Unavailable state due to local SF-P		UA:P:L Unavailable state due to local SF-P
	UA:DP:L Unavailable state due to local SD-P		UA:DP:L Unavailable state due to local SD-P
	UA:LO:R Unavailable state due to remote LO message		UA:LO:R Unavailable state due to remote LO message
	UA:P:R Unavailable state due to remote SF-P message		UA:P:R Unavailable state due to remote SF-P message
	UA:DP:L Unavailable state due to local SD-P		UA:DP:R Unavailable state due to remote SD-P message
	PF:W:L Protecting failure state due to local SF-W		PF:W:L Protecting failure state due to local SF-W
	PF:DW:L Protecting failure state due to local SD-W		PF:DW:L Protecting failure state due to local SD-W
	PF:W:R Protecting failure state due to remote SF-W message		PF:W:R Protecting failure state due to remote SF-W message
	PF:DW:R Protecting failure state due to remote SD-W message		PF:DW:R Protecting failure state due to remote SD-W message
	SA:F:L Switching administrative state due to local FS command		SA:F:L Switching administrative state due to local FS command
	SA:MW:L Switching administrative state due to local MS-W command		SA:MW:L Switching administrative state due to local MS-W command
	SA:MP:L Switching administrative state due to local MS-P command		SA:MP:L Switching administrative state due to local MS-P command
	SA:F:R Switching administrative state due to remote FS message		SA:F:R Switching administrative state due to remote FS message
	SA:MW:R Switching administrative state due to remote MS-W message		SA:MW:R Switching administrative state due to remote MS-W message
	SA:MP:R Switching administrative state due to remote MS-P message		SA:MP:R Switching administrative state due to remote MS-P message
	skipping to change at page 21, line 25		skipping to change at page 23, line 22
	UA:P:R highest local request(local FPath,0)		UA:P:R highest local request(local FPath,0)
	UA:DP:R highest local request(local FPath,0)		UA:DP:R highest local request(local FPath,0)
	PF:W:L SF(1,1)		PF:W:L SF(1,1)
	PF:DW:L SD(1,1)		PF:DW:L SD(1,1)
	PF:W:R highest local request(local FPath,1)		PF:W:R highest local request(local FPath,1)
	PF:DW:R highest local request(local FPath,1)		PF:DW:R highest local request(local FPath,1)
	SA:F:L FS(1,1)		SA:F:L FS(1,1)
	SA:MW:L MS(0,0)		SA:MW:L MS(0,0)
	SA:MP:L MS(1,1)		SA:MP:L MS(1,1)
	SA:F:R highest local request(local FPath,1)		SA:F:R highest local request(local FPath,1)
	SA:MW:R highest local request(local FPath,0)		SA:MW:R NR(0,0)
	SA:MP:R highest local request(local FPath,1)		SA:MP:R NR(0,1)
	WTR WTR(0,1)		WTR WTR(0,1)
	DNR DNR(0,1)		DNR DNR(0,1)
	E::L EXER(0,x), where x is the existing Path value		E::L EXER(0,x), where x is the existing Path value
	when Exercise command is issued.		when Exercise command is issued.
	E::R RR(0,x), where x is the existing Path value		E::R RR(0,x), where x is the existing Path value
	when RR message is generated.		when RR message is generated.
	11.1. State transition by local inputs		Some operation examples of the APS mode are shown in Appendix D.
	| OC | LO | SFc | SF-P | FS | SF-W |		11.1. State transition by local inputs
	--------+-----+---------+-----+--------+--------+--------+		| OC | LO | SFDc | SF-P | FS | SF-W |
	N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		--------+-----+---------+------+--------+--------+--------+
	UA:LO:L | (1) | i | i | i | i | i |		N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	UA:P:L | i | UA:LO:L | (1) | i | i | i |		UA:LO:L | (1) | i | i | i | i | i |
	UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L |		UA:P:L | i | UA:LO:L | (1) | i | i | i |
	UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |		UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L |
	UA:P:R | i | UA:LO:L | i | UA:P:L | PF:W:L | PF:W:L |		UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
	UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
	PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i |		UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L |		PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i |
	PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L |
	PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i |		PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i |
	SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	WTR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	E::L | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |		E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
			E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
	| SD-P | SD-W | MS-W | MS-P | WTRExp | EXER		| SD-P | SD-W | MS-W | MS-P | WTRExp | EXER
	--------+---------+---------+---------+---------+--------+------		--------+---------+---------+---------+---------+--------+------
	N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L		N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
	UA:LO:L | i | i | i | i | i | i		UA:LO:L | i | i | i | i | i | i
	UA:P:L | i | i | i | i | i | i		UA:P:L | i | i | i | i | i | i
	UA:DP:L | i | i | i | i | i | i		UA:DP:L | i | i | i | i | i | i
	UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i		UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i
	UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i		UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i
	UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i		UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i
	skipping to change at page 22, line 35		skipping to change at page 25, line 4
	SA:F:L | i | i | i | i | i | i		SA:F:L | i | i | i | i | i | i
	SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i		SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i
	SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i		SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i
	SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i		SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i
	SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i		SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i
	SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i		SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i
	WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i		WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i
	DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L		DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
	E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i		E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i
	E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L		E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
			NOTES:
	11.2. State transition by remote messages		(1) Re-evaluate to determine final state as if the LER is in the
			Normal state.
			(2) In the case that both local input after SFDc and the last
			received remote message are no requests, the LER enters into the
			WTR state when the domain is configured for revertive behavior,
			or the LER enters into the DNR state when the domain is
			configured for non-revertive behavior. In all the other cases,
			re-evaluate to determine the final state as if the LER is in the
			Normal state.
			(3) Re-evaluate to determine final state as if the LER is in the
			Normal state when the domain is configured for revertive
			behavior, or as if the LER is in the DNR state when the domain
			is configured for non-revertive behavior,
			(4) Remain in WTR and send NR(0,1). Stop the WTR timer if it is
			running.
			(5) If Path value is 0, re-evaluate to determine final state as if
			the LER is in the Normal state. If Path value is 1, re-evaluate
			to determine final state as if the LER is in the DNR state.
			(6) Remain in WTR and send NR(0,1).
			11.2. State transition by remote messages
	| LO | SF-P | FS | SF-W | SD-P | SD-W |		| LO | SF-P | FS | SF-W | SD-P | SD-W |
	--------+---------+--------+--------+--------+---------+---------+		--------+---------+--------+--------+--------+---------+---------+
	N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	UA:LO:L | i | i | i | i | i | i |		UA:LO:L | i | i | i | i | i | i |
	UA:P:L | UA:LO:R | i | i | i | i | i |		UA:P:L | UA:LO:R | i | i | i | i | i |
	UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (10) |		UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) |
	UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R |		UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R |
	PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i |		PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i |
	PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (11) | i |		PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i |
	PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R |		PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R |
	PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i |
	SA:F:L | UA:LO:R | UA:P:R | i | i | i | i |		SA:F:L | UA:LO:R | UA:P:R | i | i | i | i |
	SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R |		SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R |
	SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |		E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
	| MS-W | MS-P | WTR | EXER | RR | DNR | NR		| MS-W | MS-P | WTR | EXER | RR | DNR | NR
	--------+---------+---------+-----+------+----+-----+----		--------+---------+---------+-----+------+----+------+----
	N | SA:MW:R | SA:MP:R | i | E::R | i | i | i		N | SA:MW:R | SA:MP:R | i | E::R | i | i | i
	UA:LO:L | i | i | i | i | i | i | i		UA:LO:L | i | i | i | i | i | i | i
	UA:P:L | i | i | i | i | i | i | i		UA:P:L | i | i | i | i | i | i | i
	UA:DP:L | i | i | i | i | i | i | i		UA:DP:L | i | i | i | i | i | i | i
	UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N		UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
	UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N		UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
	UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N		UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
	PF:W:L | i | i | i | i | i | i | i		PF:W:L | i | i | i | i | i | i | i
	PF:DW:L | i | i | i | i | i | i | i		PF:DW:L | i | i | i | i | i | i | i
	PF:W:R | SA:MW:R | SA:MP:R | (7) | E::R | i | (8) | (5)		PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
	PF:DW:R | SA:MW:R | SA:MP:R | (7) | E::R | i | (8) | (5)		PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
	SA:F:L | i | i | i | i | i | i | i		SA:F:L | i | i | i | i | i | i | i
	SA:MW:L | i | i | i | i | i | i | i		SA:MW:L | i | i | i | i | i | i | i
	SA:MP:L | i | i | i | i | i | i | i		SA:MP:L | i | i | i | i | i | i | i
	SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N		SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N
	SA:MW:R | i | SA:MP:R | i | E::R | i | i | N		SA:MW:R | i | SA:MP:R | i | E::R | i | i | N
	SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N		SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N
	WTR | SA:MW:R | SA:MP:R | i | i | i | i | (9)		WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12)
	DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i		DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i
	E::L | SA:MW:R | SA:MP:R | i | i | i | i | i		E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i
	E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N		E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N
	NOTES:		NOTES:
	(1) Re-evaluate to determine final state as if the LER is in the		(7) If the received SD-W message has Path=0, ignore the message. If
	Normal state.		the received SD-W message has Path=1, go to PF:DW:R state and
			transmit SD(0,1)
	(2) In the case that both local input and the last received remote		(8) If the received SD-P message has Path=1, ignore the message. If
	message are no request after the occurrence of SFc, the LER		the received SD-P message has Path=0, go to UA:DP:R state and
	enters into the WTR state when the domain is configured for		transmit SD(1,0).
	revertive behavior, or the LER enters into the DNR state when
	the domain is configured for non-revertive behavior. In all the
	other cases, re-evaluate to determine the final state as if the
	LER is in the Normal state.
	(3) Re-evaluate to determine final state as if the LER is in the		(9) Transition to WTR state and continue to send the current
	Normal state when the domain is configured for revertive		message.
	behavior, or as if the LER is in the DNR state when the domain
	is configured for non-revertive behavior,
	(4) If Path value is 0, re-evaluate to determine final state as if		(10) Transition to DNR state and continue to send the current
	the LER is in the Normal state. If Path value is 1, re-evaluate		message.
	to determine final state as if the LER is in the DNR state
	(5) If the received NR message has Path=1, transition to WTR if		(11) If the received NR message has Path=1, transition to WTR if
	domain configured for revertive behavior, else transition to		domain configured for revertive behavior, else transition to
	DNR.		DNR. If the received NR message has Path=0, transition to N.
	(6) Remain in WTR, send NR(0,1).		(12) If the receiving LER's WTR timer is running, maintain current
			state and message. If the WTR timer is not running, transition
			to N.
	(7) Transition to WTR state and continue to send the current		(13) Transit to WTR state and send NR(0,1) message. The WTR timer is
	message.		not initiated.
	(8) Transition to DNR state and continue to send the current		11.3. State transition for 1+1 unidirectional protection
	message.
	(9) If the receiving LER's WTR timer is running, maintain current		The state transition tables given in Section 11.1 and Section 11.2
	state and message. If the WTR timer is not running, transition		are for bidirectional protection switching, where remote PSC protocol
	to N.		messages are used to determine the protection switching actions. The
			1+1 unidirectional protection switching does not require the remote
			information in PSC protocol message and acts upon local inputs only.
			The state transition by local inputs in Section 11.1 SHALL be reused
			for the 1+1 unidirectional protection under the following conditions:
	(10) If the active path just before the SD is selected as the highest		o The value of Request field in the received remote message is
	local input was the working path, then ignore. Otherwise, go to		ignored and always assumed to be no request.
	PF:DW:R and transmit SD(0,1)
	(11) If the received SD-P message has Path=1, ignore the message. If		o Replace footnote (4) with "Stop the WTR timer and transit to
	the received SD-P message has Path=0 and the active path just		Normal state."
	before the SD is selected as the highest local input was the
	working path, then go to UA:DP:R and transmit SD(1,0). If the
	received SD-P message has Path=0 and the active path just before
	the SD is selected as the highest local input was the protection
	path, then ignore the received SD-P message.
	12. Security considerations		o Replace footnote (6) with "Transit to Normal state."
	No specific security issue is raised in addition to those ones		o Exercise is not applicable.
	already documented in [RFC6378]
	13. IANA considerations		12. Provisioning mismatch and protocol failure in the APS mode
	13.1. PSC Request Field		The remote PSC message that is received from the remote LER is
			subject to the detection of provisioning mismatch and protocol
			failure conditions. In the APS mode, provisioning mismatches are
			handled as follows:
	This document defines two new values in the "MPLS PSC Request		o If the PSC message is received from the working path due to
	Registry".		working/protection path configuration mismatch, the node MUST
			alert the operator and MUST NOT perform any protection switching.
	The PSC Request Field is 4 bits, and the two new values have been		o If the "Protection Type (PT)" field mismatches and two sides are
	allocated as follows:		unable to converge as described in Section 5.1 in
			[I-D.ietf-mpls-psc-updates], the node MUST alert the operator and
			MUST NOT perform any protection switching.
	Value Description Reference		o If the "Revertive (R)" bit mismatches, two sides will interwork
	----- --------------------- ---------------		and traffic is protected in the APS mode. The node MAY notify the
	TBD1 Reverse Request [this document]		operator of this event.
	TBD2 Exercise [this document]
	[to be removed upon publication: It is requested to assign 2		o If the Capabilities TLV mismatches, the node MUST alert the
	(=TBD1)for the Reverse Request value and 3 (=TBD2) for the Exercise		operator and MUST NOT perform any protection switching.
	value to be aligned with the priority levels of those two requests
	defined in this document.]
	13.2. PSC TLV		The followings are the protocol failure situations and the actions to
			be taken:
			o No match in sent "Data Path (Path)" and received "Data Path
			(Path)" for more than 50 ms: The node MAY continue to perform
			protection switching and SHOULD notify the operator of these
			events:
			o No PSC message is received on the protection path during at least
			3.5 times the long PSC message interval (e.g. at least 17.5
			seconds) and there is no defect on the protection path (The
			Capabilities TLV Timeout error specifies in Section 9.1.3 is
			included in this situation.): The node MUST alert the operator and
			MUST NOT perform any protection switching.
			13. Security considerations
			No specific security issue is raised in addition to those ones
			already documented in RFC 6378 [RFC6378]
			14. IANA considerations
			14.1. MPLS PSC Request Registry
			In the "Multiprotocol Label Switching (MPLS) Operations,
			Administration, and Management (OAM) Parameters" registry, IANA
			maintains the "MPLS PSC Request Registry".
			IANA is requested to assign two new code points from this registry.
			The values shall be allocated as follows:
			Value Description Reference
			----- --------------------- ---------------
			2 Reverse Request (this document)
			3 Exercise (this document)
			14.2. MPLS PSC TLV Registry
			In the "Multiprotocol Label Switching (MPLS) Operations,
			Administration, and Management (OAM) Parameters" registry, IANA
			maintains the "MPLS PSC TLV Registry".
	This document defines a new value for the Capabilities TLV type in		This document defines a new value for the Capabilities TLV type in
	the "MPLS PSC TLV Registry".		the "MPLS PSC TLV Registry".
	Type TLV Name Reference		Value Description Reference
	----- --------------------- ---------------		------ --------------------- ---------------
	TBD3 Capabilities [this document]		TBD Capabilities (this document)
	[Editor's note: Need to specify a registry for Value (=options)		14.3. MPLS PSC Capability Flag Registry
	inside the Capabilities TLV in a later version of this draft]
	14. Acknowledgements		IANA is requested to create and maintain a new registry within the
			"Multiprotocol Label Switching (MPLS) Operations, Administration, and
			Management (OAM) Parameters" registry called "MPLS PSC Capability
			Flag Registry". All flags within this registry SHALL be allocated
			according to the "Standards Action" procedures as specified in RFC
			5226 [RFC5226].
	15. References		The length of the flags MUST be a multiple of 4 octets. This
			document defines 4 octet flags. Flags greater than 4 octets SHALL be
			used only if more than 32 Capabilities need to be defined. Flags
			defined in this document are:
	15.1. Normative References		Bit Hex Value Capability Reference
			---- ---------- ----------------------------------- ---------------
			0 0x80000000 priority modification (this document)
			1 0x40000000 non-revertive behavior modification (this document)
			2 0x20000000 support of MS-W command (this document)
			3 0x10000000 support of protection against SD (this document)
			4 0x08000000 support of EXER command (this document)
			5-31 Unassigned (this document)
			15. Acknowledgements
			16. References
			16.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,		[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
	and S. Ueno, "Requirements of an MPLS Transport Profile",		and S. Ueno, "Requirements of an MPLS Transport Profile",
	RFC 5654, September 2009.		RFC 5654, September 2009.
	[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and		[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
	A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear		A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
	Protection", RFC 6378, October 2011.		Protection", RFC 6378, October 2011.
	[I-D.ietf-mpls-psc-updates]		[I-D.ietf-mpls-psc-updates]
	Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-		Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
	updates-00 (work in progress), October 2013.		updates-00 (work in progress), October 2013.
	15.2. Informative References		16.2. Informative References
	[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and		[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
	Restoration) Terminology for Generalized Multi-Protocol		Restoration) Terminology for Generalized Multi-Protocol
	Label Switching (GMPLS)", RFC 4427, March 2006.		Label Switching (GMPLS)", RFC 4427, March 2006.
	[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-		[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
	TP) Survivability Framework", RFC 6372, September 2011.		TP) Survivability Framework", RFC 6372, September 2011.
			[G841] International Telecommunications Union, "Types and
			characteristics of SDH network protection architectures",
			ITU-T Recommendation G.841, October 1998.
			[G873.1] International Telecommunications Union, "Optical Transport
			Network (OTN): Linear protection", ITU-T Recommendation
			G.873.1, July 2011.
			[G8031] International Telecommunications Union, "Ethernet Linear
			Protection Switching", ITU-T Recommendation G.8031/Y.1342,
			June 2011.
	Appendix A. An example of out-of-service scenarios		Appendix A. An example of out-of-service scenarios
	The sequence diagram shown is an example of the out-of-service		The sequence diagram shown is an example of the out-of-service
	scenerios based on the priority level defined in [RFC6378]. The		scenarios based on the priority level defined in RFC 6378. The first
	first PSC message which differs from the previous PSC message is		PSC message which differs from the previous PSC message is shown.
	shown.
	A Z		A Z
	| |		| |
	(1) |-- NR(0,0) ------>| (1)		(1) |-- NR(0,0) ------>| (1)
	|<----- NR(0,0) ---|		|<----- NR(0,0) ---|
	| |		| |
	| |		| |
	| (FS issued at Z) | (2)		| (FS issued at Z) | (2)
	(3) |<------ FS(1,1) --|		(3) |<------ FS(1,1) --|
	|-- NR(0,1) ------>|		|-- NR(0,1) ------>|
	| |		| |
	| |		| |
	(4) | (SF on P(A<-Z)) |		(4) | (SF on P(A<-Z)) |
	| |		| |
	| |		| |
	| (Clear FS at Z) | (5)		| (Clear FS at Z) | (5)
	(6) | X <- NR(0,0) --|		(6) | X <- NR(0,0) --|
	| |		| |
	| |		| |
	(1) Each end is in Normal state, and transmits NR (0,0) messages.		(1) Each end is in the Normal state, and transmits NR(0,0) messages.
	(2) When a Forced Switch command is issued at node Z, node Z goes		(2) When a FS command is issued at node Z, node Z goes into local
	into local Protecting Administrative state (PA:F:L) and begins		Protecting administrative state (PA:F:L) and begins transmission of
	transmission of an FS (1,1) messages.		an FS(1,1) messages.
	(3) A remote Forced Switch message causes node A to go into remote		(3) A remote FS message causes node A to go into remote Protecting
	Protecting Administrative state (PA:F:R), and node A begins		administrative state (PA:F:R), and node A begins transmitting NR(0,1)
	transmitting NR (0,1) messages.		messages.
	(4) When node A detects a unidirectional Signal Fail on the		(4) When node A detects a unidirectional SF-P, node A keeps sending
	Protection path, node A keeps sending NR (0,1) message because SF-P		NR(0,1) message because SF-P is ignored under the PA:F:R state.
	is ignored under the state PA:F:R.
	(5) When a Clear command is issued at node Z, node Z goes into Normal		(5) When a Clear command is issued at node Z, node Z goes into the
	state and begins transmission of NR (0,0) messages.		Normal state and begins transmission of NR(0,0) messages.
	(6) But node A cannot receive PSC message because of local		(6) But, node A cannot receive PSC message because of local
	unidirectional Signal Fail on the Protection path. Because no valid		unidirectional SF-P. Because no valid PSC message is received, over
	PSC message is received, over a period of several successive message		a period of several successive message intervals, the last valid
	intervals, the last valid received message remains applicable and the		received message remains applicable and the node A continue to
	node A continue to transmit an NR (0,1) message in the state of		transmit an NR(0,1) message in the PA:F:R state.
	PA:F:R.
	Now, there exists a mismatch between the bridge/selector positions of		Now, there exists a mismatch between the bridge/selector positions of
	node A (transmitting an NR (0,1)) and node Z (transmitting an NR		node A (transmitting an NR(0,1)) and node Z (transmitting an
	(0,0)). It results in out-of-service even when there is neither		NR(0,0)). It results in out-of-service even when there is neither
	signal fail on working path nor FS.		SF-W nor FS.
	Appendix B. An example of sequence diagram showing the problem with the		Appendix B. An example of sequence diagram showing the problem with the
	priority level of Clear SF		priority level of SFc
	An example of sequence diagram showing the problem with the priority		An example of sequence diagram showing the problem with the priority
	level of Clear SF defined in [RFC6378] is given below. The following		level of SFc defined in RFC 6378 is given below. The following
	sequence diagram is depicted for the case of bidirectional signal		sequence diagram is depicted for the case of bidirectional signal
	fails. However, other cases with unidirectional signal fails can		fails. However, other cases with unidirectional signal fails can
	result in the same problem. The first PSC message which differs from		result in the same problem. The first PSC message which differs from
	the previous PSC message is shown.		the previous PSC message is shown.
	A Z		A Z
	| |		| |
	(1) |-- NR(0,0) ------>| (1)		(1) |-- NR(0,0) ------>| (1)
	|<----- NR(0,0) ---|		|<----- NR(0,0) ---|
	| |		| |
	| |		| |
	(2) | (SF on P(A<->Z)) | (2)		(2) | (SF on P(A<->Z)) | (2)
	|-- SF(0,0) ------>|		|-- SF(0,0) ------>|
	|<------ SF(0,0) --|		|<------ SF(0,0) --|
	| |		| |
	| |		| |
	(3) | (SF on W(A<->Z)) | (3)		(3) | (SF on W(A<->Z)) | (3)
	| |		| |
	| |		| |
	(4) | (Clear SF-P) | (4)		(4) | (Clear SF-P) | (4)
	| |		| |
	| |		| |
	(5) | (Clear SF-W) | (5)		(5) | (Clear SF-W) | (5)
	| |		| |
	| |		| |
	(1) Each end is in Normal state, and transmits NR (0,0) messages.		(1) Each end is in the Normal state, and transmits NR(0,0) messages.
	(2) When signal fail on protection (SF-P) occurs, each node enters		(2) When SF-P occurs, each node enters into the UA:P:L state and
	into [UA:P:L] state and transmits SF (0,0) messages. Traffic remains		transmits SF(0,0) messages. Traffic remains on the working path.
	on working path.
	(3) When signal fail on working (SF-W) occurs, each node remains in		(3) When SF-W occurs, each node remains in the UA:P:L state as SF-W
	[UA:P:L] state as SF-W has a lower priority than SF-P. Traffic is		has a lower priority than SF-P. Traffic is still on the working
	still on the working path. Traffic cannot be delivered as both		path. Traffic cannot be delivered as both the working path and the
	working and protection paths are experiencing signal fails.		protection path are experiencing signal fails.
	(4) When the signal fail on protection is cleared, local "Clear SF-P"		(4) When SF-P is cleared, local "Clear SF-P" request cannot be
	request cannot be presented to the PSC control logic, which takes the		presented to the PSC Control logic, which takes the highest local
	highest priority local request and runs PSC state machine, as the		request and runs PSC state machine, since the priority of "Clear
	priority of "Clear SF-P" is lower than that of SF-W. Consequently,		SF-P" is lower than that of SF-W. Consequently, there is no change
	there is no change in state, and the selector and/or bridge keep		in state, and the selector and/or bridge keep pointing at the working
	pointing at the working path, which has signal fail condition.		path, which has signal fail condition.
	Now, traffic cannot be delivered while the protection path is		Now, traffic cannot be delivered while the protection path is
	recovered and available. It should be noted that the same problem		recovered and available. It should be noted that the same problem
	will occur in the case that the sequence of SF-P and SF-W events is		will occur in the case that the sequence of SF-P and SF-W events is
	changed.		changed.
	If we further continue with this sequence to see what will happen		If we further continue with this sequence to see what will happen
	after SF-W is cleared,		after SF-W is cleared,
	(5) When the signal fail on working is cleared, local "Clear SF-W"		(5) When SF-W is cleared, local "Clear SF-W" request can be passed to
	request can be passed to the PSC control logic (state machine) as		the PSC Control logic as there is no higher priority local input, but
	there is no higher priority local request, but this will be ignored		this will be ignored in the PSC Control logic according to the state
	in the PSC control logic according to the state transition definition		transition definition in RFC 6378. There will be no change in state
	in [RFC6378]. There will be no change in state or protocol message		or protocol message transmitted.
	transmitted.
	As the signal fail on working is now cleared and the selector and/or		As SF-W is now cleared and the selector and/or bridge are still
	bridge are still pointing at the working path, traffic delivery is		pointing at the working path, traffic delivery is resumed. However,
	resumed. However, each node is in [UA:P:L] state and transmitting		each node is the in UA:P:L state and transmitting SF(0,0) message,
	SF(0,0) message, while there exists no outstanding request for		while there exists no outstanding request for protection switching.
	protection switching. Moreover, any future legitimate protection		Moreover, any future legitimate protection switching requests, such
	switching requests, such as SF-W, will be rejected as each node		as SF-W, will be rejected as each node thinks the protection path is
	thinks the protection path is unavailable.		unavailable.
	Appendix C. Freeze Command		Appendix C. Freeze Command
	The "Freeze" command applies only to the near end (local node) of the		The "Freeze" command applies only to the local LER of the protection
	protection group and is not signalled to the far end. This command		group and is not signaled to the remote LER. This command freezes
	freezes the state of the protection group. Until the Freeze is		the state of the protection group. Until the Freeze is cleared,
	cleared, additional near end commands are rejected and condition		additional local commands are rejected and condition changes and
	changes and received PSC information are ignored.		received PSC information are ignored.
	"Clear Freeze" command clears the local freeze. When the Freeze		"Clear Freeze" command clears the local freeze. When the Freeze
	command is cleared, the state of the protection group is recomputed		command is cleared, the state of the protection group is recomputed
	based on the persistent condition of the local triggers.		based on the persistent condition of the local triggers.
	Because the freeze is local, if the freeze is issued at one end only,		Because the freeze is local, if the freeze is issued at one end only,
	a failure of protocol can occur as the other end is open to accept		a failure of protocol can occur as the other end is open to accept
	any operator command or a fault condition.		any operator command or a fault condition.
			Appendix D. Operation examples of the APS mode
			The sequence diagrams shown in this section are only a few examples
			of the APS mode operations. The first PSC protocol message which
			differs from the previous message is shown. The operation of hold-
			off timer is omitted. The Request, FPath and Path fields, whose
			values are changed during PSC message exchange are shown. For an
			example, SF(1, 0) represents an PSC message with the following field
			values: Request = SF, FPath = 1, and Path = 1. The values of the
			other fields remain unchanged from the initial configuration.
			W(A->Z) and P(A->Z) indicate the working path and the protection path
			in the direction of A to Z, respectively.
			Example 1. 1:1 bidirectional protection switching (revertive mode) -
			Unidirectional SF case
			A Z
			| |
			(1) |<---- NR(0,0)---->| (1)
			| |
			| |
			(2) | (SF on W(Z->A)) |
			|---- SF(1,1)----->| (3)
			(4) |<----- NR(0,1)----|
			| |
			| |
			(5) | (Clear SF-W) |
			|---- WTR(0,1)---->|
			/| |
			| | |
			WTR timer | |
			| | |
			\| |
			(6) |---- NR(0,1)----->| (7)
			(8) |<----- NR(0,0)----|
			|---- NR(0,0)----->| (9)
			| |
			(1) The protection domain is operating without any defect, and the
			working path is used for delivering the traffic in the Normal state.
			(2) SF-W occurs in the Z to A direction. Node A enters into the
			PF:W:L state and generates SF(1, 1) message. Selector and bridge of
			node A are pointing at the protection path.
			(3) Upon receiving SF(1, 1), node Z sets selector and bridge to the
			protection path. As there is no local request in node Z, node Z
			generates NR(0, 1) message in the PF:W:R state.
			(4) Node A confirms that the remote LER is also selecting protection
			path.
			(5) Node A detects clearing of SF condition, starts the WTR timer,
			and sends WTR(0, 1) message in the WTR state.
			(6) At expiration of the WTR timer, node A sets selector and bridge
			to the working path and sends NR(0, 1) message.
			(7) Node Z is notified that the remote request has been cleared.
			Node Z transits to the Normal state and sends NR(0,0) message.
			(8) Upon receiving NR(0,0) message, node A transits to the Normal
			state and sends NR(0,0) message.
			(9) It is confirmed that the remote LER is also selecting the working
			path.
			Example 2. 1:1 bidirectional protection switching (revertive mode) -
			Bidirectional SF case - Inconsistent WTR timers
			A Z
			| |
			(1) |<---- NR(0,0)---->| (1)
			| |
			| |
			(2) | (SF on W(A<->Z)) | (2)
			|<---- SF(1,1)---->|
			| |
			| |
			(3) | (Clear SF-W) | (3)
			|<---- NR(0,1)---->|
			(4) |<--- WTR(0,1) --->| (4)
			/| |\
			| | | |
			WTR timer | | WTR timer
			| | | |
			| | |/
			| |<------ NR(0,1)---| (5)
			| | |
			\| |
			(6) |--- NR(0,1)------>|
			|<------ NR(0,0)---| (7)
			(8) |--- NR(0,0)------>|
			| |
			(1) Each end is in the Normal state, and transmits NR(0,0) messages.
			(2) When SF-W occurs, each node enters into the PF:W:L state and
			transmits SF(1,1) messages. Traffic is switched to the protection
			path. Upon receiving SF(1,1), each node confirms that the remote LER
			is also sending and receiving the traffic from the protection path.
			(3) When SF-W is cleared, each node transits to the PF:W:R state and
			transmits NR(0,1) messages as the last received message is SF-W.
			(4) Upon receiving NR(0,1) messages, each node goes into the WTR
			state, starts the WTR timer, and sends the WTR(0,1) messages.
			(5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as
			the last received APS message was WTR. When NR(0,1) arrives at node
			A, node A maintains the WTR state and keeps sending current WTR
			messages as described in the state transition table.
			(6) At expiration of the WTR timer in node A, node A sends NR(0,1).
			(7) When the NR(0,1) message arrives at node Z, node Z moves to the
			Normal state, sets selector and bridge to the working path, and sends
			NR(0, 0) message.
			(8) The received NR(0,0) message causes node A to go to the Normal
			state. Now, the traffic is switched back to the working path.
			Example 3. 1:1 bidirectional protection switching - R bit mismatch
			This example shows that both sides will interwork and the traffic is
			protected when one side (node A) is configured as revertive mode and
			the other (node Z) is configured as non-revertive mode. The
			interworking is covered in the state transition tables.
			(revertive) A Z (non-revertive)
			| |
			(1) |<---- NR(0,0)---->| (1)
			| |
			| |
			(2) | (SF on W(A<->Z)) | (2)
			|<---- SF(1,1)---->|
			| |
			| |
			(3) | (Clear SF-W) | (3)
			|<---- NR(0,1)---->|
			(4) |<----- DNR(0,1)---| (4)
			/|-- WTR(0,1)------>|
			| |<----- NR(0,1)----| (5)
			| | |
			WTR timer | |
			| | |
			| | |
			\| |
			(6) |--- NR(0,1)------>|
			|<------ NR(0,0)---| (7)
			(8) |--- NR(0,0)------>|
			| |
			(1) Each end is in the Normal state, and transmits NR(0,0) messages.
			(2) When SF-W occurs, each node enters into the PF:W:L state and
			transmits SF(l,l) messages. Traffic is switched to the protection
			path. Upon receiving SF(1,1), each node confirms that the remote LER
			is also sending and receiving the traffic on the protection path.
			(3) When SF-W is cleared, each node transits to the PF:W:R state and
			transmits NR(0,1) messages as the last received message is SF-W.
			(4) Upon receiving NR(0,1) messages, node A goes into the WTR state,
			starts the WTR timer, and sends WTR(0,1) messages. At the same time,
			node B transits to the DNR state and sends DNR(0,1) message.
			(5) When the WTR message arrives at node Z, node Z transits to the
			WTR state and send NR(0,1) message according to the state transition
			table. At the same time, the DNR message arrived at node Z is
			ignored according to the state transition table. Therefore, node Z,
			which is configured as non-revertive mode, is operating as if in
			revertive mode.
			(6) At expiration of the WTR timer in node A, node A sends NR(0,1).
			(7) When the NR(0,1) message arrives at node Z, node Z moves to the
			Normal state, sets selector and bridge to the working path, and sends
			NR(0, 0) message.
			(8) The received NR(0,0) message causes node A to transits to the
			Normal state. Now, the traffic is switched back to the working path.
	Authors' Addresses		Authors' Addresses
	Jeong-dong Ryoo (editor)		Jeong-dong Ryoo (editor)
	ETRI		ETRI
	218 Gajeongno		218 Gajeongno
	Yuseong-gu, Daejeon 305-700		Yuseong-gu, Daejeon 305-700
	South Korea		South Korea
	Phone: +82-42-860-5384		Phone: +82-42-860-5384
	Email: ryoo@etri.re.kr		Email: ryoo@etri.re.kr
End of changes. 199 change blocks.
	657 lines changed or deleted		973 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/