GENWiki

Network Working Group B. Thomas Request for Comments: 3037 Cisco Systems, Inc. Category: Informational E. Gray

                                                         Zaffire, Inc.
                                                          January 2001

                         LDP Applicability

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

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.  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.

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.

Thomas & Gray Informational [Page 1] RFC 3037 LDP Applicability January 2001

 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 [RFC2574] 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.

Thomas & Gray Informational [Page 2] RFC 3037 LDP Applicability January 2001

3. Feature Overview

 LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] 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

Thomas & Gray Informational [Page 3] RFC 3037 LDP Applicability January 2001

 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
 [RFC3031] 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.

Thomas & Gray Informational [Page 4] RFC 3037 LDP Applicability January 2001

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 for CR-LDP", Work in Progress,
              September 1999.

 [RFC1771]    Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

 [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

 [RFC2385]    Heffernan, A., "Protection of BGP Sessions via the TCP
              MD5 Signature Option", RFC 2385, August 1998.

 [RFC2547]    Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

 [RFC3036]    Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

 [RFC3031]    Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

 [RSVP-TE-AS] Awduche, D., Hannan, A. and X. Xiao, "Applicability
              State for Extensions to RSVP for LSP-Tunnels", Work in
              Progress, April 2000.

Thomas & Gray Informational [Page 5] RFC 3037 LDP Applicability January 2001

7. Authors' Addresses

 Eric Gray
 Zaffire, Inc
 2630 Orchard Parkway,
 San Jose, CA 95134-2020

 Phone:  408-894-7362
 EMail: ewgray@mindspring.com

 Bob Thomas
 Cisco Systems, Inc.
 250 Apollo Dr.
 Chelmsford, MA 01824

 Phone:  978-244-8078
 EMail: rhthomas@cisco.com

Thomas & Gray Informational [Page 6] RFC 3037 LDP Applicability January 2001

8. Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.

 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
 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.

Thomas & Gray Informational [Page 7]