< draft-ietf-mpls-mldp-hsmp-03.txt		draft-ietf-mpls-mldp-hsmp-04.txt >
	Network Working Group L. Jin		Network Working Group L. Jin
	Internet-Draft		Internet-Draft
	Intended status: Standards Track F. Jounay		Intended status: Standards Track F. Jounay
	Expires: April 19, 2014 France Telecom		Expires: May 30, 2014 France Telecom
	I. Wijnands		I. Wijnands
	Cisco Systems		Cisco Systems, Inc
	N. Leymann		N. Leymann
	Deutsche Telekom		Deutsche Telekom AG
	October 16, 2013		November 26, 2013
	LDP Extensions for Hub & Spoke Multipoint Label Switched Path		LDP Extensions for Hub & Spoke Multipoint Label Switched Path
	draft-ietf-mpls-mldp-hsmp-03.txt		draft-ietf-mpls-mldp-hsmp-04.txt
	Abstract		Abstract
	This draft introduces a hub & spoke multipoint LSP (or HSMP LSP for		This draft introduces a hub & spoke multipoint (HSMP) Label Switched
	short), which allows traffic both from root to leaf through P2MP LSP		Path (LSP), which allows traffic both from root to leaf through
	and also leaf to root along the co-routed reverse path. That means		point-to-multipoint (P2MP) LSP and also leaf to root along the
	traffic entering the HSMP LSP from application/customer at the root		reverse path. That means traffic entering the HSMP LSP from
	node travels downstream to each leaf node, exactly as if it is		application/customer at the root node travels downstream to each leaf
	travelling downstream along a P2MP LSP to each leaf node. Upstream		node, exactly as if it is travelling downstream along a P2MP LSP to
	traffic entering the HSMP LSP at any leaf node travels upstream along		each leaf node. Upstream traffic entering the HSMP LSP at any leaf
	the tree to the root, as if it is unicast to the root, and strictly		node travels upstream along the tree to the root, as if it is unicast
	follows the downstream path of the tree rather than routing protocol		to the root. The communication among the leaf nodes are not allowed.
	based unicast path to the root.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 4 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 19, 2014.
			This Internet-Draft will expire on May 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4
	3.1. Time Synchronization Scenario . . . . . . . . . . . . . . 5		3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4
	3.2. Virtual Private Multicast Service Scenario . . . . . . . . 5		3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
	3.3. IPTV Scenario . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
	4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 6		3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 6
	4.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 6		3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 7
	4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 7		3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7
	4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 7		3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 8
	4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 8		3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9
	4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 10		3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9
	4.3.3. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . 10		3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9
	5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10		3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 9
	6. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11		3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 10
	7. Co-routed Path Exceptions . . . . . . . . . . . . . . . . . . 11		3.7. Determining Forwarding Interface . . . . . . . . . . . . . 10
	8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11		4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
	10.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13		8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12
	11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13
	12.1. Normative references . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	12.2. Informative References . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			10.1. Normative references . . . . . . . . . . . . . . . . . . . 13
			10.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The point-to-multipoint LSP defined in [RFC6388] allows traffic to		The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in
	transmit from root to several leaf nodes, and multipoint-to-		[RFC6388] allows traffic to transmit from root to several leaf nodes,
	multipoint LSP allows traffic from every node to transmit to every		and multipoint-to-multipoint (MP2MP) LSP allows traffic from every
	other node. This draft introduces a hub & spoke multipoint LSP (or		node to transmit to every other node. This draft introduces a hub &
	HSMP LSP for short), which allows traffic both from root to leaf		spoke multipoint (HSMP) LSP, which has one root node and one or more
	through P2MP LSP and also leaf to root along the co-routed reverse		leaf nodes. HSMP LSP allows traffic both from root to leaf through
	path. That means traffic entering the HSMP LSP at the root node		downstream LSP and also leaf to root along the upstream LSP. That
	travels downstream, exactly as if it is travelling downstream along a		means traffic entering the HSMP LSP at the root node travels along
	P2MP LSP, and traffic entering the HSMP LSP at any other node travels		downstream LSP, exactly as if it is travelling along a P2MP LSP, and
	upstream along the tree to the root. A packet travelling upstream		traffic entering the HSMP LSP at any other leaf nodes travels along
	should be thought of as being unicast to the root, except that it		upstream LSP toward only the root node. The upstream LSP should be
	follows the path of the tree rather than routing protocol based		thought of unicast LSP to the root node, except that it follows the
	unicast path to the root. The combination of upstream LSPs initiated		node of reverse downstream path of the tree, rather than routing
	from all leaf nodes forms a multipoint-to-point LSP.		protocol based unicast path. The combination of upstream LSPs
			initiated from all leaf nodes forms a multipoint-to-point LSP.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses some terms and acronyms as follows:		This document uses some terms and acronyms as follows:
	HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both		mLDP: Multipoint extensions for Label Distribution Protocol (LDP)
	from root to leaf through P2MP LSP and also leaf to root along the		defined in [RFC6388].
	co-routed reverse path.
	mLDP: Multipoint extensions for LDP
	MP2MP LSP: An LSP that connects a set of nodes, such that traffic
	sent by any node in the LSP is delivered to all others.
	PTP: The timing and synchronization protocol used by IEEE1588
	P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
	LSRs.
	3. Applications
	In some cases, the P2MP LSP may not have a reply path for OAM
	messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by
	HSMP LSP instead, then the upstream path could be used as the OAM
	message reply path. This is especially useful in the case of P2MP
	LSP fault detection, performance measurement, root node redundancy
	and etc. There are several other applications that could take
	advantage of a LDP based HSMP LSP as described below.
	3.1. Time Synchronization Scenario
	[IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls].
	It is required that the LSP used to transport PTP event message
	between a Master Clock and a Slave Clock, and the LSP between the
	same Slave Clock and Master Clock must be co-routed. Using point-to-
	multipoint technology to transmit PTP event messages from Master
	Clock at root side to Slave Clock at leaf side will greatly improve
	the bandwidth usage. Unfortunately current point-to-multipoint LSP
	only provides unidirectional path from root to leaf, which cannot
	provides a co-routed reverse path for the PTP event messages. LDP
	based HSMP LSP described in this draft provides unidirectional point-
	to-multipoint LSP from root to leaf and co-routed reverse LSP from
	leaf to root.
	3.2. Virtual Private Multicast Service Scenario
	Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires		P2MP LSP: point-to-multipoint Label Switched Path. An LSP that
	to set up reverse path from leaf node (referred as egress PE) to root		has one Ingress Label Switching Router (LSR) and one or more
	node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP		Egress LSRs.
	PW, the reverse path can also be multiplexed to HSMP upstream path to
	avoid setup independent reverse path. In that case, the operational
	cost will be reduced for maintaining only one HSMP LSP, instead of
	P2MP LSP and n (number of leaf nodes) P2P reverse LSPs.
	The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires		MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP
	reverse path from leaf to root node. The P2MP PW multiplexed to HSMP		that connects a set of nodes, such that traffic sent by any node
	LSP can provide VPMS with reverse path, without introducing		in the LSP is delivered to all others.
	independent reverse path from each leaf to root.
	3.3. IPTV Scenario		HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that
			has one root node and one or more leaf nodes, allows traffic from
			root to all leaf nodes along downstream P2MP LSP and also leaf to
			root node along the upstream unicast LSP.
	The mLDP based HSMP LSP can also be applied in a typical IPTV		PTP: precise time protocol. The timing and synchronization
	scenario. There is usually only one location with senders but there		protocol defined by IEEE1588.
	are many receiver locations. If IGMP is used for signalling between
	senders as IGMP querier [RFC3376] and receivers, the IGMP messages
	from the receivers are travelling only from the leaves to the root
	(and from root towards leaves) but not from leaf to leaf. In
	addition traffic from the root is only replicated towards the leaves.
	Then leaf node receiving IGMP report message (for source specific
	multicast case) will join HSMP LSP(use similar mechanism in [RFC6826]
	section 2), and then send IGMP report message upstream to root along
	HSMP upstream LSP. Note that in above case, there is no node
	redundancy for IGMP querier. And the node redundancy for IGMP
	querier[RFC3376] could be provided by two independent VPMS instances
	with HSMP applied.
	4. Setting up HSMP LSP with LDP		3. Setting up HSMP LSP with LDP
	HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the		HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the
	difference that the leaf LSRs can only send traffic to root node		difference that, when the leaf LSRs send traffic on the LSP, the
	along the same path of traffic from root node to leaf node.		traffic is first delivered only to the root node and follows the
			upstream path from the leaf node to the root node. The root node
			then distributes the traffic on the P2MP tree to all of the leaf
			nodes.
	HSMP LSP consists of a downstream path and upstream path. The		HSMP LSP consists of a downstream path and upstream path. The
	downstream path is same as MP2MP LSP, while the upstream path is only		downstream path is same as P2MP LSP, while the upstream path is only
	from leaf to root node, without communication between leaf and leaf		from leaf to root node, without communication between leaf and leaf
	nodes. The transmission of packets from the root node of an HSMP LSP		nodes. The transmission of packets from the root node of an HSMP LSP
	to the receivers is identical to that of a P2MP LSP. Traffic from a		to the receivers (the leaf nodes) is identical to that of a P2MP LSP.
	leaf node follows the upstream path toward the root node, along a		Traffic from a leaf node to the root follows the upstream path that
	path that traverse the same nodes as the downstream node, but in		is the reverse of the path from the root to the leaf. Unlike an
	reverse order.		MP2MP LSP, traffic from a leaf node does not branch toward other leaf
			nodes, but is sent direct to the root where it is placed on the P2MP
	For setting up the upstream path of an HSMP LSP, ordered mode MUST be		path and distributed to all leaf nodes including the original sender.
	used which is same as MP2MP. Ordered mode can guarantee a leaf to
	start sending packets to root immediately after the upstream path is
	installed, without being dropped due to an incomplete LSP.
	Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the		To set up the upstream path of an HSMP LSP, ordered mode MUST be
	following sections only describe the difference between the two		used. Ordered mode can guarantee a leaf to start sending packets to
	entities.		root immediately after the upstream path is installed, without being
			dropped due to an incomplete LSP.
	4.1. Support for HSMP LSP Setup with LDP		3.1. Support for HSMP LSP Setup with LDP
	HSMP LSP requires the LDP capabilities [RFC5561] for nodes to		HSMP LSP requires the LDP capabilities [RFC5561] for nodes to
	indicate that they support setup of HSMP LSPs. An implementation		indicate that they support setup of HSMP LSPs. An implementation
	supporting the HSMP LSP procedures specified in this document MUST		supporting the HSMP LSP procedures specified in this document MUST
	implement the procedures for Capability Parameters in Initialization		implement the procedures for Capability Parameters in Initialization
	Messages. Advertisement of the HSMP LSP Capability indicates support		Messages. Advertisement of the HSMP LSP Capability indicates support
	of the procedures for HSMP LSP setup.		of the procedures for HSMP LSP setup.
	A new Capability Parameter TLV is defined, the HSMP LSP Capability		A new Capability Parameter TLV is defined, the HSMP LSP Capability
	Parameter. Following is the format of the HSMP LSP Capability		Parameter. Following is the format of the HSMP LSP Capability
	Parameter.		Parameter.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1|0| HSMP LSP Cap(TBD IANA) | Length |		|U|F| HSMP LSP Cap(TBD IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 1. HSMP LSP Capability Parameter encoding		Figure 1. HSMP LSP Capability Parameter encoding
			U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be
			1. The unknown TLV MUST be silently ignored and the rest of the
			message processed as if the unknown TLV did not exist.
			F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value
			of this bit MUST be 0 since a Capability Parameter TLV is sent only
			in Initialization and Capability messages, which are not forwarded.
	The length SHOULD be 1, and the S bit and reserved bits are defined		The length SHOULD be 1, and the S bit and reserved bits are defined
	in [RFC5561] section 3.		in [RFC5561] section 3.
	The HSMP LSP Capability Parameter type is to be assigned by IANA.		The HSMP LSP Capability Parameter type is to be assigned by IANA.
	4.2. HSMP FEC Elements		If the peer has not advertised the corresponding capability, then
			label messages using the HSMP FEC Element SHOULD NOT be sent to the
			peer. Since ordered mode is applied for HSMP LSP signalling, the
			label message break would ensure that the initiating leaf node is
			unable to establish the upstream path to root node.
			3.2. HSMP FEC Elements
	Similar as MP2MP LSP, we define two new protocol entities, the HSMP		Similar as MP2MP LSP, we define two new protocol entities, the HSMP
	Downstream FEC Element and Upstream FEC Element. If a FEC TLV		Downstream FEC Element and Upstream FEC Element. If a FEC TLV
	contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be		contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be
	the only FEC Element in the FEC TLV. The structure, encoding and		the only FEC Element in the FEC TLV. The structure, encoding and
	error handling for the HSMP Downstream FEC Element and Upstream FEC		error handling for the HSMP Downstream FEC Element and Upstream FEC
	Element are the same as for the MP2MP FEC Element described in		Element are the same as for the P2MP FEC Element described in
	[RFC6388] Section 3.2. The difference is that two additional new FEC		[RFC6388] Section 2.2. The difference is that two additional new FEC
	types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream		types are defined: HSMP Downstream FEC (to be assigned by IANA) and
	FEC(TBD, IANA).		HSMP Upstream FEC (to be assigned by IANA).
	4.3. Using the HSMP FEC Elements		3.3. Using the HSMP FEC Elements
	In order to describe the message processing clearly, the entries in		In order to describe the message processing clearly, the entries in
	the list below define the processing of the HSMP FEC Elements.		the list below define the processing of the HSMP FEC Elements.
	Additionally, the entries defined in [RFC6388] section 3.3 are also		Additionally, the entries defined in [RFC6388] section 3.3 are also
	reused in the following sections.		reused in the following sections.
	1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP		1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP
	LSP downstream path with root node address X and opaque value Y.		LSP downstream path with root node address X and opaque value Y.
	2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP		2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP
	skipping to change at page 8, line 15 ¶		skipping to change at page 6, line 18 ¶
	5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a		5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a
	single HSMP downstream FEC Element <X, Y> and label TLV with label L.		single HSMP downstream FEC Element <X, Y> and label TLV with label L.
	Label L MUST be allocated from the per-platform label space of the		Label L MUST be allocated from the per-platform label space of the
	LSR sending the Label Mapping Message.		LSR sending the Label Mapping Message.
	6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a		6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a
	single HSMP upstream FEC Element <X, Y> and label TLV with label Lu.		single HSMP upstream FEC Element <X, Y> and label TLV with label Lu.
	Label Lu MUST be allocated from the per-platform label space of the		Label Lu MUST be allocated from the per-platform label space of the
	LSR sending the Label Mapping Message.		LSR sending the Label Mapping Message.
	4.3.1. HSMP LSP Label Map		7. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a
			FEC TLV with a single HSMP downstream FEC Element <X, Y> and label
			TLV with label L.
			8. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a
			FEC TLV with a single HSMP upstream FEC Element <X, Y> and label TLV
			with label Lu.
			9. HSMP-D Label Release <X, Y, L>: a Label Release message with a
			FEC TLV with a single HSMP downstream FEC Element <X, Y> and Label
			TLV with label L.
			10. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a
			FEC TLV with a single HSMP upstream FEC Element <X, Y> and label TLV
			with label Lu.
			3.4. HSMP LSP Label Map
	This section specifies the procedures for originating HSMP Label		This section specifies the procedures for originating HSMP Label
	Mapping messages and processing received HSMP Label Mapping messages		Mapping messages and processing received HSMP Label Mapping messages
	for a particular HSMP LSP. The procedure of downstream HSMP LSP is		for a particular HSMP LSP. The procedure of downstream HSMP LSP is
	same as that of downstream MP2MP LSP described in [RFC6388]. When		similar as that of downstream MP2MP LSP described in [RFC6388]. When
	LDP operates in Ordered Label Distribution Control mode [RFC5036],		LDP operates in Ordered Label Distribution Control mode [RFC5036],
	the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping		the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping
	message with a label which is allocated by upstream LSR to its		message with a label which is allocated by upstream LSR to its
	downstream LSR hop by hop from root to leaf node, installing the		downstream LSR hop by hop from root to leaf node, installing the
	upstream forwarding table by every node along the LSP. The detail		upstream forwarding table by every node along the LSP. The detail
	procedure of setting up upstream HSMP LSP is different with that of		procedure of setting up upstream HSMP LSP is different with that of
	upstream MP2MP LSP, and is specified in below section.		upstream MP2MP LSP, and is specified in below section.
	All labels discussed here are downstream-assigned [RFC5332] except		All labels discussed here are downstream-assigned [RFC5332] except
	those which are assigned using the procedures described in section 5.		those which are assigned using the procedures described in Section 4.
	Determining the upstream LSR for the HSMP LSP <X, Y> follows the		Determining the upstream LSR for the HSMP LSP <X, Y> follows the
	procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1.		procedure for a P2MP LSP described in [RFC6388] Section 2.4.1.1.
	Determining one's HSMP downstream LSR follows the procedure defined		That is, a node Z that wants to join an HSMP LSP <X, Y> determines
	in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which		the LDP peer U that is Z's next-hop on the best path from Z to the
			root node X. If there are multiple upstream LSRs, local algorithm
			should be applied to ensure that there is a single upstream LSRs for
			a particular LSP.
			To determining one's HSMP downstream LSR, an upstream LDP peer which
	receives a Label Mapping with HSMP downstream FEC Element from an LDP		receives a Label Mapping with HSMP downstream FEC Element from an LDP
	peer D will treat D as HSMP downstream LDP peer.		peer D will treat D as HSMP downstream LDP peer.
	Determining the forwarding interface to an LSR follows the procedure		3.4.1. HSMP LSP Leaf Node Operation
	as defined in [RFC6388] section 2.4.1.2.
	4.3.1.1. HSMP LSP Leaf Node Operation		The leaf node operation is much the same as the operation of MP2MP
			LSP defined in [RFC6388] Section 3.3.1.4. The only difference is the
			FEC elements as specified below.
	The leaf node operation is same as the operation of MP2MP LSP defined		A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for
	in [RFC6388] section 3.3.1.4. The only difference is the FEC		<X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D
	elements as specified below.		Label Mapping <X, Y, L> to U. Leaf node Z expects an HSMP-U Label
			Mapping <X, Y, Lu> from node U and checks whether it already has
			forwarding state for upstream <X, Y>. If not, Z creates forwarding
			state to push label Lu onto the traffic that Z wants to forward over
			the HSMP LSP. How it determines what traffic to forward on this HSMP
			LSP is outside the scope of this document.
	A leaf node Z will send an HSMP-D Label Mapping <X, Y, L> to U,		3.4.2. HSMP LSP Transit Node Operation
	instead of MP2MP-D Label Mapping <X, Y, L>, and expects an HSMP-U
	Label Mapping <X, Y, Lu> from node U and checks whether it already
	has forwarding state for upstream <X, Y>. The created forwarding
	state on leaf node Z is same as the leaf node of MP2MP LSP. Z will
	push label Lu onto the traffic that Z wants to forward over the HSMP
	LSP.
	4.3.1.2. HSMP LSP Transit Node Operation		The procedure of HSMP-D Label Mapping message is much the same as
			processing MP2MP-D Label Mapping message defined in [RFC6388] Section
			3.3.1.5. The processing of HSMP-U Label Mapping message is different
			with that of MP2MP-U Label Mapping message as specified below.
	Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D,		Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D.
	the procedure is much the same as processing MP2MP-D Label Mapping		Z checks whether it has forwarding state for downstream <X, Y>. If
	message defined in [RFC6388] section 3.3.1.5, and the processing		not, Z determines its upstream LSR U for <X, Y> as per Section 3.3.
	protocol entity is HSMP-D Label Mapping message. The only difference		Using this Label Mapping to update the label forwarding table MUST
	is specified below.		NOT be done as long as LSR D is equal to LSR U. If LSR U is different
			from LSR D, Z will allocate a label L' and install downstream
			forwarding state to swap label L' with label L over interface I
			associated with LSR D and send an HSMP-D Label Mapping <X, Y, L'> to
			U. Interface I is determined via the procedures in Section 3.7.
			If Z already has forwarding state for downstream <X, Y>, all that Z
			needs to do in this case is check that LSR D is not equal to the
			upstream LSR of <X, Y> and update its forwarding state. Assuming its
			old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
			new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>,
			<I, L>}. If the LSR D is equal to the installed upstream LSR, the
			Label Mapping from LSR D MUST be retained and MUST NOT update the
			label forwarding table.
	Node Z checks if upstream LSR U already has assigned a label Lu to		Node Z checks if upstream LSR U already has assigned a label Lu to
	upstream <X, Y>. If not, transit node Z waits until it receives an		upstream <X, Y>. If not, transit node Z waits until it receives an
	HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label		HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label
	Mapping is received from LSR U, node Z checks whether it already has		Mapping is received from LSR U, node Z checks whether it already has
	forwarding state upstream <X, Y> with incoming label Lu' and outgoing		forwarding state upstream <X, Y> with incoming label Lu' and outgoing
	label Lu. If it does, Z sends an HSMP-U Label Mapping <X, Y, Lu'> to		label Lu. If it does not, it allocates a label Lu' and creates a new
	downstream node. If it does not, it allocates a label Lu' and		label swap for Lu' with Label Lu over interface Iu. Interface Iu is
	creates a new label swap for Lu' with Label Lu over interface Iu.		determined via the procedures in Section 3.7. Node Z determines the
	Interface Iu is determined via the procedures in section 4.3.1. Node		downstream HSMP LSR as per Section 4.3.1, and sends an HSMP-U Label
	Z determines the downstream HSMP LSR as per section 4.3.1, and sends		Mapping <X, Y, Lu'> to node D.
	an HSMP-U Label Mapping <X, Y, Lu'> to node D.
	Since a packet from any downstream node is forwarded only to the		Since a packet from any downstream node is forwarded only to the
	upstream node, the same label (representing the upstream path) SHOULD		upstream node, the same label (representing the upstream path) SHOULD
	be distributed to all downstream nodes. This differs from the		be distributed to all downstream nodes. This differs from the
	procedures for MP2MP LSPs [RFC6388], where a distinct label must be		procedures for MP2MP LSPs [RFC6388], where a distinct label must be
	distributed to each downstream node. The forwarding state upstream		distributed to each downstream node. The forwarding state upstream
	<X, Y> on node Z will be like this {<Lu'>, <Iu Lu>}. Iu means the		<X, Y> on node Z will be like this {<Lu'>, <Iu Lu>}. Iu means the
	upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu>		upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu>
	from LSR U. Packets from any downstream interface over which Z sends		from LSR U. Packets from any downstream interface over which Z sends
	HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu		HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu
	with label Lu' swap to Lu.		with label Lu' swap to Lu.
	4.3.1.3. HSMP LSP Root Node Operation		3.4.3. HSMP LSP Root Node Operation
	Suppose root node Z receives an HSMP-D Label Mapping <X, Y, L> from		The procedure of HSMP-D Label Mapping message is much the same as
	node D, the procedure is much the same as processing MP2MP-D Label		processing MP2MP-D Label Mapping message defined in [RFC6388] Section
	Mapping message defined in [RFC6388] section 3.3.1.6, and the		3.3.1.6. The processing of HSMP-U Label Mapping message is different
	processing protocol entity is HSMP-D Label Mapping message. The only		with that of MP2MP-U Label Mapping message as specified below.
	difference is specified below.
			Suppose the root node Z receives an HSMP-D Label Mapping <X, Y, L>
			from node D. Z checks whether it already has forwarding state for
			downstream <X, Y>. If not, Z creates downstream forwarding state and
			installs a outgoing label L over interface I. Interface I is
			determined via the procedures in Section 3.7. If Z already has
			forwarding state for downstream <X, Y>, then Z will add label L over
			interface I to the existing state.
	Node Z checks if it has forwarding state for upstream <X, Y>. If		Node Z checks if it has forwarding state for upstream <X, Y>. If
	not, Z creates a forwarding state for incoming label Lu' that		not, Z creates a forwarding state for incoming label Lu' that
	indicates that Z is the LSP egress. E.g., the forwarding state might		indicates that Z is the HSMP LSP egress LER. E.g., the forwarding
	specify that the label stack is popped and the packet passed to some		state might specify that the label stack is popped and the packet
	specific application. Node Z determines the downstream HSMP LSR as		passed to some specific application. Node Z determines the
	per section 4.3.1, and sends an HSMP-U Label Map <X, Y, Lu'> to node		downstream HSMP LSR as per Section 3.3, and sends an HSMP-U Label Map
	D.		<X, Y, Lu'> to node D.
	Since Z is the root of the tree, Z will not send an HSMP-D Label Map		Since Z is the root of the tree, Z will not send an HSMP-D Label Map
	and will not receive an HSMP-U Label Mapping.		and will not receive an HSMP-U Label Mapping.
	4.3.2. HSMP LSP Label Withdraw		Root node could also be a leaf node, and it is able to determine what
			traffic to forward on this HSMP LSP which is outside the scope of
			this document.
	The HSMP Label Withdraw procedure is much the same as MP2MP leaf		3.5. HSMP LSP Label Withdraw
	operation defined in [RFC6388] section 3.3.2, and the processing FEC
	Elements are HSMP FEC Elements. The only difference is the process
	of HSMP-U Label Release message, which is specified below.
	When a transit node Z receives an HSMP-U Label Release message from		3.5.1. HSMP Leaf Operation
	downstream node D, Z should check if there are any incoming interface
	in forwarding state upstream <X, Y>. If all downstream nodes are
	released and there is no incoming interface, Z should delete the
	forwarding state upstream <X, Y> and send HSMP-U Label Release
	message to its upstream node. Otherwise, no HSMP-U Label Release
	message will be sent to the upstream node.
	4.3.3. HSMP LSP Upstream LSR Change		If a leaf node Z discovers that it has no need to be an Egress LSR
			for that LSP (by means outside the scope of this document), then it
			SHOULD send an HSMP-D Label Withdraw <X, Y, L> to its upstream LSR U
			for <X, Y>, where L is the label it had previously advertised to U
			for <X,Y>. Leaf node Z will also send an unsolicited HSMP-U Label
			Release <X, Y, Lu> to U to indicate that the upstream path is no
			longer used and that label Lu can be removed.
			Leaf node Z expects the upstream router U to respond by sending a
			downstream Label Release for L.
			3.5.2. HSMP Transit Node Operation
			If a transit node Z receives an HSMP-D Label Withdraw message <X, Y,
			L> from node D, it deletes label L from its forwarding state
			downstream <X, Y>. Node Z sends an HSMP-D Label Release message with
			label L to D. There is no need to send an HSMP-U Label Withdraw <X,
			Y, Lu> to D because node D already removed Lu and sent a label
			release for Lu to Z.
			If deleting L from Z's forwarding state for downstream <X, Y> results
			in no state remaining for <X, Y>, then Z propagates the HSMP-D Label
			Withdraw <X, Y, L> to its upstream node U for <X, Y>. Z should also
			check if there are any incoming interface in forwarding state
			upstream <X, Y>. If all downstream nodes are released and there is
			no incoming interface, Z should delete the forwarding state upstream
			<X, Y> and send HSMP-U Label Release message to its upstream node.
			Otherwise, no HSMP-U Label Release message will be sent to the
			upstream node.
			3.5.3. HSMP Root Node Operation
			When the root node of an HSMP LSP receives an HSMP-D Label Withdraw
			and HSMP-U Label Release message, the procedure is the same as that
			for transit nodes, except that the root node will not propagate the
			Label Withdraw and Label Release upstream (as it has no upstream).
			3.6. HSMP LSP Upstream LSR Change
	The procedure for changing the upstream LSR is the same as defined in		The procedure for changing the upstream LSR is the same as defined in
	[RFC6388] section 3.3.3, only with different processing FEC Element,		[RFC6388] Section 2.4.3, only with different processing FEC Element.
	the HSMP FEC Element.
	5. HSMP LSP on a LAN		When the upstream LSR changes from U to U', node Z should set up the
			HSMP LSP <X, Y> to U' by applying procedures in Section 3.4. Z will
			also remove HSMP LSP <X, Y> to U by applying procedure in Section
			3.5.
			To set up HSMP LSP to U' before/after removing HSMP LSP to U is a
			local matter, and the recommended default behavior is to remove
			before adding.
			3.7. Determining Forwarding Interface
			The co-routed path between upstream and downstream LSP would be
			achieved for HSMP LSP. Both LSR U and LSR D would ensure the same
			interface to send traffic by applying some procedures. For a network
			with symmetric IGP cost configuration, the following procedure MAY be
			used. To determine the downstream interface, LSR U MUST do a lookup
			in the unicast routing table to find the best interface and next-hop
			to reach LSR D. If the next-hop and interface are also advertised by
			LSR D via the LDP session, it should be used to transmit the packet
			to LSR D. Determine the upstream interface mechanism is same as
			determining the downstream interface by exchanging the role of LSR U
			and LSR D. If symmetric IGP cost could not be ensured, static route
			configuration on LSR U and D could also be a possible way to ensure
			co-routed path.
			If co-routed is not required for HSMP LSP, the procedure defined in
			[RFC6388] Section 2.4.1.2 could be applied. LSR U is free to
			transmit the packet on any of the interfaces to LSR D. The algorithm
			it uses to choose a particular interface is a local matter.
			Determine the upstream interface mechanism is the same as determining
			the downstream interface.
			4. HSMP LSP on a LAN
	The procedure to process the downstream HSMP LSP on a LAN is much the		The procedure to process the downstream HSMP LSP on a LAN is much the
	same as downstream MP2MP LSP described in [RFC6388] section 6.1.1.		same as downstream MP2MP LSP described in [RFC6388] section 6.1.1.
	When establishing the downstream path of an HSMP LSP, as defined in		When establishing the downstream path of an HSMP LSP, as defined in
	[RFC6389], a Label Request message for an LSP label is sent to the		[RFC6389], a Label Request message for an LSP label is sent to the
	upstream LSR. The upstream LSR should send Label Mapping message		upstream LSR. The upstream LSR should send Label Mapping message
	that contains the LSP label for the downstream HSMP FEC and the		that contains the LSP label for the downstream HSMP FEC and the
	upstream LSR context label defined in [RFC5331]. When the LSR		upstream LSR context label defined in [RFC5331]. When the LSR
	forwards a packet downstream on one of those LSPs, the packet's top		forwards a packet downstream on one of those LSPs, the packet's top
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 19 ¶
	forwarded downstream using this forwarding state based on a two-label		forwarded downstream using this forwarding state based on a two-label
	lookup.		lookup.
	The upstream path of an HSMP LSP on a LAN is the same as the one on		The upstream path of an HSMP LSP on a LAN is the same as the one on
	other kind of links. That is, the upstream LSR must send Label		other kind of links. That is, the upstream LSR must send Label
	Mapping message that contains the LSP label for upstream HSMP FEC to		Mapping message that contains the LSP label for upstream HSMP FEC to
	downstream node. Packets travelling upstream need to be forwarded in		downstream node. Packets travelling upstream need to be forwarded in
	the direction of the root by using the label allocated for upstream		the direction of the root by using the label allocated for upstream
	HSMP FEC.		HSMP FEC.
	6. Redundancy Considerations		5. Redundancy Considerations
	In some scenario, it is necessary to provide two root nodes for		In some scenario, it is necessary to provide two root nodes for
	redundancy purpose. One way to implement this is to use two		redundancy purpose. One way to implement this is to use two
	independent HSMP LSPs acting as active/standby. At one time, only		independent HSMP LSPs acting as active/standby. At one time, only
	one HSMP LSP will be active, and the other will be standby. After		one HSMP LSP will be active, and the other will be standby. After
	detecting the failure of active HSMP LSP, the root and leaf nodes		detecting the failure of active HSMP LSP, the root and leaf nodes
	will switch the traffic to the standby HSMP LSP which takes on the		will switch the traffic to the standby HSMP LSP which takes on the
	role as active HSMP LSP. The detail of redundancy mechanism is out		role as active HSMP LSP. The detail of redundancy mechanism is out
	of the scope.		of the scope.
	7. Co-routed Path Exceptions		6. Failure Detection of HSMP LSP
	There are some exceptional cases when mLDP based HSMP LSP could not
	achieve co-routed path. One possible case is using static routing
	between LDP neighbors; another possible case is IGP cost asymmetric
	generated by physical link cost asymmetric, or TE-Tunnels used
	between LDP neighbors. The LSR/LER in HSMP LSP should detect if the
	path is co-routed or not. If not co-routed, an alarm indication
	should be generated to the management system.
	8. Failure Detection of HSMP LSP
	The idea of LSP ping for HSMP LSPs could be expressed as an intention		The idea of LSP ping for HSMP LSPs could be expressed as an intention
	to test the LSP Ping Echo Request packets that enter at the root		to test the LSP Ping Echo Request packets that enter at the root
	along a particular downstream path of HSMP LSP, and end their MPLS		along a particular downstream path of HSMP LSP, and end their MPLS
	path on the leaf. The leaf node then sends the LSP Ping Echo Reply		path on the leaf. The leaf node then sends the LSP Ping Echo Reply
	along the co-routed upstream path of HSMP LSP, and end on the root		along the upstream path of HSMP LSP, and end on the root that are the
	that are the (intended) root node.		(intended) root node.
	New sub-TLVs are required to be assigned by IANA in Target FEC Stack		New sub-TLVs are required to be assigned by IANA in Target FEC Stack
	TLV to define the corresponding HSMP-upstream FEC type and HSMP-		TLV to define the corresponding HSMP-upstream FEC type and HSMP-
	downstream FEC type. In order to ensure the leaf node to send the		downstream FEC type. In order to ensure the leaf node to send the
	LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate		LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate
	Reverse Path) in Global Flags Field defined in [RFC6426] is reused		Reverse Path) in Global Flags Field defined in [RFC6426] is reused
	here.		here.
	The node processing mechanism of LSP Ping Echo Request and Echo Reply		The node processing mechanism of LSP Ping Echo Request and Echo Reply
	for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4,		for HSMP LSP is inherited from [RFC6425] and [RFC6426] Section 3.4,
	except the following:		except the following:
	1. The root node sending LSP Ping Echo Request message for HSMP LSP		1. The root node sending LSP Ping Echo Request message for HSMP LSP
	MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit		MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit
	to '1' in Global Flags Field.		to '1' in Global Flags Field.
	2. When the leaf node receiving the LSP Ping Echo Request, it MUST		2. When the leaf node receiving the LSP Ping Echo Request, it MUST
	send the LSP Ping Echo Reply to the associated HSMP upstream path.		send the LSP Ping Echo Reply to the associated HSMP upstream path.
	The Reverse-path Target FEC Stack TLV attached by leaf node in Echo		The Reverse-path Target FEC Stack TLV attached by leaf node in Echo
	Reply message SHOULD contain the sub-TLV of associated HSMP upstream		Reply message SHOULD contain the sub-TLV of associated HSMP upstream
	FEC.		FEC.
	9. Security Considerations		7. Security Considerations
	The same security considerations apply as for the MP2MP LSP described		The same security considerations apply as for the MP2MP LSP described
	in [RFC6388] and [RFC6425].		in [RFC6388] and [RFC6425].
	Although this document introduces new FEC Elements and corresponding		Although this document introduces new FEC Elements and corresponding
	procedures, the protocol does not bring any new security issues		procedures, the protocol does not bring any new security issues
	compared to [RFC6388] and [RFC6425].		compared to [RFC6388] and [RFC6425].
	10. IANA Considerations		8. IANA Considerations
	10.1. New LDP FEC Element types		8.1. New LDP FEC Element types
	This document requires allocation of two new LDP FEC Element types		This document requires allocation of two new LDP FEC Element types
	from the "Label Distribution Protocol (LDP) Parameters registry" the		from the "Label Distribution Protocol (LDP) Parameters registry" the
	"Forwarding Equivalence Class (FEC) Type Name Space":		"Forwarding Equivalence Class (FEC) Type Name Space":
	1. the HSMP-upstream FEC type - requested value TBD		1. the HSMP-upstream FEC type - requested value TBD
	2. the HSMP-downstream FEC type - requested value TBD		2. the HSMP-downstream FEC type - requested value TBD
	The values should be allocated using the lowest free values from the		The values should be allocated using the lowest free values from the
	"IETF Consensus"-range (0-127).		"IETF Consensus"-range (0-127).
	10.2. HSMP LSP capability TLV		8.2. HSMP LSP capability TLV
	This document requires allocation of one new code points for the HSMP		This document requires allocation of one new code points for the HSMP
	LSP capability TLV from "Label Distribution Protocol (LDP) Parameters		LSP capability TLV from "Label Distribution Protocol (LDP) Parameters
	registry" the "TLV Type Name Space":		registry" the "TLV Type Name Space":
	HSMP LSP Capability Parameter - requested value TBD		HSMP LSP Capability Parameter - requested value TBD
	The value should be allocated from the range 0x0901-0x3DFF (IETF		The value should be allocated from the range 0x0901-0x3DFF (IETF
	Consensus) using the first free value within this range.		Consensus) using the first free value within this range.
	10.3. New sub-TLVs for the Target Stack TLV		8.3. New sub-TLVs for the Target Stack TLV
	This document requires allocation of two new sub-TLV types for		This document requires allocation of two new sub-TLV types for
	inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV		inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV
	type 1).		type 1).
	1. the HSMP-upstream LDP FEC Stack - requested value TBD		1. the HSMP-upstream LDP FEC Stack - requested value TBD
	2. the HSMP-downstream LDP FEC Stack - requested value TBD		2. the HSMP-downstream LDP FEC Stack - requested value TBD
	The value should be allocated from the IETF Standards Action range		The value should be allocated from the IETF Standards Action range
	(0-16383) that is used for mandatory and optional sub-TLVs that		(0-16383) that is used for mandatory and optional sub-TLVs that
	requires a response if not understood. The value should be allocated		requires a response if not understood. The value should be allocated
	using the lowest free value within this range.		using the lowest free value within this range.
	11. Acknowledgement		9. Acknowledgement
	The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su,		The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su,
	Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable		Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable
	comments.		comments.
	12. References		10. References
	12.1. Normative references		10.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream		[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
	Label Assignment and Context-Specific Label Space",		Label Assignment and Context-Specific Label Space",
	RFC 5331, August 2008.		RFC 5331, August 2008.
	[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS		[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
	Multicast Encapsulations", RFC 5332, August 2008.		Multicast Encapsulations", RFC 5332, August 2008.
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,		[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
	S., and T. Nadeau, "Detecting Data-Plane Failures in		S., and T. Nadeau, "Detecting Data-Plane Failures in
	Point-to-Multipoint MPLS - Extensions to LSP Ping",		Point-to-Multipoint MPLS - Extensions to LSP Ping",
	RFC 6425, November 2011.		RFC 6425, November 2011.
	[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS		[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
	On-Demand Connectivity Verification and Route Tracing",		On-Demand Connectivity Verification and Route Tracing",
	RFC 6426, November 2011.		RFC 6426, November 2011.
	12.2. Informative References		10.2. Informative References
	[I-D.ietf-l2vpn-vpms-frmwk-requirements]		[I-D.ietf-l2vpn-vpms-frmwk-requirements]
	Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,		Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
	and L. Jin, "Framework and Requirements for Virtual		and L. Jin, "Framework and Requirements for Virtual
	Private Multicast Service (VPMS)",		Private Multicast Service (VPMS)",
	draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in		draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in
	progress), October 2012.		progress), October 2012.
	[I-D.ietf-pwe3-p2mp-pw]		[I-D.ietf-pwe3-p2mp-pw]
	Sivabalan, S., Boutros, S., and L. Martini, "Signaling		Sivabalan, S., Boutros, S., and L. Martini, "Signaling
End of changes. 58 change blocks.
	229 lines changed or deleted		289 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/