idnits 2.17.1 draft-awduche-mpls-rsvp-tunnel-applicability-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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 ([1]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 306, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT 3 MPLS Working Group Daniel O. Awduche 4 Expiration Date: March 2000 UUNET (MCI Worldcom) 5 Alan Hannan 6 Xipeng Xiao 7 Frontier Globalcenter 8 September, 1999 10 Applicability Statement for Extensions to RSVP for LSP-Tunnels 12 draft-awduche-mpls-rsvp-tunnel-applicability-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo discusses the applicability of "Extensions to RSVP for LSP 38 Tunnels" [1]. It highlights the protocol's principles of operation 39 and describes the network context for which it was designed. 40 Guidelines for deployment are offered and known protocol limitations 41 are indicated. This document is intended to accompany the submission 42 of "Extensions to RSVP for LSP Tunnels" onto the Internet standards 43 track. 45 1.0 Introduction 47 Service providers and users have indicated that there is a great need 48 for traffic engineering capabilities in IP networks. These traffic 49 engineering capabilities can be based on Multiprotocol Label 50 Switching (MPLS) and can be implemented on label switching routers 51 (LSRs) from different vendors that interoperate using a common 52 signaling and label distribution protocol. A description of the 53 requirements for traffic engineering in MPLS based IP networks can be 54 found in [2]. There is, therefore, a requirement for an open, non- 55 proprietary, standards based signaling and label distribution 56 protocol for the MPLS traffic engineering application that may be 57 available from all label switching router vendors, which allow such 58 devices to interoperate. 60 The "Extensions to RSVP for LSP tunnels" (RSVP-Tunnel) specification 61 [1] was developed by the IETF MPLS working group to address this 62 requirement. RSVP-Tunnel is a composition of several related 63 proposals submitted to the IETF MPLS working group. It contains all 64 the necessary objects, packet formats, and procedures required to 65 establish and maintain explicit label switched paths (LSPs). Explicit 66 LSPs are foundational to the traffic engineering application in MPLS 67 based IP networks. Besides the traffic engineering application, the 68 RSVP-Tunnel specification may have other uses within the Internet. 70 This memo describes the applicability of the RSVP-Tunnel 71 specifications [1]. The protocol's principles of operation are 72 highlighted, the network context for which it was developed is 73 described, guidelines for deployment are offered, and known protocol 74 limitations are indicated. 76 Two fundamental aspects distinguish the RSVP-Tunnel specification [1] 77 from the original RSVP protocol [3]. 79 The first distinguishing aspect is the fact that the RSVP-Tunnel 80 specification [1] is intended for use by label switching routers (as 81 well as hosts) to establish and maintain LSP-tunnels and to reserve 82 network resources for such LSP-tunnels. The original RSVP 83 specification [3], on the other hand, was intended for use by hosts 84 to request and reserve network resources for micro-flows. 86 The second distinguishing aspect is the fact that the RSVP-Tunnel 87 specification generalizes the concept of "RSVP flow." The RSVP-Tunnel 88 specification essentially allows an RSVP session to consist of an 89 arbitrary aggregation of traffic (based on local policies) between 90 the origination node of an LSP-tunnel and the egress node of the 91 tunnel. To be definite, in the original RSVP protocol [3], a session 92 was defined as a data flow with a particular destination and 93 transport layer protocol. In the RSVP-Tunnel specification, however, 94 a session is implicitly defined as the set of packets that are 95 assigned the same MPLS label value at the origination node of an 96 LSP-tunnel. The assignment of labels to packets can be based on 97 various criteria, and may even encompass all packets (or subsets 98 thereof) between the endpoints of the LSP-tunnel. Because traffic is 99 aggregated, the number of LSP-tunnels (hence the number of RSVP 100 sessions) does not increase proportionally with the number of flows 101 in the network. Therefore, the RSVP-Tunnel specification [1] 102 addresses a major scaling issue with the original RSVP protocol [3], 103 namely the large amount of system resources that would otherwise be 104 required to manage reservations and maintain state for potentially 105 thousands or even millions of RSVP sessions at the micro-flow 106 granularity. 108 This applicability statement concerns only the use of RSVP to set up 109 unicast LSP-tunnels. It is noted that not all of the features 110 described in RFC2205 [3] are required to support the instantiation 111 and maintenance of LSP-tunnels. Aspects related to the support of 112 other features and capabilities of RSVP by an implementation that 113 also supports LSP-tunnels are beyond the scope of this document. 114 However, support of such additional features and capabilities should 115 not introduce new security vulnerabilities in environments that only 116 use RSVP to set up LSP-tunnels. 118 This applicability statement does not preclude the use of other 119 signaling and label distribution protocols for the traffic 120 engineering application in MPLS based IP networks. Service providers 121 are free to deploy whatever signaling protocol that meets their 122 needs. 124 2.0 Technical Overview of Extensions to RSVP for LSP Tunnels 126 The RSVP-Tunnel specification extends the original RSVP protocol by 127 giving it new capabilities that support the following functions in an 128 MPLS domain: 130 (1) downstream-on-demand label distribution 131 (2) instantiation of explicit label switched paths 132 (3) allocation of network resources (e.g., bandwidth) to explicit 133 LSPs 134 (4) rerouting of established LSP-tunnels in a smooth fashion using 135 the concept of make-before-break 136 (5) tracking of the actual route traversed by an LSP-tunnel 137 (6) diagnostics on LSP-tunnels 138 (7) the concept of nodal abstraction 139 (8) preemption options that are administratively controllable 141 The RSVP-Tunnel specification introduces several new RSVP objects, 142 including the LABEL-REQUEST object, the RECORD-ROUTE object, the 143 LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects. New 144 error messages are defined to provide notification of exception 145 conditions. All of the new objects defined in RSVP-Tunnel are 146 optional with respect to the RSVP protocol, except the LABEL-REQUEST 147 and LABEL objects, which are both mandatory for the establishment of 148 LSP-tunnels. 150 Informally, establishment of an LSP-tunnel proceeds in the following 151 way: First, the origination node of the LSP-tunnel creates an RSVP 152 Path message and inserts a LABEL-REQUEST object into it. Optionally, 153 an EXPLICIT-ROUTE object, a RECORD-ROUTE object, and a 154 SESSION_ATTRIBUTE object may also be inserted into the path message. 155 The LABEL-REQUEST object indicates that a label binding is requested; 156 the EXPLICIT-ROUTE object depicts the explicit route for the LSP- 157 tunnel as a sequence of abstract nodes; the RECORD-ROUTE object 158 specifies that a path vector record of the route traversed is 159 required; finally, the SESSION_ATTRIBUTE object is used for session 160 identification and diagnosis. 162 When the Path message reaches the egress node of the LSP-tunnel, a 163 Resv message is created and a LABEL object containing an MPLS label 164 is inserted into the Resv message. As the Resv message propagates to 165 the origination node (in the reverse direction along the path 166 traversed by the Path message), each node uses the MPLS label in the 167 LABEL object from its downstream neighbor as outgoing label for the 168 LSP-tunnel. Each node inserts its own LABEL object before propagating 169 the Resv message upstream. This way, labels are allocated 170 sequentially all the way from the egress node of the LSP-tunnel to 171 the origination node. It is when the Resv message reaches the 172 origination node that the LSP-tunnel becomes established. 174 3.0 Applicability of Extensions to RSVP for LSP Tunnels 176 Use of RSVP-Tunnel is appropriate in contexts where it is useful to 177 establish and maintain explicit label switched paths in an MPLS 178 network. LSP-tunnels may be instantiated for measurement purposes 179 and/or for control purposes. They may also be instantiated for other 180 administrative reasons. 182 For the measurement application, an LSP-tunnel can be used to capture 183 various path statistics between its endpoints. This can be 184 accomplished by associating various performance management and fault 185 management functions with an LSP-tunnel, such as packet and byte 186 counters. For example, an LSP-tunnel can be instantiated, with or 187 without bandwidth allocation, solely for the purpose of monitoring 188 traffic flow statistics between two label switching routers. 190 For the control application, LSP-tunnels can be used to forward 191 subsets of traffic through paths that are independent of routes 192 computed by conventional Interior Gateway Protocol (IGP) Shortest 193 Path First (SPF) algorithms. This feature provides significant 194 control over the routing function and allows policies to be 195 implemented that result in the performance optimization of 196 operational networks. For example, using LSP-tunnels, traffic can be 197 routed away from congested network resources onto relatively 198 underutilized ones. More generally, load balancing policies can be 199 actualized that increase the effective capacity of the network. 201 To further enhance the control application, RSVP-Tunnel may be 202 augmented with an ancillary constraint-based routing entity. This 203 entity may compute explicit routes based on certain traffic 204 attributes, while taking network constraints into account. 205 Additionally, IGP link state advertisements may be extended to 206 propagate new topology state information. This information can be 207 used by the constraint-based routing entity to compute feasible 208 routes. Furthermore, the IGP routing algorithm may itself be enhanced 209 to take pre-established LSP-tunnels into consideration while building 210 the routing table. All these augmentations are useful, but not 211 mandatory. In fact, the RSVP-Tunnel specification may be deployed in 212 certain contexts without any of these additional components. 214 The capability to monitor point to point traffic statistics between 215 two routers and the capability to control the forwarding paths of 216 subsets of traffic through a given network topology together make the 217 RSVP-Tunnel specifications applicable and useful for traffic 218 engineering within service provider networks. 220 These capabilities also make the RSVP-Tunnel applicable, in some 221 contexts, as a component of an MPLS based VPN provisioning framework. 223 It is significant that the MPLS architecture [4] states clearly that 224 no single label distribution protocol is assumed for the MPLS 225 technology. Therefore, this applicability statement does not (and 226 should not be construed to) prevent a label switching router from 227 implementing other signaling and label distribution protocols that 228 also support establishment of explicit LSPs and traffic engineering 229 in MPLS networks. 231 4.0 Deployment and Policy Considerations 233 When deploying RSVP-Tunnel, there should be well defined 234 administrative policies governing the selection of nodes that will 235 serve as endpoints for LSP-tunnels. Furthermore, when devising a 236 virtual topology for LSP-tunnels, special consideration should be 237 given to the tradeoff between the operational complexity associated 238 with a large number of LSP-tunnels and the control granularity that 239 large numbers of LSP-tunnels allow. Stated otherwise, a large number 240 of LSP-tunnels allows greater control over the distribution of 241 traffic across the network, but increases network operational 242 complexity. In large networks, it may be advisable to start with a 243 simple LSP-tunnel virtual topology and then introduce additional 244 complexity based on observed or anticipated traffic flow patterns. 246 Administrative policies should also guide the amount of bandwidth to 247 be allocated (if any) to each LSP-tunnel. Policies of this type may 248 take into consideration traffic statistics derived from the 249 operational network in addition to other factors. 251 5.0 Limitations 253 The RSVP-Tunnel specification supports only unicast LSP-tunnels. 254 Multicast LSP-tunnels are not supported. 256 The RSVP-Tunnel specification supports only unidirectional LSP- 257 tunnels. Bidirectional LSP-tunnels are not supported. 259 The soft state nature of RSVP remains a source of concern because of 260 the need to generate refresh messages periodically to maintain the 261 state of established LSP-tunnels. This issue is addressed in several 262 proposals that have been submitted to the RSVP working group (see 263 e.g. [6]). 265 6.0 Conclusion 267 The applicability of the "Extensions to RSVP for LSP Tunnels" 268 specification has been discussed in this document. The specification 269 introduced several enhancements to the RSVP protocol, which make it 270 applicable in contexts in which the original RSVP protocol would have 271 been inappropriate. One context in which the RSVP-Tunnel 272 specification is particularly applicable is in traffic engineering in 273 MPLS based IP networks. 275 7.0 Security Considerations 277 This document does not introduce new security issues. The RSVP-Tunnel 278 specification adds new opaque objects to RSVP and so the security 279 considerations pertaining to the original RSVP protocol remain 280 relevant. When deployed in service provider networks, it is mandatory 281 to ensure that only authorized entities are permitted to initiate 282 establishment of LSP-tunnels. 284 8.0 Acknowledgments 286 The authors gratefully acknowledge the useful comments received from 287 the following individuals during initial review of this memo in the 288 MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow. 290 9.0 References 292 [1] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, 293 V. Srinivasan, "Extensions to RSVP for LSP Tunnels," 294 Work in Progress. 296 [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 297 "Requirements for Traffic Engineering Over MPLS," 298 Work in Progress. 300 [3] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 301 Version 1, Functional Specification", RFC 2205, September 1997. 303 [4] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture 304 for MPLS", Work in Progress. 306 [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 307 A. Viswanathan, "A Framework for Multiprotocol Label 308 Switching", Work in Progress. 310 [6] L. Berger, D. Gan, G. Swallow, "RSVP Refresh Reduction 311 Extensions," Work in Progress. 313 10.0 AUTHORS' ADDRESSES 315 Daniel O. Awduche 316 UUNET (MCI Worldcom) 317 3060 Williams Drive 318 Fairfax, VA 22031 319 Email: awduche@uu.net 320 Voice: +1 703-208-5277 322 Alan Hannan 323 Frontier Globalcenter 324 141 Caspian Court, 325 Sunnyvale, CA 94089 326 Email: alan@globalcenter.net, 327 Voice: +1 408-543-4891 329 Xipeng Xiao 330 Frontier Globalcenter 331 141 Caspian Court, 332 Sunnyvale, CA 94089 333 Email: xipeng@globalcenter.net, 334 Voice: +1 408-543-4801