draft-ietf-mpls-ldp-applic-00.txt   draft-ietf-mpls-ldp-applic-01.txt 
Network Working Group Bob Thomas Network Working Group Bob Thomas
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: April 2000 Expiration Date: December 2000
Eric Gray Eric Gray
Lucent Technologies Zaffire, Inc.
October 1999 June 2000
LDP Applicability LDP Applicability
draft-ietf-mpls-ldp-applic-00.txt draft-ietf-mpls-ldp-applic-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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-FRAMEWORK], called labels, to determine packet nexthops ([MPLS-FRAMEWORK],
[MPLS-ARCH]). A fundamental concept in MPLS is that two Label [MPLS-ARCH]). A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used Switching Routers (LSRs) must agree on the meaning of the labels used
to forward traffic between and through them. This common to forward traffic between and through them. This common
understanding is achieved by using a set of procedures, called a understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of label distribution protocol, by which one LSR informs another of
label bindings it has made. This document describes the label bindings it has made. This document describes the
applicability of a set of such procedures called LDP (for Label applicability of a set of such procedures called LDP (for Label
Distribution Protocol) [LDP]. Distribution Protocol) [LDP] by which LSRs distribute labels to
support MPLS forwarding along 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
protocols have been extended so that label distribution can be protocols have been extended so that label distribution can be
piggybacked on them, and new protocols have been defined for the piggybacked on them, and new protocols have been defined for the
explicit purpose of distributing labels. explicit purpose of distributing labels.
This document describes the applicability of the Label Distribution This document describes the applicability of the Label Distribution
Protocol (LDP), a new protocol for label distribution designed to Protocol (LDP), a new protocol for label distribution designed to
support label distribution for hop-by-hop MPLS forwarding. 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 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 [RFC2457] and routed tunnels, such as MPLS-based VPN architectures [RFC2547] 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
support a common piggybacked approach to distributing labels. support a common piggybacked approach to distributing labels.
2. Feature Overview 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 LDP associates a Forwarding Equivalence Class (FEC) [MPLS-ARCH] 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.
skipping to change at page 4, line 27 skipping to change at page 5, line 5
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.
3. 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 those
skipping to change at page 5, line 12 skipping to change at page 5, line 32
require no distribution action to update previously distributed require no distribution action to update previously distributed
labels. 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 LSR,
as well as additional LDP traffic. Both impact scalability. as well as additional LDP traffic. Both impact scalability.
4. 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].
5. References 6. References
CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,
"Applicability Statement for CR-LDP", Work in Progress, September
1999.
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
"LDP Specification", Work in Progress, June 1999. "LDP Specification", Work in Progress, June 2000.
[MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture", Work in Progress, July 1998. Switching Architecture", Work in Progress, August 1999.
[MPLS-FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. [MPLS-FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Swallow, A. Viswanathan, "A Framework for Multiprotocol Label
Switching", Work in Progress, November 1997. Switching", Work in Progress, September 1999.
[RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [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. Signature Option", RFC 2385, August 1998.
[RFC2547] E. Rosen, Y. Rekhter, " BGP/MPLS VPNs", RFC 2547, March [RFC2547] E. Rosen, Y. Rekhter, " BGP/MPLS VPNs", RFC 2547, March
1999. 1999.
6. Author Information [RSVP-TE-AS] D. Awduche, A Hannan, X. Xiao, "Applicability State for
Extensions to RSVP for LSP-Tunnels", Work in Progress, April 2000.
7. Author Information
Eric Gray Bob Thomas Eric Gray Bob Thomas
Lucent Technologies, Inc Cisco Systems, Inc. Zaffire, Inc Cisco Systems, Inc.
P.O. Box 710 250 Apollo Dr. 2630 Orchard Parkway, 250 Apollo Dr.
Durham, NH 03824 Chelmsford, MA 01824 San Jose, CA 95134-2020 Chelmsford, MA 01824
Phone: 603-659-3386 Phone: 978-244-8078 Phone: 408-894-7362 Phone: 978-244-8078
email: ewgray@lucent.com email: rhthomas@cisco.com email: egray@zaffire.com email: rhthomas@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/