draft-ietf-mpls-mldp-hsmp-06.txt		rfc7140.txt
	Network Working Group L. Jin		Internet Engineering Task Force (IETF) L. Jin
	Internet-Draft		Request for Comments: 7140
	Intended status: Standards Track F. Jounay		Category: Standards Track F. Jounay
	Expires: July 2, 2014 France Telecom		ISSN: 2070-1721 Orange CH
	I. Wijnands		IJ. Wijnands
	Cisco Systems, Inc		Cisco Systems, Inc
	N. Leymann		N. Leymann
	Deutsche Telekom AG		Deutsche Telekom AG
	December 29, 2013		March 2014
	LDP Extensions for Hub & Spoke Multipoint Label Switched Path		LDP Extensions for Hub and Spoke Multipoint Label Switched Path
	draft-ietf-mpls-mldp-hsmp-06.txt
	Abstract		Abstract
	This draft introduces a hub & spoke multipoint (HSMP) Label Switched		This document introduces a hub and spoke multipoint (HSMP) Label
	Path (LSP), which allows traffic both from root to leaf through		Switched Path (LSP), which allows traffic from root to leaf through
	point-to-multipoint (P2MP) LSP and also leaf to root along the		point-to-multipoint (P2MP) LSPs and also leaf to root along the
	reverse path. That means traffic entering the HSMP LSP from		reverse path. That means traffic entering the HSMP LSP from the
	application/customer at the root node travels downstream to each leaf		application/customer at the root node travels downstream to each leaf
	node, exactly as if it is travelling downstream along a P2MP LSP to		node, exactly as if it were traveling downstream along a P2MP LSP to
	each leaf node. Upstream traffic entering the HSMP LSP at any leaf		each leaf node. Upstream traffic entering the HSMP LSP at any leaf
	node travels upstream along the tree to the root, as if it is unicast		node travels upstream along the tree to the root, as if it were
	to the root. Direct communication among the leaf nodes is not		unicast to the root. Direct communication among the leaf nodes is
	allowed.		not allowed.
	Requirements Language
	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 RFC2119 [RFC2119].
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		http://www.rfc-editor.org/info/rfc7140.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 2, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5		3. Setting Up HSMP LSP with LDP . . . . . . . . . . . . . . . . 4
	3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 5		3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4
	3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6		3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
	3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6		3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
	3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 7		3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . 6
	3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 8		3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . 7
	3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 8		3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7
	3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 9		3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . 8
	3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 10		3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9
	3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 10		3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9
	3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 10		3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9
	3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 10		3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . 10
	3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 11		3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . 10
	3.7. Determining Forwarding Interface . . . . . . . . . . . . . 11		3.7. Determining Forwarding Interface . . . . . . . . . . . . 10
	4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11		4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
	5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 12		5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
	6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 12		6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 13		8.1. New LDP FEC Element Types . . . . . . . . . . . . . . . . 12
	8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 13		8.2. HSMP LSP Capability TLV . . . . . . . . . . . . . . . . . 13
	8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 14		8.3. New Sub-TLVs for the Target Stack TLV . . . . . . . . . . 13
	9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative references . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in		The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in
	[RFC6388] allows traffic to transmit from root to several leaf nodes,		[RFC6388] allows traffic to transmit from root to several leaf nodes,
	and multipoint-to-multipoint (MP2MP) LSP allows traffic from every		and multipoint-to-multipoint (MP2MP) LSP allows traffic from every
	node to transmit to every other node. This draft introduces a hub &		node to transmit to every other node. This document introduces a hub
	spoke multipoint (HSMP) LSP, which has one root node and one or more		and spoke multipoint (HSMP) LSP, which has one root node and one or
	leaf nodes. HSMP LSP allows traffic both from root to leaf through		more leaf nodes. An HSMP LSP allows traffic from root to leaf
	downstream LSP and also leaf to root along the upstream LSP. That		through downstream LSP and also leaf to root along the upstream LSP.
	means traffic entering the HSMP LSP at the root node travels along		That means traffic entering the HSMP LSP at the root node travels
	downstream LSP, exactly as if it is travelling along a P2MP LSP, and		along the downstream LSP, exactly as if it were traveling along a
	traffic entering the HSMP LSP at any other leaf nodes travels along		P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes
	upstream LSP toward only the root node. The upstream LSP should be		travels along the upstream LSP toward only the root node. The
	thought of unicast LSP to the root node, except that it follows the		upstream LSP should be thought of as a unicast LSP to the root node,
	reverse direction of the downstream LSP, rather than routing protocol		except that it follows the reverse direction of the downstream LSP,
	based unicast path. The combination of upstream LSPs initiated from		rather than the unicast path based on the routing protocol. The
	all leaf nodes forms a multipoint-to-point LSP.		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 the following terms and acronyms:
	mLDP: Multipoint extensions for Label Distribution Protocol (LDP)		mLDP: Multipoint extensions for Label Distribution Protocol (LDP)
	defined in [RFC6388].		defined in [RFC6388].
	P2MP LSP: point-to-multipoint Label Switched Path. An LSP that		P2MP LSP: point-to-multipoint Label Switched Path. An LSP that
	has one Ingress Label Switching Router (LSR) and one or more		has one Ingress Label Switching Router (LSR) and one or more
	Egress LSRs.		Egress LSRs.
	MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP		MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP
	that connects a set of nodes, such that traffic sent by any node		that connects a set of nodes, such that traffic sent by any node
	in the LSP is delivered to all others.		in the LSP is delivered to all others.
	HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that		HSMP LSP: hub and spoke multipoint Label Switched Path. An LSP
	has one root node and one or more leaf nodes, allows traffic from		that has one root node and one or more leaf nodes, allows traffic
	root to all leaf nodes along downstream P2MP LSP and also leaf to		from the root to all leaf nodes along the downstream P2MP LSP and
	root node along the upstream unicast LSP.		also leaf to root node along the upstream unicast LSP.
	FEC: Forwarding Equivalence Class		FEC: Forwarding Equivalence Class
	3. Setting up HSMP LSP with LDP		3. Setting Up HSMP LSP with LDP
	HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the		An HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the
	difference that, when the leaf LSRs send traffic on the LSP, the		difference being that, when the leaf LSRs send traffic on the LSP,
	traffic is first delivered only to the root node and follows the		the 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		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		then distributes the traffic on the P2MP tree to all of the leaf
	nodes.		nodes.
	HSMP LSP consists of a downstream path and upstream path. The		An HSMP LSP consists of a downstream path and upstream path. The
	downstream path is same as P2MP LSP, while the upstream path is only		downstream path is the same as P2MP LSP, while the upstream path is
	from leaf to root node, without communication between leaf and leaf		only from leaf to root node, without communication between the leaf
	nodes. The transmission of packets from the root node of an HSMP LSP		nodes themselves. The transmission of packets from the root node of
	to the receivers (the leaf nodes) is identical to that of a P2MP LSP.		an HSMP LSP to the receivers (the leaf nodes) is identical to that of
	Traffic from a leaf node to the root follows the upstream path that		a P2MP LSP. Traffic from a leaf node to the root follows the
	is the reverse of the path from the root to the leaf. Unlike an		upstream path that is the reverse of the path from the root to the
	MP2MP LSP, traffic from a leaf node does not branch toward other leaf		leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch
	nodes, but is sent direct to the root where it is placed on the P2MP		toward other leaf nodes, but it is sent direct to the root where it
	path and distributed to all leaf nodes including the original sender.		is placed on the P2MP path and distributed to all leaf nodes
			including the original sender.
	To set up the upstream path of an HSMP LSP, ordered mode MUST be		To set up the upstream path of an HSMP LSP, ordered mode MUST be
	used. Ordered mode can guarantee a leaf to start sending packets to		used. Ordered mode can guarantee that a leaf will start sending
	root immediately after the upstream path is installed, without being		packets to the root immediately after the upstream path is installed,
	dropped due to an incomplete LSP.		without being dropped due to an incomplete LSP.
	3.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		An 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. Below 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| HSMP LSP Cap(TBD IANA) | Length |		|U|F| HSMP LSP Cap (0x0902) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 1. HSMP LSP Capability Parameter encoding
	U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be		Figure 1: HSMP LSP Capability Parameter Encoding
	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		U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST
	of this bit MUST be 0 since a Capability Parameter TLV is sent only		be 1. The unknown TLV MUST be silently ignored and the rest
	in Initialization and Capability messages, which are not forwarded.		of the message processed as if the unknown TLV did not exist.
	The length SHOULD be 1, and the S bit and reserved bits are defined		F-bit: Forward unknown TLV bit, as described in [RFC5036]. The
	in [RFC5561] section 3.		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 HSMP LSP Capability Parameter type is to be assigned by IANA.		Length: SHOULD be 1.
			S-bit: As defined in Section 3 of [RFC5561].
			Reserved: As defined in Section 3 of [RFC5561].
			HSMP LSP Capability Parameter type: 0x0902.
	If the peer has not advertised the corresponding capability, then		If the peer has not advertised the corresponding capability, then
	label messages using the HSMP Forwarding Equivalence Class (FEC)		label messages using the HSMP Forwarding Equivalence Class (FEC)
	Element SHOULD NOT (as described in [RFC6388] section 2.1) be sent to		Element SHOULD NOT be sent to the peer (as described in Section 2.1
	the peer. Since ordered mode is applied for HSMP LSP signalling, the		of [RFC6388]). Since ordered mode is applied for HSMP LSP signaling,
	label message break would ensure that the initiating leaf node is		the label message break would ensure that the initiating leaf node is
	unable to establish the upstream path to root node.		unable to establish the upstream path to root node.
	3.2. HSMP FEC Elements		3.2. HSMP FEC Elements
	Similar as MP2MP LSP, we define two new protocol entities, the HSMP		We define two new protocol entities: the HSMP Downstream FEC Element
	Downstream FEC Element and Upstream FEC Element. If a FEC TLV		and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC
	contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be		Elements, the HSMP FEC Element MUST be the only FEC Element in the
	the only FEC Element in the FEC TLV. The structure, encoding and		FEC TLV. The structure, encoding, and error handling for the HSMP-
	error handling for the HSMP Downstream FEC Element and Upstream FEC		downstream FEC Element and HSMP-upstream FEC Element are the same as
	Element are the same as for the P2MP FEC Element described in		for the P2MP FEC Element described in Section 2.2 of [RFC6388]. The
	[RFC6388] Section 2.2. The difference is that two additional new FEC		difference is that two additional new FEC types are defined: HSMP-
	types are defined: HSMP Downstream FEC (to be assigned by IANA) and		downstream FEC (10) and HSMP-upstream FEC (9).
	HSMP Upstream FEC (to be assigned by IANA).
	3.3. Using the HSMP FEC Elements		3.3. Using the HSMP FEC Elements
	In order to describe the message processing clearly, the entries in		The entries in the list below describe the processing of the HSMP FEC
	the list below define the processing of the HSMP FEC Elements.		Elements. Additionally, the entries defined in Section 3.3 of
	Additionally, the entries defined in [RFC6388] section 3.3 are also		[RFC6388] 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
	LSP downstream path with root node address X and opaque value Y.		HSMP 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
	upstream path for root node address X and opaque value Y which will		LSP upstream path for root node address X and opaque value Y
	be used by any of downstream node to send traffic upstream to root		that will be used by any downstream node to send traffic
	node.		upstream to root node.
	3. HSMP downstream FEC Element <X, Y>: a FEC Element with root node		3. HSMP-downstream FEC Element <X, Y>: a FEC Element with root node
	address X and opaque value Y used for a downstream HSMP LSP.		address X and opaque value Y used for a downstream HSMP LSP.
	4. HSMP upstream FEC Element <X, Y>: a FEC Element with root node		4. HSMP-upstream FEC Element <X, Y>: a FEC Element with root node
	address X and opaque value Y used for an upstream HSMP LSP.		address X and opaque value Y used for an upstream HSMP LSP.
	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 MUST be allocated from the per-platform label space of the		label L. Label L MUST be allocated from the per-platform label
	LSR sending the Label Mapping Message.		space of the 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
	Label Lu MUST be allocated from the per-platform label space of the		Lu. Label Lu MUST be allocated from the per-platform label
	LSR sending the Label Mapping Message.		space of the LSR sending the Label Mapping Message.
	7. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a		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		FEC TLV with a single HSMP-downstream FEC Element <X, Y> and
	TLV with label L.		label TLV with label L.
	8. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a		8. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with
	FEC TLV with a single HSMP upstream FEC Element <X, Y> and label TLV		a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and
	with label Lu.		label TLV with label Lu.
	9. HSMP-D Label Release <X, Y, L>: a Label Release message with a		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		FEC TLV with a single HSMP-downstream FEC Element <X, Y> and
	TLV with label L.		Label TLV with label L.
	10. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a		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		FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label
	with label Lu.		TLV with label Lu.
	3.4. HSMP LSP Label Map		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 a downstream HSMP LSP is
	similar as that of downstream MP2MP LSP described in [RFC6388]. When		similar to that of a downstream MP2MP LSP described in [RFC6388].
	LDP operates in Ordered Label Distribution Control mode [RFC5036],		When LDP operates in Ordered Label Distribution Control mode
	the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping		[RFC5036], the upstream LSP will be set up by sending an HSMP LSP LDP
	message with a label which is allocated by upstream LSR to its		Label Mapping message with a label that is allocated by the upstream
	downstream LSR hop by hop from root to leaf node, installing the		LSR to its downstream LSR hop-by-hop from root to leaf node,
	upstream forwarding table by every node along the LSP. The detail		installing the upstream forwarding table by every node along the LSP.
	procedure of setting up upstream HSMP LSP is different with that of
	upstream MP2MP LSP, and is specified in below section.		The detailed procedure of setting up upstream HSMP LSP is different
			than that of upstream MP2MP LSP, and it is specified in the remainder
			of this 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 4.		those that 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 P2MP LSP described in [RFC6388] Section 2.4.1.1.		procedure for a P2MP LSP described in Section 2.4.1.1 of [RFC6388].
	That is, a node Z that wants to join an HSMP LSP <X, Y> determines		That is, a node Z that wants to join an HSMP LSP <X, Y> determines
	the LDP peer U that is Z's next-hop on the best path from Z to the		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		root node X. If there are multiple upstream LSRs, a local algorithm
	should be applied to ensure that there is a single upstream LSRs for		should be applied to ensure that there is exactly one upstream LSR
	a particular LSP.		for a particular LSP.
	To determining one's HSMP downstream LSR, an upstream LDP peer which		To determine one's HSMP downstream LSR, an upstream LDP peer that
	receives a Label Mapping with HSMP downstream FEC Element from an LDP		receives a Label Mapping with the HSMP-downstream FEC Element from an
	peer D will treat D as HSMP downstream LDP peer.		LDP peer D will treat D as HSMP downstream LDP peer.
	3.4.1. HSMP LSP Leaf Node Operation		3.4.1. HSMP LSP Leaf Node Operation
	The leaf node operation is much the same as the operation of MP2MP		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		LSP defined in Section 3.3.1.4 of [RFC6388]. The only difference is
	FEC elements as specified below.		the FEC elements as specified below.
	A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for		A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for
	<X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D		<X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D
	Label Mapping <X, Y, L> to U. Leaf node Z expects an HSMP-U Label		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		Mapping <X, Y, Lu> from node U and checks whether it already has
	forwarding state for upstream <X, Y>. If not, Z creates forwarding		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		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		the HSMP LSP. How it determines what traffic to forward on this HSMP
	LSP is outside the scope of this document.		LSP is outside the scope of this document.
	3.4.2. HSMP LSP Transit Node Operation		3.4.2. HSMP LSP Transit Node Operation
	The procedure of HSMP-D Label Mapping message is much the same as		The procedure for processing an HSMP-D Label Mapping message is much
	processing MP2MP-D Label Mapping message defined in [RFC6388] Section		the same as that for an MP2MP-D Label Mapping message defined in
	3.3.1.5. The processing of HSMP-U Label Mapping message is different		Section 3.3.1.5 of [RFC6388]. The processing of an HSMP-U Label
	with that of MP2MP-U Label Mapping message as specified below.		Mapping message is different from that of an 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.
	Z checks whether it has forwarding state for downstream <X, Y>. If		Z checks whether it has forwarding state for downstream <X, Y>. If
	not, Z determines its upstream LSR U for <X, Y> as per Section 3.3.		not, Z determines its upstream LSR U for <X, Y> as per Section 3.3.
	Using this Label Mapping to update the label forwarding table MUST		Using this Label Mapping to update the label forwarding table MUST
	NOT be done as long as LSR D is equal to LSR U. If LSR U is different		NOT be done as long as LSR D is equal to LSR U. If LSR U is
	from LSR D, Z will allocate a label L' and install downstream		different from LSR D, Z will allocate a label L' and install
	forwarding state to swap label L' with label L over interface I		downstream forwarding state to swap label L' with label L over
	associated with LSR D and send an HSMP-D Label Mapping <X, Y, L'> to		interface I associated with LSR D and send an HSMP-D Label Mapping
	U. Interface I is determined via the procedures in Section 3.7.		<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		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		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		upstream LSR of <X, Y> and update its forwarding state. Assuming its
	old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its		old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its
	new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>,		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		<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 Mapping from LSR D MUST be retained and MUST NOT update the
	label forwarding table.		label forwarding table.
	Node Z checks if upstream LSR U already has assigned a label Lu to		Node Z checks if the upstream LSR U already has assigned a label Lu
	upstream <X, Y>. If not, transit node Z waits until it receives an		to upstream <X, Y>. If not, transit node Z waits until it receives
	HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label		an 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 not, it allocates a label Lu' and creates a new		label Lu. If it does not, it allocates a label Lu' and creates a new
	label swap for Lu' with Label Lu over interface Iu. Interface Iu is		label swap for Lu' with Label Lu over interface Iu. Interface Iu is
	determined via the procedures in Section 3.7. Node Z determines the		determined via the procedures in Section 3.7. Node Z determines the
	downstream HSMP LSR as per Section 4.3.1, and sends an HSMP-U Label		downstream HSMP LSR as per Section 3.4 and sends an HSMP-U Label
	Mapping <X, Y, Lu'> to node D.		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' swapped to Lu.
	3.4.3. HSMP LSP Root Node Operation		3.4.3. HSMP LSP Root Node Operation
	The procedure of HSMP-D Label Mapping message is much the same as		The procedure for an HSMP-D Label Mapping message is much the same as
	processing MP2MP-D Label Mapping message defined in [RFC6388] Section		processing an MP2MP-D Label Mapping message defined in
	3.3.1.6. The processing of HSMP-U Label Mapping message is different		Section 3.3.1.6 of [RFC6388]. The processing of an HSMP-U Label
	with that of MP2MP-U Label Mapping message as specified below.		Mapping message is different from that of an MP2MP-U Label Mapping
			message as specified below.
	Suppose the root node Z receives an HSMP-D Label Mapping <X, Y, L>		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		from node D. Z checks whether it already has forwarding state for
	downstream <X, Y>. If not, Z creates downstream forwarding state and		downstream <X, Y>. If not, Z creates downstream forwarding state and
	installs a outgoing label L over interface I. Interface I is		installs an outgoing label L over interface I. Interface I is
	determined via the procedures in Section 3.7. If Z already has		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		forwarding state for downstream <X, Y>, then Z will add label L over
	interface I to the existing state.		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 HSMP LSP egress LER. E.g., the forwarding		indicates that Z is the HSMP LSP egress Label Edge Router (LER). For
	state might specify that the label stack is popped and the packet		example, the forwarding state might specify that the label stack is
	passed to some specific application. Node Z determines the		popped and the packet passed to some specific application. Node Z
	downstream HSMP LSR as per Section 3.3, and sends an HSMP-U Label Map		determines the downstream HSMP LSR as per Section 3.3 and sends an
	<X, Y, Lu'> to node D.		HSMP-U Label Map <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.
	Root node could also be a leaf node, and it is able to determine what		The root node could also be a leaf node, and it is able to determine
	traffic to forward on this HSMP LSP which is outside the scope of		what traffic to forward on this HSMP LSP; that determination is
	this document.		outside the scope of this document.
	3.5. HSMP LSP Label Withdraw		3.5. HSMP LSP Label Withdraw
	3.5.1. HSMP Leaf Operation		3.5.1. HSMP Leaf Operation
	If a leaf node Z discovers that it has no need to be an Egress LSR		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		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		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>, 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		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		Release <X, Y, Lu> to U to indicate that the upstream path is no
	longer used and that label Lu can be removed.		longer used and that label Lu can be removed.
	Leaf node Z expects the upstream router U to respond by sending a		Leaf node Z expects the upstream router U to respond by sending a
	downstream Label Release for L.		downstream Label Release for L.
	3.5.2. HSMP Transit Node Operation		3.5.2. HSMP Transit Node Operation
	If a transit node Z receives an HSMP-D Label Withdraw message <X, Y,		If a transit node Z receives an HSMP-D Label Withdraw message
	L> from node D, it deletes label L from its forwarding state		<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		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,		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		Y, Lu> to D because node D already removed Lu and sent a label
	release for Lu to Z.		release for Lu to Z.
	If deleting L from Z's forwarding state for downstream <X, Y> results		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		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		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		check if there are any incoming interfaces in forwarding state
	upstream <X, Y>. If all downstream nodes are released and there is		upstream <X, Y>. If all downstream nodes are released and there is
	no incoming interface, Z should delete the forwarding state upstream		no incoming interface, Z should delete the forwarding state upstream
	<X, Y> and send HSMP-U Label Release message to its upstream node.		<X, Y> and send an HSMP-U Label Release message to its upstream node.
	Otherwise, no HSMP-U Label Release message will be sent to the		Otherwise, no HSMP-U Label Release message will be sent to the
	upstream node.		upstream node.
	3.5.3. HSMP Root Node Operation		3.5.3. HSMP Root Node Operation
	When the root node of an HSMP LSP receives an HSMP-D Label Withdraw		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		message and an HSMP-U Label Release message, the procedure is the
	for transit nodes, except that the root node will not propagate the		same as that for transit nodes, except that the root node will not
	Label Withdraw and Label Release upstream (as it has no upstream).		propagate the Label Withdraw and Label Release upstream (as it has no
			upstream).
	3.6. HSMP LSP Upstream LSR Change		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 2.4.3, only with different processing FEC Element.		Section 2.4.3 of [RFC6388], only with different processing of the FEC
			Element.
	When the upstream LSR changes from U to U', node Z should set up the		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		HSMP LSP <X, Y> to U' by applying the procedures in Section 3.4. Z
	also remove HSMP LSP <X, Y> to U by applying procedure in Section		will also remove the HSMP LSP <X, Y> to U by applying the procedure
	3.5.		in Section 3.5.
	To set up HSMP LSP to U' before/after removing HSMP LSP to U is a		To set up an HSMP LSP to U' before/after removing the HSMP LSP to U
	local matter, and the recommended default behavior is to remove		is a local matter. The recommended default behavior is to remove
	before adding.		before adding.
	3.7. Determining Forwarding Interface		3.7. Determining Forwarding Interface
	The co-routed path between upstream and downstream LSP would be		The upstream and downstream LSPs can be co-routed by applying the
	achieved for HSMP LSP. Both LSR U and LSR D would ensure the same		procedures below. Both LSR U and LSR D would ensure that the same
	interface to send traffic by applying some procedures. For a network		interface sends traffic by applying some procedures. For a network
	with symmetric IGP cost configuration, the following procedure MAY be		with symmetric IGP cost configuration, the following procedure MAY be
	used. To determine the downstream interface, LSR U MUST do a lookup		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		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		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		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		to LSR D. The mechanism to determine the upstream interface is the
	determining the downstream interface by exchanging the role of LSR U		same as that used to determine the downstream interface except the
	and LSR D. If symmetric IGP cost could not be ensured, static route		roles of LSR U and LSR D are switched. If symmetric IGP cost could
	configuration on LSR U and D could also be a possible way to ensure		not be ensured, static route configuration on LSR U and D could also
	co-routed path.		be a way to ensure a co-routed path.
	If co-routed is not required for HSMP LSP, the procedure defined in		If a co-routed path is not required for the HSMP LSP, the procedure
	[RFC6388] Section 2.4.1.2 could be applied. LSR U is free to		defined in Section 2.4.1.2 of [RFC6388] could be applied. LSR U is
	transmit the packet on any of the interfaces to LSR D. The algorithm		free to transmit the packet on any of the interfaces to LSR D. The
	it uses to choose a particular interface is a local matter.		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.		The mechanism to determine the upstream interface is the same as that
			used to determine the downstream interface.
	4. HSMP LSP on a LAN		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 for a downstream MP2MP LSP as described in Section 6.1.1 of
			[RFC6388].
	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 a 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
	label must be the "upstream LSR context label", and the packet's		label must be the "upstream LSR context label" and the packet's
	second label is "LSP label". The HSMP downstream path will be		second label is the "LSP label". The HSMP downstream path will be
	installed in the context-specific forwarding table corresponding to		installed in the context-specific forwarding table corresponding to
	the upstream LSR label. Packets sent by the upstream LSR can be		the upstream LSR label. Packets sent by the upstream LSR can be
	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 kinds of links. That is, the upstream LSR must send a Label
	Mapping message that contains the LSP label for upstream HSMP FEC to		Mapping message that contains the LSP label for the upstream HSMP FEC
	downstream node. Packets travelling upstream need to be forwarded in		to the downstream node. Packets traveling upstream need to be
	the direction of the root by using the label allocated for upstream		forwarded in the direction of the root by using the label allocated
	HSMP FEC.		for the upstream HSMP FEC.
	5. Redundancy Considerations		5. Redundancy Considerations
	In some scenarios, it is necessary to provide two root nodes for		In some scenarios, it is necessary to provide two root nodes for
	redundancy purpose. One way to implement this is to use two		redundancy purposes. 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 and standby. At a given time,
	one HSMP LSP will be active, and the other will be standby. After		only one HSMP LSP will be active; the other will be standby. After
	detecting the failure of active HSMP LSP, the root and leaf nodes		detecting the failure of the 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 details of the redundancy mechanism are
	of the scope.		out of the scope of this document.
	6. Failure Detection of HSMP LSP		6. 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 that end their
	path on the leaf. The leaf node then sends the LSP Ping Echo Reply		MPLS path on the leaf. The leaf node then sends the LSP Ping Echo
	along the upstream path of HSMP LSP, and end on the root that are the		Reply along the upstream path of HSMP LSP, and it ends on the root
	(intended) root node.		that is the (intended) root node.
	New sub-TLVs are required to be assigned by IANA in Target FEC Stack		New sub-TLVs have been assigned by IANA in Target FEC Stack TLV and
	TLV and Reverse-path Target FEC Stack TLV to define the corresponding		Reverse-path Target FEC Stack TLV to define the corresponding HSMP-
	HSMP-downstream FEC type and HSMP-upstream FEC type. In order to		downstream FEC type and HSMP-upstream FEC type. In order to ensure
	ensure the leaf node to send the LSP Ping Echo Reply along the HSMP		that the leaf node sends the LSP Ping Echo Reply along the HSMP
	upstream path, the R bit (Validate Reverse Path) in Global Flags		upstream path, the R flag (Validate Reverse Path) in the Global Flags
	Field defined in [RFC6426] is reused here.		field defined in [RFC6426] is reused 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 the HSMP LSP is inherited from [RFC6425] and Section 3.4 of
	except the following:		[RFC6426], except for the following:
	1. The root node sending LSP Ping Echo Request message for HSMP LSP		1. The root node sending the LSP Ping Echo Request message for the
	MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit		HSMP LSP MUST attach the Target FEC Stack TLV with the HSMP-
	to '1' in Global Flags Field.		downstream FEC type, and set the R flag to '1' in the Global
			Flags field.
	2. When the leaf node receiving the LSP Ping Echo Request, it MUST		2. When the leaf node receives 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
	The Reverse-path Target FEC Stack TLV attached by leaf node in Echo		path. The Reverse-path Target FEC Stack TLV attached by the leaf
	Reply message SHOULD contain the sub-TLV of associated HSMP upstream		node in the Echo Reply message SHOULD contain the sub-TLV of the
	FEC.		associated HSMP-upstream FEC.
	7. 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].		beyond those in [RFC6388] and [RFC6425].
	8. IANA Considerations		8. IANA Considerations
	8.1. New LDP FEC Element types		8.1. New LDP FEC Element Types
	This document requires allocation of two new LDP FEC Element types		Two new LDP FEC Element types have been allocated from the "Label
	from the "Label Distribution Protocol (LDP) Parameters registry" the		Distribution Protocol (LDP) Parameters" registry, under "Forwarding
	"Forwarding Equivalence Class (FEC) Type Name Space":		Equivalence Class (FEC) Type Name Space":
	1. the HSMP-upstream FEC type - requested value TBD		1. the HSMP-upstream FEC type - 9
	2. the HSMP-downstream FEC type - requested value TBD		2. the HSMP-downstream FEC type - 10
	The values should be allocated using the lowest free values from the		The values have been allocated from the "IETF Consensus" [RFC5226]
	"IETF Consensus"-range (0-127).		range (0-127).
	8.2. HSMP LSP capability TLV		8.2. HSMP LSP Capability TLV
	This document requires allocation of one new code points for the HSMP		One new code point has been allocated for the HSMP LSP capability TLV
	LSP capability TLV from "Label Distribution Protocol (LDP) Parameters		from "Label Distribution Protocol (LDP) Parameters" registry, under
	registry" the "TLV Type Name Space":		"TLV Type Name Space":
	HSMP LSP Capability Parameter - requested value TBD		HSMP LSP Capability Parameter - 0x0902
	The value should be allocated from the range 0x0901-0x3DFF (IETF		The value has been allocated from the"IETF Consensus" range
	Consensus) using the first free value within this range.		(0x0901-0x3DFF).
	8.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		Two new sub-TLV types have been allocated for inclusion within the
	inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV		LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1), Reverse-path
	type 1) and Reverse-path Target FEC Stack TLV (TLV type 16).		Target FEC Stack TLV (TLV type 16), and Reply Path TLV (TLV type 21).
	1. the HSMP-upstream LDP FEC Stack - requested value TBD		o the HSMP-upstream LDP FEC Stack - 29
	2. the HSMP-downstream LDP FEC Stack - requested value TBD		o the HSMP-downstream LDP FEC Stack - 30
	The value should be allocated from the IETF Standards Action range		The value has been 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.
	using the lowest free value within this range.
	9. Acknowledgement		9. Acknowledgements
	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, and Loa Andersson for their valuable
	comments.		comments.
	10. References		10. References
	10.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
	RFC 5331, August 2008.		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.
	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.		[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
	Le Roux, "LDP Capabilities", RFC 5561, July 2009.		Le Roux, "LDP Capabilities", RFC 5561, July 2009.
	[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,		[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
	"Label Distribution Protocol Extensions for Point-to-		"Label Distribution Protocol Extensions for Point-to-
	Multipoint and Multipoint-to-Multipoint Label Switched		Multipoint and Multipoint-to-Multipoint Label Switched
	Paths", RFC 6388, November 2011.		Paths", RFC 6388, November 2011.
	[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label		[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
	Assignment for LDP", RFC 6389, November 2011.		Assignment for LDP", RFC 6389, November 2011.
	[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
	RFC 6425, November 2011.		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.
	10.2. Informative References		10.2. Informative References
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	February 2006.		February 2006.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	Authors' Addresses		Authors' Addresses
	Lizhong Jin		Lizhong Jin
	Shanghai, China		Shanghai
			China
	Email: lizho.jin@gmail.com		EMail: lizho.jin@gmail.com
	Frederic Jounay		Frederic Jounay
	France Telecom		Orange CH
	2, avenue Pierre-Marzin		4 rue du Caudray
	22307 Lannion Cedex, FRANCE		1007 Lausanne
			Switzerland
	Email: frederic.jounay@orange.ch		EMail: frederic.jounay@orange.ch
	IJsbrand Wijnands		IJsbrand Wijnands
	Cisco Systems, Inc		Cisco Systems, Inc
	De kleetlaan 6a		De kleetlaan 6a
	Diegem 1831, Belgium		Diegem 1831
			Belgium
			EMail: ice@cisco.com
	Email: ice@cisco.com
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom AG		Deutsche Telekom AG
	Winterfeldtstrasse 21		Winterfeldtstrasse 21
	Berlin 10781		Berlin 10781
			Germany
	Email: N.Leymann@telekom.de		EMail: N.Leymann@telekom.de
End of changes. 113 change blocks.
	317 lines changed or deleted		330 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/