< draft-ietf-mpls-ldp-applic-01.txt		draft-ietf-mpls-ldp-applic-02.txt >
	Network Working Group Bob Thomas		A new Request for Comments is now available in online RFC libraries.
	Internet Draft Cisco Systems, Inc.
	Expiration Date: December 2000
	Eric Gray
	Zaffire, Inc.
	June 2000
	LDP Applicability
	draft-ietf-mpls-ldp-applic-01.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
	Multiprotocol Label Switching (MPLS) is a method for forwarding
	packets that uses short, fixed-length values carried by packets,
	called labels, to determine packet nexthops ([MPLS-FRAMEWORK],
	[MPLS-ARCH]). A fundamental concept in MPLS is that two Label
	Switching Routers (LSRs) must agree on the meaning of the labels used
	to forward traffic between and through them. This common
	understanding is achieved by using a set of procedures, called a
	label distribution protocol, by which one LSR informs another of
	label bindings it has made. This document describes the
	applicability of a set of such procedures called LDP (for Label
	Distribution Protocol) [LDP] by which LSRs distribute labels to
	support MPLS forwarding along normally routed paths.
	1. LDP Applicability
	A label distribution protocol is a set of procedures by which one
	Label Switching Router (LSR) informs another of the meaning of labels
	used to forward traffic between and through them.
	The MPLS architecture allows for the possibility of more than a
	single method for distributing labels, and a number of different
	label distribution protocols are being standardized. Existing
	protocols have been extended so that label distribution can be
	piggybacked on them, and new protocols have been defined for the
	explicit purpose of distributing labels.
	This document describes the applicability of the Label Distribution
	Protocol (LDP), a new protocol for label distribution designed to
	support label distribution for MPLS forwarding along normally routed
	paths as determined by destination-based routing protocols. This is
	sometimes called MPLS hop-by-hop forwarding.
	LDP, together with an IP routing plane and software to program ATM
	switch or Frame Relay switch cross-connect tables, can implement IP
	in a network of ATM and/or Frame Relay switches without requiring an
	overlay or the use of ATM-specific or Frame Relay-specific addressing
	or routing.
	LDP is also useful in situations that require efficient hop-by-hop
	routed tunnels, such as MPLS-based VPN architectures [RFC2547] and
	tunneling between BGP border routers.
	In addition, LDP includes a mechanism that makes it possible to
	extend it to support MPLS features that go beyond best effort hop-
	by-hop forwarding.
	As a stand-alone protocol for distributing labels LDP does not rely
	on the presence of specific routing protocols at every hop along an
	LSP path in order to establish an LSP. Hence LDP is useful in
	situations in which an LSP must traverse nodes which may not all
	support a common piggybacked approach to distributing labels.
	Traffic Engineering [TE] is expected to be an important MPLS
	application. MPLS support for Traffic Engineering uses explicitly
	routed LSPs, which need not follow normally-routed (hop-by-hop)
	paths.
	Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set of
	extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to
	RSVP. There is currently no consensus on which of these protocols is
	technically superior. Therefore, network administrators should make
	a choice between the two based upon their needs and particular
	situation.
	2. Requirement Level
	The "requirement level" [RFC2026] for LDP is:
	Implementation of LDP is recommended for devices that perform MPLS
	forwarding along normally routed paths as determined by
	destination-based routing protocols.
	3. Feature Overview
	LDP associates a Forwarding Equivalence Class (FEC) [MPLS-ARCH] with
	each label it distributes. Two LSRs which use LDP to exchange FEC-
	label binding information are known as "LDP Peers", and we speak of
	there being an "LDP Session" between them.
	LDP uses TCP for session communication. Use of TCP ensures that
	session messages are reliably delivered, and that distributed labels
	and state information associated with LSPs need not be refreshed
	periodically.
	LDP includes a mechanism by which an LSR can discover potential LDP
	peers. The discovery mechanism makes it unnecessary for operators to
	explicitly configure each LSR with its LDP peers.
	When an LSR discovers another LSR it follows the LDP session setup
	procedure to establish an LDP session. By means of this procedure
	the LSRs establish a session TCP connection and use it to negotiate
	parameters for the session, such as the label distribution method to
	be used (see below). After the LSRs agree on the parameters, the
	session is operational and the LSRs use the TCP connection for label
	distribution.
	LDP supports two different methods for label distribution. An LSR
	using Downstream Unsolicited distribution advertises FEC-label
	bindings to its peers when it is ready to forward packets in the FEC
	by means of MPLS. An LSR using Downstream on Demand distribution
	provides FEC-label bindings to a peer in response to specific
	requests from the peer for a label for the FEC.
	LDP allows LSRs flexibility in strategies for retaining learned
	labels. An LSR using liberal label retention stores all labels
	learned from peers regardless of whether it currently needs them for
	forwarding, whereas one using conservative label retention stores
	only labels for which it has immediate use and releases unneeded
	labels to the peer that advertised them.
	In addition, LDP allows flexibility in strategies for when to
	advertise FEC-label bindings. An LSR using independent control mode
	advertises FEC-label bindings to peers whenever it sees fit, whereas
	one using ordered control advertises bindings only when it has
	previously received a label for the FEC from the FEC nexthop or it is
	an MPLS egress for the FEC.
	Downstream on Demand distribution with conservative label retention
	and ordered control is appropriate in situations where labels are a
	relatively scarce resource that must be conserved, and Downstream
	Unsolicited distribution with liberal label retention and independent
	control is appropriate where labels are plentiful and need not be
	carefully conserved. However, the protocol permits other
	combinations of distribution method, label retention mode and control
	mode, including hybrid variants of them.
	LDP defines a mechanism for loop detection to protect against
	forwarding loops in LSPs that traverse non-TTL MPLS clouds; see
	[MPLS-ARCH] for discussion of situations which may benefit from this
	mechanism. The loop detection mechanism is optional in the sense
	that it may be disabled by LSR configuration. However, an LDP-
	compliant LSR must implement it.
	LDP includes an extension mechanism which supports the development of
	vendor-private and experimental features. This mechanism defines
	procedures for introducing new types of messages and TLVs, methods an
	LSR can use for detecting such messages and TLVs, and procedures an
	LSR must follow when it receives a message or TLV it does not
	implement. While it is not possible to make every future enhancement
	backwards compatible, these procedures facilitate the introduction of
	new capabilities in MPLS networks that include older implementations
	that do not recognize them.
	4. Scalability Considerations
	The following factors may influence the scalability of LDP
	implementations:
	- LDP label distribution is incremental, requiring no periodic
	refresh of FEC-label bindings.
	- In situations were label resources may be scarce (ATM and Frame
	Relay links) the use of the Downstream on Demand distribution
	method with conservative label retention ensures that only those
	labels required to support normally-routed paths are allocated
	and distributed.
	- In situations where label resources are not scarce, the use of
	the Downstream Unsolicited method with liberal label retention
	ensures that changes in FEC nexthop from one LDP peer to another
	require no distribution action to update previously distributed
	labels.
	- Limitations on the number of TCP connections an LSR supports
	limit the number of LDP peers the LSR can support.
	- Use of the optional path vector based loop detection mechanism
	imposes additional memory and processing requirements on an LSR,
	as well as additional LDP traffic. Both impact scalability.
	5. Security Considerations
	LDP defines the optional use of the TCP MD5 Signature Option to
	protect against the introduction of spoofed TCP segments into LDP
	session connection streams. LDP use of the TCP MD5 Signature Option
	is similar to BGP [RFC1771] use of the option specified in [RFC2385].
	6. References		RFC 3037
	CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,		Title: LDP Applicability
	"Applicability Statement for CR-LDP", Work in Progress, September		Author(s): B. Thomas, E. Gray
	1999.		Status: Standards Track
			Date: January 2001
			Mailbox: rhthomas@cisco.com, ewgray@mindspring.com
			Pages: 7
			Characters: 13601
			Updates/Obsoletes/SeeAlso: None
	[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,		I-D Tag: draft-ietf-mpls-ldp-applic-02.txt
	"LDP Specification", Work in Progress, June 2000.
	[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label		URL: ftp://ftp.isi.edu/in-notes/rfc3037.txt
	Switching Architecture", Work in Progress, August 1999.
	[MPLS-FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.		Multiprotocol Label Switching (MPLS) is a method for forwarding
	Swallow, A. Viswanathan, "A Framework for Multiprotocol Label		packets that uses short, fixed-length values carried by packets,
	Switching", Work in Progress, September 1999.		called labels, to determine packet nexthops. A fundamental concept in
			MPLS is that two Label Switching Routers (LSRs) must agree on the
			meaning of the labels used to forward traffic between and through
			them. This common understanding is achieved by using a set of
			procedures, called a label distribution protocol, by which one LSR
			informs another of label bindings it has made. This document
			describes the applicability of a set of such procedures called LDP
			(for Label Distribution Protocol) by which LSRs distribute labels to
			support MPLS forwarding along normally routed paths.
	[RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",		This document is a product of the Multiprotocol Label Switching
	RFC 1771, March 1995.		Working Group of the IETF.
	[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",		This memo provides information for the Internet community. It does
	RFC 2026, October 1996.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5		This announcement is sent to the IETF list and the RFC-DIST list.
	Signature Option", RFC 2385, August 1998.		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.
	[RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	1999.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	[RSVP-TE-AS] D. Awduche, A Hannan, X. Xiao, "Applicability State for		To: rfc-info@RFC-EDITOR.ORG
	Extensions to RSVP for LSP-Tunnels", Work in Progress, April 2000.		Subject: getting rfcs
	7. Author Information		help: ways_to_get_rfcs
	Eric Gray Bob Thomas		Requests for special distribution should be addressed to either the
	Zaffire, Inc Cisco Systems, Inc.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	2630 Orchard Parkway, 250 Apollo Dr.		specifically noted otherwise on the RFC itself, all RFCs are for
	San Jose, CA 95134-2020 Chelmsford, MA 01824		unlimited distribution.echo
	Phone: 408-894-7362 Phone: 978-244-8078		Submissions for Requests for Comments should be sent to
	email: egray@zaffire.com email: rhthomas@cisco.com		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	233 lines changed or deleted		39 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/