Network Working Group Bob Thomas
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 validA new Request for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It Comments is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work now available 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 online RFC libraries.
RFC 3037
Title: LDP Applicability
Author(s): B. Thomas, E. Gray
Status: Standards Track
Date: January 2001
Mailbox: rhthomas@cisco.com, ewgray@mindspring.com
Pages: 7
Characters: 13601
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-mpls-ldp-applic-02.txt
URL: ftp://ftp.isi.edu/in-notes/rfc3037.txt
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]). 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) [LDP] by which LSRs distribute labels to
support MPLS forwarding along normally routed paths.
1. LDP Applicability
A label distribution protocol
This document is a set product of procedures by which one the Multiprotocol 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
Working Group 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. IETF.
This document describes the applicability of the Label Distribution
Protocol (LDP), a new protocol for label distribution designed to
support label distribution memo provides information 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 Internet community. It 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 specify 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 Internet standard of extensions to
RSVP. There is currently no consensus on which any kind. Distribution of these protocols this
memo 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 unlimited.
This announcement 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 sent 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 IETF list and use it to negotiate
parameters for the session, such as the label distribution method RFC-DIST list.
Requests 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 added to a peer in response to specific
requests or deleted 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 IETF distribution list
should be sent to the peer that advertised them.
In addition, LDP allows flexibility in strategies for when IETF-REQUEST@IETF.ORG. Requests to
advertise FEC-label bindings. An LSR using independent control mode
advertises FEC-label bindings be
added 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 deleted from 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 RFC-DIST distribution with liberal label retention and independent
control is appropriate where labels are plentiful and need not list should
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 sent 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 RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be disabled obtained by LSR configuration. However, an LDP-
compliant LSR must implement it.
LDP includes sending
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 EMAIL 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 rfc-info@RFC-EDITOR.ORG with the scalability of LDP
implementations:
- LDP label message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution is incremental, requiring no periodic
refresh of FEC-label bindings.
- In situations were label resources may should 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 addressed to support normally-routed paths are allocated
and distributed.
- In situations where label resources are not scarce, either the use
author of the Downstream Unsolicited method with liberal label retention
ensures that changes RFC in FEC nexthop from one LDP peer to another
require no distribution action question, or to update previously distributed
labels.
- Limitations RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise 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
CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,
"Applicability Statement RFC itself, all RFCs are for CR-LDP", Work in Progress, September
1999.
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
"LDP Specification", Work in Progress, June 2000.
[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", Work in Progress, August 1999.
[MPLS-FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
Swallow, A. Viswanathan, "A Framework
unlimited distribution.echo
Submissions for Multiprotocol Label
Switching", Work in Progress, September 1999.
[RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.
[RSVP-TE-AS] D. Awduche, A Hannan, X. Xiao, "Applicability State Requests for
Extensions Comments should be sent to RSVP
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for LSP-Tunnels", Work in Progress, April 2000.
7. Author Information
Eric Gray Bob Thomas
Zaffire, Inc Cisco Systems, Inc.
2630 Orchard Parkway, 250 Apollo Dr.
San Jose, CA 95134-2020 Chelmsford, MA 01824
Phone: 408-894-7362 Phone: 978-244-8078
email: egray@zaffire.com email: rhthomas@cisco.com further information.