< draft-jjwl-mpls-mldp-hsmp-00.txt		draft-jjwl-mpls-mldp-hsmp-01.txt >
	Network Working Group L. Jin		Network Working Group L. Jin
	Internet-Draft ZTE		Internet-Draft ZTE Corporation
	Intended status: Standards Track F. Jounay		Intended status: Standards Track F. Jounay
	Expires: February 4, 2013 France Telecom		Expires: March 7, 2013 France Telecom
	I. Wijnands		I. Wijnands
	Cisco Systems		Cisco Systems, Inc
	N. Leymann		N. Leymann
	Deutsche Telekom		Deutsche Telekom AG
	Aug 3, 2012		Sep 3, 2012
	LDP Extensions for Hub & Spoke Multipoint Label Switched Path		LDP Extensions for Hub & Spoke Multipoint Label Switched Path
	draft-jjwl-mpls-mldp-hsmp-00.txt		draft-jjwl-mpls-mldp-hsmp-01.txt
	Abstract		Abstract
	This draft introduces a hub & spoke multipoint LSP (short for HSMP		This draft introduces a hub & spoke multipoint LSP (short for HSMP
	LSP), which allows traffic both from root to leaf through P2MP LSP		LSP), 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, exactly as if it was traveling downstream
	along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP		along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP
	at any leaf node travels upstream along the tree to the root as if it		at any leaf node travels upstream along the tree to the root as if it
	is unicast to the root, except that it follows the path of the tree		is unicast to the root, except that it follows the path of the tree
	rather than ordinary unicast path.		rather than ordinary unicast 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 49 ¶		skipping to change at page 1, line 49 ¶
	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 February 4, 2013.		This Internet-Draft will expire on March 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Time synchronization . . . . . . . . . . . . . . . . . . . 4		3.1. Time synchronization scenario . . . . . . . . . . . . . . 4
	3.2. IPTV scenario . . . . . . . . . . . . . . . . . . . . . . 4		3.2. VPMS scenario . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. P2MP PW based L2VPN (VPMS and VPLS) . . . . . . . . . . . 4		3.3. IPTV scenario . . . . . . . . . . . . . . . . . . . . . . 4
	4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4		4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5
	4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5		4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5
	4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5		4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6
	4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6		4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6
	4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6		4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6
	4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8		4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8
	4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 8		4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9
	5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9		5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9
	6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9		6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9
	7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9		7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative references . . . . . . . . . . . . . . . . . . . 10		11.1. Normative references . . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	(short for HSMP LSP), which allows traffic both from root to leaf		(short for HSMP LSP), 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 was traveling 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 traveling 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 path.		follows the path of the tree rather than ordinary unicast to the
			root.
	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		mLDP: Multipoint extensions for LDP
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 6 ¶
	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 the OAM
	message (e.g, LSP Ping). If P2MP LSP is provided by HSMP LSP, then		message (e.g, LSP Ping). If P2MP LSP is provided by HSMP LSP, then
	the upstream path could be exactly used as the OAM message reply		the upstream path could be exactly used as the OAM message reply
	path. This is especially useful in the case of P2MP LSP fault		path. This is especially useful in the case of P2MP LSP fault
	detection, performance measurement, root node redundancy and etc.		detection, performance measurement, root node redundancy and etc.
	There are several other applications that could take advantage of		There are several other applications that could take advantage of
	such kind of LDP based HSMP LSP as described below.		such kind of LDP based HSMP LSP as described below.
	3.1. Time synchronization		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 same		between a Master Clock and a Slave Clock, and the LSP between the
	Slave Clock and Master Clock must be co-routed. By using point-to-		same Slave Clock and Master Clock must be co-routed. By using point-
	multipoint technology to transmit PTP event messages from Master		to-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 messages. LDP based		provide a co-routed reverse path for the PTP event messages. LDP
	HSMP LSP described in this draft provides unidirectional point-to-		based HSMP LSP described in this draft provides unidirectional point-
	multipoint LSP from root to leaf and co-routed reverse path from leaf		to-multipoint LSP from root to leaf and co-routed reverse path from
	to root.		leaf to root.
	3.2. IPTV scenario
	The mLDP based HSMP LSP can also be applied in a typical IPTV
	scenario. There is usually only one location with senders but there
	are many receiver locations. If IGMP is used for signaling between
	senders as IGMP querier and receivers, the IGMP messages from the
	receivers are travelling only from the leaves to the root (and from
	root towards leaves) but not from leaf to leaf. In addition traffic
	from the root is only replicated towards the leaves. Then leaf node
	receiving IGMP message (for SSM case) will join HSMP LSP, and then
	send IGMP message upstream to root along HSMP LSP. Note that in
	above case, there is no node redundancy for IGMP querier.
	3.3. P2MP PW based L2VPN (VPMS and VPLS)		3.2. VPMS 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 setup 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
			The mLDP based HSMP LSP can also be applied in a typical IPTV
			scenario. There is usually only one location with senders but there
			are many receiver locations. If IGMP is used for signaling between
			senders as IGMP querier and receivers, the IGMP messages from the
			receivers are travelling only from the leaves to the root (and from
			root towards leaves) but not from leaf to leaf. In addition traffic
			from the root is only replicated towards the leaves. Then leaf node
			receiving IGMP message (for SSM case) will join HSMP LSP, and then
			send IGMP message upstream to root along HSMP LSP. Note that in
			above case, there is no node redundancy for IGMP querier. And the
			node redundancy for IGMP querier 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 a HSMP LSP
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 12 ¶
	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 indication could be
	generated to the management system.		generated to the management system.
	8. Security Considerations		8. 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].		in [RFC6388].
	9. IANA Considerations		9. 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
			"Forwarding Equivalence Class (FEC) Type Name Space":
	1. the HSMP-upstream FEC type - requested value 0x09		1. the HSMP-upstream FEC type - requested value TBD
	2. the HSMP-downstream FEC type - requested value 0x10		2. the HSMP-downstream FEC type - requested value TBD
	This document requires the assignment of new code points for the		This document requires allocation of one new code points for the HSMP
	Capability Parameter TLVs, corresponding to the advertisement of the		LSP capability TLV from "Label Distribution Protocol (LDP) Parameters
	HSMP LSP capabilities. The values requested are:		registry" the "TLV Type Name Space":
	HSMP LSP Capability Parameter - requested value 0x050C		HSMP LSP Capability Parameter - requested value TBD
	10. Acknowledgement		10. 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 for their valuable comments.
	11. References		11. References
	11.1. Normative references		11.1. Normative references
End of changes. 23 change blocks.
	46 lines changed or deleted		51 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/