draft-ietf-mpls-tp-psc-itu-03.txt		draft-ietf-mpls-tp-psc-itu-04.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: August 28, 2014 H. van Helvoort		Expires: September 29, 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.
	February 24, 2014		March 28, 2014
	MPLS Transport Profile (MPLS-TP) Linear Protection to Match the		MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
	Operational Expectations of SDH, OTN and Ethernet Transport Network		Operational Expectations of SDH, OTN and Ethernet Transport Network
	Operators		Operators
	draft-ietf-mpls-tp-psc-itu-03.txt		draft-ietf-mpls-tp-psc-itu-04.txt
	Abstract		Abstract
	This document describes alternate mechanisms to perform some of the		This document describes alternate mechanisms to perform some of the
	functions of MPLS Transport Profile (MPLS-TP) linear protection		functions of MPLS Transport Profile (MPLS-TP) linear protection
	defined in RFC 6378, and also defines additional mechanisms. The		defined in RFC 6378, and also defines additional mechanisms. The
	purpose of these alternate and additional mechanisms is to provide		purpose of these alternate and additional mechanisms is to provide
	operator control and experience that more closely models the behavior		operator control and experience that more closely models the behavior
	of linear protection seen in other transport networks.		of linear protection seen in other transport networks.
	skipping to change at page 2, line 15		skipping to change at page 2, line 15
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 28, 2014.		This Internet-Draft will expire on September 29, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 39		skipping to change at page 2, line 39
	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 . . . . . . . . . . . . . . 5		2. Conventions Used in This Document . . . . . . . . . . . . . . 5
	3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Capability 1: Priority Modification . . . . . . . . . . . . . 6		4. Capability 1: Priority Modification . . . . . . . . . . . . . 6
	4.1. Motivation for swapping priorities of FS and SF-P . . . . 6		4.1. Motivation for swapping priorities of FS and SF-P . . . . 6
	4.2. Motivation for raising the priority of SFc . . . . . . . 6		4.2. Motivation for raising the priority of SFc . . . . . . . 7
	4.3. Motivation for introducing Freeze command . . . . . . . . 7		4.3. Motivation for introducing Freeze command . . . . . . . . 7
	4.4. Procedures in support of Capability 1 . . . . . . . . . . 7		4.4. Procedures in support of priority modification . . . . . 7
	5. Capability 2: Non-revertive Behavior Modification . . . . . . 7		5. Capability 2: Non-revertive Behavior Modification . . . . . . 8
	6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8		6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8
	6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8		6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8
	6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 8		6.2. Terminology 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 . . . . . . . . . . . . 9		6.4. Equal priority resolution for MS . . . . . . . . . . . . 10
	7. Capability 4: Support of Protection against SD . . . . . . . 9		7. Capability 4: Support of Protection against SD . . . . . . . 10
	7.1. Motivation for supporting protection against SD . . . . . 9		7.1. Motivation for supporting protection against SD . . . . . 10
	7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10		7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10
	7.3. Behavior of protection against SD . . . . . . . . . . . . 10		7.3. Behavior of protection against SD . . . . . . . . . . . . 11
	7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11		7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12
	8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13		8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13
	9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13		9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14
	9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14		9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
	9.1.1. Sending and receiving the Capabilities TLV . . . . . 15		9.1.1. Sending and receiving the Capabilities TLV . . . . . 15
	9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 15		9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16
	9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16		9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16
	10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16		10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16
	10.1. Request field in PSC protocol message . . . . . . . . . 16		10.1. Request field in PSC protocol message . . . . . . . . . 16
	10.2. Priorities of local inputs and remote requests . . . . . 16		10.2. Priorities of local inputs and remote requests . . . . . 17
	10.2.1. Equal priority requests . . . . . . . . . . . . . . 18		10.2.1. Equal priority requests . . . . . . . . . . . . . . 18
	10.3. Acceptance and retention of local inputs . . . . . . . . 19		10.3. Acceptance and retention of local inputs . . . . . . . . 19
	11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19		11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20
	11.1. State transition by local inputs . . . . . . . . . . . . 21		11.1. State transition by local inputs . . . . . . . . . . . . 22
	11.2. State transition by remote messages . . . . . . . . . . 23		11.2. State transition by remote messages . . . . . . . . . . 24
	11.3. State transition for 1+1 unidirectional		11.3. State transition for 1+1 unidirectional
	protection . . . . . . . . . . . . . . . . . . . . . . . 25		protection . . . . . . . . . . . . . . . . . . . . . . . 26
	12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 26		12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 27		13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 27		14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28
	14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 27		14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28
	14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 27		14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	16.1. Normative References . . . . . . . . . . . . . . . . . . 28		16.1. Normative References . . . . . . . . . . . . . . . . . . 29
	16.2. Informative References . . . . . . . . . . . . . . . . . 28		16.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. An Example of Out-of-service Scenarios . . . . . . . 29		Appendix A. An Example of Out-of-service Scenarios . . . . . . . 30
	Appendix B. An Example of Sequence Diagram Showing		Appendix B. An Example of Sequence Diagram Showing
	the Problem with the Priority Level of SFc . . . . . 30		the Problem with the Priority Level of SFc . . . . . 31
	Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 32		Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33
	Appendix D. Operation Examples of the APS Mode . . . . . . . . . 32		Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP)		Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP)
	are described in RFC 6378 [RFC6378] to meet the requirements		are described in RFC 6378 [RFC6378] to meet the requirements
	described in RFC 5654 [RFC5654].		described in RFC 5654 [RFC5654].
	This document describes alternate mechanisms to perform some of the		This document describes alternate mechanisms to perform some of the
	functions of linear protection, and also defines additional		functions of linear protection, and also defines additional
	mechanisms. The purpose of these alternate and additional mechanisms		mechanisms. The purpose of these alternate and additional mechanisms
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	logic, the PSC state machine and the PSC message generation and		logic, the PSC state machine and the PSC message generation and
	reception, and the integrity of the protection path, without		reception, and the integrity of the protection path, without
	triggering the actual traffic switching.		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.
			Other modes may be defined as new combinations of the capabilities
			defined in this document or through the definition of additional
			capabilities. In either case, the specification defining a new mode
			will be responsible for documenting the behavior, the priority logic,
			and the state machine of the PSC protocol when the set of
			capabilities in the new mode are enabled.
	This document describes the behavior, the priority logic, and the		This document describes the behavior, the priority logic, and the
	state machine of the PSC protocol when all the capabilities		state machine of the PSC protocol when all the capabilities
	associated with the APS mode are enabled. The PSC protocol behavior		associated with the APS mode are enabled. The PSC protocol behavior
	for the PSC mode is as defined in [RFC6378].		for the PSC mode is as defined in [RFC6378].
	This document updates [RFC6378] by adding a capability advertisement		This document updates [RFC6378] by adding a capability advertisement
	mechanism. It is recommended that existing implementations of the		mechanism. It is recommended that existing implementations of the
	PSC protocol be updated to support this capability. Backward		PSC protocol be updated to support this capability. Backward
	compatibility with existing implementations is described in		compatibility with existing implementations that do not support this
	Section 9.2.1.		mechanism is described in Section 9.2.1.
			Implementations are expected to be configured to support a specific
			set of capabilities (a mode) and to reject messages that indicate the
			use of a different set of capabilities (a different mode). Thus, the
			capabilities advertisement is not a negotiation, but a verification
			that peers are using the same mode.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [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		DNR Do-not-Revert
	EXER Exercise		EXER Exercise
	FS Forced Switch		FS Forced Switch
	LO Lockout of protection		LO Lockout of protection
	MS Manual Switch		MS Manual Switch
	MS-P Manual Switch to Protection path		MS-P Manual Switch to Protection path
	MS-W Manual Switch to Working path		MS-W Manual Switch to Working path
	skipping to change at page 7, line 20		skipping to change at page 7, line 46
	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 case network operators need an option to		Administrative state. In case network operators need an option to
	control their networks so that the traffic can remain on the		control their networks so that the traffic can remain on the
	protection path even when the PSC communication channel is broken,		protection path even when the PSC communication channel is broken,
	the Freeze command can be used. Freeze is defined to be a "local"		the Freeze command can be used. Freeze is defined to be a "local"
	command that is not signaled to the remote node. The use of the		command that is not signaled to the remote node. The use of the
	Freeze command is described in Appendix C.		Freeze command is described in Appendix C.
	4.4. Procedures in support of Capability 1		4.4. Procedures in support of priority modification
	When the modified priorities specified in this document is in use,		When the modified priority order specified in this document is in
	the list of local requests in order of priority SHALL be as follows:		use, the list of local requests in order of priority SHALL be as
			follows:
	(from highest to lowest)		(from highest to lowest)
	o Clear Signal Fail		o Clear Signal Fail
	o Signal Fail on Protection path		o Signal Fail on Protection path
	o Forced Switch		o Forced Switch
	o Signal Fail on Working path		o Signal Fail on Working path
	skipping to change at page 8, line 18		skipping to change at page 8, line 44
	state machine) relative to that described in [RFC6378]. Sections 10		state machine) relative to that described in [RFC6378]. Sections 10
	and 11 present the PSC Control Logic when all capabilities of APS		and 11 present the PSC Control Logic when all capabilities of APS
	mode are enabled.		mode are enabled.
	6. Capability 3: Support of MS-W Command		6. Capability 3: Support of MS-W Command
	6.1. Motivation for adding MS-W		6.1. Motivation for adding MS-W
	Changing the non-revertive operation as described in Section 5		Changing the non-revertive operation as described in Section 5
	introduces necessity of a new operator command to revert traffic to		introduces necessity of a new operator command to revert traffic to
	the working path when in the DNR state. When the traffic is on the		the working path in the DNR state. When the traffic is on the
	protection path in the DNR state, a Manual Switch to Working (MS-W)		protection path in the DNR state, a Manual Switch to Working (MS-W)
	command is issued to switch the normal traffic back to the working		command is issued to switch the normal traffic back to the working
	path. According to Section 4.3.3.6 (Do-not-Revert State) in		path. According to Section 4.3.3.6 (Do-not-Revert State) in
	[RFC6378], "to revert back to the Normal state, the administrator		[RFC6378], "to revert back to the Normal state, the administrator
	SHALL issue a Lockout of protection (LO) command followed by a Clear		SHALL issue a Lockout of protection (LO) command followed by a Clear
	command." However, using LO command introduces the potential risk of		command." However, using LO command introduces the potential risk of
	an unprotected situation while the LO is in effect.		an unprotected situation while the LO is in effect.
	Manual Switch-over for recovery LSP/span command is defined in		Manual Switch-over for recovery LSP/span command is defined in
	[RFC4427]. Requirement 83 in [RFC5654] states that the external		[RFC4427]. Requirement 83 in [RFC5654] states that the external
	commands defined in [RFC4427] MUST be supported. Since there is no		commands defined in [RFC4427] MUST be supported. Since there is no
	support for this external command in [RFC6378], this functionality		support for this external command in [RFC6378], this functionality
	should be added to PSC. This support is provided by introducing the		should be added to PSC. This support is provided by introducing the
	MS-W command. The MS-W command, as described here, corresponds to		MS-W command. The MS-W command, as described here, corresponds to
	the "Manual Switch- over for recovery LSP/span" command.		the "Manual Switch-over for recovery LSP/span" command.
	6.2. Terminology to support MS-W		6.2. Terminology to support MS-W
	[RFC6378] uses the term "Manual Switch" and its acronym "MS". This		[RFC6378] uses the term "Manual Switch" and its acronym "MS". This
	document uses the term "Manual Switch to Protection path" and "MS-P"		document uses the term "Manual Switch to Protection path" and "MS-P"
	to have the same meaning, while avoiding confusion with "Manual		to have the same meaning, while avoiding confusion with "Manual
	Switch to Working path" and its acronym "MS-W".		Switch to Working path" and its acronym "MS-W".
	Similarly, we modify the name of "Protecting Administrative" state		Similarly, we modify the name of "Protecting Administrative" state
	(as defined in [RFC6378]) to be "Switching Administrative" state to		(as defined in [RFC6378]) to be "Switching Administrative" state to
	include the case where traffic is switched to the working path as a		include the case where traffic is switched to the working path as a
	result of the external MS-W command.		result of the external MS-W command.
	6.3. Behavior of MS-P and MS-W		6.3. Behavior of MS-P and MS-W
	MS-P and MS-W SHALL have the same priority. We consider different		MS-P and MS-W SHALL have the same priority. We consider different
	instances of determining the priority of the commands when they are		instances of determining the priority of the commands when they are
	received either in succession or simultaneously.		received either in succession or simultaneously.
	o When two commands are received in succession, the command that is		o When two commands are received in succession, the command that is
	received after the initial command is accepted SHALL be cancelled.		received after the initial command SHALL be cancelled.
	o If two nodes simultaneously receive commands that indicate		o If two nodes simultaneously receive commands that indicate
	opposite operations (i.e., one node receives MS-P and the other		opposite operations (i.e., one node receives MS-P and the other
	node receives MS-W) and transmit the indications to the remote		node receives MS-W) and transmit the indications to the remote
	node, the MS-W SHALL be considered to have a higher priority, and		node, the MS-W SHALL be considered to have a higher priority, and
	the MS-P SHALL be cancelled and discarded.		the MS-P SHALL be cancelled and discarded.
	Two commands, MS-P and MS-W are transmitted using the same Request		Two commands, MS-P and MS-W are transmitted using the same Request
	field value, but SHALL indicate in the Fault Path (FPath) value the		field value, but SHALL indicate in the Fault Path (FPath) value the
	path that the traffic is being diverted from. When traffic is		path that the traffic is being diverted from. When traffic is
	skipping to change at page 10, line 45		skipping to change at page 11, line 23
	transport networks (such as SDH, OTN, and Ethernet transport		transport networks (such as SDH, OTN, and Ethernet transport
	networks) we define the followings:		networks) we define the followings:
	o The priorities of SD-P and SD-W SHALL be equal.		o The priorities of SD-P and SD-W SHALL be equal.
	o Once a switch has been completed due to SD on one path, it will		o Once a switch has been completed due to SD on one path, it will
	not be overridden by SD on the other path (first come, first		not be overridden by SD on the other path (first come, first
	served behavior), to avoid protection switching that cannot		served behavior), to avoid protection switching that cannot
	improve signal quality.		improve signal quality.
	The SD message indicates that the transmitting node has identified a		The SD message indicates that the transmitting node has identified
	degradation of the signal, or integrity of the packet transmission on		degradation of the signal or integrity of the packet received on
	either the working path or the protection path. The FPath field		either the working path or the protection path. The FPath field
	SHALL identify the path that is reporting the degraded condition		SHALL identify the path that is reporting the degraded condition
	(i.e., if the protection path, then FPath is set to 0; if the working		(i.e., if the protection path, then FPath is set to 0; if the working
	path, then FPath is set to 1), and the Path field SHALL indicate		path, then FPath is set to 1), and the Path field SHALL indicate
	where the data traffic is being transported (i.e., if the working		where the data traffic is being transported (i.e., if the working
	path is selected, then Path is set to 0; if the protection path is		path is selected, then Path is set to 0; if the protection path is
	selected, then Path is set to 1).		selected, then Path is set to 1).
	When the SD condition is cleared and the protected domain is		When the SD condition is cleared and the protected domain is
	recovering from the situation, the Wait-to-Restore (WTR) timer SHALL		recovering from the situation, the Wait-to-Restore (WTR) timer SHALL
	skipping to change at page 11, line 20		skipping to change at page 11, line 46
	The WTR timer SHALL be started at the node that recovers from a local		The WTR timer SHALL be started at the node that recovers from a local
	degraded condition on the working path.		degraded condition on the working path.
	Protection switching against SD is always provided by a selector		Protection switching against SD is always provided by a selector
	bridge duplicating user data traffic and feeding it to both the		bridge duplicating user data traffic and feeding it to both the
	working path and the protection path under SD condition. When a		working path and the protection path under SD condition. When a
	local or remote SD occurs on either the working path or the		local or remote SD occurs on either the working path or the
	protection path, the node SHALL duplicate user data traffic and SHALL		protection path, the node SHALL duplicate user data traffic and SHALL
	feed to both the working path and the protection path. The packet		feed to both the working path and the protection path. The packet
	duplication SHALL continue as long as any SD condition exists in the		duplication SHALL continue as long as any SD condition exists in the
	protected domain. The packet duplication SHALL continue in the WTR		protected domain. When the SD condition is cleared, in revertive
	state in revertive operation and SHALL stop when the node leaves the		operation, the packet duplication SHALL continue in the WTR state and
	WTR state. In non-revertive operation, the packet duplication SHALL		SHALL stop when the node leaves the WTR state; while in non-revertive
	stop when the SD condition is cleared.		operation, the packet duplication SHALL stop immediately.
	The selector bridge with the packet duplication under SD condition,		The selector bridge with the packet duplication under SD condition,
	which is a non-permanent bridge, is considered to be a 1:1 protection		which is a non-permanent bridge, is considered to be a 1:1 protection
	architecture.		architecture.
	Protection switching against SD does not introduce any modification		Protection switching against SD does not introduce any modification
	to the operation of the selector at the sink node described in		to the operation of the selector at the sink node described in
	[RFC6378]. The selector chooses either the working or protection		[RFC6378]. The selector chooses either the working or protection
	path from which to receive the normal traffic in both 1:1 and 1+1		path from which to receive the normal traffic in both 1:1 and 1+1
	architectures. The position of the selector, i.e., which path to		architectures. The position of the selector, i.e., which path to
	receive the traffic, is determined by the PSC protocol in		receive the traffic, is determined by the PSC protocol in
	bidirectional switching or by the local input in unidirectional		bidirectional switching or by the local input in unidirectional
	switching.		switching.
	7.4. Equal priority resolution		7.4. Equal priority resolution
	In order to support the MS behavior described in Section 6.3 and the		In order to support the MS behavior described in Section 6.3 and the
	protection against SD described in Section 7.3, it is necessary to		protection against SD described in Section 7.3, it is necessary to
	expand the rules for treating equal priority inputs.		expand rules for treating equal priority inputs.
	For equal priority local inputs, such as MS and SD, apply a simple		For equal priority local inputs, such as MS and SD, apply a simple
	first-come, first-served rule. Once a local input is determined as		first-come, first-served rule. 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 action results		local input requesting a different action, i.e., the action results
	in the same PSC Request field but different FPath value, 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 command, the subsequent local MS		Furthermore, in the case of MS command, the subsequent local MS
	command requesting a different action will be cancelled.		command requesting a different action will be cancelled.
	skipping to change at page 13, line 39		skipping to change at page 14, line 15
	o If a node has issued EXER and receives EXER before receiving RR,		o If a node has issued EXER and receives EXER before receiving RR,
	it MUST treat the received EXER as it would an RR, and SHOULD NOT		it MUST treat the received EXER as it would an RR, and SHOULD NOT
	respond with RR.		respond with RR.
	The following PSC Requests are added to the PSC Request field to		The following PSC Requests are added to the PSC Request field to
	support the Exercise command (see also Section 14.1):		support the Exercise command (see also Section 14.1):
	(3) 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 No Request (NR), RR or DNR		are set to the same value of the No Request (NR), RR or DNR
	request that EXER replaces.		message whose transmission is stopped by EXER.
	(2) Reverse Request - indicates that the transmitting end point is		(2) Reverse Request - indicates that the transmitting end point is
	responding to an EXER command from the remote node. FPath and		responding to an EXER command from the remote node. FPath and
	Path are set to the same value of the NR or DNR request that RR		Path are set to the same value of the NR or DNR message whose
	replaces.		transmission is stopped by RR.
	The relative priorities of EXER and RR are defined in Section 10.2.		The relative priorities of EXER and RR are defined in Section 10.2.
	9. Capabilities and Modes		9. Capabilities and Modes
	9.1. Capabilities		9.1. Capabilities
	A Capability is an individual behavior whose use is signaled in a		A Capability is an individual behavior whose use is signaled in a
	Capabilities TLV, which is placed in Optional TLVs field inside the		Capabilities TLV, which is placed in Optional TLVs field inside the
	PSC message shown in Figure 2 of [RFC6378]. The format of the		PSC message shown in Figure 2 of [RFC6378]. The format of the
	Capabilities TLV is:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 31		skipping to change at page 16, line 10
	and received Capabilities TLVs are not equal, this indicates a		and received Capabilities TLVs are not equal, this indicates a
	capabilities TLV mismatch. When this happens, the node MUST alert		capabilities TLV mismatch. When this happens, the node MUST alert
	the operator and MUST NOT perform any protection switching until the		the operator and MUST NOT perform any protection switching until the
	operator resolves the mismatch between the two end-points.		operator resolves the mismatch between the two end-points.
	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. Capability TLVs with other
			combinations than the one specified by a mode are not supported in
			this specification.
	9.2.1. PSC mode		9.2.1. PSC mode
	PSC mode is defined as the lack of support for any of the additional		PSC mode is defined as the lack of support for any of the additional
	capabilities defined in this document - that is, a Capabilities set		capabilities defined in this document - that is, a Capabilities set
	of 0x0. It is the behavior specified in [RFC6378].		of 0x0. It is the behavior specified in [RFC6378].
	There are two ways to declare PSC mode. A node can send no		There are two ways to declare PSC mode. A node can send no
	Capabilities TLV at all since there are no TLV units defined in		Capabilities TLV at all since there are no TLV units defined in
	[RFC6378], or it can send a Capabilities TLV with Flags value set to		[RFC6378], or it can send a Capabilities TLV with Flags value set to
	skipping to change at page 24, line 48		skipping to change at page 25, line 48
	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 | (9) | E::R | i | (10) | (11)		PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
	PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)		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 | (12)		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 | (13)| E::R | i | i | i
	E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i		E::L | SA:MW:R | SA:MP:R | i | 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:
	(7) If the received SD-W message has Path=0, ignore the message. If		(7) If the received SD-W message has Path=0, ignore the message. If
	the received SD-W message has Path=1, go to the PF:DW:R state		the received SD-W message has Path=1, go to the PF:DW:R state
	and transmit SD(0,1)		and transmit SD(0,1)
	(8) If the received SD-P message has Path=1, ignore the message. If		(8) If the received SD-P message has Path=1, ignore the message. If
	the received SD-P message has Path=0, go to the UA:DP:R state		the received SD-P message has Path=0, go to the UA:DP:R state
	and transmit SD(1,0).		and transmit SD(1,0).
	skipping to change at page 37, line 32		skipping to change at page 38, line 32
	Taesik Cheung		Taesik Cheung
	ETRI		ETRI
	218 Gajeongno		218 Gajeongno
	Yuseong-gu, Daejeon 305-700		Yuseong-gu, Daejeon 305-700
	South Korea		South Korea
	Phone: +82-42-860-5646		Phone: +82-42-860-5646
	Email: cts@etri.re.kr		Email: cts@etri.re.kr
	Eric Osborne		Eric Osborne
	Cisco Systems, Inc.
	Email: eosborne@cisco.com		Email: eric.osborne@notcom.com
End of changes. 32 change blocks.
	61 lines changed or deleted		76 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/