--- 1/draft-ietf-mpls-ldp-applic-00.txt 2006-02-05 00:40:06.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-applic-01.txt 2006-02-05 00:40:06.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Bob Thomas Internet Draft Cisco Systems, Inc. -Expiration Date: April 2000 +Expiration Date: December 2000 Eric Gray - Lucent Technologies + Zaffire, Inc. - October 1999 + June 2000 LDP Applicability - draft-ietf-mpls-ldp-applic-00.txt + 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. @@ -36,60 +36,83 @@ 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]. + 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 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 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 [RFC2457] and + 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. -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 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. @@ -146,21 +169,21 @@ 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. -3. Scalability Considerations +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 @@ -173,46 +196,56 @@ 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. -4. Security Considerations +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]. -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 Specification", Work in Progress, June 1999. + "LDP Specification", Work in Progress, June 2000. [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. 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)", 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. [RFC2547] E. Rosen, Y. Rekhter, " BGP/MPLS VPNs", RFC 2547, March 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 - Lucent Technologies, Inc Cisco Systems, Inc. - P.O. Box 710 250 Apollo Dr. - Durham, NH 03824 Chelmsford, MA 01824 - Phone: 603-659-3386 Phone: 978-244-8078 - email: ewgray@lucent.com email: rhthomas@cisco.com + 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