draft-ietf-mpls-mldp-hsmp-04.txt		draft-ietf-mpls-mldp-hsmp-05.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: May 30, 2014 France Telecom		Expires: June 14, 2014 France Telecom
	I. Wijnands		I. Wijnands
	Cisco Systems, Inc		Cisco Systems, Inc
	N. Leymann		N. Leymann
	Deutsche Telekom AG		Deutsche Telekom AG
	November 26, 2013		December 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-04.txt		draft-ietf-mpls-mldp-hsmp-05.txt
	Abstract		Abstract
	This draft introduces a hub & spoke multipoint (HSMP) Label Switched		This draft introduces a hub & spoke multipoint (HSMP) Label Switched
	Path (LSP), which allows traffic both from root to leaf through		Path (LSP), which allows traffic both from root to leaf through
	point-to-multipoint (P2MP) LSP and also leaf to root along the		point-to-multipoint (P2MP) LSP 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
	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 is travelling 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 is unicast
	to the root. The communication among the leaf nodes are not allowed.		to the root. Direct communication among the leaf nodes is not
			allowed.
	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 June 14, 2014.
	This Internet-Draft will expire on May 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4		3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4
	3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4		3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 5
	3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5		3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6
	3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5		3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6
	3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 6		3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 7
	3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 7		3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 8
	3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7		3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 8
	3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 8		3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 9
	3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9		3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 10
	3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9		3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 10
	3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9		3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 10
	3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 9		3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 10
	3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 10		3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 11
	3.7. Determining Forwarding Interface . . . . . . . . . . . . . 10		3.7. Determining Forwarding Interface . . . . . . . . . . . . . 11
	4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10		4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
	5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11		5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 12
	6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11		6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12		8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 13
	8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12		8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 13
	8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13		8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 14
	9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative references . . . . . . . . . . . . . . . . . . . 13		10.1. Normative references . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		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 draft introduces a hub &
	spoke multipoint (HSMP) LSP, which has one root node and one or more		spoke multipoint (HSMP) LSP, which has one root node and one or more
	leaf nodes. HSMP LSP allows traffic both from root to leaf through		leaf nodes. HSMP LSP allows traffic both from root to leaf through
	downstream LSP and also leaf to root along the upstream LSP. That		downstream LSP and also leaf to root along the upstream LSP. That
	means traffic entering the HSMP LSP at the root node travels along		means traffic entering the HSMP LSP at the root node travels along
	downstream LSP, exactly as if it is travelling along a P2MP LSP, and		downstream LSP, exactly as if it is travelling along a P2MP LSP, and
	traffic entering the HSMP LSP at any other leaf nodes travels along		traffic entering the HSMP LSP at any other leaf nodes travels along
	upstream LSP toward only the root node. The upstream LSP should be		upstream LSP toward only the root node. The upstream LSP should be
	thought of unicast LSP to the root node, except that it follows the		thought of unicast LSP to the root node, except that it follows the
	node of reverse downstream path of the tree, rather than routing		reverse direction of the downstream LSP, rather than routing protocol
	protocol based unicast path. The combination of upstream LSPs		based unicast path. The combination of upstream LSPs initiated from
	initiated from all leaf nodes forms a multipoint-to-point LSP.		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 Label Distribution Protocol (LDP)		mLDP: Multipoint extensions for Label Distribution Protocol (LDP)
	skipping to change at page 3, line 47		skipping to change at page 4, line 47
	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 & spoke multipoint Label Switched Path. An LSP that
	has one root node and one or more leaf nodes, allows traffic from		has one root node and one or more leaf nodes, allows traffic from
	root to all leaf nodes along downstream P2MP LSP and also leaf to		root to all leaf nodes along downstream P2MP LSP and also leaf to
	root node along the upstream unicast LSP.		root node along the upstream unicast LSP.
	PTP: precise time protocol. The timing and synchronization
	protocol defined by IEEE1588.
	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		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 that, when the leaf LSRs send traffic on the LSP, the
	traffic is first delivered only to the root node and follows 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		HSMP LSP consists of a downstream path and upstream path. The
	skipping to change at page 11, line 21		skipping to change at page 12, line 21
	The upstream path of an HSMP LSP on a LAN is the same as the one on		The upstream path of an HSMP LSP on a LAN is the same as the one on
	other kind of links. That is, the upstream LSR must send Label		other kind of links. That is, the upstream LSR must send Label
	Mapping message that contains the LSP label for upstream HSMP FEC to		Mapping message that contains the LSP label for upstream HSMP FEC to
	downstream node. Packets travelling upstream need to be forwarded in		downstream node. Packets travelling upstream need to be forwarded in
	the direction of the root by using the label allocated for upstream		the direction of the root by using the label allocated for upstream
	HSMP FEC.		HSMP FEC.
	5. Redundancy Considerations		5. Redundancy Considerations
	In some scenario, 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 purpose. One way to implement this is to use two
	independent HSMP LSPs acting as active/standby. At one time, only		independent HSMP LSPs acting as active/standby. At one time, only
	one HSMP LSP will be active, and the other will be standby. After		one HSMP LSP will be active, and the other will be standby. After
	detecting the failure of active HSMP LSP, the root and leaf nodes		detecting the failure of active HSMP LSP, the root and leaf nodes
	will switch the traffic to the standby HSMP LSP which takes on the		will switch the traffic to the standby HSMP LSP which takes on the
	role as active HSMP LSP. The detail of redundancy mechanism is out		role as active HSMP LSP. The detail of redundancy mechanism is out
	of the scope.		of the scope.
	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 end their MPLS
	path on the leaf. The leaf node then sends the LSP Ping Echo Reply		path on the leaf. The leaf node then sends the LSP Ping Echo Reply
	along the upstream path of HSMP LSP, and end on the root that are the		along the upstream path of HSMP LSP, and end on the root that are the
	(intended) root node.		(intended) root node.
	New sub-TLVs are required to be assigned by IANA in Target FEC Stack		New sub-TLVs are required to be assigned by IANA in Target FEC Stack
	TLV to define the corresponding HSMP-upstream FEC type and HSMP-		TLV and Reverse-path Target FEC Stack TLV to define the corresponding
	downstream FEC type. In order to ensure the leaf node to send the		HSMP-downstream FEC type and HSMP-upstream FEC type. In order to
	LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate		ensure the leaf node to send the LSP Ping Echo Reply along the HSMP
	Reverse Path) in Global Flags Field defined in [RFC6426] is reused		upstream path, the R bit (Validate Reverse Path) in Global Flags
	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 HSMP LSP is inherited from [RFC6425] and [RFC6426] Section 3.4,
	except the following:		except the following:
	1. The root node sending LSP Ping Echo Request message for HSMP LSP		1. The root node sending LSP Ping Echo Request message for HSMP LSP
	MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit		MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit
	to '1' in Global Flags Field.		to '1' in Global Flags Field.
	2. When the leaf node receiving the LSP Ping Echo Request, it MUST		2. When the leaf node receiving the LSP Ping Echo Request, it MUST
	skipping to change at page 13, line 9		skipping to change at page 14, line 9
	HSMP LSP Capability Parameter - requested value TBD		HSMP LSP Capability Parameter - requested value TBD
	The value should be allocated from the range 0x0901-0x3DFF (IETF		The value should be allocated from the range 0x0901-0x3DFF (IETF
	Consensus) using the first free value within this range.		Consensus) using the first free value within this range.
	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		This document requires allocation of two new sub-TLV types for
	inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV		inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV
	type 1).		type 1) and Reverse-path Target FEC Stack TLV (TLV type 16).
	1. the HSMP-upstream LDP FEC Stack - requested value TBD		1. the HSMP-upstream LDP FEC Stack - requested value TBD
	2. the HSMP-downstream LDP FEC Stack - requested value TBD		2. the HSMP-downstream LDP FEC Stack - requested value TBD
	The value should be allocated from the IETF Standards Action range		The value should be allocated from the IETF Standards Action range
	(0-16383) that is used for mandatory and optional sub-TLVs that		(0-16383) that is used for mandatory and optional sub-TLVs that
	requires a response if not understood. The value should be allocated		requires a response if not understood. The value should be allocated
	using the lowest free value within this range.		using the lowest free value within this range.
	skipping to change at page 14, line 16		skipping to change at page 15, line 16
	S., and T. Nadeau, "Detecting Data-Plane Failures in		S., and T. Nadeau, "Detecting Data-Plane Failures in
	Point-to-Multipoint MPLS - Extensions to LSP Ping",		Point-to-Multipoint MPLS - Extensions to LSP Ping",
	RFC 6425, November 2011.		RFC 6425, November 2011.
	[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS		[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
	On-Demand Connectivity Verification and Route Tracing",		On-Demand Connectivity Verification and Route Tracing",
	RFC 6426, November 2011.		RFC 6426, November 2011.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-l2vpn-vpms-frmwk-requirements]
	Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
	and L. Jin, "Framework and Requirements for Virtual
	Private Multicast Service (VPMS)",
	draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in
	progress), October 2012.
	[I-D.ietf-pwe3-p2mp-pw]
	Sivabalan, S., Boutros, S., and L. Martini, "Signaling
	Root-Initiated Point-to-Multipoint Pseudowire using LDP",
	draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
	[I-D.ietf-tictoc-1588overmpls]
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
	Montini, "Transporting Timing messages over MPLS
	Networks", draft-ietf-tictoc-1588overmpls-05 (work in
	progress), June 2013.
	[IEEE1588]
	"IEEE standard for a precision clock synchronization
	protocol for networked measurement and control systems",
	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.
	[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.
	[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
End of changes. 14 change blocks.
	78 lines changed or deleted		43 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/