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