< draft-ietf-mpls-crldp-applic-00.txt		draft-ietf-mpls-crldp-applic-01.txt >
	MPLS Working Group Jerry Ash		A new Request for Comments is now available in online RFC libraries.
	Internet Draft AT&T
	Expiration Date: March 2000
	Muckai Girish
	SBC Technology Resources Inc.
	Eric Gray
	Lucent Technologies
	Bilel Jamoussi
	Gregory Wright
	Nortel Networks Corp.
	September 1999
	Applicability Statement for CR-LDP
	draft-ietf-mpls-crldp-applic-00.txt
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	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
	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.
	Abstract
	This Internet-Draft discusses the applicability of Constraint-Based
	LSP Setup using LDP [1]. It discusses possible network applications,
	extensions to Label Distribution Protocol (LDP) [2] required to
	implement constraint-based routing, guidelines for deployment and
	known limitations of the protocol. This document is a prerequisite
	to advancing CR-LDP on the standards track.
	Jamoussi, et. al. [Page 1]Internet Draft Applicability Statement for CR-LDP September, 1999
	1. Introduction
	As the Internet evolves, additional capabilities are required to
	ensure proper treatment of data [3], voice, video and other delay
	sensitive traffic [4]. MPLS enhances source routing and allows for
	certain techniques, used in circuit switching, in IP networks. This
	permits a scalable approach to handling these diverse transmission
	requirements. CR-LDP is a simple, scalable, open, non-proprietary,
	traffic engineering signaling protocol for MPLS IP networks.
	CR-LDP provides mechanisms for establishing explicitly routed Label
	Switched Paths (LSPs). These mechanisms are defined as extensions
	to LDP [1]. Because LDP is a peer-to-peer protocol based on the
	establishment and maintenance of TCP sessions, the following natural
	benefits exist:
	CR-LDP messages are reliably delivered by the underlying TCP,
	and State information associated with explicitly routed LSPs
	does not require periodic refresh.
	CR-LDP messages are flow controlled (throttled) through TCP.
	CR-LDP is defined for the specific purpose of establishing and
	maintaining explicitly routed LSPs. Additional optional
	capabilities included have minimal impact on system performance and
	requirements when not in use for a specific explicitly routed LSP.
	Optional capabilities provide for negotiation of LSP services and
	traffic management parameters over and above best-effort packet
	delivery including bandwidth allocation, setup and holding
	priorities. CR-LDP optionally allows these parameters to be
	dynamically modified without disruption of the operational (in-
	service) LSP [4].
	CR-LDP allows the specification of a set of parameters to be
	signaled along with the LSP setup request. Moreover, the network can
	be provisioned with a set of edge traffic conditioning functions
	(which could include marking, metering, policing and shaping). This
	set of parameters along with the specification of edge conditioning
	functions can be shown to be adequate and powerful enough to
	describe, characterize and parameterize a wide variety of QoS
	scenarios and services including IP differentiated services [5],
	integrated services [6], ATM service classes [7], and frame relay
	[8].
	CR-LDP is designed to adequately support the various media types
	that MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.).
	Hence, it will work equally well for Multi-service switched
	networks, router networks, or hybrid networks.
	Jamoussi, et. al. March 2000 [Page 2]Internet Draft Applicability Statement for CR-LDP September, 1999
	2. Applicability of extensions to LDP
	To provide for support of additional LSP services, CR-LDP extensions
	are defined in such a way as to be directly translatable to objects
	and messages used in other protocols defined to provide similar
	services [9]. Implementations can take advantage of this fact to:
	Setup LSPs for provision of an aggregate service associated
	with the services being provided via these other protocols.
	Directly translate protocol messages to provide services
	defined in a non-CR-LDP portion of the network.
	Describe, characterize and parameterize a wide variety of QoS
	scenarios and services including IP differentiated services,
	integrated services, ATM service classes, and frame relay.
	Steady state information required for proper maintenance of an LSP
	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
	hundred thousand or one million LSPs switched through a single Label
	Switching Router (LSR) under fairly stable conditions.
	Because CR-LDP provides for low overhead per LSP - both in terms of
	needed state information and control traffic - CR-LDP is applicable
	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
	large backbone networks using MPLS exclusively to transport very
	large numbers of traffic streams between a moderately large number
	of MPLS edge nodes.
	CR-LDP may also be applicable as a mediating service between
	networks providing similar service extensions using widely varying
	signaling models.
	3. Implementation and deployment considerations in relation to LDP
	LDP specifies the following label distribution and management modes
	(which can be combined in various logical ways described in LDP):
	. Downstream On Demand label distribution
	. Downstream Unsolicited label distribution
	. Independent Label Distribution Control
	. Ordered Label Distribution Control
	. Conservative Label Retention Mode
	. Liberal Label Retention Mode
	In networks where only Traffic Engineered LSPs are required, the CR-
	LDP implementation and deployment does NOT require all the
	functionality defined in the LDP specification. The basic Discovery,
	Jamoussi, et. al. March 2000 [Page 3]Internet Draft Applicability Statement for CR-LDP September, 1999
	Session, and Notification messages are required. However, CR-LDP
	requires one specific combination of the label distribution modes:
	. Downstream On Demand Ordered label distribution and
	conservative Label Retention Mode
	Although CR-LDP is defined as an extension to LDP, support for
	Downstream Unsolicited Label Advertisement and Independent Control
	modes is not required for support of Strict Explicit Routes. In
	addition, implementations of CR-LDP MAY be able to support Loose
	Explicit Routes via the use of `Abstract Nodes' and/or `Hierarchical
	Explicit Routing', without using LDP for hop-by-hop LSP setup.
	CR-LDP also includes support for loose explicit routes. Use of this
	capability allows the network operator to define an 'explicit path'
	through portions of their network with imperfect knowledge of the
	entire network topology. Proper use of this capability may also
	allow CR-LDP implementations to inter-operate with 'vanilla' LDP
	implementations - particularly if it is desired to set up an
	explicitly routed LSP for best-effort packet delivery via a loosely
	defined path.
	Finally, in networks where both Routing Protocol-driven LSPs (a.k.a.
	hop-by-hop LSPs) and Traffic Engineered LSPs are required, a single
	protocol (LDP, with the extensions defined in CR-LDP) can be used
	for both TE and Hop-by-Hop LSPs. New protocols do not have to be
	introduced in the network to provide TE-LSP signaling.
	4. Limitations
	CR-LDP specification only supports point-to-point LSPs. Multi-point-
	to-point and point-to-multi-point are FFS.
	CR-LDP specification only supports unidirectional LSP setup. Bi-
	directional LSP setup is FFS.
	CR-LDP specification only supports a unique label allocation per LSP
	setup. Multiple label allocations per LSP setup are FFS.
	5. Security Considerations
	No additional security issues are introduced in this draft. As an
	extension to LDP, CR-LDP shares the security concerns associated
	with LDP.
	6. Acknowledgements
	The authors would like to thank the following people for their
	careful review of the draft and their comments: Loa Andersson, Peter
	Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil, and Adrian
	Farrel.
	Jamoussi, et. al. March 2000 [Page 4]Internet Draft Applicability Statement for CR-LDP September, 1999
	7. References
	1 B. Jamoussi, et., al., "Constraint-based LSP Setup Using LDP",
	work in progress, September 1999.
	2 L. Andersson, et., al., "LDP Specification", work in progress,
	June 1999.
	3 D. Awduche et., al., "Requirements for Traffic Engineering Over
	MPLS", RFC 2702, September 1999.
	4 G. Ash, et., al.,"LSP Modification using CR-LDP," work in
	progress, July 1999.
	5 S. Blake et., al., "An Architecture for Differentiated Services",
	RFC-2495, December 1998.
	6 S. Shenker, J. Wroclawski, "General Characterization Parameters		RFC 3213
	for Integrated Service Network Elements" RFC-2215
	7 ATM Forum Traffic Management Specification Version 4.1 (AF-TM-		Title: Applicability Statement for CR-LDP
	0121.000), March 1999.		Author(s): J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright
			Status: Informational
			Date: January 2002
			Mailbox: gash@att.com, eric.gray@sandburst.com,
			gwright@nortelnetworks.com, muckai@atoga.com,
			Jamoussi@nortelnetworks.com
			Pages: 7
			Characters: 14489
			Updates/Obsoletes/SeeAlso: None
	8 CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING BEARER		I-D Tag: draft-ietf-mpls-crldp-applic-01.txt
	SERVICE, ITU (CCITT) Recommendation I.370, 1991.
	9 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan,		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3213.txt
	"Extensions to RSVP for LSP Tunnels," work in progress, September
	1999.
	8. Author's Addresses		This document discusses the applicability of Constraint-Based
			LSP Setup using LDP. It discusses possible network applications,
			extensions to Label Distribution Protocol (LDP) required to implement
			constraint-based routing, guidelines for deployment and known
			limitations of the protocol. This document is a prerequisite to
			advancing CR-LDP on the standards track.
	Gerald R. Ash M. K. Girish		This document is a product of the Multiprotocol Label Switching
	AT&T SBC Technology Resources, Inc.		Working Group of the IETF.
	Room MT E3-3C37 4698 Willow Road,
	200 Laurel Avenue Pleasanton, CA 94588
	Middletown, NJ 07748 USA
	USA Phone: +1 925 598-1263
	Phone: 732-420-4578 Fax: +1 925 598-1322
	Fax: 732-440-6687 mgirish@tri.sbc.com
	Email: gash@att.com
	Eric W Gray Bilel Jamoussi		This memo provides information for the Internet community. It does
	Lucent Technologies, Inc. Nortel Networks Corp.		not specify an Internet standard of any kind. Distribution of this
	PO Box 0710 600 Technology Park Drive		memo is unlimited.
	Durham, NH, 03824-0710 Billerica, MA 01821
	USA USA
	Phone: +1 603 659 3386 phone: +1 978-288-4506
	Ewgray@lucent.com Jamoussi@nortelnetworks.com
	Jamoussi, et. al. March 2000 [Page 5]Internet Draft Applicability Statement for CR-LDP September, 1999		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Gregory Wright		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Nortel Networks Corp.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	P O Box 3511 Station C		help: ways_to_get_rfcs. For example:
	Ottawa, ON K1Y 4H7
	Canada
	Phone: +1 613 765-7912
	gwright@nortelnetworks.com
	Full Copyright Statement		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	"Copyright (C) The Internet Society (date). All Rights Reserved.		help: ways_to_get_rfcs
	This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Requests for special distribution should be addressed to either the
	revoked by the Internet Society or its successors or assigns.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	274 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/