idnits 2.17.1 draft-jamoussi-mpls-crldp-applic-00.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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '...ations of CR-LDP MAY be able to suppor...' 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 (August 1999) is 8992 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 section? '1' on line 60 looks like a reference -- Missing reference section? '2' on line 43 looks like a reference -- Missing reference section? '3' on line 51 looks like a reference -- Missing reference section? '4' on line 79 looks like a reference -- Missing reference section? '5' on line 88 looks like a reference -- Missing reference section? '6' on line 89 looks like a reference -- Missing reference section? '7' on line 89 looks like a reference -- Missing reference section? '8' on line 90 looks like a reference -- Missing reference section? '9' on line 102 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG Jerry Ash 3 Internet Draft AT&T 4 Expiration Date: February 2000 Muckai Girish 5 SBC Technology Resources Inc. 6 Eric Gray 7 Lucent Technologies 8 Bilel Jamoussi 9 Gregory Wright 10 Nortel Networks Corp. 12 August 1999 14 Applicability Statement for CR-LDP 16 draft-jamoussi-mpls-crldp-applic-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This Internet-Draft discusses the applicability of Constraint-Based 42 LSP Setup using LDP [1]. It discusses possible network applications, 43 extensions to Label Distribution Protocol (LDP) [2] required to 44 implement constraint-based routing, guidelines for deployment and 45 known limitations of the protocol. This document is a prerequisite 46 to advancing CR-LDP on the standards track. 48 1. Introduction 50 As the Internet evolves, additional capabilities are required to 51 ensure proper treatment of data [3], voice, video and other delay 52 sensitive traffic [4]. MPLS enhances source routing and allows for 53 certain techniques, used in circuit switching, in IP networks. This 54 permits a scalable approach to handling these diverse transmission 55 requirements. CR-LDP is a simple, scalable, open, non-proprietary, 56 traffic engineering signaling protocol for MPLS IP networks. 58 CR-LDP provides mechanisms for establishing explicitly routed Label 59 Switched Paths (LSPs). These mechanisms are defined as extensions 60 to LDP [1]. Because LDP is a peer-to-peer protocol based on the 61 establishment and maintenance of TCP sessions, the following natural 62 benefits exist: 64 CR-LDP messages are reliably delivered by the underlying TCP, and 65 State information associated with explicitly routed LSPs does not 66 require periodic refresh. 68 CR-LDP messages are flow controlled (throttled) through TCP. 70 CR-LDP is defined for the specific purpose of establishing and 71 maintaining explicitly routed LSPs. Additional optional 72 capabilities included have minimal impact on system performance and 73 requirements when not in use for a specific explicitly routed LSP. 74 Optional capabilities provide for negotiation of LSP services and 75 traffic management parameters over and above best-effort packet 76 delivery including bandwidth allocation, setup and holding 77 priorities. CR-LDP optionally allows these parameters to be 78 dynamically modified without disruption of the operational (in- 79 service) LSP [4]. 81 CR-LDP allows the specification of a set of parameters to be 82 signaled along with the LSP setup request. Moreover, the network can 83 be provisioned with a set of edge traffic conditioning functions 84 (which could include marking, metering, policing and shaping). This 85 set of parameters along with the specification of edge conditioning 86 functions can be shown to be adequate and powerful enough to 87 describe, characterize and parameterize a wide variety of QoS 88 scenarios and services including IP differentiated services [5], 89 integrated services [6], ATM service classes [7], and frame relay 90 [8]. 92 CR-LDP is designed to adequately support the various media types 93 that MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.). 94 Hence, it will work equally well for Multi-service switched 95 networks, a router networks, or hybrid networks. 97 2. Applicability of extensions to LDP 99 To provide for support of additional LSP services, CR-LDP extensions 100 are defined in such a way as to be directly translatable to objects 101 and messages used in other protocols defined to provide similar 102 services [9]. Implementations can take advantage of this fact to: 104 Setup LSPs for provision of an aggregate service associated with the 105 services being provided via these other protocols; 107 Directly translate protocol messages to provide services defined in 108 a non-CR-LDP portion of the network. 110 Describe, characterize and parameterize a wide variety of QoS 111 scenarios and services including IP differentiated services, 112 integrated services, ATM service classes, and frame relay. 114 Steady state information required for proper maintenance of an LSP 115 may be as little as 200 bytes or less. It is not unreasonable to 116 anticipate that CR-LDP implementations may support in excess of one 117 hundred thousand or one million LSPs switched through a single Label 118 Switching Router (LSR) under fairly stable conditions. 120 Because CR-LDP provides for low overhead per LSP - both in terms of 121 needed state information and control traffic - CR-LDP is applicable 122 in those portions of the Internet where very large numbers of LSPs 123 may need to be switched at each LSR. An example of this would be 124 large backbone networks using MPLS exclusively to transport very 125 large numbers of traffic streams between a moderately large number 126 of MPLS edge nodes. 128 CR-LDP may also be applicable as a mediating service between 129 networks providing similar service extensions using widely varying 130 signaling models. 132 3. Implementation and deployment considerations in relation to LDP 134 LDP specifies the following label distribution and management modes 135 (which can be combined in various logical ways described in LDP): 137 . Downstream On Demand label distribution 138 . Downstream Unsolicited label distribution 139 . Independent Label Distribution Control 140 . Ordered Label Distribution Control 141 . Conservative Label Retention Mode 142 . Liberal Label Retention Mode 144 In networks where only Traffic Engineered LSPs are required, the CR- 145 LDP implementation and deployment does NOT require all the 146 functionality defined in the LDP specification. The basic Discovery, 147 Session, and Notification messages are required. However, CR-LDP 148 requires one specific combination of the label distribution modes: 150 . Downstream On Demand Ordered label distribution and 151 conservative Label Retention Mode 153 Although CR-LDP is defined as an extension to LDP, support for 154 Downstream Unsolicited Label Advertisement and Independent Control 155 modes is not required for support of Strict Explicit Routes. In 156 addition, implementations of CR-LDP MAY be able to support Loose 157 Explicit Routes via the use of `Abstract Nodes' and/or `Hierarchical 158 Explicit Routing', without using LDP for hop-by-hop LSP setup. 160 CR-LDP also includes support for loose explicit routes. Use of this 161 capability allows the network operator to define an 'explicit path' 162 through portions of their network with imperfect knowledge of the 163 entire network topology. Proper use of this capability may also 164 allow CR-LDP implementations to inter-operate with 'vanilla' LDP 165 implementations - particularly if it is desired to set up an 166 explicitly routed LSP for best-effort packet delivery via a loosely 167 defined path. 169 Finally, in networks where both Routing Protocol-driven LSPs (a.k.a. 170 hop-by-hop LSPs) and Traffic Engineered LSPs are required, asingle 171 protocol (LDP, with the extensions defined in CR-LDP) can be used 172 for both TE and Hop-by-Hop LSPs. New protocols do not have to be 173 introduced in the network to provide TE-LSP signaling. 175 4. Limitations 177 CR-LDP specification only supports point-to-point LSPs. Multi-point- 178 to-point and point-to-multi-point are FFS. 180 CR-LDP specification only supports unidirectional LSP setup. Bi- 181 directional LSP setup is FFS. 183 CR-LDP specification only supports a unique label allocation per LSP 184 setup. Multiple label allocations per LSP setup are FFS. 186 5. Security Considerations 188 No additional security issues are introduced in this draft. As an 189 extension to LDP, CR-LDP shares the security concerns associated 190 with LDP. 192 6. Acknowledgements 194 The authors would like to thank the following people for their 195 careful review of the draft and their comments: Loa Andersson, Peter 196 Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, and Jon Weil. 198 7. References 200 1 B. Jamoussi, et., al., _Constraint-based LSP Setup Using LDP_, 201 work in progress, March 1999. 203 2 L. Andersson, et., al., _LDP Specification_, work in progress, 204 June 1999. 206 3 D. Awduche et., al., "Requirements for Traffic Engineering Over 207 MPLS", work in progress, June 1999. 209 4 G. Ash, Y. Lee, B. Jamoussi, P. Ashwood-Smith, L. Li, D. 210 Skalecki, D. Fedyk, "LSP Modification using CR-LDP," work in 211 progress, July 1999. 213 5 S. Blake et., al., "An Architecture for Differentiated Services", 214 RFC-2495, December 1998. 216 6 S. Shenker, J. Wroclawski, "General Characterization Parameters 217 for Integrated Service Network Elements" RFC-2215 219 7 ATM Forum Traffic Management Specification Version 4.1 (AF-TM- 220 0121.000), March 1999. 222 8 CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING BEARER 223 SERVICE, ITU (CCITT) Recommendation I.370, 1991. 225 9 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan, 226 "Extensions to RSVP for LSP Tunnels," work in progress, March 227 1999. 229 8. Author's Addresses 231 Gerald R. Ash M. K. Girish 232 AT&T SBC Technology Resources, Inc. 233 Room MT E3-3C37 4698 Willow Road, 234 200 Laurel Avenue Pleasanton, CA 94588 235 Middletown, NJ 07748 USA 236 USA Phone: +1 925 598-1263 237 Phone: 732-420-4578 Fax: +1 925 598-1322 238 Fax: 732-440-6687 mgirish@tri.sbc.com 239 Email: gash@att.com 241 Eric W Gray Bilel Jamoussi 242 Lucent Technologies, Inc. Nortel Networks Corp. 243 PO Box 0710 3 Federal Street 244 Durham, NH, 03824-0710 Billerica, MA 01821 245 USA USA 246 Phone: +1 603 659 3386 phone: +1 978-288-4506 247 Ewgray@lucent.com Jamoussi@nortelnetworks.com 248 Gregory Wright 249 Nortel Networks Corp. 250 P O Box 3511 Station C 251 Ottawa, ON K1Y 4H7 252 Canada 253 Phone: +1 613 765-7912 254 gwright@nortelnetworks.com 256 Full Copyright Statement 258 "Copyright (C) The Internet Society (date). All Rights Reserved. 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain it 261 or assist in its implementation may be prepared, copied, published 262 and distributed, in whole or in part, without restriction of any 263 kind, provided that the above copyright notice and this paragraph 264 are included on all such copies and derivative works. However, this 265 document itself may not be modified in any way, such as by removing 266 the copyright notice or references to the Internet Society or other 267 Internet organizations, except as needed for the purpose of 268 developing Internet standards in which case the procedures for 269 copyrights defined in the Internet Standards process must be 270 followed, or as required to translate it into languages other than 271 English. 273 The limited permissions granted above are perpetual and will not be 274 revoked by the Internet Society or its successors or assigns.