draft-ietf-mpls-ldp-applic-02.txt   rfc3037.txt 
Network Working Group Bob Thomas
Internet Draft Cisco Systems, Inc.
Expiration Date: February 2001
Eric Gray
Zaffire, Inc.
August 2000 Network Working Group B. Thomas
Request for Comments: 3037 Cisco Systems, Inc.
Category: Informational E. Gray
Zaffire, Inc.
January 2001
LDP Applicability LDP Applicability
draft-ietf-mpls-ldp-applic-02.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 (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
Multiprotocol Label Switching (MPLS) is a method for forwarding Multiprotocol Label Switching (MPLS) is a method for forwarding
packets that uses short, fixed-length values carried by packets, packets that uses short, fixed-length values carried by packets,
called labels, to determine packet nexthops [MPLS-ARCH]). A called labels, to determine packet nexthops. A fundamental concept
fundamental concept in MPLS is that two Label Switching Routers in MPLS is that two Label Switching Routers (LSRs) must agree on the
(LSRs) must agree on the meaning of the labels used to forward meaning of the labels used to forward traffic between and through
traffic between and through them. This common understanding is them. This common understanding is achieved by using a set of
achieved by using a set of procedures, called a label distribution procedures, called a label distribution protocol, by which one LSR
protocol, by which one LSR informs another of label bindings it has informs another of label bindings it has made. This document
made. This document describes the applicability of a set of such describes the applicability of a set of such procedures called LDP
procedures called LDP (for Label Distribution Protocol) [LDP] by (for Label Distribution Protocol) by which LSRs distribute labels to
which LSRs distribute labels to support MPLS forwarding along support MPLS forwarding along normally routed paths.
normally routed paths.
1. LDP Applicability 1. LDP Applicability
A label distribution protocol is a set of procedures by which one A label distribution protocol is a set of procedures by which one
Label Switching Router (LSR) informs another of the meaning of labels Label Switching Router (LSR) informs another of the meaning of labels
used to forward traffic between and through them. used to forward traffic between and through them.
The MPLS architecture allows for the possibility of more than a The MPLS architecture allows for the possibility of more than a
single method for distributing labels, and a number of different single method for distributing labels, and a number of different
label distribution protocols are being standardized. Existing label distribution protocols are being standardized. Existing
skipping to change at page 2, line 33 skipping to change at page 2, line 18
paths as determined by destination-based routing protocols. This is paths as determined by destination-based routing protocols. This is
sometimes called MPLS hop-by-hop forwarding. sometimes called MPLS hop-by-hop forwarding.
LDP, together with an IP routing plane and software to program ATM LDP, together with an IP routing plane and software to program ATM
switch or Frame Relay switch cross-connect tables, can implement IP switch or Frame Relay switch cross-connect tables, can implement IP
in a network of ATM and/or Frame Relay switches without requiring an 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 overlay or the use of ATM-specific or Frame Relay-specific addressing
or routing. or routing.
LDP is also useful in situations that require efficient hop-by-hop LDP is also useful in situations that require efficient hop-by-hop
routed tunnels, such as MPLS-based VPN architectures [RFC2547] and routed tunnels, such as MPLS-based VPN architectures [RFC2574] and
tunneling between BGP border routers. tunneling between BGP border routers.
In addition, LDP includes a mechanism that makes it possible to In addition, LDP includes a mechanism that makes it possible to
extend it to support MPLS features that go beyond best effort hop- extend it to support MPLS features that go beyond best effort hop-
by-hop forwarding. by-hop forwarding.
As a stand-alone protocol for distributing labels LDP does not rely As a stand-alone protocol for distributing labels LDP does not rely
on the presence of specific routing protocols at every hop along an 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 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 situations in which an LSP must traverse nodes which may not all
skipping to change at page 3, line 17 skipping to change at page 2, line 47
extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to 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 RSVP. There is currently no consensus on which of these protocols is
technically superior. Therefore, network administrators should make technically superior. Therefore, network administrators should make
a choice between the two based upon their needs and particular a choice between the two based upon their needs and particular
situation. situation.
2. Requirement Level 2. Requirement Level
The "requirement level" [RFC2026] for LDP is: The "requirement level" [RFC2026] for LDP is:
Implementation of LDP is recommended for devices that perform MPLS Implementation of LDP is recommended for devices that perform MPLS
forwarding along normally routed paths as determined by forwarding along normally routed paths as determined by
destination-based routing protocols. destination-based routing protocols.
3. Feature Overview 3. Feature Overview
LDP associates a Forwarding Equivalence Class (FEC) [MPLS-ARCH] with LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
each label it distributes. Two LSRs which use LDP to exchange FEC- each label it distributes. Two LSRs which use LDP to exchange FEC-
label binding information are known as "LDP Peers", and we speak of label binding information are known as "LDP Peers", and we speak of
there being an "LDP Session" between them. there being an "LDP Session" between them.
LDP uses TCP for session communication. Use of TCP ensures that LDP uses TCP for session communication. Use of TCP ensures that
session messages are reliably delivered, and that distributed labels session messages are reliably delivered, and that distributed labels
and state information associated with LSPs need not be refreshed and state information associated with LSPs need not be refreshed
periodically. periodically.
LDP includes a mechanism by which an LSR can discover potential LDP LDP includes a mechanism by which an LSR can discover potential LDP
skipping to change at page 4, line 31 skipping to change at page 4, line 12
and ordered control is appropriate in situations where labels are a and ordered control is appropriate in situations where labels are a
relatively scarce resource that must be conserved, and Downstream relatively scarce resource that must be conserved, and Downstream
Unsolicited distribution with liberal label retention and independent Unsolicited distribution with liberal label retention and independent
control is appropriate where labels are plentiful and need not be control is appropriate where labels are plentiful and need not be
carefully conserved. However, the protocol permits other carefully conserved. However, the protocol permits other
combinations of distribution method, label retention mode and control combinations of distribution method, label retention mode and control
mode, including hybrid variants of them. mode, including hybrid variants of them.
LDP defines a mechanism for loop detection to protect against LDP defines a mechanism for loop detection to protect against
forwarding loops in LSPs that traverse non-TTL MPLS clouds; see forwarding loops in LSPs that traverse non-TTL MPLS clouds; see
[MPLS-ARCH] for discussion of situations which may benefit from this [RFC3031] for discussion of situations which may benefit from this
mechanism. The loop detection mechanism is optional in the sense mechanism. The loop detection mechanism is optional in the sense
that it may be disabled by LSR configuration. However, an LDP- that it may be disabled by LSR configuration. However, an LDP-
compliant LSR must implement it. compliant LSR must implement it.
LDP includes an extension mechanism which supports the development of LDP includes an extension mechanism which supports the development of
vendor-private and experimental features. This mechanism defines vendor-private and experimental features. This mechanism defines
procedures for introducing new types of messages and TLVs, methods an procedures for introducing new types of messages and TLVs, methods an
LSR can use for detecting such messages and TLVs, and procedures 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 LSR must follow when it receives a message or TLV it does not
implement. While it is not possible to make every future enhancement implement. While it is not possible to make every future enhancement
backwards compatible, these procedures facilitate the introduction of backwards compatible, these procedures facilitate the introduction of
new capabilities in MPLS networks that include older implementations new capabilities in MPLS networks that include older implementations
that do not recognize them. that do not recognize them.
4. Scalability Considerations 4. Scalability Considerations
The following factors may influence the scalability of LDP The following factors may influence the scalability of LDP
implementations: implementations:
- LDP label distribution is incremental, requiring no periodic - LDP label distribution is incremental, requiring no periodic
refresh of FEC-label bindings. refresh of FEC-label bindings.
- In situations were label resources may be scarce (ATM and Frame - In situations were label resources may be scarce (ATM and Frame
Relay links) the use of the Downstream on Demand distribution Relay links) the use of the Downstream on Demand distribution
method with conservative label retention ensures that only those method with conservative label retention ensures that only
labels required to support normally-routed paths are allocated those labels required to support normally-routed paths are
and distributed. allocated and distributed.
- In situations where label resources are not scarce, the use of - In situations where label resources are not scarce, the use of
the Downstream Unsolicited method with liberal label retention the Downstream Unsolicited method with liberal label retention
ensures that changes in FEC nexthop from one LDP peer to another ensures that changes in FEC nexthop from one LDP peer to
require no distribution action to update previously distributed another require no distribution action to update previously
labels. distributed labels.
- Limitations on the number of TCP connections an LSR supports - Limitations on the number of TCP connections an LSR supports
limit the number of LDP peers the LSR can support. limit the number of LDP peers the LSR can support.
- Use of the optional path vector based loop detection mechanism - Use of the optional path vector based loop detection mechanism
imposes additional memory and processing requirements on an LSR, imposes additional memory and processing requirements on an
as well as additional LDP traffic. Both impact scalability. LSR, as well as additional LDP traffic. Both impact
scalability.
5. Security Considerations 5. Security Considerations
LDP defines the optional use of the TCP MD5 Signature Option to LDP defines the optional use of the TCP MD5 Signature Option to
protect against the introduction of spoofed TCP segments into LDP protect against the introduction of spoofed TCP segments into LDP
session connection streams. LDP use of the TCP MD5 Signature Option session connection streams. LDP use of the TCP MD5 Signature Option
is similar to BGP [RFC1771] use of the option specified in [RFC2385]. is similar to BGP [RFC1771] use of the option specified in [RFC2385].
6. References 6. References
[CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright, [CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,
"Applicability Statement for CR-LDP", Work in Progress, September "Applicability Statement for CR-LDP", Work in Progress,
1999. September 1999.
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
"LDP Specification", Work in Progress, June 2000. (BGP-4)", RFC 1771, March 1995.
[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Switching Architecture", Work in Progress, August 1999. 3", BCP 9, RFC 2026, October 1996.
[RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
RFC 1771, March 1995. MD5 Signature Option", RFC 2385, August 1998.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
RFC 2026, October 1996. March 1999.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
Signature Option", RFC 2385, August 1998. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
1999. Label Switching Architecture", RFC 3031, January 2001.
[RSVP-TE-AS] D. Awduche, A Hannan, X. Xiao, "Applicability State for [RSVP-TE-AS] Awduche, D., Hannan, A. and X. Xiao, "Applicability
Extensions to RSVP for LSP-Tunnels", Work in Progress, April 2000. State for Extensions to RSVP for LSP-Tunnels", Work in
Progress, April 2000.
7. Author Information 7. Authors' Addresses
Eric Gray Bob Thomas Eric Gray
Zaffire, Inc Cisco Systems, Inc. Zaffire, Inc
2630 Orchard Parkway, 250 Apollo Dr. 2630 Orchard Parkway,
San Jose, CA 95134-2020 Chelmsford, MA 01824 San Jose, CA 95134-2020
Phone: 408-894-7362 Phone: 978-244-8078
email: egray@zaffire.com email: rhthomas@cisco.com 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
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.
 End of changes. 26 change blocks. 
75 lines changed or deleted 62 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/