draft-ietf-mpls-ldp-p2mp-09.txt		draft-ietf-mpls-ldp-p2mp-10.txt
	Network Working Group I. Minei (Editor)		Network Working Group I. Minei (Editor)
	Internet-Draft K. Kompella		Internet-Draft K. Kompella
	Intended status: Standards Track Juniper Networks		Intended status: Standards Track Juniper Networks
	Expires: November 1, 2010 I. Wijnands (Editor)		Expires: January 12, 2011 I. Wijnands (Editor)
	B. Thomas		B. Thomas
	Cisco Systems, Inc.		Cisco Systems, Inc.
	April 30, 2010		July 11, 2010
	Label Distribution Protocol Extensions for Point-to-Multipoint and		Label Distribution Protocol Extensions for Point-to-Multipoint and
	Multipoint-to-Multipoint Label Switched Paths		Multipoint-to-Multipoint Label Switched Paths
	draft-ietf-mpls-ldp-p2mp-09		draft-ietf-mpls-ldp-p2mp-10
	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 multi-point (P2MP) and multipoint-to-		(LDP) for the setup of point to multi-point (P2MP) and multipoint-to-
	multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol		multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol
	Label Switching (MPLS) networks. These extensions are also referred		Label Switching (MPLS) networks. These extensions are also referred
	to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs		to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs
	without interacting with or relying upon any other multicast tree		without interacting with or relying upon any other multicast tree
	construction protocol. Protocol elements and procedures for this		construction protocol. Protocol elements and procedures for this
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	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 November 1, 2010.		This Internet-Draft will expire on January 12, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 3, line 51		skipping to change at page 3, line 51
	9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27		9.1. MBB overview . . . . . . . . . . . . . . . . . . . . . . . 27
	9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28		9.2. The MBB Status code . . . . . . . . . . . . . . . . . . . 28
	9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28		9.3. The MBB capability . . . . . . . . . . . . . . . . . . . . 28
	9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29		9.4. The MBB procedures . . . . . . . . . . . . . . . . . . . . 29
	9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29		9.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 29
	9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30		9.4.2. Accepting elements . . . . . . . . . . . . . . . . . . 30
	9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30		9.4.3. Procedures for upstream LSR change . . . . . . . . . . 30
	9.4.4. Receiving a Label Map with MBB status code . . . . . . 31		9.4.4. Receiving a Label Map with MBB status code . . . . . . 31
	9.4.5. Receiving a Notification with MBB status code . . . . 31		9.4.5. Receiving a Notification with MBB status code . . . . 31
	9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31		9.4.6. Node operation for MP2MP LSPs . . . . . . . . . . . . 31
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 32		10. Typed Wildcard for mLDP FEC Element . . . . . . . . . . . . . 32
	11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32		11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
	13. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		14. Contributing authors . . . . . . . . . . . . . . . . . . . . . 33
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 35		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	14.2. Informative References . . . . . . . . . . . . . . . . . . 35		15.1. Normative References . . . . . . . . . . . . . . . . . . . 35
			15.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	The LDP protocol is described in [RFC5036]. It defines mechanisms		The LDP protocol is described in [RFC5036]. It defines mechanisms
	for setting up point-to-point (P2P) and multipoint-to-point (MP2P)		for setting up point-to-point (P2P) and multipoint-to-point (MP2P)
	LSPs in the network. This document describes extensions to LDP for		LSPs in the network. This document describes extensions to LDP for
	setting up point-to-multipoint (P2MP) and multipoint-to-multipoint		setting up point-to-multipoint (P2MP) and multipoint-to-multipoint
	(MP2MP) LSPs. These are collectively referred to as multipoint LSPs		(MP2MP) LSPs. These are collectively referred to as multipoint LSPs
	(MP LSPs). A P2MP LSP allows traffic from a single root (or ingress)		(MP LSPs). A P2MP LSP allows traffic from a single root (or ingress)
	skipping to change at page 11, line 32		skipping to change at page 11, line 32
	next-hop on the best path from Z to the root node X. If there is more		next-hop on the best path from Z to the root node X. If there is more
	than one such LDP peer, only one of them is picked. U is Z's		than one such LDP peer, only one of them is picked. U is Z's
	"Upstream LSR" for <X, Y>.		"Upstream LSR" for <X, Y>.
	When there are several candidate upstream LSRs, the LSR MAY select		When there are several candidate upstream LSRs, the LSR MAY select
	one upstream LSR using the following procedure:		one upstream LSR using the following procedure:
	1. The candidate upstream LSRs are numbered from lower to higher IP		1. The candidate upstream LSRs are numbered from lower to higher IP
	address		address
	2. The following hash is performed: H = (Sum Opaque value) modulo N,		2. The following hash is performed: H = (CRC32(Opaque value)) modulo
	where N is the number of candidate upstream LSRs		N, where N is the number of upstream LSRs.
	3. The selected upstream LSR U is the LSR that has the number H.		3. The selected upstream LSR U is the LSR that has the number H.
	This allows for load balancing of a set of LSPs among a set of		This allows for load balancing of a set of LSPs among a set of
	candidate upstream LSRs, while ensuring that on a LAN interface a		candidate upstream LSRs, while ensuring that on a LAN interface a
	single upstream LSR is selected.		single upstream LSR is selected.
	2.4.1.2. Determining the forwarding interface to an LSR		2.4.1.2. Determining the forwarding interface to an LSR
	Suppose LSR U receives a MP Label Map message from a downstream LSR		Suppose LSR U receives a MP Label Map message from a downstream LSR
	skipping to change at page 33, line 5		skipping to change at page 33, line 5
	The procedures described above apply to the downstream path of a		The procedures described above apply to the downstream path of a
	MP2MP LSP. The upstream path of the MP2MP is setup as normal without		MP2MP LSP. The upstream path of the MP2MP is setup as normal without
	including a MBB Status code. If the MBB procedures apply to a MP2MP		including a MBB Status code. If the MBB procedures apply to a MP2MP
	downstream FEC element, the upstream path to a node N is only		downstream FEC element, the upstream path to a node N is only
	installed in the label forwarding database if node N is part of the		installed in the label forwarding database if node N is part of the
	active accepting element. If node N is part of an inactive accepting		active accepting element. If node N is part of an inactive accepting
	element, the upstream path is installed when this inactive accepting		element, the upstream path is installed when this inactive accepting
	element is activated.		element is activated.
	10. Security Considerations		10. Typed Wildcard for mLDP FEC Element
			The format of the mLDP FEC Typed Wildcard FEC is as follows:
			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 2
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Typed Wcard | Type = mLDP | Len = 2 | AFI ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ |
			+-+-+-+-+-+-+-+-+
			Type Wcard: As specified in [I-D.ietf-mpls-ldp-typed-wildcard]
			Type: mLDP FEC Element Type as documented in this draft.
			Len: Len FEC Type Info, two octets (=0x02).
			AFI: Address Family, two octet quantity containing a value from
			ADDRESS FAMILY NUMBERS in [IANA-AF].
			11. 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].
	11. IANA considerations		12. IANA considerations
	This document creates a new name space (the LDP MP Opaque Value		This document creates a new name space (the LDP MP Opaque Value
	Element type) that is to be managed by IANA, and the allocation of		Element type) that is to be managed by IANA, and the allocation of
	the value 1 for the type of Generic LSP Identifier.		the value 1 for the type of Generic LSP Identifier.
	This document requires allocation of three new LDP FEC Element types:		This document requires allocation of three new LDP FEC Element types:
	1. the P2MP FEC type - requested value 0x06		1. the P2MP FEC type - requested value 0x06
	2. the MP2MP-up FEC type - requested value 0x07		2. the MP2MP-up FEC type - requested value 0x07
	skipping to change at page 34, line 5		skipping to change at page 34, line 28
	This document requires the assigment of a new code point for a LDP MP		This document requires the assigment of a new code point for a LDP MP
	Status TLV. The value requested from the LDP TLV Type Name Space:		Status TLV. The value requested from the LDP TLV Type Name Space:
	LDP MP Status TLV Type - requested value 0x096F		LDP MP Status TLV Type - requested value 0x096F
	This document creates a new name space (the LDP MP Status Value		This document creates a new name space (the LDP MP Status Value
	Element type) that is to be managed by IANA, and the allocation of		Element type) that is to be managed by IANA, and the allocation of
	the value 1 for the type of MBB Status.		the value 1 for the type of MBB Status.
	12. Acknowledgments		This document creates a new name space (the LDP MP Opaque Value
			Element type) that is to be managed by IANA.
			13. Acknowledgments
	The authors would like to thank the following individuals for their		The authors would like to thank the following individuals for their
	review and contribution: Nischal Sheth, Yakov Rekhter, Rahul		review and contribution: Nischal Sheth, Yakov Rekhter, Rahul
	Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert,		Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert,
	George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas		George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel and Thomas
	Morin.		Morin.
	13. Contributing authors		14. Contributing authors
	Below is a list of the contributing authors in alphabetical order:		Below is a list of the contributing authors in alphabetical order:
	Shane Amante		Shane Amante
	Level 3 Communications, LLC		Level 3 Communications, LLC
	1025 Eldorado Blvd		1025 Eldorado Blvd
	Broomfield, CO 80021		Broomfield, CO 80021
	US		US
	Email: Shane.Amante@Level3.com		Email: Shane.Amante@Level3.com
	Luyuan Fang		Luyuan Fang
	Cisco Systems		Cisco Systems
	300 Beaver Brook Road		300 Beaver Brook Road
	Boxborough, MA 01719		Boxborough, MA 01719
	US		US
	Email: lufang@cisco.com		Email: lufang@cisco.com
	Hitoshi Fukuda		Hitoshi Fukuda
	NTT Communications Corporation		NTT Communications Corporation
	1-1-6, Uchisaiwai-cho, Chiyoda-ku		1-1-6, Uchisaiwai-cho, Chiyoda-ku
	skipping to change at page 35, line 45		skipping to change at page 36, line 24
	Norway		Norway
	Email: lei.wang@telenor.com		Email: lei.wang@telenor.com
	IJsbrand Wijnands		IJsbrand Wijnands
	Cisco Systems, Inc.		Cisco Systems, Inc.
	De kleetlaan 6a		De kleetlaan 6a
	1831 Diegem		1831 Diegem
	Belgium		Belgium
	E-mail: ice@cisco.com		E-mail: ice@cisco.com
	14. References		15. References
	14.1. Normative References
			15.1. Normative References
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[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.
	[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by		[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
	an On-line Database", RFC 3232, January 2002.		an On-line Database", RFC 3232, January 2002.
	skipping to change at page 36, line 34		skipping to change at page 37, line 11
	[I-D.ietf-mpls-ldp-upstream]		[I-D.ietf-mpls-ldp-upstream]
	Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment		Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
	for LDP", draft-ietf-mpls-ldp-upstream-02 (work in		for LDP", draft-ietf-mpls-ldp-upstream-02 (work in
	progress), November 2007.		progress), November 2007.
	[I-D.ietf-mpls-ldp-capabilities]		[I-D.ietf-mpls-ldp-capabilities]
	Thomas, B., "LDP Capabilities",		Thomas, B., "LDP Capabilities",
	draft-ietf-mpls-ldp-capabilities-02 (work in progress),		draft-ietf-mpls-ldp-capabilities-02 (work in progress),
	March 2008.		March 2008.
	14.2. Informative References		[I-D.ietf-mpls-ldp-typed-wildcard]
			Minei, I., Thomas, B., and R. Asati, "Label Distribution
			Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
			(FEC)", draft-ietf-mpls-ldp-typed-wildcard-07 (work in
			progress), March 2010.
			15.2. Informative References
	[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual		[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
	Private Networks (L2VPNs)", RFC 4664, September 2006.		Private Networks (L2VPNs)", RFC 4664, September 2006.
	[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,		[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
	"Extensions to Resource Reservation Protocol - Traffic		"Extensions to Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		Engineering (RSVP-TE) for Point-to-Multipoint TE Label
	Switched Paths (LSPs)", RFC 4875, May 2007.		Switched Paths (LSPs)", RFC 4875, May 2007.
	[I-D.ietf-mpls-mp-ldp-reqs]		[I-D.ietf-mpls-mp-ldp-reqs]
End of changes. 13 change blocks.
	21 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/