< draft-ietf-mpls-ldp-p2mp-14.txt		draft-ietf-mpls-ldp-p2mp-15.txt >
	Network Working Group I. Minei, Ed.		Network Working Group I. Minei, Ed.
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Standards Track IJ. Wijnands, Ed.		Intended status: Standards Track IJ. Wijnands, Ed.
	Expires: December 18, 2011 Cisco Systems, Inc.		Expires: February 5, 2012 Cisco Systems, Inc.
	K. Kompella		K. Kompella
	Juniper Networks		Juniper Networks
	B. Thomas		B. Thomas
	June 16, 2011		August 4, 2011
	Label Distribution Protocol Extensions for Point-to-Multipoint and		Label Distribution Protocol Extensions for Point-to-Multipoint and
	Multipoint-to-Multipoint Label Switched Paths		Multipoint-to-Multipoint Label Switched Paths
	draft-ietf-mpls-ldp-p2mp-14		draft-ietf-mpls-ldp-p2mp-15
	Abstract		Abstract
	This document describes extensions to the Label Distribution Protocol		This document describes extensions to the Label Distribution Protocol
	for the setup of Point-to-Multipoint and Multipoint-to-Multipoint		for the setup of Point-to-Multipoint and Multipoint-to-Multipoint
	Label Switched Paths in Multi-Protocol Label Switching networks.		Label Switched Paths in Multi-Protocol Label Switching networks.
	These extensions are also referred to as Multipoint LDP. Multipoint		These extensions are also referred to as Multipoint LDP. Multipoint
	LDP constructs the P2MP or MP2MP Label Switched Paths without		LDP constructs the P2MP or MP2MP Label Switched Paths without
	interacting with or relying upon any other multicast tree		interacting with or relying upon any other multicast tree
	construction protocol. Protocol elements and procedures for this		construction protocol. Protocol elements and procedures for this
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 December 18, 2011.		This Internet-Draft will expire on February 5, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	mLDP: Multipoint extensions for LDP.		mLDP: Multipoint extensions for LDP.
	P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.		P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
	P2MP LSP: An LSP that has one Ingress LSR and one or more Egress		P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
	LSRs.		LSRs.
	MP2P LSP: An LSP that has one or more Ingress LSRs and one unique		MP2P LSP: An LSP that has one or more Ingress LSRs and one unique
	Egress LSR.		Egress LSR.
	MP2MP LSP: An LSP that connects a set of nodes, such that traffic		MP2MP LSP: An LSP with a distinguished root node that connects a set
	sent by any node in the LSP is delivered to all others.		of nodes, such that traffic sent by any node in the LSP is
			delivered to all others.
	MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.		MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
	Ingress LSR: An ingress LSR for a particular LSP is an LSR that can		Ingress LSR: An ingress LSR for a particular LSP is an LSR that can
	send a data packet along the LSP. MP2MP LSPs can have multiple		send a data packet along the LSP. MP2MP LSPs can have multiple
	ingress LSRs, P2MP LSPs have just one, and that node is often		ingress LSRs, P2MP LSPs have just one, and that node is often
	referred to as the "root node".		referred to as the "root node".
	Egress LSR: An egress LSR for a particular LSP is an LSR that can		Egress LSR: An egress LSR for a particular LSP is an LSR that can
	remove a data packet from that LSP for further processing. P2P		remove a data packet from that LSP for further processing. P2P
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 37 ¶
	Bud LSR: An LSR that is an egress but also has one or more directly		Bud LSR: An LSR that is an egress but also has one or more directly
	connected downstream LSRs.		connected downstream LSRs.
	Leaf node: A Leaf node can be either an Egress or Bud LSR when		Leaf node: A Leaf node can be either an Egress or Bud LSR when
	referred in the context of a P2MP LSP. In the context of a MP2MP		referred in the context of a P2MP LSP. In the context of a MP2MP
	LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and		LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and
	can also be a Bud LSR.		can also be a Bud LSR.
	CRC32: This contains a Cyclic Redundancy Check value of the		CRC32: This contains a Cyclic Redundancy Check value of the
	uncompressed data computed according to CRC-32 algorithm used in		uncompressed data in network byte order computed according to
	the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T		CRC-32 algorithm used in the ISO 3309 standard and in section
	recommendation V.42. (See http://www.iso.ch for ordering ISO		8.1.1.6.2 of ITU-T recommendation V.42.
	documents. See gopher://info.itu.ch for an online version of
	ITU-T V.42.)
	2. Setting up P2MP LSPs with LDP		2. Setting up P2MP LSPs with LDP
	A P2MP LSP consists of a single root node, zero or more transit nodes		A P2MP LSP consists of a single root node, zero or more transit nodes
	and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and		and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and
	tear-down. Leaf nodes also install forwarding state to deliver the		tear-down. Leaf nodes also install forwarding state to deliver the
	traffic received on a P2MP LSP to wherever it needs to go; how this		traffic received on a P2MP LSP to wherever it needs to go; how this
	is done is outside the scope of this document. Transit nodes install		is done is outside the scope of this document. Transit nodes install
	MPLS forwarding state and propagate the P2MP LSP setup (and tear-		MPLS forwarding state and propagate the P2MP LSP setup (and tear-
	down) toward the root. The root node installs forwarding state to		down) toward the root. The root node installs forwarding state to
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 26 ¶
	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| P2MP Capability (TBD IANA)| Length (= 1) |		|1|0| P2MP Capability (TBD IANA)| Length (= 1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	S: As specified in [RFC5561]		S: As specified in [RFC5561]
	The P2MP Capability TLV MUST be supported in the LDP Initialization		The P2MP Capability TLV MUST be advertised in the LDP Initialization
	Message. Advertisement of the P2MP Capability indicates support of		Message. Advertisement of the P2MP Capability indicates support of
	the procedures for P2MP LSP setup detailed in this document. If the		the procedures for P2MP LSP setup detailed in this document. If the
	peer has not advertised the corresponding capability, then label		peer has not advertised the corresponding capability, then label
	messages using the P2MP FEC Element SHOULD NOT be sent to the peer.		messages using the P2MP FEC Element SHOULD NOT be sent to the peer.
	2.2. The P2MP FEC Element		2.2. The P2MP FEC Element
	For the setup of a P2MP LSP with LDP, we define one new protocol		For the setup of a P2MP LSP with LDP, we define one new protocol
	entity, the P2MP FEC Element to be used as a FEC Element in the FEC		entity, the P2MP FEC Element to be used as a FEC Element in the FEC
	TLV. Note that the P2MP FEC Element does not necessarily identify		TLV. Note that the P2MP FEC Element does not necessarily identify
	skipping to change at page 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	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| MP2MP Capability TBD IANA | Length (= 1) |		|1|0| MP2MP Capability TBD IANA | Length (= 1) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved |		|S| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	S: As specified in [RFC5561]		S: As specified in [RFC5561]
	The MP2MP Capability TLV MUST be supported in the LDP Initialization		The MP2MP Capability TLV MUST be advertised in the LDP Initialization
	Message. Advertisement of the MP2MP Capability indicates support of		Message. Advertisement of the MP2MP Capability indicates support of
	the procedures for MP2MP LSP setup detailed in this document. If the		the procedures for MP2MP LSP setup detailed in this document. If the
	peer has not advertised the corresponding capability, then label		peer has not advertised the corresponding capability, then label
	messages using the MP2MP upstream and downstream FEC Elements SHOULD		messages using the MP2MP upstream and downstream FEC Elements SHOULD
	NOT be sent to the peer.		NOT be sent to the peer.
	3.2. The MP2MP downstream and upstream FEC Elements.		3.2. The MP2MP downstream and upstream FEC Elements.
	For the setup of a MP2MP LSP with LDP we define 2 new protocol		For the setup of a MP2MP LSP with LDP we define 2 new protocol
	entities, the MP2MP downstream FEC and upstream FEC Element. Both		entities, the MP2MP downstream FEC and upstream FEC Element. Both
	skipping to change at page 19, line 10 ¶		skipping to change at page 19, line 10 ¶
	2. We install the upstream MP2MP path (to a downstream neighbor)		2. We install the upstream MP2MP path (to a downstream neighbor)
	based on receiving a MP2MP-U Label Mapping from the upstream		based on receiving a MP2MP-U Label Mapping from the upstream
	neighbor. An LSR does not need to wait for the MP2MP-U Label		neighbor. An LSR does not need to wait for the MP2MP-U Label
	Mapping if it is the root of the MP2MP LSP or already has		Mapping if it is the root of the MP2MP LSP or already has
	received an MP2MP-U Label Mapping from the upstream neighbor. We		received an MP2MP-U Label Mapping from the upstream neighbor. We
	call this method ordered mode. The typical result of this mode		call this method ordered mode. The typical result of this mode
	is that the downstream path of the MP2MP is built hop by hop		is that the downstream path of the MP2MP is built hop by hop
	towards the root. Once the root is reached, the root node will		towards the root. Once the root is reached, the root node will
	trigger a MP2MP-U Label Mapping to the downstream neighbor(s).		trigger a MP2MP-U Label Mapping to the downstream neighbor(s).
	For setting up the upstream path of a MP2MP LSP ordered mode MUST be		For setting up the upstream path of a MP2MP LSP ordered mode SHOULD
	used. Due to ordered mode the upstream path of the MP2MP LSP is		be used. Due to ordered mode the upstream path of the MP2MP LSP is
	installed at the leaf node once the path to the root is completed.		installed at the leaf node once the path to the root is completed.
	The advantage is that when a leaf starts sending immediately after		The advantage is that when a leaf starts sending immediately after
	the upstream path is installed, packets are able to reach the root		the upstream path is installed, packets are able to reach the root
	node without being dropped due to an incomplete LSP. Method 1 is not		node without being dropped due to an incomplete LSP. Method 1 is not
	able to guarantee that the upstream path is completed before the leaf		able to guarantee that the upstream path is completed before the leaf
	starts sending.		starts sending.
	3.3.1.4. MP2MP leaf node operation		3.3.1.4. MP2MP leaf node operation
	A leaf node Z of a MP2MP LSP <X, Y> determines its upstream LSR U for		A leaf node Z of a MP2MP LSP <X, Y> determines its upstream LSR U for
	skipping to change at page 22, line 40 ¶		skipping to change at page 22, line 40 ¶
	also result in a micro-loop in the MP LSPs. Micro-loops that involve		also result in a micro-loop in the MP LSPs. Micro-loops that involve
	2 directly connected routers don't create a loop in mLDP. mLDP is		2 directly connected routers don't create a loop in mLDP. mLDP is
	able to prevent this inconsistency by never allowing an upstream LDP		able to prevent this inconsistency by never allowing an upstream LDP
	neighbor to be added as a downstream LDP neighbor into the Label		neighbor to be added as a downstream LDP neighbor into the Label
	Forwarding Table (LFT) for the same FEC. Micro-loops that involve		Forwarding Table (LFT) for the same FEC. Micro-loops that involve
	more than 2 LSRs are not prevented.		more than 2 LSRs are not prevented.
	Micro-loops that involve more than 2 LSRs may create a micro-loop in		Micro-loops that involve more than 2 LSRs may create a micro-loop in
	the downstream path of either a MP2MP LSP or P2MP LSP and the		the downstream path of either a MP2MP LSP or P2MP LSP and the
	upstream path of the MP2MP LSP. The loops are transient and will		upstream path of the MP2MP LSP. The loops are transient and will
	disappear as soon as the unicast routing protocol converges. Micro-		disappear as soon as the unicast routing protocol converges and mLDP
	loops that occur in the upstream path of a MP2MP LSP may be detected		has updated the forwarding state accordingly. Micro-loops that occur
	by including LDP path vector in the MP2MP-U Label Mapping messages.		in the upstream path of a MP2MP LSP may be detected by including LDP
	These procedures are currently under investigation and are subjected		path vector in the MP2MP-U Label Mapping messages. These procedures
	to further study.		are currently under investigation and are subjected to further study.
	5. The LDP MP Status TLV		5. The LDP MP Status TLV
	An LDP MP capable router MAY use an LDP MP Status TLV to indicate		An LDP MP capable router MAY use an LDP MP Status TLV to indicate
	additional status for a MP LSP to its remote peers. This includes		additional status for a MP LSP to its remote peers. This includes
	signaling to peers that are either upstream or downstream of the LDP		signaling to peers that are either upstream or downstream of the LDP
	MP capable router. The value of the LDP MP status TLV will remain		MP capable router. The value of the LDP MP status TLV will remain
	opaque to LDP and MAY encode one or more status elements.		opaque to LDP and MAY encode one or more status elements.
	The LDP MP Status TLV is encoded as follows:		The LDP MP Status TLV is encoded as follows:
	skipping to change at page 38, line 17 ¶		skipping to change at page 38, line 17 ¶
	for LDP", draft-ietf-mpls-ldp-upstream-10 (work in		for LDP", draft-ietf-mpls-ldp-upstream-10 (work in
	progress), February 2011.		progress), February 2011.
	[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.
	[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution		[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
	Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class		Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
	(FEC)", RFC 5918, August 2010.		(FEC)", RFC 5918, August 2010.
			[ITU.V42.1994]
			International Telecommunications Union, "Error-correcting
			Procedures for DCEs Using Asynchronous-to-Synchronous
			Conversion", ITU-T Recommendation V.42, 1994.
			http://www.itu.int/rec/T-REC-V.42-200203-I
	14.2. Informative References		14.2. Informative References
	[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,		[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
	"Extensions to Resource Reservation Protocol - Traffic		"Extensions to Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		Engineering (RSVP-TE) for Point-to-Multipoint TE Label
	Switched Paths (LSPs)", RFC 4875, May 2007.		Switched Paths (LSPs)", RFC 4875, May 2007.
	[I-D.ietf-mpls-mp-ldp-reqs]		[I-D.ietf-mpls-mp-ldp-reqs]
	Morin, T., "Requirements for Point-To-Multipoint		Morin, T., "Requirements for Point-To-Multipoint
	Extensions to the Label Distribution Protocol",		Extensions to the Label Distribution Protocol",
	skipping to change at page 38, line 39 ¶		skipping to change at page 39, line 5 ¶
	[I-D.ietf-l3vpn-2547bis-mcast]		[I-D.ietf-l3vpn-2547bis-mcast]
	Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,		Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
	Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in		Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
	MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work		MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
	in progress), January 2010.		in progress), January 2010.
	[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.
	[ITU.V42.1994]
	International Telecommunications Union, "Error-correcting
	Procedures for DCEs Using Asynchronous-to-Synchronous
	Conversion", ITU-T Recommendation V.42, 1994.
	Authors' Addresses		Authors' Addresses
	Ina Minei (editor)		Ina Minei (editor)
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	US		US
	Email: ina@juniper.net		Email: ina@juniper.net
End of changes. 12 change blocks.
	25 lines changed or deleted		25 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/