< draft-pan-shared-mesh-protection-03.txt		draft-pan-shared-mesh-protection-04.txt >
	IETF Ping Pan, Ed.
	Internet Draft Rajan Rao		Network Working Group P. Pan
	Biao Lu		Internet-Draft R. Rao
	(Infinera)		Intended status: Standards Track B. Lu
	Luyuan Fang		Expires: September 12, 2012 (Infinera)
			L. Fang
	(Cisco)		(Cisco)
	Andrew G. Malis		A. Malis
	(Verizon)		(Verizon)
	Fatai Zhang		F. Zhang
	Sam Aldrin		S. Aldrin
	(Huawei)		(Huawei)
	Fei Zhang		F. Zhang
	(ZTE)		(ZTE)
	Mohana Singamsetty		S. Singamsetty
	(Tellabs)		(Tellabs)
			March 11, 2012
	Expires: January 31, 2012 October 31, 2011		Supporting Shared Mesh Protection in MPLS-TP Networks
			draft-pan-shared-mesh-protection-04.txt
	Supporting Shared Mesh Protection in MPLS-TP Networks
	draft-pan-shared-mesh-protection-03.txt		Abstract
	Status of this Memo		Shared mesh protection is a common protection and recovery mechanism
			in transport networks, where multiple paths can share the same set of
			network resources for protection purposes.
	This Internet-Draft is submitted in full conformance with the		In the context of MPLS-TP, it has been explicitly requested as a part
	provisions of BCP 78 and BCP 79.		of the overall solution (Req. 67, 68 and 69 in RFC5654 [RFC5654]).
	This Internet-Draft is submitted in full conformance with the		It's important to note that each MPLS-TP LSP may be associated with
	provisions of BCP 78 and BCP 79. This document may not be modified,		transport network resources. In event of network failure, it may
	and derivative works of it may not be created, and it may not be		require explicit activation on the protecting paths before switching
	published except as an Internet-Draft.		user traffic over.
	This Internet-Draft is submitted in full conformance with the		In this memo, we define a lightweight signaling mechanism for
	provisions of BCP 78 and BCP 79. This document may not be modified,		protecting path activation in shared mesh protection-enabled MPLS-TP
	and derivative works of it may not be created, except to publish it		networks.
	as an RFC and to translate it into languages other than English.
	This document may contain material from IETF Documents or IETF		Requirements Language
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	the copyright in such materials, this document may not be modified		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	outside the IETF Standards Process, and derivative works of it may		document are to be interpreted as described in RFC 2119 [RFC2119].
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Internet-Drafts are working documents of the Internet Engineering		Status of this Memo
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		This Internet-Draft is submitted in full conformance with the
	months and may be updated, replaced, or obsoleted by other documents		provisions of BCP 78 and BCP 79.
	at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		Internet-Drafts are working documents of the Internet Engineering
	http://www.ietf.org/ietf/1id-abstracts.txt		Task Force (IETF). Note that other groups may also distribute
			working documents as Internet-Drafts. The list of current Internet-
			Drafts is at http://datatracker.ietf.org/drafts/current/.
	The list of Internet-Draft Shadow Directories can be accessed at		Internet-Drafts are draft documents valid for a maximum of six months
	http://www.ietf.org/shadow.html		and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 31, 2012.		This Internet-Draft will expire on September 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document.		to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
	Abstract		the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Shared mesh protection is a common protection and recovery mechanism
	in transport networks, where multiple paths can share the same set
	of network resources for protection purposes.
	In the context of MPLS-TP, it has been explicitly requested as a
	part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).
	It's important to note that each MPLS-TP LSP may be associated with
	transport network resources. In event of network failure, it may
	require explicit activation on the protecting paths before switching
	user traffic over.
	In this memo, we define a lightweight signaling mechanism for
	protecting path activation in shared mesh protection-enabled MPLS-TP
	networks.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions used in this document..............................4		2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Acronyms..................................................4		3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Definitions and Terminology....Error! Bookmark not defined.		3.1. Protection Switching . . . . . . . . . . . . . . . . . . . 7
	3. Solution Overview..............................................5		3.2. Operation Overview . . . . . . . . . . . . . . . . . . . . 8
	3.1. Protection Switching......................................7		4. SMP Message and Action Definition . . . . . . . . . . . . . . 9
	3.2. Operation Overview........................................8		4.1. Protection Switching Control (PSC) Logic . . . . . . . . . 9
	4. SMP Message and Action Definition..............................9		4.2. SMP Action Types . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Protection Switching Control (PSC) Logic..................9		4.3. PSC Signal to SMP Action Mapping . . . . . . . . . . . . . 11
	4.2. SMP Action Types.........................................11		5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12
	4.3. PSC Signal to SMP Action Mapping.........................12		5.1. Message Encapsulation . . . . . . . . . . . . . . . . . . 13
	5. Protocol Definition...........................................13		5.2. Reliable Messaging . . . . . . . . . . . . . . . . . . . . 14
	5.1. Message Encapsulation....................................14		5.3. Message Scoping . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Reliable Messaging.......................................15		6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3. Message Scoping..........................................15		6.1. Enable a Protecting Path . . . . . . . . . . . . . . . . . 15
	6. Processing Rules..............................................16		6.2. Disable a Protecting Path . . . . . . . . . . . . . . . . 15
	6.1. Enable a protecting path.................................16		6.3. Get Protecting Path Status . . . . . . . . . . . . . . . . 16
	6.2. Disable a protecting path................................17		6.4. Preemption . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3. Get protecting path status...............................17		7. Security Consideration . . . . . . . . . . . . . . . . . . . . 16
	6.4. Preemption...............................................17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. Security Consideration........................................18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations...........................................18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. Normative References..........................................18		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgments..............................................18		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Shared mesh protection (SMP) is a common traffic protection		Shared mesh protection (SMP) is a common traffic protection mechanism
	mechanism in transport networks, where multiple paths can share the		in transport networks, where multiple paths can share the same set of
	same set of network resources for protection purposes.		network resources for protection purposes.
	In the context of MPLS-TP, it has been explicitly requested as a		In the context of MPLS-TP, it has been explicitly requested as a part
	part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its		of the overall solution (Req. 67, 68 and 69 in RFC5654 [RFC5654]).Its
	operation has been further outlined in Section 4.7.6 of MPLS-TP		operation has been further outlined in Section 4.7.6 of MPLS-TP
	Survivability Framework [2].		Survivability Framework.
	It's important to note that each MPLS-TP LSP may be associated with		It's important to note that each MPLS-TP LSP may be associated with
	transport network resources. In event of network failure, it may		transport network resources. In event of network failure, it may
	require explicit activation on the protecting paths before switching		require explicit activation on the protecting paths before switching
	user traffic over.		user traffic over.
	In this memo, we define a lightweight signaling mechanism for		In this memo, we define a lightweight signaling mechanism for
	protecting path activation in shared mesh protection-enabled MPLS-TP		protecting path activation in shared mesh protection-enabled MPLS-TP
	networks.		networks.
	Here are the key design goals:		Here are the key design goals:
	1. Fast: The protocol is to activate the previously configured		1. Fast: The protocol is to activate the previously configured
	protecting paths in a timely fashion, with minimal transport and		protecting paths in a timely fashion, with minimal transport and
	processing overhead. The goal is to support 50msec end-to-end		processing overhead. The goal is to support 50msec end-to-end
	traffic switch-over in large transport networks.		traffic switch-over in large transport networks.
	2. Reliable message delivery: Activation and deactivation operation
	have serious impact on user traffic. This requires the protocol to
	adapt a low-overhead reliable messaging mechanism. The activation
	messages may either traverse through a "trusted" transport
	channel, or require some level of built-in reliability mechanism.
	3. Modular: Depending on deployment scenarios, the signaling may need
	to support functions such as preemption, resource re-allocation
	and bi-directional activation in a modular fashion.
	2. Conventions used in this document		2. Reliable message delivery: Activation and deactivation operation
			have serious impact on user traffic. This requires the protocol
			to adapt a low-overhead reliable messaging mechanism. The
			activation messages may either traverse through a "trusted"
			transport channel, or require some level of built-in reliability
			mechanism.
	Here are some of the conventions used in this document. The key		3. Modular: Depending on deployment scenarios, the signaling may
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		need to support functions such as preemption, resource re-
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		allocation and bi-directional activation in a modular fashion.
	document are to be interpreted as described in RFC-2119 [RFC2119].
	2.1. Acronyms		2. Acronyms
	This draft uses the following acronyms:		This draft uses the following acronyms:
	SMP Shared Mesh Protection		o SMP: Shared Mesh Protection
	LO Lockout of protection		o LO: Lockout of protection
	DNR Do not revert		o DNR: Do not revert
	FS Forced Switch		o FS: Forced Switch
	SF Signal Fail		o SF: Signal Fail
	SD Signal Degrade		o SD: Signal Degrade
	MS Manual Switch		o MS: Manual Switch
	NR No Request		o NR: No Request
	WTR Wait-to-Restore		o WTR: Wait-to-Restore
	EXER Exercise		o EXER: Exercise
	RR Reverse Request		o RR: Reverse Request
	ACK Acknowledgement		o ACK: Acknowledgement
	NACK Negative Acknowledgement		o NACK: Negative Acknowledgement
	G-ACh Generic Associated Channel		o G-ACh: Generic Associated Channel
	MPLS-TP Transport Profile for MPLS		o MPLS-TP Transport Profile for MPLS
	3. Solution Overview		3. Solution Overview
	In this section, we describe the SMP operation in the context of		In this section, we describe the SMP operation in the context of
	MPLS-TP networks, and outline some of the relevant definitions.		MPLS-TP networks, and outline some of the relevant definitions.
	We refer to the figure below for illustration:		We refer to the figure below for illustration:
	----- B ------- C ----		----- B ------- C ----
	/ \		/ \
	/ \		/ \
	A D		A D
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 13 ¶
	----- I ------- J ----		----- I ------- J ----
	Working paths: X = {A, B, C, D}, Y = {H, I, J, K}		Working paths: X = {A, B, C, D}, Y = {H, I, J, K}
	Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K}		Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K}
	The links between E, F and G are shared by both protecting paths.		The links between E, F and G are shared by both protecting paths.
	All paths are established via MPLS-TP control plane prior to network		All paths are established via MPLS-TP control plane prior to network
	failure.		failure.
	All paths are assumed to be bi-directional. An edge node is denoted		All paths are assumed to be bi-directional. An edge node is denoted
	as a headend or tailend for a particular path in accordance to the		as a headend or tailend for a particular path in accordance to the
	path setup direction.		path setup direction.
	Initially, the operators setup both working and protecting paths.		Initially, the operators setup both working and protecting paths.
	During setup, the operators specify the network resources for each		During setup, the operators specify the network resources for each
	path.		path. The working path X and Y will configure the appropriate
			resources on the intermediate nodes, however, the protecting paths,
	The working path X and Y will configure the appropriate resources on		X' and Y', will reserve the resources on the nodes, but won't occupy
	the intermediate nodes, however, the protecting paths, X' and Y',		them.
	will reserve the resources on the nodes, but won't occupy them.
	Depending on network planning requirements (such as SRLG), X' and Y'		Depending on network planning requirements (such as SRLG), X' and Y'
	may share the same set of resources on node E, F and G. The resource		may share the same set of resources on node E, F and G. The resource
	assignment is a part of the control-plane CAC operation taking place		assignment is a part of the control-plane CAC operation taking place
	on each node.		on each node.
	At some time, link B-C is cut. Node A will detect the outage, and		At some time, link B-C is cut. Node A will detect the outage, and
	initiate activation messages to bring up the protecting path X'. The		initiate activation messages to bring up the protecting path X'. The
	intermediate nodes, E, F and G will program the switch fabric and		intermediate nodes, E, F and G will program the switch fabric and
	configure the appropriate resources. Upon the completion of the		configure the appropriate resources. Upon the completion of the
	activation, A will switch the user traffic to X'.		activation, A will switch the user traffic to X'.
	The operation may have extra caveat:		The operation may have extra caveat:
	1. Preemption: Protecting paths X' and Y' may share the same		1. Preemption: Protecting paths X' and Y' may share the same
	resources on node E, F or G due to resource constraints. Y' has		resources on node E, F or G due to resource constraints. Y' has
	higher priority than that of X'. In the previous example, X' is		higher priority than that of X'. In the previous example, X' is
	up and running. When there is a link outage on I-J, H can		up and running. When there is a link outage on I-J, H can
	activate its protecting path Y'. On E, F or G, Y' can take over		activate its protecting path Y'. On E, F or G, Y' can take over
	the resources from X' for its own traffic. The behavior is		the resources from X' for its own traffic. The behavior is
	acceptable with the condition that A should be notified about		acceptable with the condition that A should be notified about the
	the preemption action.		preemption action.
	2. Over-subscription (1:N): A unit of network resource may be		2. Over-subscription (1:N): A unit of network resource may be
	reserved by one or multiple protecting paths. In the example,		reserved by one or multiple protecting paths. In the example,
	the network resources on E-F and F-G are shared by two		the network resources on E-F and F-G are shared by two protecting
	protecting paths, X' and Y'. In deployment, the over-		paths, X' and Y'. In deployment, the over-subscription ratio is
	subscription ratio is an important factor on network resource		an important factor on network resource utilization.
	utilization.
	3.1. Protection Switching		3.1. Protection Switching
	The entire activation and switch-over operation need to be within		The entire activation and switch-over operation need to be within the
	the range of milliseconds to meet customer's expectation [1]. This		range of milliseconds to meet customer's expectation. This section
	section illustrates how this may be achieved on MPLS-TP-enabled		illustrates how this may be achieved on MPLS-TP-enabled transport
	transport switches. Note that this is for illustration of protection		switches. Note that this is for illustration of protection switching
	switching operation, not mandating the implementation itself.		operation, not mandating the implementation itself.
	The diagram below illustrates the operation.		The diagram below illustrates the operation:
	+---------------+		+---------------+
	Control | MPLS-TP | Control		Control | MPLS-TP | Control
	<=== Signaling ====| Control Plane |=== Signaling ===>		<=== Signaling ====| Control Plane |=== Signaling ===>
	+---------------+		+---------------+
	/ \		/ \
	/ \ (MPLS label assignment)		/ \ (MPLS label assignment)
	/ \		/ \
	/ \		/ \
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	Activation |Line | |Switch| |Line | Activation		Activation |Line | |Switch| |Line | Activation
	<=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===>		<=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===>
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	Typical MPLS-TP user flows (or, LSP's) are bi-directional, and setup		Typical MPLS-TP user flows (or, LSP's) are bi-directional, and setup
	as co-routed or associated tunnels, with a MPLS label for each of		as co-routed or associated tunnels, with a MPLS label for each of the
	the upstream and downstream traffic. On this particular type of		upstream and downstream traffic. On this particular type of
	transport switch, the control-plane can download the labels to the		transport switch, the control-plane can download the labels to the
	line modules. Subsequently, the line module will maintain a label		line modules. Subsequently, the line module will maintain a label
	lookup table on all working and protecting paths.		lookup table on all working and protecting paths.
	Upon the detection of network failure, the headend nodes will		Upon the detection of network failure, the headend nodes will
	transmit activation messages along the MPLS LSP's. When receiving		transmit activation messages along the MPLS LSP's. When receiving
	the messages, the line modules can locate the associated protecting		the messages, the line modules can locate the associated protecting
	path from the label lookup table, and perform activation procedure		path from the label lookup table, and perform activation procedure by
	by programming the switching fabric directly. Upon its success, the		programming the switching fabric directly. Upon its success, the
	line module will swap the label, and forward the activation messages		line module will swap the label, and forward the activation messages
	to the next hop.		to the next hop.
	In summary, the activation procedure involves efficient path lookup		In summary, the activation procedure involves efficient path lookup
	and switch fabric re-programming.		and switch fabric re-programming.
	To achieve the tight end-to-end switch-over budget, it's possible to		To achieve the tight end-to-end switch-over budget, it's possible to
	implement the entire activation procedure with hardware-assistance		implement the entire activation procedure with hardware-assistance
	(such as in FPGA or ASIC).		(such as in FPGA or ASIC). The activation messages are encapsulated
			with a MPLS-TP Generic Associated Channel Header (GACH) [RFC5586].
	The activation messages are encapsulated with a MPLS-TP Generic		Detailed message encoding is explained in later sections.
	Associated Channel Header (GACH) [3]. Detailed message encoding is
	explained in Section 6.
	3.2. Operation Overview		3.2. Operation Overview
	To achieve high performance, the activation procedure is designed to		To achieve high performance, the activation procedure is designed to
	be simple and straightforward on the network nodes.		be simple and straightforward on the network nodes.
	In this section, we describe the activation procedure using the same		In this section, we describe the activation procedure using the same
	figure shown before:		figure shown before:
	----- B ------- C ----		----- B ------- C ----
	/ \		/ \
	/ \		/ \
	skipping to change at page 9, line 14 ¶		skipping to change at page 8, line 36 ¶
	Working paths: X = {A, B, C, D}, Y = {H, I, J, K}		Working paths: X = {A, B, C, D}, Y = {H, I, J, K}
	Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K}		Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K}
	Upon the detection of working path failure, the edge nodes, A, D, H		Upon the detection of working path failure, the edge nodes, A, D, H
	and K may trigger the activation messages to activate the protecting		and K may trigger the activation messages to activate the protecting
	paths, and redirect user traffic immediately after.		paths, and redirect user traffic immediately after.
	We assume that there is a consistent definition of priority levels		We assume that there is a consistent definition of priority levels
	among the paths throughout the network. At activation time, each		among the paths throughout the network. At activation time, each
	node may rely on the priority levels to potentially preempt other		node may rely on the priority levels to potentially preempt other
	paths.		paths.
	When the nodes detect path preemption on a particular node, they		When the nodes detect path preemption on a particular node, they
	should inform all relevant nodes to free the resources by sending		should inform all relevant nodes to free the resources by sending out
	out notification messages. Upon the reception of notification		notification messages. Upon the reception of notification messages,
	messages, the relevant nodes will send out de-activation messages.		the relevant nodes will send out de-activation messages.
	To optimize traffic protection and resource management, each headend		To optimize traffic protection and resource management, each headend
	may periodically poll the protecting paths about resource		may periodically poll the protecting paths about resource
	availability. The intermediate nodes have the option to inform the		availability. The intermediate nodes have the option to inform the
	current resource utilization.		current resource utilization.
	Note that, upon the detection of a working path failure, both		Note that, upon the detection of a working path failure, both headend
	headend and tailend may initiate the activation simultaneously		and tailend may initiate the activation simultaneously (known as bi-
	(known as bi-directional activation). This may expedite the		directional activation). This may expedite the activation time.
	activation time. However, both headend and tailend nodes need to		However, both headend and tailend nodes need to coordinate the order
	coordinate the order of protecting paths for activation, since there		of protecting paths for activation, since there may be multiple
	may be multiple protecting paths for each working path (i.e., 1:N		protecting paths for each working path (i.e., 1:N protection). For
	protection). For clarity, we will describe the operation from		clarity, we will describe the operation from headend in the memo.
	headend in the memo. The tailend operation will be available in the		The tailend operation will be available in the subsequent revisions.
	subsequent revisions.
	4. SMP Message and Action Definition		4. SMP Message and Action Definition
	4.1. Protection Switching Control (PSC) Logic		4.1. Protection Switching Control (PSC) Logic
	Protection switching processes the local triggers described in		Protection switching processes the local triggers described in
	requirements 74-79 of [1] together with inputs received from the		requirements 74-79 of [RFC5654] together with inputs received from
	tailend node. Based on these inputs the headend will take SMP		the tailend node. Based on these inputs the headend will take SMP
	actions, and transmit different protocol messages.		actions, and transmit different protocol messages.
	Here, we reuse the switching control logic described in MPLS Linear		Here, we reuse the switching control logic described in MPLS Linear
	Protection [6], with the following logical decomposition at headend		Protection, with the following logical decomposition at headend node:
	node:
	Server Indication Control Plane Indication		Server Indication Control Plane Indication
	-----------------+ +-------------		-----------------+ +-------------
	Operator Command | | OAM Indication		Operator Command | | OAM Indication
	----------------+ | | +---------------		----------------+ | | +---------------
	| | | |		| | | |
	V V V V		V V V V
	+---------------+ +-------+		+---------------+ +-------+
	| Local Request |<--------| WTR |		| Local Request |<--------| WTR |
	| logic |WTR Exps | Timer |		| logic |WTR Exps | Timer |
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 7 ¶
	| Action +------------+		| Action +------------+
	+---------------->| Message |		+---------------->| Message |
	| Generator |		| Generator |
	+------------+		+------------+
	|		|
	Output PSC | Message		Output PSC | Message
	V		V
	The Local Request logic unit accepts the triggers from the OAM,		The Local Request logic unit accepts the triggers from the OAM,
	external operator commands, from the local control plane (when		external operator commands, from the local control plane (when
	present), and the Wait-to-Restore timer. By considering all of these		present), and the Wait-to-Restore timer. By considering all of these
	local request sources it determines the highest priority local		local request sources it determines the highest priority local
	request. This high-priority request is passed to the PSC Control		request. This high-priority request is passed to the PSC Control
	logic, that will cross-check this local request with the information		logic, that will cross-check this local request with the information
	received from the tailend node. The PSC Control logic uses this		received from the tailend node. The PSC Control logic uses this
	input to determine what actions need to be taken, e.g. local actions		input to determine what actions need to be taken, e.g. local actions
	at the headend, or what message should be sent to the tailend node.		at the headend, or what message should be sent to the tailend node.
	Specifically, the signals could be the following:		Specifically, the signals could be the following:
	o Clear - if the operator cancels an active local administrative		o Clear - if the operator cancels an active local administrative
	command, i.e. LO/FS/MS.		command, i.e. LO/FS/MS.
	o Lockout of Protection (LO) - if the operator requested to prevent		o Lockout of Protection (LO) - if the operator requested to prevent
	switching data traffic to the protection path, for any purpose.		switching data traffic to the protection path, for any purpose.
	skipping to change at page 11, line 17 ¶		skipping to change at page 10, line 35 ¶
	protection path or one of the working paths.		protection path or one of the working paths.
	o Signal Degrade (SD) - if any of the Server Layer, Control plane,		o Signal Degrade (SD) - if any of the Server Layer, Control plane,
	or OAM indications signaled a degraded transmission condition on		or OAM indications signaled a degraded transmission condition on
	either the protection path or one of the working paths.		either the protection path or one of the working paths.
	o Forced Switch (FS) - if the operator requested that traffic be		o Forced Switch (FS) - if the operator requested that traffic be
	switched from one of the working paths to the protection path,		switched from one of the working paths to the protection path,
	o Manual Switch (MS) - if the operator requested that traffic is		o Manual Switch (MS) - if the operator requested that traffic is
	switched from the working path to the protection path. This is		switched from the working path to the protection path. This is
	only relevant if there is no currently active fault condition or		only relevant if there is no currently active fault condition or
	Operator command.		Operator command.
	o WTR Expires - generated by the WTR timer completing its period.		o WTR Expires - generated by the WTR timer completing its period.
			If none of the input sources have generated any input then the
			request logic should generate a No Request (NR) request.
	If none of the input sources have generated any input then the		In addition to the local requests, the PSC Control Logic SHALL accept
	request logic should generate a No Request (NR) request.		PSC messages from the tailend node of the transport path. Remote
			messages indicate the status of the transport path from the viewpoint
	In addition to the local requests, the PSC Control Logic SHALL		of the tailend nodes. The remote requests may include remote LO, SF,
	accept PSC messages from the tailend node of the transport path.		SD, FS, MS, WTR and NR.
	Remote messages indicate the status of the transport path from the
	viewpoint of the tailend nodes. The remote requests may include
	remote LO, SF, SD, FS, MS, WTR and NR.
	Much of the signal definition is further described in ITU G.709 and		Much of the signal definition is further described in ITU G.709 and
	G.873.1.		G.873.1.
	4.2. SMP Action Types		4.2. SMP Action Types
	As shown in the previous section, SMP requires four actions types		As shown in the previous section, SMP requires four actions types
	throughout the operation:		throughout the operation:
	o ACTIVATION: This action is triggered by the head-end (or tail-		o ACTIVATION: This action is triggered by the head-end (or tail-end)
	end) to activate a protecting connection. The intermediate nodes		to activate a protecting connection. The intermediate nodes need
	need to propagate this towards the other end of the protecting		to propagate this towards the other end of the protecting
	connection.		connection.
	o DE-ACTIVATION: This action is used to de-activate a particular		o DE-ACTIVATION: This action is used to de-activate a particular
	protecting connection. This can be originated by one end of a		protecting connection. This can be originated by one end of a
	protecting connection (i.e. head-end, or tail-end). The		protecting connection (i.e. head-end, or tail-end). The
	intermediate nodes need to propagate this towards the other end		intermediate nodes need to propagate this towards the other end of
	of the protecting connection.		the protecting connection.
	o QUERY: This action is used when an operator decides to query a		o QUERY: This action is used when an operator decides to query a
	particular protecting connection.		particular protecting connection.
	o NOTIFICATION: SMP operation requires the coordination between		o NOTIFICATION: SMP operation requires the coordination between
	nodes. The coordination takes places in two occasions:		nodes. The coordination takes places in two occasions:
	(1) The activation/de-activation is initiated at the headend		1. The activation/de-activation is initiated at the headend
	(tailend) nodes. To avoid potential mis-connection, the user		(tailend) nodes. To avoid potential mis-connection, the user
	traffic cannot be switched on to the protecting connection until		traffic cannot be switched on to the protecting connection
	the reception of an acknowledgement from the tailend (headend)		until the reception of an acknowledgement from the tailend
	nodes.		(headend) nodes.
	(2) If an intermediate node cannot process the activation		2. If an intermediate node cannot process the activation
	requests, due to lack of resources or preemption levels, it needs		requests, due to lack of resources or preemption levels, it
	to report the failure to the request originators.		needs to report the failure to the request originators.
	It is conceivable that this message can be used to report the		It is conceivable that this message can be used to report the
	location of the fault, with respect to a protecting connection so		location of the fault, with respect to a protecting connection so
	that the head-end may use this information as one of the criteria		that the head-end may use this information as one of the criteria for
	for restoring the working transport entity. The fault location		restoring the working transport entity. The fault location could be
	could be used by the head-end node to select among a list of		used by the head-end node to select among a list of possible
	possible protecting connections associated with the working		protecting connections associated with the working connection (i.e.
	connection (i.e. avoid the faulty location), or to determine that		avoid the faulty location), or to determine that none of the
	none of the provisioned protecting connections is usable at the		provisioned protecting connections is usable at the time the failure
	time the failure is reported and then fallback to restoring the		is reported and then fallback to restoring the working connection.
	working connection.
	4.3. PSC Signal to SMP Action Mapping		4.3. PSC Signal to SMP Action Mapping
	In SMP operation, there is the action-signal mapping:		In SMP operation, there is the action-signal mapping:
	Activation action: FS, SF, SD, MS,		o Activation action: FS, SF, SD, MS
			o De-activation action: NR
	De-activation action: NR
	Query action: EXER		o Query action: EXER
	Notification action: ACK, NACK (see next section)		o Notification action: ACK, NACK (see next section)
	5. Protocol Definition		5. Protocol Definition
	Each SMP message has the following format:		Each SMP message has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ver|Request|Rsv|R| Reserved | Status | Seq |		|Ver|Request|Rsv|R| Reserved | Status | Seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Version: 1		o Version: 1
	o Request:		o Request:
	o 1111b: Lockout of Protection (LO)		* 1111b: Lockout of Protection (LO)
	o 1110b: Forced Switch (FS). This triggers activation		* 1110b: Forced Switch (FS). This triggers activation
	o 1100b: Signal Fail (SF). This triggers activation		* 1100b: Signal Fail (SF). This triggers activation
	o 1011b: Acknowledgement (ACK). This is to acknowledge a		* 1011b: Acknowledgement (ACK). This is to acknowledge a
	successful activation/de-activation request		successful activation/de-activation request
	o 1010b: Signal Degrade (SD). This triggers activation		* 1010b: Signal Degrade (SD). This triggers activation
	o 1001b: Negative Acknowledgement (NACK). This is to report		* 1001b: Negative Acknowledgement (NACK). This is to report
	failure in activation/de-activation process.		failure in activation/de-activation process.
	o 1000b: Manual Switch (MS). This triggers activation		* 1000b: Manual Switch (MS). This triggers activation
	o 0110b: Wait-to-Restore (WTR). Used for revertive switching		* 0110b: Wait-to-Restore (WTR). Used for revertive switching
	o 0100b: Exercise (EXER). Triggers SMP query		* 0100b: Exercise (EXER). Triggers SMP query
	o 0001b: Do Not Revert (DNR). Used for revertive switching		* 0001b: Do Not Revert (DNR). Used for revertive switching
	o 0000b: No Request (NR). This triggers de-activation		* 0000b: No Request (NR). This triggers de-activation
	o R: Revertive field		o R: Revertive field
	o 0: non-revertive mode		* 0: non-revertive mode
	o 1: revertive mode		* 1: revertive mode
	o Rsv/Reserved: This field is reserved for future use		o Rsv/Reserved: This field is reserved for future use
	o Status: this informs the status of the AMP activation. This field
	is only relevant with ACK and NACK requests. Specifically, the		o Status: this informs the status of the AMP activation. This field
			is only relevant with ACK and NACK requests. Specifically, the
	Status Code has the following encoding value and definition:		Status Code has the following encoding value and definition:
	o 1: end-to-end ack		* 1: end-to-end ack
	o 2: hop-to-hop ack		* 2: hop-to-hop ack
	o 3: no such path		* 3: no such path
	o 4: no more resource for the path		* 4: no more resource for the path
	o 5: preempted by another path		* 5: preempted by another path
	o 6: system failure		* 6: system failure
	o 7: shared resource has been taken by other paths		* 7: shared resource has been taken by other paths
	o Seq: This uniquely identifies a particular message. This field is		o Seq: This uniquely identifies a particular message. This field is
	defined to support reliable message delivery		defined to support reliable message delivery
	Note that the message format and naming convention are very similar		Note that the message format and naming convention are very similar
	to that of MPLS linear protection [6] and ITU G.873.1.		to that of MPLS linear protection [6] and ITU G.873.1.
	5.1. Message Encapsulation		5.1. Message Encapsulation
	SMP messages use MPLS labels to identify the paths. Further, the		SMP messages use MPLS labels to identify the paths. Further, the
	messages are encapsulated in GAL/GACH:		messages are encapsulated in GAL/GACH:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS Label stack |		| MPLS Label stack |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL |		| GAL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Reserved | Activation Channel Type |		|0 0 0 1|Version| Reserved | Activation Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Activation Message Payload |		| Activation Message Payload |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o GAL is described in [3]		GAL is described in [RFC5586]. Activation Channel Type is the GACH
	o Activation Channel Type is the GACH channel number assigned to		channel number assigned to the protocol. This uniquely identifies
	the protocol. This uniquely identifies the activation messages.		the activation messages.
	Specifically, the messages have the following message format:		Specifically, the messages have the following message format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label | Exp |S| TTL |		| Label | Exp |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label (13) | Exp |S| TTL |		| Label (13) | Exp |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Reserved | Activation Channel Type |		|0 0 0 1|Version| Reserved | Activation Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ver|Request|Rsv|R| Reserved | Status | Seq |		|Ver|Request|Rsv|R| Reserved | Status | Seq |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.2. Reliable Messaging		5.2. Reliable Messaging
	The activation procedure adapts a simple two-way handshake reliable		The activation procedure adapts a simple two-way handshake reliable
	messaging.		messaging. Each node maintains a sequence number generator. Each
			new sending message will have a new sequence number. After sending a
	Each node maintains a sequence number generator. Each new sending		message, the node will wait for a response with the same sequence
	message will have a new sequence number. After sending a message,		number.
	the node will wait for a response with the same sequence number.
	Specifically, upon the generation of activation, de-activation,		Specifically, upon the generation of activation, de-activation, query
	query and notification messages, the message sender expects to		and notification messages, the message sender expects to receive
	receive acknowledgement in reply with same sequence number.		acknowledgement in reply with same sequence number.
	If a sender is not getting the reply within a time interval, it will		If a sender is not getting the reply within a time interval, it will
	retransmit the same message with a new sequence number, and starts		retransmit the same message with a new sequence number, and starts to
	to wait again. After multiple retries (by default, 3), the sender		wait again. After multiple retries (by default, 3), the sender will
	will declare activation failure, and alarm the operators for further		declare activation failure, and alarm the operators for further
	service.		service.
	5.3. Message Scoping		5.3. Message Scoping
	Activation signaling uses MPLS label TTL to control how far the		Activation signaling uses MPLS label TTL to control how far the
	message would traverse. Here are the processing rules on each		message would traverse. Here are the processing rules on each
	intermediate node:		intermediate node:
	o On receive, if the message has label TTL = 0, the node must drop		o On receive, if the message has label TTL = 0, the node must drop
	the packet without further processing		the packet without further processing
	o The receiving node must always decrement the label TTL value by		o The receiving node must always decrement the label TTL value by
	one. If TTL = 0 after the decrement, the node must process the		one. If TTL = 0 after the decrement, the node must process the
	message. Otherwise, the node must forward the message without		message. Otherwise, the node must forward the message without
	further processing (unless, of course, the node is headend or		further processing (unless, of course, the node is headend or
	tailend)		tailend)
	o On transmission, the node will adjust the TTL value. For hop-by-		o On transmission, the node will adjust the TTL value. For hop-by-
	hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default.		hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default.
	6. Processing Rules		6. Processing Rules
	6.1. Enable a protecting path		6.1. Enable a Protecting Path
	Upon the detection of network failure (SF/SD/FS) on a working path,		Upon the detection of network failure (SF/SD/FS) on a working path,
	the headend node identifies the corresponding MPLS-TP label and		the headend node identifies the corresponding MPLS-TP label and
	initiates the protection switching by sending an activation message.		initiates the protection switching by sending an activation message.
	The activation messages always use MPLS label TTL = 1 to force hop-		The activation messages always use MPLS label TTL = 1 to force hop-
	by-hop process. Upon reception, a next-hop node will locate the		by-hop process. Upon reception, a next-hop node will locate the
	corresponding path and activate the path.		corresponding path and activate the path.
	If the activation message is received on an intermediate node, due		If the activation message is received on an intermediate node, due to
	to label TTL expiry, the message is processed and then propagated to		label TTL expiry, the message is processed and then propagated to the
	the next hop of the MPLS TP LSP, by setting the MPLS TP label TTL =		next hop of the MPLS TP LSP, by setting the MPLS TP label TTL = 1.
	1.
	The headend node will declare the success of the activation only		The headend node will declare the success of the activation only when
	when it gets a positive reply from the tailend node. This requires		it gets a positive reply from the tailend node. This requires that
	that the tailend nodes must reply the messages with ACK to the		the tailend nodes must reply the messages with ACK to the headend
	headend nodes in all cases.		nodes in all cases.
	If the headend node is not receiving the acknowledgement within a		If the headend node is not receiving the acknowledgement within a
	time internal, it will retransmit another activation message with a		time internal, it will retransmit another activation message with a
	different Seq number.		different Seq number.
	If the headend node is not receiving a positive reply within a		If the headend node is not receiving a positive reply within a longer
	longer time interval, it will declare activation failure.		time interval, it will declare activation failure.
	If an intermediate node cannot activate a protecting path, it will		If an intermediate node cannot activate a protecting path, it will
	reply a message with NACK to report failure. When the headend node		reply a message with NACK to report failure. When the headend node
	receives the message for failure, it must initiate the de-activation		receives the message for failure, it must initiate the de-activation
	messages to clean up networks resources on all the relevant nodes on		messages to clean up networks resources on all the relevant nodes on
	the path.		the path.
	6.2. Disable a protecting path		6.2. Disable a Protecting Path
	The headend removes the network resources on a path by sending the		The headend removes the network resources on a path by sending the
	de-activation messages.		de-activation messages.
	In the message, the MPLS label represents the path to be de-		In the message, the MPLS label represents the path to be de-
	activated. The MPLS TTL is one to force hop-by-hop processing.		activated. The MPLS TTL is one to force hop-by-hop processing.
	Upon reception, a node will de-activate the path, by freeing the		Upon reception, a node will de-activate the path, by freeing the
	resources from the data-plane.		resources from the data-plane.
	As a part of the clean-up procedure, each de-activation message must		As a part of the clean-up procedure, each de-activation message must
	traverse through and be processed on all the nodes of the		traverse through and be processed on all the nodes of the
	corresponding path. When the de-activation message reaches to the		corresponding path. When the de-activation message reaches to the
	tailend node, the tailend is required to reply with an		tailend node, the tailend is required to reply with an
	acknowledgement message to the headend.		acknowledgement message to the headend.
	The de-activation process is complete when the headend receives the		The de-activation process is complete when the headend receives the
	corresponding acknowledgement message from the tailend.		corresponding acknowledgement message from the tailend.
	6.3. Get protecting path status		6.3. Get Protecting Path Status
	The operators have the option to trigger the query messages from the		The operators have the option to trigger the query messages from the
	headend to check on the protecting path periodically or on-demand.		headend to check on the protecting path periodically or on-demand.
	The process procedure on each node is very similar to that of the		The process procedure on each node is very similar to that of the
	activation messages on the intermediate nodes, except the query		activation messages on the intermediate nodes, except the query
	messages should not trigger any network resource re-programming.		messages should not trigger any network resource re-programming.
	Upon reception, the node will check the availability of resources.		Upon reception, the node will check the availability of resources.
	If the resource is no longer available, the node will reply an NACK		If the resource is no longer available, the node will reply an NACK
	with error conditions.		with error conditions.
	6.4. Preemption		6.4. Preemption
	The preemption operation typically takes place when processing an		The preemption operation typically takes place when processing an
	activation message.		activation message. If the activating network resources have been
			used by another path and carrying user traffic, the node needs to
	If the activating network resources have been used by another path		compare the priority levels.
	and carrying user traffic, the node needs to compare the priority
	levels.
	If the existing path has higher priority, the node needs to reject		If the existing path has higher priority, the node needs to reject
	the activation request by sending an ACK to the corresponding		the activation request by sending an ACK to the corresponding headend
	headend to inform the unavailability of network resources.		to inform the unavailability of network resources.
	If the new path has higher priority, the node will reallocate the		If the new path has higher priority, the node will reallocate the
	resource to the new path, and send an ACK to old path's headend node		resource to the new path, and send an ACK to old path's headend node
	to inform about the preemption.		to inform about the preemption.
	7. Security Consideration		7. Security Consideration
	The protection activation takes place in a controlled networking		The protection activation takes place in a controlled networking
	environment. Nevertheless, it is expected that the edge nodes will		environment. Nevertheless, it is expected that the edge nodes will
	encapsulate and transport external traffic into separated tunnels,		encapsulate and transport external traffic into separated tunnels,
	and the intermediate nodes will never have to process them.		and the intermediate nodes will never have to process them.
	8. IANA Considerations		8. IANA Considerations
	Activation messages are encapsulated in MPLS-TP with a specific GACH		Activation messages are encapsulated in MPLS-TP with a specific GACH
	channel type that needs to be assigned by IANA.		channel type that needs to be assigned by IANA.
	9. Normative References		9. Acknowledgments
	[1] RFC 5654: Requirements of an MPLS Transport Profile, B. Niven-
	Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno,
	September 2009
	[2] IETF draft, Multiprotocol Label Switching Transport Profile
	Survivability Framework (draft-ietf-mpls-tp-survive-fwk-
	06.txt), N. Sprecher, A. Farrel, June 2010
	[3] RFC5586 - Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal,
	R., and D. Ward, "MPLS Generic Associated Channel", May 2009.
	[4] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[5] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
	Syntax Specifications: ABNF", RFC 2234, Internet Mail
	Consortium and Demon Internet Ltd., November 1997.
	[6] IETF draft, MPLS-TP Linear Protection, (draft-ietf-mpls-tp-
	linear-protection-09.txt), Bryant, et al.
	10. Acknowledgments
	Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and		Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and
	Deborah Brungard for detailed feedback on the earlier work, and the		Deborah Brungard for detailed feedback on the earlier work, and the
	guidance and recommendation for this proposal.		guidance and recommendation for this proposal.
	We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague,		We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague, Ann
	Ann Gui and Tony Jorgenson for discussion on network operation,		Gui and Tony Jorgenson for discussion on network operation,
	feasibility and implementation methodology.		feasibility and implementation methodology.
	During ITU-T SG15 Interim meeting in May 2011, we have had long		During ITU-T SG15 Interim meeting in May 2011, we have had long
	discussion with the G.SMP contributors, in particular Fatai Zhang,		discussion with the G.SMP contributors, in particular Fatai Zhang,
	Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback		Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback
	and corrections.		and corrections.
			10. References
			10.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
			Heron, "Pseudowire Setup and Maintenance Using the Label
			Distribution Protocol (LDP)", RFC 4447, April 2006.
			[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
			Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
			10.2. Informative References
			[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
			Associated Channel", RFC 5586, June 2009.
			[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
			and S. Ueno, "Requirements of an MPLS Transport Profile",
			RFC 5654, September 2009.
	Authors' Addresses		Authors' Addresses
	Ping Pan		Ping Pan
			(Infinera)
	Email: ppan@infinera.com		Email: ppan@infinera.com
	Rajan Rao		Rajan Rao
			(Infinera)
	Email: rrao@infinera.com		Email: rrao@infinera.com
	Biao Lu		Biao Lu
			(Infinera)
	Email: blu@infinera.com		Email: blu@infinera.com
	Luyuan Fang		Luyuan Fang
			(Cisco)
	Email: lufang@cisco.com		Email: lufang@cisco.com
	Andrew G. Malis		Andrew G. Malis
			(Verizon)
	Email: andrew.g.malis@verizon.com		Email: andrew.g.malis@verizon.com
	Fatai Zhang		Fatai Zhang
	Email: zhangfatai@huawei.com		(Huawei)
			Email: zhangfatai@huawei.com
	Sam Aldrin		Sam Aldrin
			(Huawei)
	Email: sam.aldrin@huawei.com		Email: sam.aldrin@huawei.com
	Fei Zhang		Fei Zhang
			(ZTE)
	Email: zhang.fei3@zte.com.cn		Email: zhang.fei3@zte.com.cn
	Sri Mohana Satya Srinivas Singamsetty		Sri Mohana Satya Srinivas Singamsetty
			(Tellabs)
	Email: SriMohanS@Tellabs.com		Email: SriMohanS@Tellabs.com
End of changes. 154 change blocks.
	356 lines changed or deleted		334 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/