< draft-ietf-mpls-mldp-hsmp-01.txt		draft-ietf-mpls-mldp-hsmp-02.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: October 20, 2013 France Telecom		Expires: April 14, 2014 France Telecom
	I. Wijnands		I. Wijnands
	Cisco Systems, Inc		Cisco Systems
	N. Leymann		N. Leymann
	Deutsche Telekom AG		Deutsche Telekom
	April 18, 2013		October 11, 2013
	LDP Extensions for Hub & Spoke Multipoint Label Switched Path		LDP Extensions for Hub & Spoke Multipoint Label Switched Path
	draft-ietf-mpls-mldp-hsmp-01.txt		draft-ietf-mpls-mldp-hsmp-02.txt
	Abstract		Abstract
	This draft introduces a hub & spoke multipoint LSP (short for HSMP		This draft introduces a hub & spoke multipoint LSP (or HSMP LSP for
	LSP), which allows traffic both from root to leaf through P2MP LSP		short), which allows traffic both from root to leaf through P2MP LSP
	and also leaf to root along the co-routed reverse path. That means		and also leaf to root along the co-routed reverse path. That means
	traffic entering the HSMP LSP from application/customer at the root		traffic entering the HSMP LSP from application/customer at the root
	node travels downstream, exactly as if it was traveling downstream		node travels downstream to each leaf node, exactly as if it is
	along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP		travelling downstream along a P2MP LSP to each leaf node. Upstream
	at any leaf node travels upstream along the tree to the root as if it		traffic entering the HSMP LSP at any leaf node travels upstream along
	is unicast to the root, except that it follows the path of the tree		the tree to the root, as if it is unicast to the root, and strictly
	rather than ordinary unicast to the root.		follows the downstream path of the tree rather than routing protocol
			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 1, line 48 ¶		skipping to change at page 2, line 4 ¶
	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 14, 2014.
	This Internet-Draft will expire on October 20, 2013.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Time synchronization scenario . . . . . . . . . . . . . . 4		3.1. Time Synchronization Scenario . . . . . . . . . . . . . . 5
	3.2. VPMS scenario . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Virtual Private Multicast Service Scenario . . . . . . . . 5
	3.3. IPTV scenario . . . . . . . . . . . . . . . . . . . . . . 4		3.3. IPTV Scenario . . . . . . . . . . . . . . . . . . . . . . 5
	4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5		4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 6
	4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5		4.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 6
	4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6		4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 7
	4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6		4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 7
	4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6		4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 8
	4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8		4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 10
	4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9		4.3.3. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . 10
	5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9		5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10
	6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9		6. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
	7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9		7. Co-routed Path Exceptions . . . . . . . . . . . . . . . . . . 11
	8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 10		8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11		11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Normative references . . . . . . . . . . . . . . . . . . . 11		12.1. Normative references . . . . . . . . . . . . . . . . . . . 13
	12.2. Informative References . . . . . . . . . . . . . . . . . . 12		12.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The point-to-multipoint LSP defined in [RFC6388] allows traffic to		The point-to-multipoint LSP defined in [RFC6388] allows traffic to
	transmit from root to several leaf nodes, and multipoint-to-		transmit from root to several leaf nodes, and multipoint-to-
	multipoint LSP allows traffic from every node to transmit to every		multipoint LSP allows traffic from every node to transmit to every
	other node. This draft introduces a hub & spoke multipoint LSP		other node. This draft introduces a hub & spoke multipoint LSP (or
	(short for HSMP LSP), which allows traffic both from root to leaf		HSMP LSP for short), which allows traffic both from root to leaf
	through P2MP LSP and also leaf to root along the co-routed reverse		through P2MP LSP and also leaf to root along the co-routed reverse
	path. That means traffic entering the HSMP LSP at the root node		path. That means traffic entering the HSMP LSP at the root node
	travels downstream, exactly as if it was traveling downstream along a		travels downstream, exactly as if it is travelling downstream along a
	P2MP LSP, and traffic entering the HSMP LSP at any other node travels		P2MP LSP, and traffic entering the HSMP LSP at any other node travels
	upstream along the tree to the root. A packet traveling upstream		upstream along the tree to the root. A packet travelling upstream
	should be thought of as being unicast to the root, except that it		should be thought of as being unicast to the root, except that it
	follows the path of the tree rather than ordinary unicast to the		follows the path of the tree rather than routing protocol based
	root.		unicast path to the root. 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:
	mLDP: Multipoint extensions for LDP		HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both
			from root to leaf through P2MP LSP and also leaf to root along the
			co-routed reverse path.
	P2MP LSP: An LSP that has one Ingress LSR and one or more Egress		mLDP: Multipoint extensions for LDP
	LSRs.
	MP2MP LSP: An LSP that connects a set of nodes, such that traffic		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.		sent by any node in the LSP is delivered to all others.
	HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both
	from root to leaf through P2MP LSP and also leaf to root along the
	co-routed reverse path.
	PTP: The timing and synchronization protocol used by IEEE1588		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		3. Applications
	In some cases, the P2MP LSP may not have a reply path for the OAM		In some cases, the P2MP LSP may not have a reply path for OAM
	message (e.g, LSP Ping). If P2MP LSP is provided by HSMP LSP, then		messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by
	the upstream path could be exactly used as the OAM message reply		HSMP LSP instead, then the upstream path could be used as the OAM
	path. This is especially useful in the case of P2MP LSP fault		message reply path. This is especially useful in the case of P2MP
	detection, performance measurement, root node redundancy and etc.		LSP fault detection, performance measurement, root node redundancy
	There are several other applications that could take advantage of		and etc. There are several other applications that could take
	such kind of LDP based HSMP LSP as described below.		advantage of a LDP based HSMP LSP as described below.
	3.1. Time synchronization scenario		3.1. Time Synchronization Scenario
	[IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls].		[IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls].
	It is required that the LSP used to transport PTP event message		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		between a Master Clock and a Slave Clock, and the LSP between the
	same Slave Clock and Master Clock must be co-routed. By using point-		same Slave Clock and Master Clock must be co-routed. Using point-to-
	to-multipoint technology to transmit PTP event messages from Master		multipoint technology to transmit PTP event messages from Master
	Clock at root side to Slave Clock at leaf side will greatly improve		Clock at root side to Slave Clock at leaf side will greatly improve
	the bandwidth usage. Unfortunately current point-to-multipoint LSP		the bandwidth usage. Unfortunately current point-to-multipoint LSP
	only provides unidirectional path from root to leaf, which cannot		only provides unidirectional path from root to leaf, which cannot
	provide a co-routed reverse path for the PTP event messages. LDP		provides a co-routed reverse path for the PTP event messages. LDP
	based HSMP LSP described in this draft provides unidirectional point-		based HSMP LSP described in this draft provides unidirectional point-
	to-multipoint LSP from root to leaf and co-routed reverse path from		to-multipoint LSP from root to leaf and co-routed reverse LSP from
	leaf to root.		leaf to root.
	3.2. VPMS scenario		3.2. Virtual Private Multicast Service Scenario
	Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires		Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires
	to setup reverse path from leaf node (referred as egress PE) to root		to set up reverse path from leaf node (referred as egress PE) to root
	node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP		node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP
	PW, the reverse path can also be multiplexed to HSMP upstream path to		PW, the reverse path can also be multiplexed to HSMP upstream path to
	avoid setup independent reverse path. In that case, the operational		avoid setup independent reverse path. In that case, the operational
	cost will be reduced for maintaining only one HSMP LSP, instead of		cost will be reduced for maintaining only one HSMP LSP, instead of
	P2MP LSP and n (number of leaf nodes) P2P reverse LSPs.		P2MP LSP and n (number of leaf nodes) P2P reverse LSPs.
	The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires		The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires
	reverse path from leaf to root node. The P2MP PW multiplexed to HSMP		reverse path from leaf to root node. The P2MP PW multiplexed to HSMP
	LSP can provide VPMS with reverse path, without introducing		LSP can provide VPMS with reverse path, without introducing
	independent reverse path from each leaf to root.		independent reverse path from each leaf to root.
	3.3. IPTV scenario		3.3. IPTV Scenario
	The mLDP based HSMP LSP can also be applied in a typical IPTV		The mLDP based HSMP LSP can also be applied in a typical IPTV
	scenario. There is usually only one location with senders but there		scenario. There is usually only one location with senders but there
	are many receiver locations. If IGMP is used for signaling between		are many receiver locations. If IGMP is used for signalling between
	senders as IGMP querier and receivers, the IGMP messages from the		senders as IGMP querier [RFC3376] and receivers, the IGMP messages
	receivers are travelling only from the leaves to the root (and from		from the receivers are travelling only from the leaves to the root
	root towards leaves) but not from leaf to leaf. In addition traffic		(and from root towards leaves) but not from leaf to leaf. In
	from the root is only replicated towards the leaves. Then leaf node		addition traffic from the root is only replicated towards the leaves.
	receiving IGMP message (for SSM case) will join HSMP LSP, and then		Then leaf node receiving IGMP report message (for source specific
	send IGMP message upstream to root along HSMP LSP. Note that in		multicast case) will join HSMP LSP(use similar mechanism in [RFC6826]
	above case, there is no node redundancy for IGMP querier. And the		section 2), and then send IGMP report message upstream to root along
	node redundancy for IGMP querier could be provided by two independent		HSMP upstream LSP. Note that in above case, there is no node
	VPMS instances with HSMP applied.		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		4. Setting up HSMP LSP with LDP
	HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the		HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the
	difference that the leaf LSRs can only send traffic to root node		difference that the leaf LSRs can only send traffic to root node
	along the same path of traffic from root node to leaf node.		along the same path of traffic from root node to leaf node.
	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 MP2MP 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 a 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 is identical to that of a P2MP LSP. Traffic from a
	leaf node follows the upstream path toward the root node, along the		leaf node follows the upstream path toward the root node, along a
	identical path of downstream path.		path that traverse the same nodes as the downstream node, but in
			reverse order.
	For setting up the upstream path of a HSMP LSP, ordered mode MUST be		For setting up the upstream path of an HSMP LSP, ordered mode MUST be
	used which is same as MP2MP. Ordered mode can guarantee a leaf to		used which is same as MP2MP. Ordered mode can guarantee a leaf to
	start sending packets to root immediately after the upstream path is		start sending packets to root immediately after the upstream path is
	installed, without being dropped due to an incomplete LSP.		installed, without being dropped due to an incomplete LSP.
	Due to much of same behavior between HSMP LSP and MP2MP LSP, the		Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the
	following sections only describe the difference between the two		following sections only describe the difference between the two
	entities.		entities.
	4.1. Support for HSMP LSP setup with LDP		4.1. Support for HSMP LSP Setup with LDP
	HSMP LSP also needs the LDP capabilities [RFC5561] to indicate the		HSMP LSP requires the LDP capabilities [RFC5561] for nodes to
	supporting for the setup of HSMP LSPs. An implementation supporting		indicate that they support setup of HSMP LSPs. An implementation
	the HSMP LSP procedures specified in this document MUST implement the		supporting the HSMP LSP procedures specified in this document MUST
	procedures for Capability Parameters in Initialization Messages.		implement the procedures for Capability Parameters in Initialization
	Advertisement of the HSMP LSP Capability indicates support of the		Messages. Advertisement of the HSMP LSP Capability indicates support
	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
	Following is the format of the HSMP LSP Capability Parameter.		Parameter. Following is the format of the HSMP LSP Capability
			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 (= 1) |		|1|0| HSMP LSP Cap(TBD IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 1. HSMP LSP Capability Parameter encoding		Figure 1. HSMP LSP Capability Parameter encoding
	The HSMP LSP capability type is to be assigned by IANA.		The length SHOULD be 1, and the S bit and reserved bits are defined
			in [RFC5561] section 3.
			The HSMP LSP Capability Parameter type is to be assigned by IANA.
	4.2. HSMP FEC Elements		4.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 and upstream FEC Element. If a FEC TLV contains an		Downstream FEC Element and Upstream FEC Element. If a FEC TLV
	HSMP FEC Element, the HSMP FEC Element MUST be the only FEC Element		contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be
	in the FEC TLV. The structure, encoding and error handling for the		the only FEC Element in the FEC TLV. The structure, encoding and
	HSMP downstream and upstream FEC Elements are the same as for the		error handling for the HSMP Downstream FEC Element and Upstream FEC
	MP2MP FEC Element described in [RFC6388] Section 4.2. The difference		Element are the same as for the MP2MP FEC Element described in
	is that two additional new FEC types are used: HSMP downstream type		[RFC6388] Section 3.2. The difference is that two additional new FEC
	(TBD, IANA) and HSMP upstream type (TBD, IANA).		types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream
			FEC(TBD, IANA).
	4.3. Using the HSMP FEC Elements		4.3. Using the HSMP FEC Elements
	In order to describe the message processing clearly, following		In order to describe the message processing clearly, the entries in
	defines the processing of the HSMP FEC Elements, which is inherited		the list below define the processing of the HSMP FEC Elements.
	from [RFC6388] section 4.3.		Additionally, the entries defined in [RFC6388] section 3.3 are also
			reused in the following sections.
	1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): a 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>): a HSMP LSP		2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP
	upstream path for root node address X and opaque value Y which will		upstream path for root node address X and opaque value Y which will
	be used by any of downstream node to send traffic upstream to root		be used by any of downstream node to send traffic upstream to root
	node.		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 Map <X, Y, L>: A Label Map message with a single		5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a
	HSMP downstream FEC Element <X, Y> and label TLV with label L. Label		single HSMP downstream FEC Element <X, Y> and label TLV with label L.
	L MUST be allocated from the per-platform label space of the LSR		Label L MUST be allocated from the per-platform label space of the
	sending the Label Map Message.		LSR sending the Label Mapping Message.
	6. HSMP-U Label Map <X, Y, Lu>: A Label Map message with a single		6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a
	HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label		single HSMP upstream FEC Element <X, Y> and label TLV with label Lu.
	Lu MUST be allocated from the per-platform label space of the LSR		Label Lu MUST be allocated from the per-platform label space of the
	sending the Label Map Message.		LSR sending the Label Mapping Message.
	4.3.1. HSMP LSP Label Map		4.3.1. HSMP LSP Label Map
	This section specifies the procedures for originating HSMP Label Map		This section specifies the procedures for originating HSMP Label
	messages and processing received HSMP label map messages for a		Mapping messages and processing received HSMP Label Mapping messages
	particular HSMP LSP. The procedure of downstream HSMP LSP is same as		for a particular HSMP LSP. The procedure of downstream HSMP LSP is
	that of downstream MP2MP LSP described in [RFC6388]. Under the		same as that of downstream MP2MP LSP described in [RFC6388]. When
	operation of ordered mode, the upstream LSP will be setup by sending		LDP operates in Ordered Label Distribution Control mode [RFC5036],
	HSMP LSP mapping message with label which is allocated by upstream		the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping
	LSR to its downstream LSR one by one from root to leaf node,		message with a label which is allocated by upstream LSR to its
	installing the upstream forwarding table by every node along the LSP.		downstream LSR hop by hop from root to leaf node, installing the
	Detail procedure of upstream HSMP LSP is different with that of		upstream forwarding table by every node along the LSP. The detail
			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 5.
	Determining the upstream LSR for a 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 4.3.1.1.		procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1.
	Determining one's downstream HSMP LSR procedure is much same as		Determining one's HSMP downstream LSR follows the procedure defined
	defined in [RFC6388] section 4.3.1.2. A LDP peer U which receives a		in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which
	HSMP-D Label Map from a LDP peer D will treat D as downstream HSMP		receives a Label Mapping with HSMP downstream FEC Element from an LDP
	LSR.		peer D will treat D as HSMP downstream LDP peer.
	Determining the forwarding interface to an LSR has same procedure as		Determining the forwarding interface to an LSR follows the procedure
	defined in [RFC6388] section 2.4.1.2.		as defined in [RFC6388] section 2.4.1.2.
	4.3.1.1. HSMP LSP leaf node operation		4.3.1.1. HSMP LSP Leaf Node Operation
	The leaf node operation is same as the operation of MP2MP LSP defined		The leaf node operation is same as the operation of MP2MP LSP defined
	in [RFC6388] section 4.3.1.4, only with different FEC element		in [RFC6388] section 3.3.1.4. The only difference is the FEC
	processing and specified below.		elements as specified below.
	A leaf node Z will send a HSMP-D Label Map <X, Y, L> to U, instead of		A leaf node Z will send an HSMP-D Label Mapping <X, Y, L> to U,
	MP2MP-D Label Map <X, Y, L>. and expects a HSMP-U Label Map <X, Y,		instead of MP2MP-D Label Mapping <X, Y, L>, and expects an HSMP-U
	Lu> from node U and checks whether it already has forwarding state		Label Mapping <X, Y, Lu> from node U and checks whether it already
	for upstream <X, Y>. The created forwarding state on leaf node Z is		has forwarding state for upstream <X, Y>. The created forwarding
	same as the leaf node of MP2MP LSP. Z will push label Lu onto the		state on leaf node Z is same as the leaf node of MP2MP LSP. Z will
	traffic that Z wants to forward over the HSMP LSP.		push label Lu onto the traffic that Z wants to forward over the HSMP
			LSP.
	4.3.1.2. HSMP LSP transit node operation		4.3.1.2. HSMP LSP Transit Node Operation
	Suppose node Z receives a HSMP-D Label Map <X, Y, L> from LSR D, the		Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D,
	procedure is same as processing MP2MP-D Label Mapping message defined		the procedure is much the same as processing MP2MP-D Label Mapping
	in [RFC6388] section 4.3.1.5, and the processing protocol entity is		message defined in [RFC6388] section 3.3.1.5, and the processing
	HSMP-D label mapping message. The different procedure is specified		protocol entity is HSMP-D Label Mapping message. The only difference
	below.		is specified below.
	Node Z checks if upstream LSR U already 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 a		upstream <X, Y>. If not, transit node Z waits until it receives an
	HSMP-U Label Map <X, Y, Lu> from LSR U. Once the HSMP-U Label Map is		HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label
	received from LSR U, node Z checks whether it already has forwarding		Mapping is received from LSR U, node Z checks whether it already has
	state upstream <X, Y> with incoming label Lu' and outgoing label Lu.		forwarding state upstream <X, Y> with incoming label Lu' and outgoing
	If it does, Z sends a HSMP-U Label Map <X, Y, Lu'> to downstream		label Lu. If it does, Z sends an HSMP-U Label Mapping <X, Y, Lu'> to
	node. 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 4.3.1. Node Z determines		Interface Iu is determined via the procedures in section 4.3.1. Node
	the downstream HSMP LSR as per Section 4.3.1, and sends a HSMP-U		Z determines the downstream HSMP LSR as per section 4.3.1, and sends
	Label Map <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) can be		upstream node, the same label (representing the upstream path) SHOULD
	distributed to all downstream nodes. This differs from the		be distributed to all downstream nodes. This differs from the
	procedures for MPMP 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 send		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		4.3.1.3. HSMP LSP Root Node Operation
	Suppose root node Z receives a HSMP-D Label Map <X, Y, L> from node		Suppose root node Z receives an HSMP-D Label Mapping <X, Y, L> from
	D, the procedure is much same as processing MP2MP-D Label Mapping		node D, the procedure is much the same as processing MP2MP-D Label
	message defined in [RFC6388] section 4.3.1.6, and the processing		Mapping message defined in [RFC6388] section 3.3.1.6, and the
	protocol entity is HSMP-D label mapping message. The different		processing protocol entity is HSMP-D Label Mapping message. The only
	procedure is specified below.		difference is specified below.
	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 LSP egress. E.g., the forwarding state might
	specify that the label stack is popped and the packet passed to some		specify that the label stack is popped and the packet passed to some
	specific application. Node Z determines the downstream HSMP LSR as		specific application. Node Z determines the downstream HSMP LSR as
	per section 4.3.1, and sends a HSMP-U Label Map <X, Y, Lu'> to node		per section 4.3.1, and sends an HSMP-U Label Map <X, Y, Lu'> to node
	D.		D.
	Since Z is the root of the tree, Z will not send a 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 a HSMP-U Label Map.		and will not receive an HSMP-U Label Mapping.
	4.3.2. HSMP LSP Label Withdraw		4.3.2. HSMP LSP Label Withdraw
	The HSMP Label Withdraw procedure is much same as MP2MP leaf		The HSMP Label Withdraw procedure is much the same as MP2MP leaf
	operation defined in [RFC6388] section 4.3.2, and the processing		operation defined in [RFC6388] section 3.3.2, and the processing FEC
	protocol entities are HSMP FECs. The only difference is process of		Elements are HSMP FEC Elements. The only difference is the process
	HSMP-U label release message, which is specified below.		of HSMP-U Label Release message, which is specified below.
	When a transit node Z receives a HSMP-U label release message from		When a transit node Z receives an HSMP-U Label Release message from
	downstream node D, Z should check if there are any incoming interface		downstream node D, Z should check if there are any incoming interface
	in forwarding state upstream <X, Y>. If all downstream nodes are		in forwarding state upstream <X, Y>. If all downstream nodes are
	released and there is no incoming interface, Z should delete the		released and there is no incoming interface, Z should delete the
	forwarding state upstream <X, Y> and send HSMP-U label release		forwarding state upstream <X, Y> and send HSMP-U Label Release
	message to its upstream node.		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		4.3.3. 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 4.3.3, except it is applied to HSMP FECs.		[RFC6388] section 3.3.3, only with different processing FEC Element,
			the HSMP FEC Element.
	5. HSMP LSP on a LAN		5. HSMP LSP on a LAN
	The procedure to process P2MP LSP on a LAN has been described in		The procedure to process the downstream HSMP LSP on a LAN is much the
	[RFC6388]. When the LSR forwards a packet downstream on one of those		same as downstream MP2MP LSP described in [RFC6388] section 6.1.1.
	LSPs, the packet's top label must be the "upstream LSR label", and
	the packet's second label is "LSP label".
	When establishing the downstream path of a HSMP LSP, as defined in		When establishing the downstream path of an HSMP LSP, as defined in
	[RFC6389], a label request for a LSP label is send to the upstream		[RFC6389], a Label Request message for an LSP label is sent to the
	LSR. The upstream LSR should send label mapping that contains the		upstream LSR. The upstream LSR should send Label Mapping message
	LSP label for the downstream HSMP FEC and the upstream LSR context		that contains the LSP label for the downstream HSMP FEC and the
	label. At the same time, it must also send label mapping for		upstream LSR context label defined in [RFC5331]. When the LSR
	upstream HSMP FEC to downstream node. Packets sent by the upstream		forwards a packet downstream on one of those LSPs, the packet's top
	router can be forwarded downstream using this forwarding state based		label must be the "upstream LSR context label", and the packet's
	on a two label lookup. Packets traveling upstream need to be		second label is "LSP label". The HSMP downstream path will be
	forwarded in the direction of the root by using the label allocated		installed in the context-specific forwarding table corresponding to
	by upstream LSR.		the upstream LSR label. Packets sent by the upstream LSR can be
			forwarded downstream using this forwarding state based on a two-label
			lookup.
	6. Redundancy considerations		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
			Mapping message that contains the LSP label for upstream HSMP FEC to
			downstream node. Packets travelling upstream need to be forwarded in
			the direction of the root by using the label allocated for upstream
			HSMP FEC.
			6. 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 new active HSMP LSP which is switched		will switch the traffic to the standby HSMP LSP which takes on the
	from former standby LSP. The detail of redundancy mechanism will be		role as active HSMP LSP. The detail of redundancy mechanism is out
	for future study.		of the scope.
	7. Co-routed path exceptions		7. Co-routed Path Exceptions
	There are some exceptional cases that mLDP based HSMP LSP could not		There are some exceptional cases when mLDP based HSMP LSP could not
	achieve co-routed path. One possible case is using static routing		achieve co-routed path. One possible case is using static routing
	between LDP neighbors; another possible case is IGP cost asymmetric		between LDP neighbors; another possible case is IGP cost asymmetric
	generated by physical link cost asymmetric, or TE-Tunnels used		generated by physical link cost asymmetric, or TE-Tunnels used
	between LDP neighbors. The LSR/LER in HSMP LSP could detect if the		between LDP neighbors. The LSR/LER in HSMP LSP should detect if the
	path is co-routed or not, if not co-routed, an indication could be		path is co-routed or not. If not co-routed, an alarm indication
	generated to the management system.		should be generated to the management system.
	8. Failure Detection of HSMP LSP		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 packets that enter at the root along a particular		to test the LSP Ping Echo Request packets that enter at the root
	downstream path of HSMP LSP, and end their MPLS path on the leaf.		along a particular downstream path of HSMP LSP, and end their MPLS
	The leaf node then sends the LSP ping response along the co-routed		path on the leaf. The leaf node then sends the LSP Ping Echo Reply
	upstream path of HSMP LSP, and end on the root that are the		along the co-routed upstream path of HSMP LSP, and end on the root
	(intended) root node.		that are the (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 response 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 for HSMP LSP is inherited		The node processing mechanism of LSP Ping Echo Request and Echo Reply
	from [RFC6425] and [RFC6426] section 3.4, except the following:		for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4,
			except the following:
	1. The root node sending LSP ping message for HSMP LSP MUST attach		1. The root node sending LSP Ping Echo Request message for HSMP LSP
	Target FEC Stack with HSMP downstream FEC, and set R bit to '1' in		MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit
	Global Flags Field.		to '1' in Global Flags Field.
	2. When the leaf node receiving the LSP ping, it MUST send the LSP		2. When the leaf node receiving the LSP Ping Echo Request, it MUST
	ping response to the associated HSMP upstream path. The Reverse-path		send the LSP Ping Echo Reply to the associated HSMP upstream path.
	Target FEC Stack TLV attached by leaf node in reply message SHOULD		The Reverse-path Target FEC Stack TLV attached by leaf node in Echo
	contain the sub-TLV of associated HSMP upstream FEC.		Reply message SHOULD contain the sub-TLV of associated HSMP upstream
			FEC.
	9. Security Considerations		9. 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
			procedures, the protocol does not bring any new security issues
			compared to [RFC6388] and [RFC6425].
	10. IANA Considerations		10. IANA Considerations
	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
	skipping to change at page 11, line 18 ¶		skipping to change at page 13, line 8 ¶
	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
	11. Acknowledgement		11. 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 for their valuable comments.		Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable
			comments.
	12. References		12. References
	12.1. Normative references		12.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
			Label Assignment and Context-Specific Label Space",
			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.
	[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.
	skipping to change at page 12, line 22 ¶		skipping to change at page 14, line 14 ¶
	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
	Root-Initiated Point-to-Multipoint Pseudowire using LDP",		Root-Initiated Point-to-Multipoint Pseudowire using LDP",
	draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.		draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
	[I-D.ietf-tictoc-1588overmpls]		[I-D.ietf-tictoc-1588overmpls]
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.		Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
	Montini, "Transporting Timing messages over MPLS		Montini, "Transporting Timing messages over MPLS
	Networks", draft-ietf-tictoc-1588overmpls-04 (work in		Networks", draft-ietf-tictoc-1588overmpls-05 (work in
	progress), February 2013.		progress), June 2013.
	[IEEE1588]		[IEEE1588]
	"IEEE standard for a precision clock synchronization		"IEEE standard for a precision clock synchronization
	protocol for networked measurement and control systems",		protocol for networked measurement and control systems",
	IEEE1588v2 , March 2008.		IEEE1588v2 , March 2008.
			[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
			Thyagarajan, "Internet Group Management Protocol, Version
			3", RFC 3376, October 2002.
	[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.
	[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service		[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
	(VPLS) Using Label Distribution Protocol (LDP) Signaling",		(VPLS) Using Label Distribution Protocol (LDP) Signaling",
	RFC 4762, January 2007.		RFC 4762, January 2007.
			[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
			Specification", RFC 5036, October 2007.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay		[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374, September 2011.		Measurement for MPLS Networks", RFC 6374, September 2011.
			[RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
			"Multipoint LDP In-Band Signaling for Point-to-Multipoint
			and Multipoint-to-Multipoint Label Switched Paths",
			RFC 6826, January 2013.
	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		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex, FRANCE		22307 Lannion Cedex, FRANCE
	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
End of changes. 82 change blocks.
	219 lines changed or deleted		264 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/