idnits 2.17.1 draft-ietf-mpls-ldp-applic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MPLS-FRAMEWORK], [MPLS-ARCH], [LDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2000) is 8714 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TE' is mentioned on line 88, but not defined == Missing Reference: 'CRLDP-AS' is mentioned on line 93, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FRAMEWORK' ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-TE-AS' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Thomas 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: December 2000 4 Eric Gray 5 Zaffire, Inc. 7 June 2000 9 LDP Applicability 11 draft-ietf-mpls-ldp-applic-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Multiprotocol Label Switching (MPLS) is a method for forwarding 37 packets that uses short, fixed-length values carried by packets, 38 called labels, to determine packet nexthops ([MPLS-FRAMEWORK], 39 [MPLS-ARCH]). A fundamental concept in MPLS is that two Label 40 Switching Routers (LSRs) must agree on the meaning of the labels used 41 to forward traffic between and through them. This common 42 understanding is achieved by using a set of procedures, called a 43 label distribution protocol, by which one LSR informs another of 44 label bindings it has made. This document describes the 45 applicability of a set of such procedures called LDP (for Label 46 Distribution Protocol) [LDP] by which LSRs distribute labels to 47 support MPLS forwarding along normally routed paths. 49 1. LDP Applicability 51 A label distribution protocol is a set of procedures by which one 52 Label Switching Router (LSR) informs another of the meaning of labels 53 used to forward traffic between and through them. 55 The MPLS architecture allows for the possibility of more than a 56 single method for distributing labels, and a number of different 57 label distribution protocols are being standardized. Existing 58 protocols have been extended so that label distribution can be 59 piggybacked on them, and new protocols have been defined for the 60 explicit purpose of distributing labels. 62 This document describes the applicability of the Label Distribution 63 Protocol (LDP), a new protocol for label distribution designed to 64 support label distribution for MPLS forwarding along normally routed 65 paths as determined by destination-based routing protocols. This is 66 sometimes called MPLS hop-by-hop forwarding. 68 LDP, together with an IP routing plane and software to program ATM 69 switch or Frame Relay switch cross-connect tables, can implement IP 70 in a network of ATM and/or Frame Relay switches without requiring an 71 overlay or the use of ATM-specific or Frame Relay-specific addressing 72 or routing. 74 LDP is also useful in situations that require efficient hop-by-hop 75 routed tunnels, such as MPLS-based VPN architectures [RFC2547] and 76 tunneling between BGP border routers. 78 In addition, LDP includes a mechanism that makes it possible to 79 extend it to support MPLS features that go beyond best effort hop- 80 by-hop forwarding. 82 As a stand-alone protocol for distributing labels LDP does not rely 83 on the presence of specific routing protocols at every hop along an 84 LSP path in order to establish an LSP. Hence LDP is useful in 85 situations in which an LSP must traverse nodes which may not all 86 support a common piggybacked approach to distributing labels. 88 Traffic Engineering [TE] is expected to be an important MPLS 89 application. MPLS support for Traffic Engineering uses explicitly 90 routed LSPs, which need not follow normally-routed (hop-by-hop) 91 paths. 93 Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set of 94 extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to 95 RSVP. There is currently no consensus on which of these protocols is 96 technically superior. Therefore, network administrators should make 97 a choice between the two based upon their needs and particular 98 situation. 100 2. Requirement Level 102 The "requirement level" [RFC2026] for LDP is: 104 Implementation of LDP is recommended for devices that perform MPLS 105 forwarding along normally routed paths as determined by 106 destination-based routing protocols. 108 3. Feature Overview 110 LDP associates a Forwarding Equivalence Class (FEC) [MPLS-ARCH] with 111 each label it distributes. Two LSRs which use LDP to exchange FEC- 112 label binding information are known as "LDP Peers", and we speak of 113 there being an "LDP Session" between them. 115 LDP uses TCP for session communication. Use of TCP ensures that 116 session messages are reliably delivered, and that distributed labels 117 and state information associated with LSPs need not be refreshed 118 periodically. 120 LDP includes a mechanism by which an LSR can discover potential LDP 121 peers. The discovery mechanism makes it unnecessary for operators to 122 explicitly configure each LSR with its LDP peers. 124 When an LSR discovers another LSR it follows the LDP session setup 125 procedure to establish an LDP session. By means of this procedure 126 the LSRs establish a session TCP connection and use it to negotiate 127 parameters for the session, such as the label distribution method to 128 be used (see below). After the LSRs agree on the parameters, the 129 session is operational and the LSRs use the TCP connection for label 130 distribution. 132 LDP supports two different methods for label distribution. An LSR 133 using Downstream Unsolicited distribution advertises FEC-label 134 bindings to its peers when it is ready to forward packets in the FEC 135 by means of MPLS. An LSR using Downstream on Demand distribution 136 provides FEC-label bindings to a peer in response to specific 137 requests from the peer for a label for the FEC. 139 LDP allows LSRs flexibility in strategies for retaining learned 140 labels. An LSR using liberal label retention stores all labels 141 learned from peers regardless of whether it currently needs them for 142 forwarding, whereas one using conservative label retention stores 143 only labels for which it has immediate use and releases unneeded 144 labels to the peer that advertised them. 146 In addition, LDP allows flexibility in strategies for when to 147 advertise FEC-label bindings. An LSR using independent control mode 148 advertises FEC-label bindings to peers whenever it sees fit, whereas 149 one using ordered control advertises bindings only when it has 150 previously received a label for the FEC from the FEC nexthop or it is 151 an MPLS egress for the FEC. 153 Downstream on Demand distribution with conservative label retention 154 and ordered control is appropriate in situations where labels are a 155 relatively scarce resource that must be conserved, and Downstream 156 Unsolicited distribution with liberal label retention and independent 157 control is appropriate where labels are plentiful and need not be 158 carefully conserved. However, the protocol permits other 159 combinations of distribution method, label retention mode and control 160 mode, including hybrid variants of them. 162 LDP defines a mechanism for loop detection to protect against 163 forwarding loops in LSPs that traverse non-TTL MPLS clouds; see 164 [MPLS-ARCH] for discussion of situations which may benefit from this 165 mechanism. The loop detection mechanism is optional in the sense 166 that it may be disabled by LSR configuration. However, an LDP- 167 compliant LSR must implement it. 169 LDP includes an extension mechanism which supports the development of 170 vendor-private and experimental features. This mechanism defines 171 procedures for introducing new types of messages and TLVs, methods an 172 LSR can use for detecting such messages and TLVs, and procedures an 173 LSR must follow when it receives a message or TLV it does not 174 implement. While it is not possible to make every future enhancement 175 backwards compatible, these procedures facilitate the introduction of 176 new capabilities in MPLS networks that include older implementations 177 that do not recognize them. 179 4. Scalability Considerations 181 The following factors may influence the scalability of LDP 182 implementations: 184 - LDP label distribution is incremental, requiring no periodic 185 refresh of FEC-label bindings. 187 - In situations were label resources may be scarce (ATM and Frame 188 Relay links) the use of the Downstream on Demand distribution 189 method with conservative label retention ensures that only those 190 labels required to support normally-routed paths are allocated 191 and distributed. 193 - In situations where label resources are not scarce, the use of 194 the Downstream Unsolicited method with liberal label retention 195 ensures that changes in FEC nexthop from one LDP peer to another 196 require no distribution action to update previously distributed 197 labels. 199 - Limitations on the number of TCP connections an LSR supports 200 limit the number of LDP peers the LSR can support. 202 - Use of the optional path vector based loop detection mechanism 203 imposes additional memory and processing requirements on an LSR, 204 as well as additional LDP traffic. Both impact scalability. 206 5. Security Considerations 208 LDP defines the optional use of the TCP MD5 Signature Option to 209 protect against the introduction of spoofed TCP segments into LDP 210 session connection streams. LDP use of the TCP MD5 Signature Option 211 is similar to BGP [RFC1771] use of the option specified in [RFC2385]. 213 6. References 215 CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright, 216 "Applicability Statement for CR-LDP", Work in Progress, September 217 1999. 219 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, 220 "LDP Specification", Work in Progress, June 2000. 222 [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 223 Switching Architecture", Work in Progress, August 1999. 225 [MPLS-FRAMEWORK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. 226 Swallow, A. Viswanathan, "A Framework for Multiprotocol Label 227 Switching", Work in Progress, September 1999. 229 [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 230 RFC 1771, March 1995. 232 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 233 RFC 2026, October 1996. 235 [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 236 Signature Option", RFC 2385, August 1998. 238 [RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 239 1999. 241 [RSVP-TE-AS] D. Awduche, A Hannan, X. Xiao, "Applicability State for 242 Extensions to RSVP for LSP-Tunnels", Work in Progress, April 2000. 244 7. Author Information 246 Eric Gray Bob Thomas 247 Zaffire, Inc Cisco Systems, Inc. 248 2630 Orchard Parkway, 250 Apollo Dr. 249 San Jose, CA 95134-2020 Chelmsford, MA 01824 250 Phone: 408-894-7362 Phone: 978-244-8078 251 email: egray@zaffire.com email: rhthomas@cisco.com