draft-ietf-mpls-mldp-in-band-signaling-08.txt		rfc6826.txt
	Network Working Group IJ. Wijnands, Ed.		Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
	Internet-Draft T. Eckert		Request for Comments: 6826 T. Eckert
	Intended status: Standards Track Cisco Systems, Inc.		Category: Standards Track Cisco Systems, Inc.
	Expires: June 2, 2013 N. Leymann		ISSN: 2070-1721 N. Leymann
	Deutsche Telekom		Deutsche Telekom
	M. Napierala		M. Napierala
	AT&T Labs		AT&T Labs
	November 29, 2012		January 2013
	Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-		Multipoint LDP In-Band Signaling for
	to-Multipoint Label Switched Paths		Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
	draft-ietf-mpls-mldp-in-band-signaling-08
	Abstract		Abstract
	Consider an IP multicast tree, constructed by Protocol Independent		Consider an IP multicast tree, constructed by Protocol Independent
	Multicast (PIM), needs to pass through an MPLS domain in which		Multicast (PIM), that needs to pass through an MPLS domain in which
	Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-		Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-
	Multipoint Labels Switched Paths (LSPs) can be created. The part of		multipoint Labels Switched Paths (LSPs) can be created. The part of
	the IP multicast tree that traverses the MPLS domain can be		the IP multicast tree that traverses the MPLS domain can be
	instantiated as a multipoint LSP. When a PIM Join message is		instantiated as a multipoint LSP. When a PIM Join message is
	received at the border of the MPLS domain, information from that		received at the border of the MPLS domain, information from that
	message is encoded into mLDP messages. When the mLDP messages reach		message is encoded into mLDP messages. When the mLDP messages reach
	the border of the next IP domain, the encoded information is used to		the border of the next IP domain, the encoded information is used to
	generate PIM messages that can be sent through the IP domain. The		generate PIM messages that can be sent through the IP domain. The
	result is an IP multicast tree consisting of a set of IP multicast		result is an IP multicast tree consisting of a set of IP multicast
	sub-trees that are spliced together with a multipoint LSP. This		sub-trees that are spliced together with a multipoint LSP. This
	document describes procedures how IP multicast trees are spliced		document describes procedures regarding how IP multicast trees are
	together with multipoint LSPs.		spliced together with multipoint LSPs.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This is an Internet Standards Track document.
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on June 2, 2013.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6826.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4		2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4
	2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6		2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6
	2.2. Transiting IP multicast source trees . . . . . . . . . . . 6		2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6
	2.3. Transiting IP multicast bidirectional trees . . . . . . . 7		2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7
	3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7		3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7		3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
	3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8		3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
	3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9		3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9
	3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9		3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11		6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		6.2. Informative References . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The mLDP (Multipoint LDP) [RFC6388] specification describes		The mLDP (Multipoint LDP) [RFC6388] specification describes
	mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-		mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
	multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are		multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are
	typically used for transporting end-user multicast packets. However,		typically used for transporting end-user multicast packets. However,
	the mLDP specification does not provide any rules for associating		the mLDP specification does not provide any rules for associating
	particular end-user multicast packets with any particular LSP. Other		particular end-user multicast packets with any particular LSP. Other
	documents, like [RFC6513], describe applications in which out-of-band		documents, like [RFC6513], describe applications in which out-of-band
	signaling protocols, such as PIM and BGP, are used to establish the		signaling protocols, such as PIM and BGP, are used to establish the
	mapping between an LSP and the multicast packets that need to be		mapping between an LSP and the multicast packets that need to be
	forwarded over the LSP.		forwarded over the LSP.
	This document describes an application in which the information		This document describes an application in which the information
	needed to establish the mapping between an LSP and the set of		needed to establish the mapping between an LSP and the set of
	multicast packets to be forwarded over it is carried in the "opaque		multicast packets to be forwarded over it is carried in the "opaque
	value" field of an mLDP FEC (Forwarding Equivalence Class) element.		value" field of an mLDP FEC (Forwarding Equivalence Class) element.
	When an IP multicast tree (either a source-specific tree or a		When an IP multicast tree (either a source-specific tree or a
	bidirectional tree) enters the MPLS network the (S,G) or (*,G)		bidirectional tree) enters the MPLS network, the (S,G) or (*,G)
	information from the IP multicast control plane state is carried in		information from the IP multicast control-plane state is carried in
	the opaque value field of the mLDP FEC message. As the tree leaves		the opaque value field of the mLDP FEC message. As the tree leaves
	the MPLS network, this information is extracted from the FEC element		the MPLS network, this information is extracted from the FEC Element
	and used to build the IP multicast control plane. PIM messages can		and used to build the IP multicast control plane. PIM messages can
	be sent outside the MPLS domain. Note that although the PIM control		be sent outside the MPLS domain. Note that although the PIM control
	messages are sent periodically, the mLDP messages are not.		messages are sent periodically, the mLDP messages are not.
	Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in		Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
	the MPLS network. A network operator should expect to see as many		the MPLS network. A network operator should expect to see as many
	LSPs in the MPLS network as there are IP multicast trees. A network		LSPs in the MPLS network as there are IP multicast trees. A network
	operator should be aware how IP multicast state is created in the		operator should be aware how IP multicast state is created in the
	network to ensure it does not exceed the scalability numbers of the		network to ensure that it does not exceed the scalability numbers of
	protocol, either PIM or mLDP.		the protocol, either PIM or mLDP.
	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 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.2. Terminology		1.2. Terminology
	IP multicast tree : An IP multicast distribution tree identified by		ASM: PIM Any Source Multicast
	a IP multicast Group address and optionally a Source IP address,
	also referred to as (S,G) and (*,G).
	RP: The PIM Rendezvous Point.		Egress LSR: One of potentially many destinations of an LSP; also
			referred to as leaf node in the case of P2MP and MP2MP LSPs.
	SSM: PIM Source Specific Multicast.		In-band signaling: Using the opaque value of an mLDP FEC Element to
			carry the (S,G) or (*,G) identifying a particular IP multicast
			tree.
	ASM: PIM Any Source Multicast.		Ingress LSR: Source of the P2MP LSP; also referred to as a root
			node.
	mLDP : Multipoint LDP.		IP multicast tree: An IP multicast distribution tree identified by
			an IP multicast Group address and, optionally, by a Source IP
			address, also referred to as (S,G) and (*,G).
	Transit LSP : A P2MP or MP2MP LSP whose FEC element contains the		LSR: Label Switching Router
	(S,G) or (*,G) identifying a particular IP multicast distribution
	tree.
	In-band signaling : Using the opaque value of a mLDP FEC element to		LSP: Labels Switched Path
	carry the (S,G) or (*,G) identifying a particular IP multicast
	tree.
	P2MP LSP: An LSP that has one Ingress LSR and one or more Egress		mLDP: Multipoint LDP
	LSRs.
	MP2MP LSP: An LSP that connects a set of leaf nodes that may each		MP2MP LSP: An LSP that connects a set of leaf nodes that may each
	independently act as ingress or egress.		independently act as ingress or egress.
	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: Source of the P2MP LSP, also referred to as root node.		P2MP LSP: An LSP that has one Ingress Label Switching Router (LSR)
			and one or more Egress LSRs.
	Egress LSR: One of potentially many destinations of an LSP, also		RP: PIM Rendezvous Point
	referred to as leaf node in the case of P2MP and MP2MP LSPs.
			SSM: PIM Source-Specific Multicast
			Transit LSP: A P2MP or MP2MP LSP whose FEC Element contains the
			(S,G) or (*,G) identifying a particular IP multicast distribution
			tree.
	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.
	2. In-band signaling for MP LSPs		2. In-Band Signaling for MP LSPs
	Consider the following topology;		Consider the following topology:
	|--- IPM ---|--- MPLS --|--- IPM ---|
	S/RP -- (A) - (U) - (C) - (D) -- (B) -- R		|--- IPM ---|--- MPLS --|--- IPM ---|
	Figure 1.		S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
	Nodes A and B are IP Multicast capable routers and respectively		Figure 1
	connect to a Source/RP and a Receiver. Nodes U, C and D are MPLS
			Nodes A and B are IP-multicast-capable routers and connect to a
			Source/RP and a Receiver, respectively. Nodes U, C, and D are MPLS
	Label Switched Routers (LSRs).		Label Switched Routers (LSRs).
	Label Switched Router D is attached to a network that is capable of		LSR D is attached to a network that is capable of MPLS multicast and
	MPLS multicast and IP multicast (see figure 1), and D is required to		IP multicast (see figure 1), and D is required to create a IP
	create a IP multicast tree due to a certain IP multicast event, like		multicast tree due to a certain IP multicast event, like a PIM Join,
	a PIM Join, MSDP Source Announcement (SA) [RFC3618], BGP Source		MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
	Active auto-discovery route [I-D.rekhter-pim-sm-over-mldp] or		discovery route [SM-MLDP], or Rendezvous Point (RP) discovery.
	Rendezvous Point (RP) discovery. Suppose that D can determine that		Suppose that D can determine that the IP multicast tree needs to
	the IP multicast tree needs to travel through the MPLS network until		travel through the MPLS network until it reaches LSR U. For
	it reaches LSR U. For instance, when D looks up the route to the		instance, when D looks up the route to the Source or RP [RFC4601] of
	Source or RP [RFC4601] of the IP multicast tree, it may discover that		the IP multicast tree, it may discover that the route is a BGP route
	the route is a BGP route with U as the BGP next hop. Then D may		with U as the BGP next hop. Then D may choose to set up a P2MP or an
	chose to set up a P2MP or MP2MP LSP, with U as root, and to make that		MP2MP LSP, with U as root, and to make that LSP become part of the IP
	LSP become part of the IP multicast distribution tree. Note that		multicast distribution tree. Note that other methods are possible to
	other methods are possible to determine that an IP multicast tree is		determine that an IP multicast tree is to be transported across an
	to be transported across an MPLS network using P2MP or MP2MP LSPs,		MPLS network using P2MP or MP2MP LSPs. However, these methods are
	these methods are outside the scope of this document.		outside the scope of this document.
	In order to establish a multicast tree via a P2MP or MP2MP LSP using		In order to establish a multicast tree via a P2MP or MP2MP LSP using
	"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with		"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with
	the IP address of LSR U as the "Root Node Address", and with the		the IP address of LSR U as the "Root Node Address" and with the
	source and the group encoded into the "opaque value" ([RFC6388],		source and the group encoded into the "opaque value" ([RFC6388],
	section 2.2 and 3.2). Several different opaque value types are		Sections 2.2 and 3.2). Several different opaque value types are
	defined in this document; LSR D MUST NOT use a particular opaque		defined in this document. LSR D MUST NOT use a particular opaque
	value type unless it knows (through provisioning, or through some		value type unless it knows (through provisioning or through some
	other means outside the scope of this document) that LSR U supports		other means outside the scope of this document) that LSR U supports
	the root node procedures for that opaque value type.		the root node procedures for that opaque value type.
	The particular type of FEC Element and opaque value used depends on		The particular type of FEC Element and opaque value used depends on
	the IP address family being used, and on whether the multicast tree		the IP address family being used, and on whether the multicast tree
	being established is a source specific or a bidirectional multicast		being established is a source-specific or a bidirectional multicast
	tree.		tree.
	When an LSR receives a label mapping or withdraw whose FEC Element		When an LSR receives a label mapping or withdraw whose FEC Element
	contains one of the opaque value types defined in this document, and		contains one of the opaque value types defined in this document, and
	that LSR is not the one identified by the "Root Node Address" field		that LSR is not the one identified by the "Root Node Address" field
	of that FEC element, the LSR follows the procedures of RFC 6388.		of that FEC Element, the LSR follows the procedures provided in RFC
			6388.
	When an LSR receives a label mapping or withdraw whose FEC Element		When an LSR receives a label mapping or withdraw whose FEC Element
	contains one of the opaque value types defined in this document, and		contains one of the opaque value types defined in this document, and
	that LSR is the one identified by the "Root Node Address" field of		that LSR is the one identified by the Root Node Address field of that
	that FEC element, then the following procedure is executed. The		FEC Element, then the following procedure is executed. The multicast
	multicast source and group are extracted and passed to the multicast		source and group are extracted and passed to the multicast code. If
	code. If a label mapping is being processed, the multicast code will		a label mapping is being processed, the multicast code will add the
	add the downstream LDP neighbor to the olist of the corresponding		downstream LDP neighbor to the olist of the corresponding (S,G) or
	(S,G) or (*,G) state, creating such state if it does not already		(*,G) state, creating such state if it does not already exist. If a
	exist. If a label withdraw is being processed, the multicast code		label withdraw is being processed, the multicast code will remove the
	will remove the downstream LDP neighbor from the olist of the		downstream LDP neighbor from the olist of the corresponding (S,G) or
	corresponding (S,G) or (*,G) state. From this point on normal PIM		(*,G) state. From this point on, normal PIM processing will occur.
	processing will occur.
	Note that if the LSR identified by the "Root Node Address" field does		Note that if the LSR identified by the Root Node Address field does
	not recognize the opaque value type, the MP LSP will be established,		not recognize the opaque value type, the MP LSP will be established,
	but the root node will not send any multicast data packets on it.		but the root node will not send any multicast data packets on it.
	Source or RP addresses that are reachable in a VPN context are		Source or RP addresses that are reachable in a VPN context are
	outside the scope of this document.		outside the scope of this document.
	Multicast groups that operate in PIM Dense-Mode are outside the scope		Multicast groups that operate in PIM Dense-Mode are outside the scope
	of this document.		of this document.
	2.1. Transiting Unidirectional IP multicast Shared Trees		2.1. Transiting Unidirectional IP Multicast Shared Trees
	Nothing prevents PIM shared trees, used by PIM-SM in the ASM service		Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
	model, from being transported across a MPLS core. However, it is not		model, from being transported across an MPLS core. However, it is
	possible to prune individual sources from the shared tree without the		not possible to prune individual sources from the shared tree without
	use of an additional out-of-band signaling protocol, like PIM or BGP		the use of an additional out-of-band signaling protocol, like PIM or
	[I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared		BGP [SM-MLDP]. For this reason, transiting shared trees across a
	Trees across a Transit LSP is outside the scope of this document.		transit LSP is outside the scope of this document.
	2.2. Transiting IP multicast source trees		2.2. Transiting IP Multicast Source Trees
	IP multicast source trees can either be created via PIM operating in		IP multicast source trees can be created via PIM operating in either
	SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM		SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM
	mode, the usual means of discovering active sources is to join a		mode, the usual means of discovering active sources is to join a
	sparse mode shared tree. However, this document does not provide any		sparse-mode shared tree. However, this document does not provide any
	method of establishing a sparse mode shared tree across an MPLS		method of establishing a sparse-mode shared tree across an MPLS
	network. To apply the technique of this document to PIM-SM in ASM		network. To apply the technique of this document to PIM-SM in ASM
	mode, there must be some other means of discovering the active		mode, there must be some other means of discovering the active
	sources. One possible means is the use of MSDP [RFC3618]. Another		sources. One possible means is the use of MSDP [RFC3618]. Another
	possible means is to use BGP Source Active auto-discovery routes, as		possible means is to use BGP Source Active auto-discovery routes, as
	documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of		documented in [SM-MLDP]. However, the method of discovering the
	discovering the active sources is outside the scope of this document,		active sources is outside the scope of this document; as a result,
	and as a result this document does not specify everything that is		this document does not specify everything that is needed to support
	needed to support the ASM service model using in-band signaling.		the ASM service model using in-band signaling.
	The source and group addresses are encoded into the a transit TLV as		The source and group addresses are encoded into the a transit TLV as
	specified in Section 3.1 and Section 3.2.		specified in Sections 3.1 and 3.2.
	2.3. Transiting IP multicast bidirectional trees		2.3. Transiting IP Multicast Bidirectional Trees
	If a Bidirectional IP multicast trees [RFC5015] has to be transported		If a bidirectional IP multicast tree [RFC5015] has to be transported
	over a MPLS network using in-band signaling, as described in this		over an MPLS network using in-band signaling, as described in this
	document, it MUST be transported using a MP2MP LSPs. A bidirectional		document, it MUST be transported using an MP2MP LSPs. A
	tree does not have a specific source address; the group address,		bidirectional tree does not have a specific source address; the group
	subnet mask and RP are relevant for multicast forwarding. This		address, subnet mask, and RP are relevant for multicast forwarding.
	document does not provide procedures to discover RP to group mappings		This document does not provide procedures to discover RP-to-group
	dynamically across an MPLS network and assumes the RP is statically		mappings dynamically across an MPLS network and assumes the RP is
	defined. Support of dynamic RP mappings in combination with in-band		statically defined. Support of dynamic RP mappings in combination
	signaling is outside the scope of his document.		with in-band signaling is outside the scope of this document.
	The RP for the group is used to select the ingress LSR and root of		The RP for the group is used to select the ingress LSR and the root
	the LSP. The group address is encoded according to the rules of		of the LSP. The group address is encoded according to the rules of
	Section 3.3 or Section 3.4, depending on the IP version. The subnet		Sections 3.3 or 3.4, depending on the IP version. The subnet mask
	mask associated with the bidirectional group is encoded in the		associated with the bidirectional group is encoded in the Transit
	Transit TLV. There are two types of bidirectional states in IP		TLV. There are two types of bidirectional states in IP multicast,
	multicast, the group specific state and the RP state. The first type		the group specific state and the RP state. The first type is
	is typically created due to receiving a PIM join and has a subnet		typically created when a PIM Join has been received and has a subnet
	mask of 32 for IPv4 and 128 for IPv6. The latter is typically		mask of 32 for IPv4 and 128 for IPv6. The RP state is typically
	created via the static RP mapping and has a variable subnet mask.		created via the static RP mapping and has a variable subnet mask.
	The RP state is used to build a tree to the RP and used for sender		The RP state is used to build a tree to the RP and is used for
	only branches. Each state (group specific and RP state) will result		sender-only branches. Each state (group specific and RP state) will
	in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be		result in a separate MP2MP LSP. The merging of the two MP2MP LSPs
	done by PIM on the root LSR. No special procedures are necessary for		will be done by PIM on the root LSR. No special procedures are
	PIM to merge the two LSPs, each LSP is effectively treated as a PIM		necessary for PIM to merge the two LSPs. Each LSP is effectively
	enabled interface. Please see [RFC5015] for more details.		treated as a PIM-enabled interface. Please see [RFC5015] for more
			details.
	For transporting the packets of a sender only branch we create a		For transporting the packets of a sender-only branch, we create a
	MP2MP LSP. Other sender only branches will receive these packets and		MP2MP LSP. Other sender-only branches will receive these packets and
	will not forward them because there are no receivers. These packets		will not forward them because there are no receivers. These packets
	will be dropped. If that affect is undesireable some other means of		will be dropped. If that effect is undesirable, some other means of
	transport has to be established to forward packets to the root of the		transport has to be established to forward packets to the root of the
	tree, like a Multi-Point to Point LSP for example. A technique to		tree, for example, a multipoint-to-point LSP for example. A
	unicast packets to the root of a P2MP or MP2MP LSP is documented in		technique to unicast packets to the root of a P2MP or MP2MP LSP is
	[I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1.		documented in Section 3.2.2.1 of [MVPN-MSPMSI].
	3. LSP opaque encodings		3. LSP Opaque Encodings
	This section documents the different transit opaque encodings.		This section documents the different transit opaque encodings.
	3.1. Transit IPv4 Source TLV		3.1. Transit IPv4 Source TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Group |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 3 (to be assigned by IANA).		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Source |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | Group |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type: 3
	Length: 8 (octet size of Source and Group fields)		Length: 8 (octet size of Source and Group fields)
	Source: IPv4 multicast source address, 4 octets.		Source: IPv4 multicast source address, 4 octets
	Group: IPv4 multicast group address, 4 octets.		Group: IPv4 multicast group address, 4 octets
	3.2. Transit IPv6 Source TLV		3.2. Transit IPv6 Source TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source ~		| Type | Length | Source ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ | Group ~		~ | Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 4 (to be assigned by IANA).		Type: 4
	Length: 32 (octet size of Source and Group fields)		Length: 32 (octet size of Source and Group fields)
	Source: IPv6 multicast source address, 16 octets.		Source: IPv6 multicast source address, 16 octets
	Group: IPv6 multicast group address, 16 octets.		Group: IPv6 multicast group address, 16 octets.
	3.3. Transit IPv4 bidir TLV		3.3. Transit IPv4 Bidir TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Mask Len |		| Type | Length | Mask Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RP |		| RP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group |		| Group |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 5 (to be assigned by IANA).		Type: 5
	Length: 9 (octet size of Mask Len, RP and Group fields)		Length: 9 (octet size of Mask Len, RP, and Group fields)
	Mask Len: The number of contiguous one bits that are left justified		Mask Len: The number of contiguous one bits that are left-justified
	and used as a mask, 1 octet. Maximum value allowed is 32.		and used as a mask, 1 octet. Maximum value allowed is 32.
	RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4		RP: Rendezvous Point (RP) IPv4 address used for the encoded Group, 4
	octets.		octets.
	Group: IPv4 multicast group address, 4 octets.		Group: IPv4 multicast group address, 4 octets.
	3.4. Transit IPv6 bidir TLV		3.4. Transit IPv6 Bidir TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Mask Len |		| Type | Length | Mask Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RP ~		| RP ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group ~		| Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 6 (to be assigned by IANA).		Type: 6
	Length: 33 (octet size of Mask Len, RP and Group fields)		Length: 33 (octet size of Mask Len, RP and Group fields)
	Mask Len: The number of contiguous one bits that are left justified		Mask Len: The number of contiguous one bits that are left-justified
	and used as a mask, 1 octet. Maximum value allowed is 128.		and used as a mask, 1 octet. Maximum value allowed is 128.
	RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16		RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16
	octets.		octets.
	Group: IPv6 multicast group address, 16 octets.		Group: IPv6 multicast group address, 16 octets.
	4. Security Considerations		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 [RFC5036].		specification, as described in [RFC5036].
	5. IANA considerations		5. IANA Considerations
	This document requires allocation from the 'LDP MP Opaque Value		IANA has allocated the following values from the "LDP MP Opaque Value
	Element basic type' name space managed by IANA. The values requested		Element basic type" registry: are:
	are:
	Transit IPv4 Source TLV type - 3		Transit IPv4 Source TLV type - 3
	Transit IPv6 Source TLV type - 4		Transit IPv6 Source TLV type - 4
	Transit IPv4 Bidir TLV type - 5		Transit IPv4 Bidir TLV type - 5
	Transit IPv6 Bidir TLV type - 6		Transit IPv6 Bidir TLV type - 6
	6. Acknowledgments		6. References
	Thanks to Eric Rosen for his valuable comments on this document.
	Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
	Andersson and Arkadiy Gulko for providing comments on this document.
	7. Contributing authors
	Below is a list of the contributing authors in alphabetical order:
	Toerless Eckert
	Cisco Systems, Inc.
	170 Tasman Drive
	San Jose, CA, 95134
	USA
	E-mail: eckert@cisco.com
	Nicolai Leymann
	Deutsche Telekom
	Winterfeldtstrasse 21
	Berlin, 10781
	Germany
	E-mail: n.leymann@telekom.de
	Maria Napierala
	AT&T Labs
	200 Laurel Avenue
	Middletown, NJ 07748
	USA
	E-mail: mnapierala@att.com
	IJsbrand Wijnands
	Cisco Systems, Inc.
	De kleetlaan 6a
	1831 Diegem
	Belgium
	E-mail: ice@cisco.com
	8. References
	8.1. Normative References		6.1. Normative References
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	Specification", RFC 5036, October 2007.		"LDP Specification", RFC 5036, October 2007.
	[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.
	[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,		[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
	"Label Distribution Protocol Extensions for Point-to-		Thomas, "Label Distribution Protocol Extensions for Point-
	Multipoint and Multipoint-to-Multipoint Label Switched		to-Multipoint and Multipoint-to-Multipoint Label Switched
	Paths", RFC 6388, November 2011.		Paths", RFC 6388, November 2011.
	8.2. Informative References		6.2. Informative References
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	IP", RFC 4607, August 2006.		IP", RFC 4607, August 2006.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	PIM)", RFC 5015, October 2007.		PIM)", RFC 5015, October 2007.
	[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery		[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
	Protocol (MSDP)", RFC 3618, October 2003.		Discovery Protocol (MSDP)", RFC 3618, October 2003.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
	VPNs", RFC 6513, February 2012.		MPLS/BGP IP VPNs", RFC 6513, February 2012.
	[I-D.rekhter-pim-sm-over-mldp]		[SM-MLDP] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-
	Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode		SM in ASM mode Trees over P2MP mLDP LSPs", Work in
	Trees over P2MP mLDP LSPs",		Progress, August 2011.
	draft-rekhter-pim-sm-over-mldp-04 (work in progress),
	August 2011.
	[I-D.rosen-l3vpn-mvpn-mspmsi]		[MVPN-MSPMSI]
	Cai, Y., Rosen, E., Wijnands, I., Napierala, M., and A.		Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers,
	Boers, "MVPN: Optimized use of PIM via MS-PMSIs",		MVPN: Optimized use of PIM via MS-PMSIs", February 2012.
	draft-rosen-l3vpn-mvpn-mspmsi-10 (work in progress),
	February 2012.		7. Acknowledgments
			Thanks to Eric Rosen for his valuable comments on this document.
			Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
			Andersson and Arkadiy Gulko for providing comments on this document.
	Authors' Addresses		Authors' Addresses
	IJsbrand Wijnands (editor)		IJsbrand Wijnands (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	De kleetlaan 6a		De kleetlaan 6a
	Diegem 1831		Diegem 1831
	Belgium		Belgium
	Email: ice@cisco.com		EMail: ice@cisco.com
	Toerless Eckert		Toerless Eckert
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose CA, 95134		San Jose CA, 95134
	USA		USA
	Email: eckert@cisco.com		EMail: eckert@cisco.com
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	Winterfeldtstrasse 21		Winterfeldtstrasse 21
	Berlin 10781		Berlin 10781
	Germany		Germany
	Email: n.leymann@telekom.de		EMail: n.leymann@telekom.de
	Maria Napierala		Maria Napierala
	AT&T Labs		AT&T Labs
	200 Laurel Avenue		200 Laurel Avenue
	Middletown NJ 07748		Middletown NJ 07748
	USA		USA
	Email: mnapierala@att.com		EMail: mnapierala@att.com
End of changes. 87 change blocks.
	272 lines changed or deleted		238 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/