< draft-minei-mpls-ldp-p2mp-00.txt		draft-minei-mpls-ldp-p2mp-01.txt >
	Network Working Group I. Minei		Network Working Group I. Minei
	Internet-Draft K. Kompella		Internet-Draft K. Kompella
	Expires: September 29, 2005 Juniper Networks		Expires: January 18, 2006 Juniper Networks
	J-L. Le Roux		J-L. Le Roux
	France Telecom		France Telecom
	L. Fang		L. Fang
	AT&T		AT&T
	L. Wang		L. Wang
	Telenor		Telenor
	S. Amante		S. Amante
	Level 3 Communications, LLC		Level 3 Communications, LLC
	March 28, 2005		July 17, 2005
	Label Distribution Protocol Extensions for Point-to-Multipoint Label		Label Distribution Protocol Extensions for Point-to-Multipoint Label
	Switched Paths		Switched Paths
	draft-minei-mpls-ldp-p2mp-00		draft-minei-mpls-ldp-p2mp-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 29, 2005.		This Internet-Draft will expire on January 18, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes extensions to the Label Distribution Protocol		This document describes extensions to the Label Distribution Protocol
	(LDP) for the setup of point-to-multipoint (P2MP) Label Switched		(LDP) for the setup of point to multi-point (P2MP) Label Switched
	Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The		Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The
	solution relies on LDP without requiring a multicast routing protocol		solution relies on LDP without requiring a multicast routing protocol
	in the network. Protocol elements and procedures for this solution		in the network. Protocol elements and procedures for this solution
	are described. There can be various applications for P2MP LSPs such		are described. There can be various applications for P2MP LSPs such
	as IP multicast. Specification of how such applications can use a		as IP multicast. Specification of how such applications can use a
	LDP signaled P2MP LSP is outside the scope of this document.		LDP signaled P2MP LSP is outside the scope of this document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Conventions used in this document . . . . . . . . . . . . 3		1.1 Conventions used in this document . . . . . . . . . . . . 3
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5
	2.1 The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 4		2.1 The P2MP FEC Element . . . . . . . . . . . . . . . . . . . 5
	2.2 Using the P2MP FEC Element . . . . . . . . . . . . . . . . 5		2.2 Using the P2MP FEC Element . . . . . . . . . . . . . . . . 6
	2.2.1 Label Map . . . . . . . . . . . . . . . . . . . . . . 6		2.2.1 Label Map . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.2 Label Withdraw . . . . . . . . . . . . . . . . . . . . 7		2.2.2 Label Withdraw . . . . . . . . . . . . . . . . . . . . 8
	3. Security considerations . . . . . . . . . . . . . . . . . . . 8		3. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		4. Security considerations . . . . . . . . . . . . . . . . . . . 11
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1 Normative References . . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2 Informative References . . . . . . . . . . . . . . . . . . 10		6.1 Normative References . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10		6.2 Informative References . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
			Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Introduction		1. Introduction
	The LDP protocol is described in [4]. It defines mechanisms for		The LDP protocol is described in [1]. It defines mechanisms for
	setting up point to point and multi-point to point LSPs in the		setting up point to point (P2P) and multi-point to point (MP2P) LSPs
	network. This document describes extensions to LDP for setting up		in the network. This document describes extensions to LDP for
	point to multi-point (P2MP) LSPs. Specifically, this document		setting up point to multi-point (P2MP) LSPs. Specifically, this
	describes how a P2MP LSP can be set up that allows traffic from a		document describes how a P2MP LSP can be set up that allows traffic
	single root (or ingress) node to be delivered to a number of leaf (or		from a single root (or ingress) node to be delivered to a number of
	egress) nodes. Only a single copy of the packet will be sent on any		leaf (or egress) nodes. Only a single copy of the packet will be
	link traversed by the P2MP LSP (see note at end of Section 2.2.1).		sent on any link traversed by the P2MP LSP (see note at end of
	This is accomplished without the use of a multicast protocol in the		Section 2.2.1). This is accomplished without the use of a multicast
	network. There can be several P2MP LSPs rooted at a given ingress		protocol in the network. There can be several P2MP LSPs rooted at a
	node, each with its own identifier.		given ingress node, each with its own identifier.
	The solution assumes that the leaf nodes of the P2MP LSP know the		The solution assumes that the leaf nodes of the P2MP LSP know the
	root node and identifier of the P2MP LSP to which they belong. The		root node and identifier of the P2MP LSP to which they belong. The
	mechanisms for the distribution of this information are outside the		mechanisms for the distribution of this information are outside the
	scope of this document. The specification of how an application can		scope of this document. The specification of how an application can
	use a P2MP LSP signaled by LDP is also outside the scope of this		use a P2MP LSP signaled by LDP is also outside the scope of this
	document.		document.
	Interested readers may also wish to peruse the documents [6] and [7].		Interested readers may also wish to peruse the documents [4] and [6].
	1.1 Conventions used in this document		1.1 Conventions used in this document
	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 RFC 2119 [2].		document are to be interpreted as described in RFC 2119 [2].
	1.2 Terminology		1.2 Terminology
	The following terminology is taken from [6].		The following terminology is taken from [4].
	P2MP LSP: An LSP that has one Ingress LSR, and one ore more Egress		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
	LSRs.		LSRs.
			MP2P LSP: A LSP that has one or more Ingress LSRs and one unique
			Egress LSR.
			MP2MP LSP: A LSP that has one or more Ingress LSRs and one or more
			Egress LSRs.
	Ingress LSR: Source of the P2MP LSP, also referred to as root node.		Ingress LSR: Source of the P2MP LSP, also referred to as root node.
	Egress LSR: One of potentially many destinations of the P2MP LSP,		Egress LSR: One of potentially many destinations of an LSP, also
	also referred to as leaf node.		referred to as leaf node in the case of P2MP and MP2MP LSPs.
	Transit LSR: An LSR that has one or more directly connected		Transit LSR: An LSR that has one or more directly connected
	downstream LSRs.		downstream LSRs.
	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.
	2. Protocol Operation		2. Protocol Operation
	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		MPLS forwarding state and propagate the P2MP LSP setup (and tear-
	tear-down) toward the root. The root node installs forwarding state		down) toward the root. The root node installs forwarding state to
	to map traffic into the P2MP LSP; how the root node determines which		map traffic into the P2MP LSP; how the root node determines which
	traffic should go over the P2MP LSP is outside the scope of this		traffic should go over the P2MP LSP is outside the scope of this
	document.		document.
	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 in the FEC TLV. The		entity, the P2MP FEC Element to be used in the FEC TLV. The
	description of the P2MP FEC Element follows.		description of the P2MP FEC Element follows.
	2.1 The P2MP FEC Element		2.1 The P2MP FEC Element
	The P2MP FEC Element consists of the address of the root of the P2MP		The P2MP FEC Element consists of the address of the root of the P2MP
	skipping to change at page 4, line 48 ¶		skipping to change at page 5, line 48 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque Identifier Type | Opaque Identifier Length |		| Opaque Identifier Type | Opaque Identifier Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque Identifier ... |		| Opaque Identifier ... |
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: The type of the P2MP FEC element is to be assigned by IANA.		Type: The type of the P2MP FEC element is to be assigned by IANA.
	Address Family: Two octet quantity containing a value from ADDRESS		Address Family: Two octet quantity containing a value from ADDRESS
	FAMILY NUMBERS in [RFC1700] that encodes the address family for		FAMILY NUMBERS in [3] that encodes the address family for the Root
	the Root LSR Address.		LSR Address.
	Address Length: Length of the Root LSR Address in octets.		Address Length: Length of the Root LSR Address in octets.
	Root Node Address: A host address encoded according to the Address		Root Node Address: A host address encoded according to the Address
	Family field.		Family field.
	Opaque Identifier Type: The type of Opaque Identifier.		Opaque Identifier Type: The type of Opaque Identifier.
	Length: The length of the P2MP Opaque Identifier, in octets.		Length: The length of the P2MP Opaque Identifier, in octets.
	skipping to change at page 6, line 23 ¶		skipping to change at page 7, line 33 ¶
	should apply those procedures that apply to it, based on its role in		should apply those procedures that apply to it, based on its role in
	the P2MP LSP.		the P2MP LSP.
	In the current approach, if there are several receivers for a P2MP		In the current approach, if there are several receivers for a P2MP
	LSP on a LAN, packets are replicated over the LAN. This may not be		LSP on a LAN, packets are replicated over the LAN. This may not be
	optimal; optimizing this case is for further study.		optimal; optimizing this case is for further study.
	2.2.1.1 Determining one's 'upstream LSR'		2.2.1.1 Determining one's 'upstream LSR'
	A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U		A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
	which lies on the best path from Z to the root node X. If there are		which lies on the best path from Z to the root node X. If there are
	more than one such LDP peers, only one of them is picked. U is Z's		more than one such LDP peers, only one of them is picked. U is Z's
	"Upstream LSR" for <X, Y>.		"Upstream LSR" for <X, Y>.
	2.2.1.2 Leaf Operation		2.2.1.2 Leaf Operation
	A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for		A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for
	<X, Y> as per Section 2.2.1.1, allocates a label L, and sends a P2MP		<X, Y> as per Section 2.2.1.1, allocates a label L, and sends a P2MP
	Label Map <X, Y, L> to U.		Label Map <X, Y, L> to U.
	2.2.1.3 Transit Node operation		2.2.1.3 Transit Node operation
	Suppose a transit node Z receives a P2MP Label Map <X, Y, L> over		Suppose a transit node Z receives a P2MP Label Map <X, Y, L> over
	interface I. Z checks whether it already has state for <X, Y>. If		interface I. Z checks whether it already has state for <X, Y>. If
	not, Z allocates a label L', and installs state to swap L' with L		not, Z allocates a label L', and installs state to swap L' with L
	over interface I. Z also determines its upstream LSR U for <X, Y> as		over interface I. Z also determines its upstream LSR U for <X, Y> as
	per Section 2.2.1.1, and sends a P2MP Label Map <X, Y, L'> to U.		per Section 2.2.1.1, and sends a P2MP Label Map <X, Y, L'> to U.
	If Z already has state for <X, Y>, then Z adds "swap L, send over		If Z already has state for <X, Y>, then Z adds "swap L, send over
	interface I" to the nexthop. Z does not send a Label Map message for		interface I" to the nexthop. Z does not send a Label Map message for
	P2MP LSP <X, Y>.		P2MP LSP <X, Y>.
	2.2.1.4 Root Node Operation		2.2.1.4 Root Node Operation
	Suppose the root node Z receives a P2MP Label Map <X, Y, L> over		Suppose the root node Z receives a P2MP Label Map <X, Y, L> over
	interface I. Z checks whether it already has forwarding state for		interface I. Z checks whether it already has forwarding state for <X,
	<X, Y>. If not, Z creates forwarding state to push label L onto the		Y>. If not, Z creates forwarding state to push label L onto the
	traffic that Z wants to forward over the P2MP LSP (how this traffic		traffic that Z wants to forward over the P2MP LSP (how this traffic
	is determined is outside the scope of this document).		is determined is outside the scope of this document).
	If Z already has forwarding state for <X, Y>, then Z adds "push label		If Z already has forwarding state for <X, Y>, then Z adds "push label
	L, send over interface I" to the nexthop.		L, send over interface I" to the nexthop.
	2.2.2 Label Withdraw		2.2.2 Label Withdraw
	The following lists procedures for generating and processing P2MP		The following lists procedures for generating and processing P2MP
	Label Withdraw messages for nodes that participate in a P2MP LSP. An		Label Withdraw messages for nodes that participate in a P2MP LSP. An
	skipping to change at page 8, line 5 ¶		skipping to change at page 10, line 5 ¶
	1. send a Label Withdraw <X, Y, L> to U, where L is the label Z had		1. send a Label Withdraw <X, Y, L> to U, where L is the label Z had
	previously sent to U for <X, Y>;		previously sent to U for <X, Y>;
	2. delete all forwarding state for the P2MP LSP <X, Y>;		2. delete all forwarding state for the P2MP LSP <X, Y>;
	3. allocate a label L' for <X, Y>, and send a Label Map <X, Y, L'>		3. allocate a label L' for <X, Y>, and send a Label Map <X, Y, L'>
	to U';		to U';
	4. install forwarding state for label L'.		4. install forwarding state for label L'.
	3. Security considerations		3. Shared Trees
			The mechanism described above shows how to build a tree with a single
			root and multiple leaves, i.e., a P2MP LSP. One can use essentially
			the same mechanism to build Shared Trees with LDP. A Shared Tree can
			be used by a group of routers that want to multicast traffic among
			themselves, i.e., each node is both a root node (when it sources
			traffic) and a leaf node (when any other member of the group sources
			traffic). A Shared Tree offers similar functionality to a MP2MP LSP,
			but the underlying multicasting mechanism uses a P2MP LSP. One
			example where a Shared Tree is useful is video-conferencing. Another
			is Virtual Private LAN Service (VPLS) [5], where for some types of
			traffic, each device participating in a VPLS must send packets to
			every other device in that VPLS.
			One way to build a Shared Tree is to build an LDP P2MP LSP rooted at
			a common point, the Shared Root (SR), and whose leaves are all the
			members of the group. Each member of the Shared Tree unicasts
			traffic to the SR (using, for example, the MP2P LSP created by the
			unicast LDP FEC advertised by the SR); the SR then splices this
			traffic into the LDP P2MP LSP. The SR may be (but need not be) a
			member of the multicast group.
			A major advantage of this approach is that no further protocol
			mechanisms beyond the one already described are needed to set up a
			Shared Tree. Furthermore, a Shared Tree is very efficient in terms
			of the multicast state in the network, and is reasonably efficient in
			terms of the bandwidth required to send traffic.
			An important consideration in this approach is that a sender will
			receive its own packets as part of the multicast; thus a sender must
			be prepared to recognize and discard packets that it itself has sent.
			For a number of applications (for example, VPLS), this requirement is
			easy to meet. Another consideration is the various techniques that
			can be used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP;
			these will be described in a later revision.
			4. Security considerations
	The same security considerations apply as for the base LDP		The same security considerations apply as for the base LDP
	specification, as described in [RFC3036].		specification, as described in [1].
	4. Acknowledgments		5. Acknowledgments
	The authors would like to thank Nischal Sheth, Yakov Rekhter and		The authors would like to thank Nischal Sheth, Yakov Rekhter and
	Rahul Aggarwal for their suggestions and review.		Rahul Aggarwal for their suggestions and review.
	5. References		6. References
	5.1 Normative References		6.1 Normative References
	[1] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,		[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
	October 1994.		Thomas, "LDP Specification", RFC 3036, January 2001.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label		[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
	Switching Architecture", RFC 3031, January 2001.		October 1994.
	[4] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
	Thomas, "LDP Specification", RFC 3036, January 2001.
	5.2 Informative References		[4] Roux, J., "Requirements for multipoint extensions to the Label
			Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs-00 (work
			in progress), July 2005.
	[5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G.		6.2 Informative References
	Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
	RFC 3209, December 2001.
	[6] Yasukawa, S., "Signaling Requirements for Point to Multipoint		[5] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
	Traffic Engineered MPLS LSPs",		Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05
	Internet-Draft draft-ietf-mpls-p2mp-sig-requirement-01, February		(work in progress), June 2004.
	2005.
	[7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE		[6] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE
	LSPs", Internet-Draft draft-ietf-mpls-rsvp-te-p2mp-01, January		LSPs", draft-ietf-mpls-rsvp-te-p2mp-01 (work in progress),
	2005.		January 2005.
	Authors' Addresses		Authors' Addresses
	Ina Minei		Ina Minei
	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. 32 change blocks.
	75 lines changed or deleted		114 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/