idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7412], [RFC4872]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC7412, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4872, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In SMP, a preempted LSP SHOULD not be torn down. Once the working LSP and the protecting LSP are configured or pre-configured, the end node SHOULD keep refreshing both working and protecting LSPs regardless of failure or preempted situation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: [Editor's note: See if it is ok to add the next sentence at the end of the previous paragraph.] The Path_State_Removed flag in the ERROR_SPEC object MUST not be set in PathErr and ResvErr messages generated due to preemption. -- The document date (July 5, 2019) is 1755 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: 'A' is mentioned on line 180, but not defined == Missing Reference: 'B' is mentioned on line 180, but not defined == Missing Reference: 'C' is mentioned on line 180, but not defined == Missing Reference: 'D' is mentioned on line 180, but not defined == Missing Reference: 'H' is mentioned on line 168, but not defined == Missing Reference: 'I' is mentioned on line 167, but not defined == Missing Reference: 'J' is mentioned on line 167, but not defined == Missing Reference: 'K' is mentioned on line 168, but not defined == Missing Reference: 'E' is mentioned on line 168, but not defined == Missing Reference: 'F' is mentioned on line 168, but not defined == Missing Reference: 'G' is mentioned on line 168, but not defined Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group J. He 3 Internet-Draft I. Busi 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 6, 2020 J. Ryoo 6 B. Yoon 7 ETRI 8 P. Park 9 KT 10 July 5, 2019 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-01 15 Abstract 17 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 18 a Shared Mesh Protection (SMP) mechanism, where the difference 19 between SMP and Shared Mesh Restoration (SMR) is also identified. 20 ITU-T Recommendation G.873.3 [G873.3] defines the protection 21 switching operation and associated protocol for SMP at the Optical 22 Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for 23 any mechanism that would be used to implement SMP in a Multi-Protocol 24 Label Switching - Transport Profile (MPLS-TP) network. 26 This document updates RFC 4872 [RFC4872] to provide the extensions to 27 the Generalized Multi-Protocol Label Switching (GMPLS) signaling to 28 support the control of the shared mesh protection. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 6, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4 68 4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 6 70 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 6 71 4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8 72 5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8 73 5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8 74 5.2. Other Updates . . . . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 9.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol 86 - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration 87 (SMR) mechanism. SMR can be seen as a particular case of pre-planned 88 Label Switched Path (LSP) rerouting that reduces the recovery 89 resource requirements by allowing multiple protecting LSPs to share 90 common link and node resources. The recovery resources for the 91 protecting LSPs are pre-reserved during the provisioning phase, and 92 an explicit restoration signaling is required to activate (i.e., 93 commit resource allocation at the data plane) a specific protecting 94 LSP instantiated during the provisioning phase. 96 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 97 a shared mesh protection (SMP) mechanism. ITU-T Recommendation 98 G.873.3 [G873.3] defines the protection switching operation and 99 associated protocol for SMP at the Optical Data Unit (ODU) layer. 100 RFC 7412 [RFC7412] provides requirements for any mechanism that would 101 be used to implement SMP in a Multi-Protocol Label Switching - 102 Transport Profile (MPLS-TP) network. 104 SMP differs from SMR in the activation/protection switching 105 operation. The former activates a protecting LSP via the automatic 106 protection switching (APS) protocol in the data plane when the 107 working LSP fails, while the latter does it via the control plane 108 signaling. It is therefore necessary to distinguish SMP from SMR 109 during provisioning so that each node involved behaves appropriately 110 in the recovery phase when activation of a protecting LSP is done. 112 This document updates [RFC4872] to provide the extensions to the 113 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 114 support the control of the SMP mechanism. Only the generic aspects 115 for signaling SMP are addressed by this document. The technology- 116 specific aspects are expected to be addressed by other drafts. 118 2. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 In addition, the reader is assumed to be familiar with the 127 terminology used in [RFC4872] and RFC 4426 [RFC4426]. 129 3. SMP Definition 131 [G808.3] defines the generic aspects of a SMP mechanism. [G873.3] 132 defines the protection switching operation and associated protocol 133 for SMP at the ODU layer. [RFC7412] provides requirements for any 134 mechanism that would be used to implement SMP in a MPLS-TP network. 136 The SMP mechanism is based on pre-computed protection transport 137 entities that are pre-configured into the network elements. Pre- 138 configuration here means pre-reserving resources for the protecting 139 LSPs without activating a particular protecting LSP (e.g. in circuit 140 networks, the cross-connects in the intermediate nodes of the 141 protecting LSP are not pre-established). Pre-configuring but not 142 activating the protecting LSP allows the common link and node 143 resources in a protecting LSP to be shared by multiple working LSPs 144 that are physically (i.e., link, node, Shared Risk Link Group (SRLG), 145 etc.) disjoint. Protecting LSPs are activated in response to 146 failures of working LSPs or operator's commands by means of the APS 147 protocol that operates in the data plane. The APS protocol messages 148 are exchanged along the protecting LSP. SMP is always revertive. 150 SMP has a lot of similarity to SMR except that the activation in case 151 of SMR is achieved by control plan signaling during the recovery 152 operation while SMP is done by APS protocol in the data plane. SMP 153 has advantages with regard to the recovery speed compared with SMR. 155 4. GMPLS Signaling Extension for SMP 157 Consider the following network topology: 159 A---B---C---D 160 \ / 161 E---F---G 162 / \ 163 H---I---J---K 165 Figure 1: An example of SMP topology 167 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 168 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], 169 in order to achieve resource sharing during the signaling of these 170 protecting LSPs, they must have the same Tunnel Endpoint Address (as 171 part of their SESSION object). However, these addresses are not the 172 same in this example. Similar to SMR, a new LSP Protection Type of 173 the secondary LSP is defined as "Shared Mesh Protection" (see 174 PROTECTION object defined in [RFC4872]) to allow resource sharing 175 along nodes E, F, and G. In this case, the protecting LSPs are not 176 merged (which is useful since the paths diverge at G), but the 177 resources along E, F, G can be shared. 179 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 180 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 181 end-node (say node A) that detects the failure initiates the 182 protection switching operation. The end-node A will send a 183 protection switching request APS message (for example SF) to its 184 adjacent (downstream) intermediate node (say node E) to activate 185 setting up the corresponding protecting LSP and will wait for a 186 confirmation message from node E. If the protection resource is 187 available, node E will send the confirmation APS message to the end- 188 node A and forward the switching request APS message to its adjacent 189 (downstream) node (say node F). When the confirmation APS message is 190 received by node A, the cross-connection on node A is established. 191 At this time the traffic is bridged to and selected from the 192 protecting LSP at node A. After forwarding the switching request APS 193 message, node E will wait for a confirmation APS message from node F, 194 which triggers node E to set up the cross-connection for the 195 protecting LSP being activated. If the protection resource is not 196 available (due to failure or being used by higher priority 197 connections), the switching will not be successful; the intermediate 198 node may send a message to notify the end node, or may keep trying 199 until the resource is available or the switching request is 200 cancelled. If the resource is in use by a lower priority protecting 201 LSP, the lower priority service will be removed and then the 202 intermediate node will follow the procedure as described for the case 203 when the protection resource is available for the higher priority 204 protecting LSP. 206 The following subsections detail how LSPs using SMP can be signaled 207 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 208 3473 [RFC3473]). This includes; 210 (1) the ability to identify a "secondary protecting LSP" (hereby 211 called the "secondary LSP") used to recover another primary 212 working LSP (hereby called the "protected LSP"), 214 (2) the ability to associate the secondary LSP with the protected 215 LSP, 217 (3) the capability to include information about the resources used 218 by the protected LSP while instantiating the secondary LSP, 220 (4) the capability to instantiate during the provisioning phase 221 several secondary LSPs in an efficient manner, and 223 (5) the capability to support activation of a secondary LSP after 224 failure occurrence via APS protocol in the data plane. 226 4.1. Identifiers 228 To simplify association operations, both LSPs (i.e., the protected 229 and the secondary LSPs) belong to the same session. Thus, the 230 SESSION object MUST be the same for both LSPs. The LSP ID, however, 231 MUST be different to distinguish between the protected LSP carrying 232 working traffic and the secondary LSP. 234 A new LSP Protection Type "Shared Mesh Protection" is introduced to 235 the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two 236 LSPs. This LSP Protection Type value is applicable only to 237 bidirectional LSPs as required in [G808.3]. 239 4.2. Signaling Primary LSPs 241 The PROTECTION object (see [RFC4872]) is included in the Path message 242 during signaling of the primary working LSPs, with the LSP Protection 243 Type value set to "Shared Mesh Protection". 245 Primary working LSPs are signaled by setting in the POTECTION object 246 the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION 247 object, the Association ID to the associated secondary protecting 248 LSP_ID. 250 Note: N bit is set to indicate that the protection switching 251 signaling is done via data plane. 253 4.3. Signaling Secondary LSPs 255 The PROTECTION object (see [RFC4872]) is included in the Path message 256 during signaling of the secondary protecting LSPs, with the LSP 257 Protection Type value set to "Shared Mesh Protection". 259 Secondary protecting LSPs are signaled by setting in the PROTECTION 260 object the S bit and the P bit to 1, the N bit to 1 and in the 261 ASSOCIATION object, the Association ID to the associated primary 262 working LSP_ID, which MUST be known before signaling of the secondary 263 LSP. Moreover, the Path message used to instantiate the secondary 264 LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see 265 [RFC4872]) that further allows for recovery resource sharing at each 266 intermediate node along the secondary path. 268 With this setting, the resources for the secondary LSP SHOULD be pre- 269 reserved, but not committed at the data plane level, meaning that the 270 internals of the switch need not be established until explicit action 271 is taken to activate this LSP. Activation of a secondary LSP and 272 protection switching to the activated protecting LSP is done using 273 APS protocol in the data plane. 275 After protection switching completes the protecting LSP SHOULD be 276 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 277 object. At this point, the link and node resources must be allocated 278 for this LSP that becomes a primary LSP (ready to carry normal 279 traffic). The formerly working LSP MAY be signaled with the A bit 280 set in the ADMIN_STATUS object (see [RFC3473]). 282 Support for extra traffic in SMP is for further study. Therefore, 283 mechanisms to setup LSPs for extra traffic are also for further 284 study. 286 The preemption priority of a protecting LSP that is used to resolve 287 the competition for the same shared resource among multiple 288 protecting LSPs, is indicated in the TBD1 field of the TBD2 object in 289 the Path message of the protecting LSP. In SMP, the Setup and 290 Holding priorities in the SESSION_ATTRIBUTE object can be used to 291 configure or pre-configure a LSP, but is irrelevant to resolving the 292 competition among multiple protecting LSPs, which experience failures 293 on their working LSPs. 295 When an intermediate node on the protection LSP receives the Path 296 message, the preemption priority value in the TBD1 field MUST be 297 stored for that protection LSP. When resource competition among 298 multiple protecting LSPs occurs, their priority values will be used 299 to resolve the competition. Once the preemption priorities are 300 configured, the preemption of the protecting LSPs is fully controlled 301 by the APS. 303 When an APS request for a lower priority protecting LSP is preempted 304 or cannot be confirmed due to existing higher priority APS request 305 for another protection LSPs, an intermediate node MAY send PathErr 306 and ResvErr with the error code/sub-code "Policy Control Failure/Hard 307 Pre-empted" toward the source nodes of Path and Resv, respectively, 308 to notify that the lower priority protecting LSP is preempted. 310 Upon receiving a PathErr or ResvErr message with the error code/sub- 311 code "Policy Control Failure/Hard Pre-empted," the end node that has 312 initiated the protection switching for a protecting LSP may cancel it 313 (and try with another protecting LPS) or may keep trying until the 314 resource is available. 316 In SMP, a preempted LSP SHOULD not be torn down. Once the working 317 LSP and the protecting LSP are configured or pre-configured, the end 318 node SHOULD keep refreshing both working and protecting LSPs 319 regardless of failure or preempted situation. 321 [Editor's note: See if it is ok to add the next sentence at the end 322 of the previous paragraph.] The Path_State_Removed flag in the 323 ERROR_SPEC object MUST not be set in PathErr and ResvErr messages 324 generated due to preemption. 326 [Editor's note: Check what should be the behavior to notify the end 327 nodes of the lower priority protecting LSP that is no longer 328 preempted and therefore it is available for SMP protection switching, 329 if needed.] 331 4.4. SMP APS Configuration 333 SMP relies on APS protocol messages being exchanged between the nodes 334 along the path to activate a SMP protecting LSP. 336 In order to allow exchange of APS protocol messages, an APS channel 337 has to be configured between adjacent nodes along the path of the SMP 338 protecting LSP. This should be done before any SMP protecting LSP 339 has been setup by other means than GMPL signaling which are therefore 340 outside the scope of this document. 342 Depending on the APS protocol message format, the APS protocol may 343 use different identifiers than GMPLS signaling to identify the SMP 344 protecting LSP. 346 Since APS protocol is for further study in [G808.3], it can be 347 assumed that APS message format and identifiers are technology- 348 specific and/or vendor-specific. Therefore, additional requirements 349 for APS configuration are outside the scope of this document. 351 5. Updates to PROTECTION Object 353 GMPLS extension requirements for SMP introduce several updates to the 354 Protection Object (see [RFC4872]). 356 5.1. New Protection Type 358 A new LSP protection type "Shared Mesh Protection" is added in the 359 protection object. This LSP Protection Type value is applicable to 360 only bidirectional LSPs. 362 LSP (Protection Type) Flags: 364 0x11: Shared Mesh Protection 366 5.2. Other Updates 368 N bit and O bit in the Protection object as defined in [RFC4872] are 369 also updated to include applicability to SMP. 371 Notification (N): 1 bit 373 When set to 1, this bit indicates that the control plane message 374 exchange is only used for notification during protection 375 switching. When set to 0 (default), it indicates that the control 376 plane message exchanges are used for protection-switching 377 purposes. The N bit is only applicable when the LSP Protection 378 Type Flag is set to either 0x04 (1:N Protection with Extra- 379 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 380 Bidirectional Protection). In SMP, N bit MUST be set to 1. The N 381 bit MUST be set to 0 in any other case. 383 Operational (O): 1 bit 385 When set to 1, this bit indicates that the protecting LSP is 386 carrying the normal traffic after protection switching. The O bit 387 is only applicable when the P bit is set to 1, and the LSP 388 Protection Type Flag is set to either 0x04 (1:N Protection with 389 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 390 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 391 The O bit MUST be set to 0 in any other case. 393 6. IANA Considerations 395 IANA actions required by this document will be described later. 397 7. Security Considerations 399 No further security considerations than [RFC4872]. 401 8. Contributor 403 The following person contributed significantly to the content of this 404 document and should be considered as a co-author. 406 Yuji Tochio 407 Fujitsu 408 Email: tochio@fujitsu.com 410 9. References 412 9.1. Normative References 414 [G808.3] International Telecommunication Union, "Generic protection 415 switching - Shared mesh protection", ITU-T Recommendation 416 G.08.3, October 2012. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 424 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 425 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 426 . 428 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 429 Switching (GMPLS) Signaling Resource ReserVation Protocol- 430 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 431 DOI 10.17487/RFC3473, January 2003, 432 . 434 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 435 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 436 Recovery Functional Specification", RFC 4426, 437 DOI 10.17487/RFC4426, March 2006, 438 . 440 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 441 Ed., "RSVP-TE Extensions in Support of End-to-End 442 Generalized Multi-Protocol Label Switching (GMPLS) 443 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 444 . 446 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 447 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 448 May 2017, . 450 9.2. Informative References 452 [G873.3] International Telecommunication Union, "Optical transport 453 network - Shared mesh protection", ITU-T Recommendation 454 G.873.3, September 2017. 456 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 457 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 458 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 459 December 2014, . 461 Authors' Addresses 463 Jia He 464 Huawei Technologies 465 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 466 Shenzhen 467 China 469 Email: hejia@huawei.com 471 Italo Busi 472 Huawei Technologies 474 Email: italo.busi@huawei.com 475 Jeong-dong Ryoo 476 ETRI 477 218 Gajeongno 478 Yuseong-gu, Daejeon 34129 479 South Korea 481 Phone: +82-42-860-5384 482 Email: ryoo@etri.re.kr 484 Bin Yeong Yoon 485 ETRI 487 Email: byyun@etri.re.kr 489 Peter Park 490 KT 492 Email: peter.park@kt.com