draft-ietf-mpls-mldp-in-band-signaling-03.txt		draft-ietf-mpls-mldp-in-band-signaling-04.txt
	Network Working Group IJ. Wijnands, Ed.		Network Working Group IJ. Wijnands, Ed.
	Internet-Draft T. Eckert		Internet-Draft T. Eckert
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: August 12, 2011 N. Leymann		Expires: November 19, 2011 N. Leymann
	Deutsche Telekom		Deutsche Telekom
	M. Napierala		M. Napierala
	AT&T Labs		AT&T Labs
	February 8, 2011		May 18, 2011
	mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to-		Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-
	Multipoint Label Switched Paths		to-Multipoint Label Switched Paths
	draft-ietf-mpls-mldp-in-band-signaling-03		draft-ietf-mpls-mldp-in-band-signaling-04
	Abstract		Abstract
	Suppose 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), 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 are		message is encoded into mLDP messages. When the mLDP messages reach
	received at the border of the next IP domain, the encoded information		the border of the next IP domain, the encoded information is used to
	is used to generate PIM messages that can be sent through the IP		generate PIM messages that can be sent through the IP domain. The
	domain. The result is an IP multicast tree consisting of a set of IP		result is an IP multicast tree consisting of a set of IP multicast
	multicast sub-trees that are spliced together with a multipoint LSP.		sub-trees that are spliced together with a multipoint LSP.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on November 19, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 12, 2011.
	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
	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
	skipping to change at page 2, line 21		skipping to change at page 2, line 15
	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 BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conventions used in this document . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4		2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5
	2.1. Transiting Unidirectional IP multicast Shared Trees . . . 5		2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6
	2.2. Transiting IP multicast source trees . . . . . . . . . . . 5		2.2. Transiting IP multicast source trees . . . . . . . . . . . 7
	2.3. Transiting IP multicast bidirectional trees . . . . . . . 6		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 . . . . . . . . . . . . . . . . . 7		3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
	3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8		3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9
	3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8		3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10		7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms		The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms
	for creating point-to-multipoint (P2MP) and multipoint-to-multipoint		for creating point-to-multipoint (P2MP) and multipoint-to-multipoint
	MP2MP LSPs. These LSPs are typically used for transporting enduser		MP2MP LSPs. These LSPs are typically used for transporting enduser
	multicast packets. However, the mLDP specification		multicast packets. However, the mLDP specification does not provide
	[I-D.ietf-mpls-ldp-p2mp] does not provide any rules for associating		any rules for associating particular enduser multicast packets with
	particular enduser multicast packets with any particular LSP. Other		any particular LSP. Other drafts, like
	drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in		[I-D.ietf-l3vpn-2547bis-mcast], describe applications in which out-
	which out-of-band signaling protocols, such as PIM and BGP, are used		of-band signaling protocols, such as PIM and BGP, are used to
	to establish the mapping between an LSP and the multicast packets		establish the mapping between an LSP and the multicast packets that
	that need to be forwarded over the LSP.		need to be forwarded over the LSP.
	This draft describes an application in which the information needed		This draft describes an application in which the information needed
	to establish the mapping between an LSP and the set of multicast		to establish the mapping between an LSP and the set of multicast
	packets to be forwarded over it is carried in the "opaque value"		packets to be forwarded over it is carried in the "opaque value"
	field of an mLDP FEC element. When an IP multicast tree (either a		field of an mLDP FEC element. When an IP multicast tree (either a
	source-specific tree or a bidirectional tree) enters the MPLS network		source-specific tree or a bidirectional tree) enters the MPLS network
	the (S,G) or (*,G) information from the IP multicast control plane		the (S,G) or (*,G) information from the IP multicast control plane
	state is carried in the opaque value field of the mLDP FEC message.		state is carried in the opaque value field of the mLDP FEC message.
	As the tree leaves the MPLS network, this information is extracted		As the tree leaves the MPLS network, this information is extracted
	from the FEC element and used to build the IP multicast control		from the FEC element and used to build the IP multicast control
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	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		IP multicast tree : An IP multicast distribution tree identified by
	an source IP address and/or IP multicast destination address, also		an source IP address and/or IP multicast destination address, also
	refered to as (S,G) and (*,G).		refered to as (S,G) and (*,G).
	mLDP : Multicast LDP.		RP: The PIM Rendezvous Point.
			SSM: PIM Source Specific Multicast.
			ASM: PIM Any Source Multicast.
			mLDP : Multipoint LDP.
	Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the		Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the
	(S,G) or (*,G) identifying a particular IP multicast distribution		(S,G) or (*,G) identifying a particular IP multicast distribution
	tree.		tree.
	In-band signaling : Using the opaque value of a mLDP FEC element to		In-band signaling : Using the opaque value of a mLDP FEC element to
	carry the (S,G) or (*,G) indentifying a particular IP multicast		carry the (S,G) or (*,G) indentifying a particular IP multicast
	tree.		tree.
	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
	skipping to change at page 5, line 34		skipping to change at page 5, line 40
	Egress LSR: One of potentially many destinations of an LSP, also		Egress LSR: One of potentially many destinations of an LSP, also
	referred to as leaf node in the case of P2MP and MP2MP LSPs.		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.
	2. In-band signaling for MP LSPs		2. In-band signaling for MP LSPs
	Suppose an LSR, call it D, is attached to a network that is capable		Suppose an LSR, call it D, is attached to a network that is capable
	of MPLS multicast and IP multicast, and D has the desire to create IP		of MPLS multicast and IP multicast, and D is required to create a IP
	multicast tree due to a certain IP multicast event, like a PIM Join,		multicast tree due to a certain IP multicast event, like a PIM Join,
	MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-		MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
	discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery.		discovery route [I-D.rekhter-pim-sm-over-mldp] or Rendezvous Point
	Suppose that D can determine that the IP multicast tree needs to		(RP) discovery. Suppose that D can determine that the IP multicast
	travel through the MPLS network until it reaches some other LSR, U.		tree needs to travel through the MPLS network until it reaches some
	For instance, when D looks up the route to the Source or Rendezvous		other LSR, U. For instance, when D looks up the route to the Source
	Point (RP) [RFC4601] of the IP multicast tree, it may discover that		or RP [RFC4601] of the IP multicast tree, it may discover that the
	the route is a BGP route with U as the BGP next hop. Then D may		route is a BGP route with U as the BGP next hop. Then D may chose to
	chose to set up a P2MP or MP2MP LSP, with U as root, and to make that		set up a P2MP or MP2MP LSP, with U as root, and to make that LSP
	LSP become part of the IP multicast distribution tree. Note that		become part of the IP multicast distribution tree. Note that other
	other methods are possible to determine that an IP multicast tree is		methods are possible to determine that an IP multicast tree is to be
	to be transported across an MPLS network using P2MP or MP2MP LSPs,		transported across an MPLS network using P2MP or MP2MP LSPs, these
	these methods are outside the scope of this document.		methods are outside the scope of this document.
	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.
	In order to transport the multicast tree via a P2MP or MP2MP LSP		In order to establish a multicast tree via a P2MP or MP2MP LSP using
	using in-band signaling the source and the group will be encoded into		in-band signaling the source and the group will be encoded into an
	an mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of		mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of
	encoding depends on the IP version. The tree type (P2MP or MP2MP)		encoding depends on the IP version. The tree type (P2MP or MP2MP)
	depends on whether this is a source specific or a bidirectional		depends on whether this is a source specific or a bidirectional
	multicast tree. The root of the tree is the BGP next-hop that was		multicast tree. The root of the tree is the BGP next-hop that was
	found during the route lookup on the source or RP. Using this		found during the route lookup on the source or RP. Using this
	information a mLDP FEC is created and the LSP is build towards the		information a mLDP FEC is created and the LSP is build towards the
	root of the LSP.		root of the LSP.
	When an LSR receives a label mapping or withdraw and discovers it is		When an LSR receives a label mapping or withdraw and discovers it is
	the root of the identified P2MP or MP2MP LSP, then the following		the root of the identified P2MP or MP2MP LSP, then the following
	procedure is executed. If the opaque encoding of the FEC indicates		procedure is executed. If the opaque encoding of the FEC indicates
	this is a Transit LSP (indicated by the opaque type), the opaque TLV		this is a Transit LSP (indicated by the opaque type), the opaque TLV
	is decoded and the multicast source and group is passed to the		is decoded and the multicast source and group is passed to the
	multicast code. If the multicast tree information is received via a		multicast code. If the multicast tree information is received via a
	label mapping, the multicast code will adds the downstream LDP		label mapping, the multicast code will add the downstream LDP
	neighbor to the olist of the corresponding (S,G) or (*,G) state,		neighbor to the olist of the corresponding (S,G) or (*,G) state,
	creating such state if it does not already exist. If it is due to a		creating such state if it does not already exist. If it is due to a
	label withdraw, the multicast code will remove the downstream LDP		label withdraw, the multicast code will remove the downstream LDP
	neighbor from the olist of the corresponding (S,G) or (*,G) state.		neighbor from the olist of the corresponding (S,G) or (*,G) state.
	From this point on normal PIM processing will occur.		From this point on normal PIM processing will occur.
	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 a MPLS core. However, it is not
	skipping to change at page 7, line 5		skipping to change at page 7, line 14
	use of an additional out-of-band signaling protocol, like PIM or BGP		use of an additional out-of-band signaling protocol, like PIM or BGP
	[I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared		[I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared
	Trees across a Transit LSP is outside the scope of this draft.		Trees across a Transit LSP is outside the scope of this draft.
	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 either be created via PIM operating in
	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 transporting 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 [I-D.rekhter-pim-sm-over-mldp]. However, the method of
	discovering the active sources is outside the scope of this document,		discovering the active sources is outside the scope of this document,
	and as a result this document does not specify everything that is		and as a result this document does not specify everything that is
	needed to support the ASM service model using in-band signaling.		needed to support 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
	skipping to change at page 7, line 29		skipping to change at page 7, line 38
	Bidirectional IP multicast trees [RFC5015] MUST be transported across		Bidirectional IP multicast trees [RFC5015] MUST be transported across
	a MPLS network using MP2MP LSPs. A bidirectional tree does not have		a MPLS network using MP2MP LSPs. A bidirectional tree does not have
	a specific source address; the group address, subnet mask and RP are		a specific source address; the group address, subnet mask and RP are
	relevant for multicast forwarding. This document does not provide		relevant for multicast forwarding. This document does not provide
	procedures to discover RP to group mappings dynamically across an		procedures to discover RP to group mappings dynamically across an
	MPLS network and assumes the RP is statically defined. Support of		MPLS network and assumes the RP is statically defined. Support of
	dynamic RP mappings in combination with in-band signaling is outside		dynamic RP mappings in combination with in-band signaling is outside
	the scope of his document.		the scope of his document.
	The RP for the group is used to select the ingress PE and root of the		The RP for the group is used to select the ingress LSR and root of
	LSP. The group address is encoded according to the rules 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		Section 3.3 or Section 3.4, depending on the IP version. The subnet
	mask associated with the bidirectional group is encoded in the		mask associated with the bidirectional group is encoded in the
	Transit TLV. There are two types of bidirectional states in IP		Transit TLV. There are two types of bidirectional states in IP
	multicast, the group specific state and the RPA state. The first		multicast, the group specific state and the RP state. The first type
	type is typically created due to receiving a PIM join and has a		is typically created due to receiving a PIM join and has a subnet
	subnet mask of 32 for IPv4 and 128 for IPv6. The latter is typically		mask of 32 for IPv4 and 128 for IPv6. The latter 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 RPA 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 used for sender
	only branches. Each state (group specific and RPA state) will result		only branches. Each state (group specific and RP state) will result
	in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be		in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be
	done by PIM on the root LSR. No speccial procedures are nessesary		done by PIM on the root LSR. No speccial procedures are nessesary
	for PIM to merge the two LSPs, each LSP is effectively treated as a		for PIM to merge the two LSPs, each LSP is effectively treated as a
	PIM enabled interface. Please see [RFC5015] for more details.		PIM enabled interface. Please see [RFC5015] for more details.
	In order transport the packets of sender only branch to the root of		In order transport the packets of sender only branch to the root of
	the LSP a MP2MP is created. This will cause the sender only branches		the LSP a MP2MP is created. This will cause the sender only branches
	to receive each others packets. These packets will be dropped and		to receive each others packets. These packets will be dropped and
	not forwarded, if that affect is undesireable some other means of		not forwarded, if that affect is undesireable 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
	skipping to change at page 8, line 26		skipping to change at page 8, line 34
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source		| Type | Length | Source
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group		| Group
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|		|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 3 (to be assigned by IANA).		Type: 3 (to be assigned by IANA).
	Length: 8		Length: 8 octets
	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 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 7		skipping to change at page 9, line 16
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source ~		| Type | Length | Source ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ | Group ~		~ | Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 4 (to be assigned by IANA).		Type: 4 (to be assigned by IANA).
	Length: 32		Length: 32 octets
	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 (to be assigned by IANA).
	Length: 9		Length: 9 octets
	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.		and used as a mask, 1 octet.
	RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4		RP: Rendezvous Point (RP) IPv4 address used for 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
	skipping to change at page 10, line 20		skipping to change at page 10, line 28
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group ~		| Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 6 (to be assigned by IANA).		Type: 6 (to be assigned by IANA).
	Length: 33		Length: 33 octets
	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.		and used as a mask, 1 octet.
	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		This document requires allocation from the 'LDP MP Opaque Value
	Element type name space managed by IANA. The values requested are:		Element basic type' name space managed by IANA. The values requested
			are:
	Transit IPv4 Source TLV type - requested 3		Transit IPv4 Source TLV type - 3
	Transit IPv6 Source TLV type - requested 4		Transit IPv6 Source TLV type - 4
	Transit IPv4 Bidir TLV type - requested 5
	Transit IPv6 Bidir TLV type - requested 6		Transit IPv4 Bidir TLV type - 5
			Transit IPv6 Bidir TLV type - 6
	6. Acknowledgments		6. Acknowledgments
	Thanks to Eric Rosen for his valuable comments on this draft. Also		Thanks to Eric Rosen for his valuable comments on this draft. Also
	thanks to Yakov Rekhter, Adrial Farrel and Uwe Joorde for providing		thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde and Loa Andersson
	comments on this draft.		for providing comments on this draft.
	7. Contributing authors		7. Contributing authors
	Below is a list of the contributing authors in alphabetical order:		Below is a list of the contributing authors in alphabetical order:
	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
End of changes. 31 change blocks.
	89 lines changed or deleted		89 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/