draft-ietf-mpls-crldp-applic-01.txt		rfc3213.txt
	MPLS Working Group Jerry Ash, AT&T		Network Working Group J. Ash
	Internet Draft		Request for Comments: 3213 AT&T
	Expiration Date: January 2001 Muckai Girish, Atoga Systems		Category: Informational M. Girish
			Atoga Systems
	Eric Gray, Zaffire, Inc.		E. Gray
			Sandburst
	Bilel Jamoussi, Gregory Wright,		B. Jamoussi
			G. Wright
	Nortel Networks Corp.		Nortel Networks Corp.
			January 2002
	July 2000
	Applicability Statement for CR-LDP		Applicability Statement for CR-LDP
	draft-ietf-mpls-crldp-applic-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This memo provides information for the Internet community. It does
	all provisions of Section 10 of RFC2026.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		Copyright Notice
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright (C) The Internet Society (2002). All Rights Reserved.
	http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This Internet-Draft discusses the applicability of Constraint-Based		This document discusses the applicability of Constraint-Based LSP
	LSP Setup using LDP [1]. It discusses possible network applications,		Setup using LDP. It discusses possible network applications,
	extensions to Label Distribution Protocol (LDP) [2] required to		extensions to Label Distribution Protocol (LDP) required to implement
	implement constraint-based routing, guidelines for deployment and		constraint-based routing, guidelines for deployment and known
	known limitations of the protocol. This document is a prerequisite		limitations of the protocol. This document is a prerequisite to
	to advancing CR-LDP on the standards track.		advancing CR-LDP on the standards track.
	1. Introduction		1. Introduction
	As the Internet evolves, additional capabilities are required to		As the Internet evolves, additional capabilities are required to
	ensure proper treatment of data [3], voice, video and other delay		ensure proper treatment of data [3], voice, video and other delay
	sensitive traffic [4]. MPLS enhances source routing and allows for		sensitive traffic [4]. MPLS enhances source routing and allows for
	certain techniques, used in circuit switching, in IP networks. This		certain techniques, used in circuit switching, in IP networks. This
	permits a scalable approach to handling these diverse transmission		permits a scalable approach to handling these diverse transmission
	requirements. CR-LDP is a simple, scalable, open, non-proprietary,		requirements. CR-LDP [1] is a simple, scalable, open, non-
	traffic engineering signaling protocol for MPLS IP networks.		proprietary, traffic engineering signaling protocol for MPLS IP
			networks.
	CR-LDP provides mechanisms for establishing explicitly routed Label		CR-LDP provides mechanisms for establishing explicitly routed Label
	Switched Paths (LSPs). These mechanisms are defined as extensions		Switched Paths (LSPs). These mechanisms are defined as extensions to
	to LDP [1]. Because LDP is a peer-to-peer protocol based on the		LDP [2]. Because LDP is a peer-to-peer protocol based on the
	establishment and maintenance of TCP sessions, the following natural		establishment and maintenance of TCP sessions, the following natural
	benefits exist:		benefits exist:
	CR-LDP messages are reliably delivered by the underlying TCP,		CR-LDP messages are reliably delivered by the underlying TCP, and
	and State information associated with explicitly routed LSPs		State information associated with explicitly routed LSPs does not
	does not require periodic refresh.		require periodic refresh.
	CR-LDP messages are flow controlled (throttled) through TCP.		CR-LDP messages are flow controlled (throttled) through TCP.
	CR-LDP is defined for the specific purpose of establishing and		CR-LDP is defined for the specific purpose of establishing and
	maintaining explicitly routed LSPs. Additional optional		maintaining explicitly routed LSPs. Additional optional capabilities
	capabilities included have minimal impact on system performance and		included have minimal impact on system performance and requirements
	requirements when not in use for a specific explicitly routed LSP.		when not in use for a specific explicitly routed LSP. Optional
	Optional capabilities provide for negotiation of LSP services and		capabilities provide for negotiation of LSP services and traffic
	traffic management parameters over and above best-effort packet		management parameters over and above best-effort packet delivery
	delivery including bandwidth allocation, setup and holding		including bandwidth allocation, setup and holding priorities. CR-LDP
	priorities. CR-LDP optionally allows these parameters to be		optionally allows these parameters to be dynamically modified without
	dynamically modified without disruption of the operational (in-		disruption of the operational (in-service) LSP [4].
	service) LSP [4].
	CR-LDP allows the specification of a set of parameters to be		CR-LDP allows the specification of a set of parameters to be signaled
	signaled along with the LSP setup request. Moreover, the network can		along with the LSP setup request. Moreover, the network can be
	be provisioned with a set of edge traffic conditioning functions		provisioned with a set of edge traffic conditioning functions (which
	(which could include marking, metering, policing and shaping). This		could include marking, metering, policing and shaping). This set of
	set of parameters along with the specification of edge conditioning		parameters along with the specification of edge conditioning
	functions can be shown to be adequate and powerful enough to		functions can be shown to be adequate and powerful enough to
	describe, characterize and parameterize a wide variety of QoS		describe, characterize and parameterize a wide variety of QoS
	scenarios and services including IP differentiated services [5],		scenarios and services including IP differentiated services [5],
	integrated services [6], ATM service classes [7], and frame relay		integrated services [6], ATM service classes [7], and frame relay
	[8].		[8].
	CR-LDP is designed to adequately support the various media types		CR-LDP is designed to adequately support the various media types that
	that MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.).		MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.). Hence,
	Hence, it will work equally well for Multi-service switched		it will work equally well for Multi-service switched networks, router
	networks, router networks, or hybrid networks.		networks, or hybrid networks.
	This applicability statement does not preclude the use of other		This applicability statement does not preclude the use of other
	signaling and label distribution protocols for the traffic		signaling and label distribution protocols for the traffic
	engineering application in MPLS based networks. Service providers		engineering application in MPLS based networks. Service providers
	are free to deploy whatever signaling protocol meets their needs.		are free to deploy whatever signaling protocol meets their needs.
	In particular CR-LDP and RSVP-TE [9] are two signaling protocols		In particular CR-LDP and RSVP-TE [9] are two signaling protocols that
	that perform similar functions in MPLS networks. There is currently		perform similar functions in MPLS networks. There is currently no
	no consensus on which protocol is technically superior. Therefore,		consensus on which protocol is technically superior. Therefore,
	network administrators should make a choice between the two based		network administrators should make a choice between the two based
	upon their needs and particular situation. Applicability of RSVP-TE		upon their needs and particular situation. Applicability of RSVP-TE
	is described in [10].		is described in [10].
	2. Applicability of extensions to LDP		2. Applicability of extensions to LDP
	To provide support of additional LSP services, CR-LDP extensions are		To provide support of additional LSP services, CR-LDP extensions are
	defined in such a way as to be directly translatable to objects and		defined in such a way as to be directly translatable to objects and
	messages used in other protocols defined to provide similar services		messages used in other protocols defined to provide similar services
	[9]. Implementations can take advantage of this fact to:		[9]. Implementations can take advantage of this fact to:
	Setup LSPs for provision of an aggregate service associated		Setup LSPs for provision of an aggregate service associated with
	with the services being provided via these other protocols.		the services being provided via these other protocols.
	Directly translate protocol messages to provide services		Directly translate protocol messages to provide services defined
	defined in a non-CR-LDP portion of the network.		in a non-CR-LDP portion of the network.
	Describe, characterize and parameterize a wide variety of QoS		Describe, characterize and parameterize a wide variety of QoS
	scenarios and services including IP differentiated services,		scenarios and services including IP differentiated services,
	integrated services, ATM service classes, and frame relay.		integrated services, ATM service classes, and frame relay.
	Steady state information required for proper maintenance of an LSP		Steady state information required for proper maintenance of an LSP
	may be as little as 200 bytes or less. It is not unreasonable to		may be as little as 200 bytes or less. It is not unreasonable to
	anticipate that CR-LDP implementations may support in excess of one		anticipate that CR-LDP implementations may support in excess of one
	hundred thousand or one million LSPs switched through a single Label		hundred thousand or one million LSPs switched through a single Label
	Switching Router (LSR) under fairly stable conditions.		Switching Router (LSR) under fairly stable conditions.
	Because CR-LDP provides for low overhead per LSP - both in terms of		Because CR-LDP provides for low overhead per LSP - both in terms of
	needed state information and control traffic - CR-LDP is applicable		needed state information and control traffic - CR-LDP is applicable
	in those portions of the Internet where very large numbers of LSPs		in those portions of the Internet where very large numbers of LSPs
	may need to be switched at each LSR. An example of this would be		may need to be switched at each LSR. An example of this would be
	large backbone networks using MPLS exclusively to transport very		large backbone networks using MPLS exclusively to transport very
	large numbers of traffic streams between a moderately large number		large numbers of traffic streams between a moderately large number of
	of MPLS edge nodes.		MPLS edge nodes.
	CR-LDP may also be applicable as a mediating service between		CR-LDP may also be applicable as a mediating service between networks
	networks providing similar service extensions using widely varying		providing similar service extensions using widely varying signaling
	signaling models.		models.
	3. Implementation and deployment considerations in relation to LDP		3. Implementation and deployment considerations in relation to LDP
	LDP specifies the following label distribution and management modes		LDP specifies the following label distribution and management modes
	(which can be combined in various logical ways described in LDP):		(which can be combined in various logical ways described in LDP):
	. Downstream On Demand label distribution		. Downstream On Demand label distribution
	. Downstream Unsolicited label distribution		. Downstream Unsolicited label distribution
	. Independent Label Distribution Control		. Independent Label Distribution Control
	. Ordered Label Distribution Control		. Ordered Label Distribution Control
	skipping to change at page 6, line ?		skipping to change at page 3, line 51
	LDP specifies the following label distribution and management modes		LDP specifies the following label distribution and management modes
	(which can be combined in various logical ways described in LDP):		(which can be combined in various logical ways described in LDP):
	. Downstream On Demand label distribution		. Downstream On Demand label distribution
	. Downstream Unsolicited label distribution		. Downstream Unsolicited label distribution
	. Independent Label Distribution Control		. Independent Label Distribution Control
	. Ordered Label Distribution Control		. Ordered Label Distribution Control
	. Conservative Label Retention Mode		. Conservative Label Retention Mode
	. Liberal Label Retention Mode		. Liberal Label Retention Mode
	The applicability of LDP is described in [11].		The applicability of LDP is described in [11].
	In networks where only Traffic Engineered LSPs are required, the CR-		In networks where only Traffic Engineered LSPs are required, the CR-
	LDP implementation and deployment does NOT require all the		LDP implementation and deployment does NOT require all the
	functionality defined in the LDP specification. The basic Discovery,		functionality defined in the LDP specification. The basic Discovery,
	Session, and Notification messages are required. However, CR-LDP		Session, and Notification messages are required. However, CR-LDP
	requires one specific combination of the label distribution modes:		requires one specific combination of the label distribution modes:
	. Downstream On Demand Ordered label distribution and		. Downstream On Demand Ordered label distribution and
	conservative Label Retention Mode		conservative Label Retention Mode
	Although CR-LDP is defined as an extension to LDP, support for		Although CR-LDP is defined as an extension to LDP, support for
	Downstream Unsolicited Label Advertisement and Independent Control		Downstream Unsolicited Label Advertisement and Independent Control
	modes is not required for support of Strict Explicit Routes. In		modes is not required for support of Strict Explicit Routes. In
	addition, implementations of CR-LDP MAY be able to support Loose		addition, implementations of CR-LDP MAY be able to support Loose
	Explicit Routes via the use of `Abstract Nodes' and/or `Hierarchical		Explicit Routes via the use of 'Abstract Nodes' and/or 'Hierarchical
	Explicit Routing', without using LDP for hop-by-hop LSP setup.		Explicit Routing', without using LDP for hop-by-hop LSP setup.
	CR-LDP also includes support for loose explicit routes. Use of this		CR-LDP also includes support for loose explicit routes. Use of this
	capability allows the network operator to define an 'explicit path'		capability allows the network operator to define an 'explicit path'
	through portions of their network with imperfect knowledge of the		through portions of their network with imperfect knowledge of the
	entire network topology. Proper use of this capability may also		entire network topology. Proper use of this capability may also
	allow CR-LDP implementations to inter-operate with 'vanilla' LDP		allow CR-LDP implementations to inter-operate with 'vanilla' LDP
	implementations - particularly if it is desired to set up an		implementations - particularly if it is desired to set up an
	explicitly routed LSP for best-effort packet delivery via a loosely		explicitly routed LSP for best-effort packet delivery via a loosely
	defined path.		defined path.
	Finally, in networks where both Routing Protocol-driven LSPs (a.k.a.		Finally, in networks where both Routing Protocol-driven LSPs (a.k.a.
	hop-by-hop LSPs) and Traffic Engineered LSPs are required, a single		hop-by-hop LSPs) and Traffic Engineered LSPs are required, a single
	protocol (LDP, with the extensions defined in CR-LDP) can be used		protocol (LDP, with the extensions defined in CR-LDP) can be used for
	for both TE and Hop-by-Hop LSPs. New protocols do not have to be		both TE and Hop-by-Hop LSPs. New protocols do not have to be
	introduced in the network to provide TE-LSP signaling.		introduced in the network to provide TE-LSP signaling.
	4. Limitations		4. Limitations
	CR-LDP specification only supports point-to-point LSPs. Multi-point-		CR-LDP specification only supports point-to-point LSPs. Multi-
	to-point and point-to-multi-point are FFS.		point-to-point and point-to-multi-point are for further study (FFS).
	CR-LDP specification only supports unidirectional LSP setup. Bi-		CR-LDP specification only supports unidirectional LSP setup. Bi-
	directional LSP setup is FFS.		directional LSP setup is FFS.
	CR-LDP specification only supports a unique label allocation per LSP		CR-LDP specification only supports a unique label allocation per LSP
	setup. Multiple label allocations per LSP setup are FFS.		setup. Multiple label allocations per LSP setup are FFS.
	5. Security Considerations		5. Security Considerations
	No additional security issues are introduced in this draft. As an		No additional security issues are introduced in this document. As an
	extension to LDP, CR-LDP shares the security concerns associated		extension to LDP, CR-LDP shares the security concerns associated with
	with LDP.		LDP.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	careful review of the draft and their comments: Loa Andersson, Peter		careful review of the document and their comments: Loa Andersson,
	Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil, and Adrian		Peter Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil and
	Farrel.		Adrian Farrel.
	7. References		7. References
	1 B. Jamoussi, et., al., "Constraint-based LSP Setup Using LDP",		[1] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
	work in progress, June 2000.		Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
			Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-
			based LSP Setup Using LDP", RFC 3212, January 2002.
	2 L. Andersson, et., al., "LDP Specification", work in progress,		[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
	June 2000.		Thomas, "LDP Specification", RFC 3036, January 2001.
	3 D. Awduche et., al., "Requirements for Traffic Engineering Over		[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
	MPLS", RFC 2702, September 1999.		McManus, "Requirements for Traffic Engineering Over MPLS", RFC
			2702, September 1999.
	4 G. Ash, et., al.,"LSP Modification using CR-LDP," work in		[4] Ash, B., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D.,
	progress, February 2000.		Skalecki, D. and L. Li, "LSP Modification using CR-LDP", RFC
			3214, January 2002.
	5 S. Blake et., al., "An Architecture for Differentiated Services",		[5] Blake S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
	RFC-2495, December 1998.		Weiss, "An Architecture for Differentiated Services", RFC 2475,
			December 1998.
	6 S. Shenker, J. Wroclawski, "General Characterization Parameters		[6] Shenker, S. and J. Wroclawski, "General Characterization
	for Integrated Service Network Elements" RFC-2215		Parameters for Integrated Service Network Elements", RFC 2215,
			September 1997.
	7 ATM Forum Traffic Management Specification Version 4.1 (AF-TM-		[7] ATM Forum Traffic Management Specification Version 4.1 (AF-TM-
	0121.000), March 1999.		0121.000), March 1999.
	8 CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING BEARER		[8] CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING BEARER
	SERVICE, ITU (CCITT) Recommendation I.370, 1991.		SERVICE, ITU (CCITT) Recommendation I.370, 1991.
	9 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan,		[9] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G.
	"Extensions to RSVP for LSP Tunnels," work in progress, February		Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
	2000.		3209, December 2001.
	10 D. Awduche, A. Hannan, X. Xiao, "Applicability Statement for		[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
	Extensions to RSVP for LSP-Tunnels_, work in progress, April		for Extensions to RSVP for LSP-Tunnels", RFC 3210, December
	2000.		2001.
	11 B. Thomas, E. Gray, "LDP Applicability", Work in Progress, June		[11] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January
	2000.		2001.
	8. Author's Addresses		8. Author's Addresses
	Gerald R. Ash M. K. Girish		Gerald R. Ash
	AT&T Atoga Systems		AT&T
	Room MT E3-3C37 49026 Milmont Drive		Room MT D5-2A01
	200 Laurel Avenue Fremont, CA 94538		200 Laurel Avenue
	Middletown, NJ 07748 E-mail: muckai@atoga.com		Middletown, NJ 07748
	USA		USA
	Phone: 732-420-4578		Phone: 732-420-4578
	Fax: 732-440-6687		Fax: 732-368-8659
	Email: gash@att.com		EMail: gash@att.com
			Eric Gray
			Sandburst
			600 Federal Drive
			Andover, MA 01810
			Phone: (978) 689-1610
			EMail: eric.gray@sandburst.com
	Eric W Gray Bilel Jamoussi
	Zaffire, Inc Nortel Networks Corp.
	2630 Orchard Parkway, 600 Technology Park Drive
	San Jose, CA 95134-2020 Billerica, MA 01821
	Phone: 408-894-7362 USA
	egray@zaffire.com phone: +1 978-288-4506
	Jamoussi@nortelnetworks.com
	Gregory Wright		Gregory Wright
	Nortel Networks Corp.		Nortel Networks Corp.
	P O Box 3511 Station C		P O Box 3511 Station C
	Ottawa, ON K1Y 4H7		Ottawa, ON K1Y 4H7
	Canada		Canada
	Phone: +1 613 765-7912		Phone: +1 613 765-7912
	gwright@nortelnetworks.com		EMail: gwright@nortelnetworks.com
	Full Copyright Statement		M. K. Girish
			Atoga Systems
			49026 Milmont Drive
			Fremont, CA 94538
			EMail: muckai@atoga.com
			Bilel Jamoussi
			Nortel Networks Corp.
			600 Technology Park Drive
			Billerica, MA 01821
			USA
			phone: +1 978-288-4506
			EMail: Jamoussi@nortelnetworks.com
			9. Full Copyright Statement
			Copyright (C) The Internet Society (2002). All Rights Reserved.
	"Copyright (C) The Internet Society (date). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph are
	are included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 54 change blocks.
	138 lines changed or deleted		148 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/