idnits 2.17.1 draft-ali-ccamp-lsp-inquiry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 4. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4085 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? 'RFC2119' on line 383 looks like a reference -- Missing reference section? 'RFC4208' on line 413 looks like a reference -- Missing reference section? 'ID.SRLG-RECORDING' on line 403 looks like a reference -- Missing reference section? 'ID.METRIC-RECORDING' on line 129 looks like a reference -- Missing reference section? 'RFC6001' on line 390 looks like a reference -- Missing reference section? 'RFC5420' on line 395 looks like a reference -- Missing reference section? 'RFC3209' on line 386 looks like a reference -- Missing reference section? 'RFC5920' on line 430 looks like a reference -- Missing reference section? 'RFC2205' on line 356 looks like a reference -- Missing reference section? 'RFC3473' on line 419 looks like a reference -- Missing reference section? 'RFC4874' on line 357 looks like a reference -- Missing reference section? 'ID.TE-METRIC-RECORDING' on line 408 looks like a reference -- Missing reference section? 'RFC2209' on line 426 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 17, 2013 Ori Gerstel 6 Matt Hartley 7 Cisco Systems 8 February 18, 2013 10 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 11 Extension for Label Switched Path (LSP) Inquiry 13 draft-ali-ccamp-lsp-inquiry-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 15, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 RSVP-TE reoptimization procedure for Packet Switch Capable (PSC) 64 tunnels and non-PSC tunnels has some differences. This document 65 highlights these differences, describes how existing procedures can 66 be used for reoptimization of non-PSC tunnels and proposes some 67 enhancements for reoptimization of non-PSC tunnels. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 Table of Contents 77 1. Introduction .................................................. 2 78 1.1. Inquiry with Resource Locking.............................. 4 79 1.2. Inquiry without Resource Locking .......................... 5 80 2. RSVP-TE signaling procedure ................................... 6 81 2.1. RSVP-TE Signaling for Inquiry with Resource Locking ....... 6 82 2.2. RSVP-TE Signaling for Inquiry without Resource Locking .... 7 83 3. Security Considerations ....................................... 8 84 4. IANA Considerations ........................................... 8 85 4.1. RSVP Attribute Bit Flags .................................. 8 86 5. References 87 .................................................... 9 88 5.1. Normative References ...................................... 9 89 5.2. Informative References .................................... 9 91 1. Introduction 93 During reoptimization of PSC tunnel, existing and reoptimization 94 LPSs may use independent labels and may install independent 95 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 97 forwarding states for each LSP. That is, existing and reoptimization 98 LSPs may be simultaneously active in both control and data planes. 99 However, for many non-PSC technologies label itself represents the 100 underlying physical resource and hence cannot be shared between 101 existing and reoptimization LSPs in the data plane. Consequently, 102 for many non-PSC technologies, reoptimization LSPs can only be 103 instantiated in the control plane. Furthermore, reoptimization LSP 104 is not immediately available to carry any traffic and requires 105 additional signaling for its activation in the data plane. 107 In this document, inquiry refers to a way to signal sharing of 108 resources (e.g., labels, links) between the existing and 109 reoptimization LSPs in the control plane without installing any 110 forwarding states in the data plane (e.g., without installing cross- 111 connections). In most non-PSC networks, inquiry step is required to 112 access feasibility and characteristics of the reoptimization LSP 113 before committing data plane resources and moving traffic to it. 114 This is especially true of scenarios when route computation is not 115 performed by ingress Label Edge Router (LER). These include (but are 116 not limited to): 117 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 118 inter-domain LSPs. 120 . Generalized Multi-Protocol Label Switching (GMPLS) User- 121 Network Interface (UNI) where route computation may be 122 performed by the (server layer) core Label Switch Router (LSR) 123 [RFC4208]; 125 In such cases, ingress LER may like to inquire about feasibility and 126 attributes of a better path. Cost, TE metrics and SRLG values are 127 examples of attributes that ingress LER may like to inquire about 128 (e.g., before making a reoptimization decision). Procedures 129 specified in [ID.SRLG-RECORDING] and [ID.METRIC-RECORDING] may be 130 used for this purpose. 132 Reoptimization is an example where inquiry procedure is needed. 133 However, inquiry is also useful for other use cases, e.g., for 134 probing purposes. Hence, for the generalization purposes, LSP 135 signaled during inquiry is referred as inquiry LSP. Reoptimization 136 LSP is an example of inquiry LSP. 138 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 140 Inquiry LSP may be signaled with or without resource locking in the 141 control plane. This is detailed in the following. 143 1.1. Inquiry with Resource Locking 145 Signaling inquiry LSP with resource locking is depicted in Figure 146 1. Specifically, Path message (Path1) is signaled such that 147 resource activation is Data Plane (DP) is skipped. However, 148 inquiry LSP reserves resources in the Control Plane (CP), i.e., 149 resources/ labels are locked/ committed in the control plane. 150 Nonetheless, resources/ labels are still shared with the existing 151 LSP(s) belonging to the tunnel inquiry LSP belongs to. 153 | Path (Path1) | Path (Path1) | Path (Path1) | 154 | with resource | with resource | with resource | 155 | locking in CP | locking in CP | locking in CP | 156 | but without DP | but without DP | but without DP | 157 | activation | activation | activation | 158 |--------------->|--------------->|--------------->| 159 |<---------------|<---------------|<---------------| 160 | Resv (Resv1) | Resv (Resv1) | Resv (Resv1) | 161 | | | | 162 +-----------+ 163 |Inquiry LSP| 164 |Passes | 165 |Evaluation | 166 +-----------+ 167 | | | | 168 | Path Change | Path Change | Path Change | 169 | (Path2) | (Path2) | (Path2) | 170 | for DP | for DP | for DP | 171 | activation | activation | activation | 172 |--------------->|--------------->|--------------->| 173 |<---------------|<---------------|<---------------| 174 | Resv (Resv2) | Resv (Resv2) | Resv (Resv2) | 175 | | | | 176 Ingress LER LSR A LSR B Egress LER 178 Figure 1: Inquiry LSP Signaling with Resource Locking 180 By the time Resv1 for the initial Path message (Path1) is received 181 by the ingress LER, the ingress LER knows about feasibility and the 182 requested attributes of the inquiry LSR. Please note that to ensure 183 resource locking at the right priority, inquiry LSP needs to be 184 signaled using the same setup and hold priority as existing LSP. 186 After finding feasibility and the requested attributes of the 187 inquiry LSP, the ingress LER evaluates inquiry LSP. E.g., if the 188 inquiry LSP is signaled for reoptimization purposes, the ingress LER 189 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 191 determines if it would like to reoptimize the existing LSP. If 192 ingress LER decides not to reoptimize existing LSP, it deletes the 193 inquiry LSP (by sending Path tear message - 194 - this option is not shown 195 in Figure 1). However, if the ingress LER decides to reoptimize the 196 tunnel to use the inquire LSP, it initiates activation of the 197 inquiry LSP in the data plane (as shown by Path2 and Resv2 signaling 198 loop in Figure 1). How ingress LER moves traffic from existing LSP 199 to inquire LSP for reoptimization purpose is beyond the scope of 200 this document. 202 1.2. Inquiry without Resource Locking 204 When inquiry is performed with resource locking, the resources used 205 by the inquiry LSP are locked in control plane and cannot be used by 206 any LSP other than the LSP(s) belonging to the same tunnel (of 207 course resource preemption based on setup and hold priority of the 208 inquiry LSP is still possible). This limits network availability in 209 the event of a failure, especially when inquiry is used frequently, 210 e.g., for probing purposes. This issue can be addressed by signaling 211 inquiry LSP without resource locking. In this case, the resources 212 used by the inquiry LSP are not locked in control plane and can be 213 used by any LSP, including the existing LSP(s) belonging to the same 214 tunnel. Therefore, if inquiry LSP is signaled without resource 215 locking, additional signaling is required to first lock the 216 resources in the control plane, before the LSP can be activated in 217 the data plane. This is depicted in the following Figure. 219 | Path (Path1) | Path (Path1) | Path (Path1) | 220 |without resource|without resource|without resource| 221 | locking in CP | locking in CP | locking in CP | 222 | and without DP | and without DP | and without DP | 223 | activation | activation | activation | 224 |--------------->|--------------->|--------------->| 225 |<---------------|<---------------|<---------------| 226 | Resv (Resv1) | Resv (Resv1) | Resv (Resv1) | 227 | | | | 228 +-----------+ 229 |Inquiry LSP| 230 |Passes | 231 |Evaluation | 232 +-----------+ 233 | | | | 234 | Path Change | Path Change | Path Change | 235 | (Path2) | (Path2) | (Path2) | 236 | for resource | for resource | for resource | 237 | locking in CP | locking in CP | locking in CP | 238 |--------------->|--------------->|--------------->| 239 |<---------------|<---------------|<---------------| 240 | Resv (Resv2) | Resv (Resv2) | Resv (Resv2) | 241 | | | | 243 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 245 | | | | 246 | Path Change | Path Change | Path Change | 247 | (Path3) | (Path3) | (Path3) | 248 | for DP | for DP | for DP | 249 | activation | activation | activation | 250 |--------------->|--------------->|--------------->| 251 |<---------------|<---------------|<---------------| 252 | Resv (Resv3) | Resv (Resv3) | Resv (Resv3) | 253 | | | | 254 Ingress LER LSR A LSR B Egress LER 256 Figure 2: Inquiry LSP Signaling without Resource Locking 258 Initial Path message (Path1) is signaled such that resource locking 259 in control plane and resource activation is data plane is skipped. 260 By the time Resv1 for the initial Path message (Path1) is received 261 by the ingress LER, the ingress LER knows about feasibility and the 262 requested attributes of the inquiry LSR. The inquiry LSP evaluation 263 process works in the same fashion as discussed in Section 1.1. 265 As Path1 is signaled without resource locking, there is no guarantee 266 that the resources for the inquiry LSP will be available when 267 ingress LER decides to activate the inquiry LSP. Therefore, the 268 ingress LER first signals a path change (Path2) to lock the resource 269 in the control plane before inquiry LSP can be activated in the data 270 plane. 272 2. RSVP-TE signaling procedure 274 This section describes the signaling procedure for LSP inquiry with 275 and without resource locking. 277 2.1. RSVP-TE Signaling for Inquiry with Resource Locking 279 [RFC6001] specifies procedure for signaling Soft Forwarding 280 Adjacency (Soft FA). It defines the Pre-Planned LSP flag in the 281 Attribute Flags TLV, which can be carried in an LSP_ATTRIBUTES 282 object defined in [RFC5420]. The Pre-Planned LSP flag can also be 283 used to signal inquiry LSP with resource locking. 285 The processing rules for the Pre-Planned LSP flag are unchanged 286 from [RFC6001]. The procedures for the processing the Attribute 287 Flags TLV are also unchanged from [RFC5420]. The following 288 description is provided to help describe usage of the Pre-Planned 289 LSP flag in the context of signaling the inquiry LSP. Example of 290 Figure 1 is used to describe the usage. 292 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 294 . Path1 message in Figure 1 is sent with the Pre-Planned LSP 295 flag set to 1. As per [RFC6001], this enables provisioning 296 of inquiry LSP in control plane only. In order to enable 297 sharing if resources within the same tunnel, Path1 message 298 is sent with shared explicit reservation style [RFC3209]. 300 . In order to activate inquiry LSP in the data plane, Path2 301 message (please see Figure 1) is sent with the Pre-Planned 302 LSP flag set to 0. 304 2.2. RSVP-TE Signaling for Inquiry without Resource Locking 306 In order to indicate signaling of an LSP without resource 307 provisioning in neither control plane nor data plane, a new flag 308 in the Attribute Flags TLV, which can be carried in an 309 LSP_ATTRIBUTES Object, is defined as follows: 311 . Pre-Planned LSP Without Resource Locking flag (to be 312 assigned by IANA, recommended bit position TBD) 314 The Pre-Planned LSP Without Resource Locking flag is 315 meaningful on a Path message. The procedure for the processing 316 the Attribute Flags TLV follows [RFC5420]. The flag is used as 317 described in the following. 319 . If the Pre-Planned LSP Without Resource Locking flag is set 320 to 1, the transit nodes SHOULD NOT reserve resources 321 required by the LSP in the control plane and MUST NOT 322 install any forwarding states associated with the LSP in the 323 data plane. However, all LERs and LSRs are required to 324 remember the resource (labels, links, etc.) assignments and 325 the RSVP-TE states associated with this LSP. These resources 326 are not locked and hence can be claimed by anther LSP. If 327 the Pre-Planned LSP Without Resource Locking flag is set to 328 1, the Pre-Planned LSP flag MUST be ignored. In our example 329 of Figure 2, Path1 message is sent with the Pre-Planned LSP 330 Without Resource Locking flag set to 1. 332 . If the Pre-Planned LSP Without Resource Locking flag is set 333 to 0 and the Pre-Planned LSP flag is set to 1, the transit 334 nodes MUST commit resources associated with the LSP in the 335 control plane. However, if a resource is already claimed by 336 another LSP, the processing LSR/ LER MUST send a Path Error 337 with code: "Admission Control Failure (1)" and subcode "LSP 338 Admission Failure (4) and Path State Removal flag. A 340 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 342 processing LSR/ LER MUST NOT install any forwarding states 343 associated with the LSP in the data plane. Path2 message in 344 Figure 2 is sent with the Pre-Planned LSP Without Resource 345 Locking flag set to 0 and the Pre-Planned LSP flag is set to 346 1. It is RECOMMENDED that no other modifications be made to 347 other RSVP objects during this operation (signaling Path2). 349 . Activation of LSP in data plane follows the procedure 350 specific in [RFC6001]. E.g., Path2 message in Figure 2 is 351 sent with the Pre-Planned LSP flag set to 0. 353 3. Security Considerations 355 This document does not introduce any additional security issues 356 above those identified in [RFC5920], [RFC2205], [RFC3209], and 357 [RFC3473] and [RFC4874]. 359 4. IANA Considerations 361 4.1. RSVP Attribute Bit Flags 363 The IANA has created a registry and manages the space of 364 attributes bit flags of Attribute Flags TLV as described in 365 section 11.3 of [RFC5420]. It is requested that the IANA makes 366 assignments from the Attribute Bit Flags defined in this 367 document. 369 This document introduces the following new Attribute Bit Flag: 371 - Bit number: TBD 373 - Defining RFC: this I-D 375 - Name of bit: Pre-Planned LSP Without Resource Locking 376 Flag 377 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 379 5. References 381 5.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 387 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 388 LSP Tunnels", RFC 3209, December 2001. 390 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., 391 Brungard, D., and JL. Le Roux, "Generalized MPLS 392 (GMPLS) Protocol Extensions for Multi-Layer and Multi- 393 Region Networks (MLN/MRN)", RFC 6001, October 2010. 395 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 396 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 397 Establishment Using Resource Reservation Protocol 398 Traffic Engineering (RSVP-TE)", RFC 5420, February 399 2009. 401 5.2. Informative References 403 [ID.SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 404 Margaria, "RSVP-TE Extensions for Collecting SRLG 405 Information", draft-ietf-ccamp-rsvp-te-srlg- 406 collect.txt, work in progress. 408 [ID.TE-METRIC-RECORDING] Ali, Z., Swallow, G., Filsfils, C., et 409 al "RSVP-TE extension for recording TE Metric of a 410 Label Switched Path", draft-ali-ccamp-te-metric- 411 recording, work in progress. 413 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 414 "Generalized Multiprotocol Label Switching (GMPLS) 415 User-Network Interface (UNI): Resource ReserVation 416 Protocol-Traffic Engineering (RSVP-TE) Support for the 417 Overlay Model", RFC 4208, October 2005. 419 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 420 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 421 Engineering (RSVP-TE) Extensions", RFC 3473, January 422 2003. 424 Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt 426 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 427 (RSVP) -- Version 1 Message Processing Rules", RFC 428 2209, September 1997. 430 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 431 Networks", RFC 5920, July 2010. 433 Authors' Addresses 435 Zafar Ali 436 Cisco Systems. 437 Email: zali@cisco.com 439 George Swallow 440 Cisco Systems 441 swallow@cisco.com 443 Clarence Filsfils 444 Cisco Systems, Inc. 445 cfilsfil@cisco.com 447 Ori Gerstel 448 Cisco Systems 449 Email: ogerstel@cisco.com 451 Matt Hartley 452 Cisco Systems 453 Email: mhartley@cisco.com