idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-04.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. -- The document date (September 8, 2020) is 1288 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 181, but not defined == Missing Reference: 'B' is mentioned on line 181, but not defined == Missing Reference: 'C' is mentioned on line 181, but not defined == Missing Reference: 'D' is mentioned on line 181, but not defined == Missing Reference: 'H' is mentioned on line 169, but not defined == Missing Reference: 'I' is mentioned on line 168, but not defined == Missing Reference: 'J' is mentioned on line 168, but not defined == Missing Reference: 'K' is mentioned on line 169, but not defined == Missing Reference: 'E' is mentioned on line 169, but not defined == Missing Reference: 'F' is mentioned on line 169, but not defined == Missing Reference: 'G' is mentioned on line 169, but not defined Summary: 1 error (**), 0 flaws (~~), 13 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: March 12, 2021 J. Ryoo 6 B. Yoon 7 ETRI 8 P. Park 9 KT 10 September 8, 2020 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-04 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 March 12, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 70 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 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 documents. 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 protecting LSPs that are 137 pre-configured into the network elements. Pre-configuration here 138 means pre-reserving resources for the protecting LSPs without 139 activating a particular protecting LSP (e.g. in circuit networks, the 140 cross-connects in the intermediate nodes of the protecting LSP are 141 not pre-established). Pre-configuring but not activating a 142 protecting LSP allows the common link and node resources in the 143 protecting LSP to be shared by multiple working LSPs that are 144 physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) 145 disjoint. Protecting LSPs are activated in response to failures of 146 working LSPs or operator's commands by means of the APS protocol that 147 operates in the data plane. The APS protocol messages are exchanged 148 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 the APS protocol in the data plane. 153 SMP has advantages with regard to the recovery speed compared with 154 SMR. 156 4. GMPLS Signaling Extension for SMP 158 Consider the following network topology: 160 A---B---C---D 161 \ / 162 E---F---G 163 / \ 164 H---I---J---K 166 Figure 1: An example of SMP topology 168 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 169 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], 170 in order to achieve resource sharing during the signaling of these 171 protecting LSPs, they must have the same Tunnel Endpoint Address (as 172 part of their SESSION object). However, these addresses are not the 173 same in this example. Similar to SMR, a new LSP Protection Type of 174 the secondary LSP is defined as "Shared Mesh Protection" (see 175 Section 5.1) to allow resource sharing along nodes E, F, and G. In 176 this case, the protecting LSPs are not merged (which is useful since 177 the paths diverge at G), but the resources along E, F, G can be 178 shared. 180 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 181 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 182 end-node (say node A) that detects the failure initiates the 183 protection switching operation. End-node A will send a protection 184 switching request APS message (for example SF) to its adjacent 185 (downstream) intermediate node (say node E) to activate the 186 corresponding protecting LSP and will wait for a confirmation message 187 from node E. If the protection resource is available, node E will 188 send the confirmation APS message to the end-node A and forward the 189 switching request APS message to its adjacent (downstream) node (say 190 node F). When the confirmation APS message is received by node A, 191 the cross-connection on node A is established. At this time the 192 traffic is bridged to and selected from the protecting LSP at node A. 193 After forwarding the switching request APS message, node E will wait 194 for a confirmation APS message from node F, which triggers node E to 195 set up the cross-connection for the protecting LSP being activated. 196 If the protection resource is not available (due to failure or being 197 used by higher priority connections), the switching will not be 198 successful; the intermediate node may send a message to notify the 199 end node, or may keep trying until the resource is available, or the 200 switching request is cancelled. If the resource is in use by a lower 201 priority protecting LSP, the lower priority service will be removed 202 and then the intermediate node will follow the procedure as described 203 for the case when the protection resource is available for the higher 204 priority protecting LSP. 206 The SMP preemption priority of a protecting LSP that the APS protocol 207 uses to resolve the competition for shared resources among multiple 208 protecting LSPs, is indicated in the TBD1 field of the PROTECTION 209 object in the Path message of the protecting LSP. In SMP, the Setup 210 and Holding priorities in the SESSION_ATTRIBUTE object can be used to 211 configure or pre-configure a LSP, but is irrelevant to resolving the 212 competition among multiple protecting LSPs, when controlled by the 213 APS. 215 When an intermediate node on the protecting LSP receives the Path 216 message, the preemption priority value in the TBD1 field MUST be 217 stored for that protecting LSP. When resource competition among 218 multiple protecting LSPs occurs, the APS protocol will use their 219 priority values to resolve the competition. 221 [EDITOR'S NOTE: The TBD1 field for the preemption priority will be 222 defined in the next version of this draft.] 224 In SMP, a preempted LSP SHOULD not be torn down. Once the working 225 LSP and the protecting LSP are configured or pre-configured, the end 226 node SHOULD keep refreshing both working and protecting LSPs 227 regardless of failure or preempted situation. 229 When a lower priority protecting LSP is preempted, the intermediate 230 node that performed preemption MAY send a Notify message with a new 231 sub-code "Shared resources unavailable" under "Notify Error" code 232 (see [RFC4872]) to the end nodes of that protecting LSP. Upon 233 receipt of this Notify message, the end node MAY stop sending and 234 selecting normal traffic to/from its protecting LSP and try switching 235 the traffic to another protection LSP, if available. 237 When the shared resources become unavailable, the same Notify message 238 MAY also be generated by the intermediate node to all the end nodes 239 of the protecting LSPs that have lower preemption priorities than the 240 one that has occupied the shared resources. These end nodes, in case 241 of a failure of the working LSP, MAY avoid trying to switch the 242 traffic to these protection LSPs that have been configured to use the 243 shared resources and try switching the traffic to other protection 244 LSPs, if available. 246 When the shared resources become available, a Notify message with a 247 new sub-code "Shared resources available" under "Notify Error" code 248 MAY be generated by the intermediate node. The recipients of this 249 Notify message are the end nodes of the lower priority protecting 250 LSPs that have been preempted and/or all the end nodes of the 251 protecting LSPs that have lower preemption priorities than the one 252 that does not need the shared resources any more. 254 The following subsections detail how LSPs using SMP can be signaled 255 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 256 3473 [RFC3473]). This includes; 258 (1) the ability to identify a "secondary protecting LSP" (hereby 259 called the "secondary LSP") used to recover another primary 260 working LSP (hereby called the "protected LSP"), 262 (2) the ability to associate the secondary LSP with the protected 263 LSP, 265 (3) the capability to include information about the resources used 266 by the protected LSP while instantiating the secondary LSP, 268 (4) the capability to instantiate during the provisioning phase 269 several secondary LSPs in an efficient manner, and 271 (5) the capability to support activation of a secondary LSP after 272 failure occurrence via APS protocol in the data plane. 274 4.1. Identifiers 276 To simplify association operations, both LSPs (i.e., the protected 277 and the secondary LSPs) belong to the same session. Thus, the 278 SESSION object MUST be the same for both LSPs. The LSP ID, however, 279 MUST be different to distinguish between the protected LSP carrying 280 normal traffic and the secondary LSP. 282 A new LSP Protection Type "Shared Mesh Protection" is introduced to 283 the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two 284 LSPs. This LSP Protection Type value is applicable only to 285 bidirectional LSPs as required in [G808.3]. 287 4.2. Signaling Primary LSPs 289 The PROTECTION object (see [RFC4872]) is included in the Path message 290 during signaling of the primary working LSPs, with the LSP Protection 291 Type value set to "Shared Mesh Protection". 293 Primary working LSPs are signaled by setting in the PROTECTION object 294 the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION 295 object, the Association ID to the associated secondary protecting 296 LSP_ID. 298 Note: N bit is set to indicate that the protection switching 299 signaling is done via data plane. 301 4.3. Signaling Secondary LSPs 303 The PROTECTION object (see [RFC4872]) is included in the Path message 304 during signaling of the secondary protecting LSPs, with the LSP 305 Protection Type value set to "Shared Mesh Protection". 307 Secondary protecting LSPs are signaled by setting in the PROTECTION 308 object the S bit and the P bit to 1, the N bit to 1 and in the 309 ASSOCIATION object, the Association ID to the associated primary 310 working LSP_ID, which MUST be known before signaling of the secondary 311 LSP. Moreover, the Path message used to instantiate the secondary 312 LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see 313 [RFC4872]) that further allows for recovery resource sharing at each 314 intermediate node along the secondary path. 316 With this setting, the resources for the secondary LSP SHOULD be pre- 317 reserved, but not committed at the data plane level, meaning that the 318 internals of the switch need not be established until explicit action 319 is taken to activate this LSP. Activation of a secondary LSP and 320 protection switching to the activated protecting LSP is done using 321 APS protocol in the data plane. 323 After protection switching completes the protecting LSP SHOULD be 324 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 325 object. At this point, the link and node resources must be allocated 326 for this LSP that becomes a primary LSP (ready to carry normal 327 traffic). The formerly working LSP MAY be signaled with the A bit 328 set in the ADMIN_STATUS object (see [RFC3473]). 330 Support for extra traffic in SMP is for further study. Therefore, 331 mechanisms to setup LSPs for extra traffic are also for further 332 study. 334 4.4. SMP APS Configuration 336 SMP relies on APS protocol messages being exchanged between the nodes 337 along the path to activate a SMP protecting LSP. 339 In order to allow exchange of APS protocol messages, an APS channel 340 has to be configured between adjacent nodes along the path of the SMP 341 protecting LSP. This should be done before any SMP protecting LSP 342 has been setup by other means than GMPL signaling which are therefore 343 outside the scope of this document. 345 Depending on the APS protocol message format, the APS protocol may 346 use different identifiers than GMPLS signaling to identify the SMP 347 protecting LSP. 349 Since APS protocol is for further study in [G808.3], it can be 350 assumed that APS message format and identifiers are technology- 351 specific and/or vendor-specific. Therefore, additional requirements 352 for APS configuration are outside the scope of this document. 354 [EDITOR'S NOTE: Three options for APS configuration: a) out-of-scope, 355 b) define a new object whose content is vendor-specific, c) define a 356 new object with a TLV structure. The above paragraph (option a) can 357 be confirmed or modified depending on a reply LS from the ITU-T SG15. 359 5. Updates to PROTECTION Object 361 GMPLS extension requirements for SMP introduce several updates to the 362 Protection Object (see [RFC4872]). 364 5.1. New Protection Type 366 A new LSP protection type "Shared Mesh Protection" is added in the 367 protection object. This LSP Protection Type value is applicable to 368 only bidirectional LSPs. 370 LSP (Protection Type) Flags: 372 0x11: Shared Mesh Protection 374 5.2. Other Updates 376 N bit and O bit in the Protection object as defined in [RFC4872] are 377 also updated to include applicability to SMP. 379 Notification (N): 1 bit 380 When set to 1, this bit indicates that the control plane message 381 exchange is only used for notification during protection 382 switching. When set to 0 (default), it indicates that the control 383 plane message exchanges are used for protection-switching 384 purposes. The N bit is only applicable when the LSP Protection 385 Type Flag is set to either 0x04 (1:N Protection with Extra- 386 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 387 Bidirectional Protection). In SMP, N bit MUST be set to 1. The N 388 bit MUST be set to 0 in any other case. 390 Operational (O): 1 bit 392 When set to 1, this bit indicates that the protecting LSP is 393 carrying the normal traffic after protection switching. The O bit 394 is only applicable when the P bit is set to 1, and the LSP 395 Protection Type Flag is set to either 0x04 (1:N Protection with 396 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 397 (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). 398 The O bit MUST be set to 0 in any other case. 400 6. IANA Considerations 402 IANA actions required by this document will be described later. 404 7. Security Considerations 406 No further security considerations than [RFC4872]. 408 8. Contributor 410 The following person contributed significantly to the content of this 411 document and should be considered as a co-author. 413 Yuji Tochio 414 Fujitsu 415 Email: tochio@fujitsu.com 417 9. References 419 9.1. Normative References 421 [G808.3] International Telecommunication Union, "Generic protection 422 switching - Shared mesh protection", ITU-T Recommendation 423 G.08.3, October 2012. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 431 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 432 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 433 . 435 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 436 Switching (GMPLS) Signaling Resource ReserVation Protocol- 437 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 438 DOI 10.17487/RFC3473, January 2003, 439 . 441 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 442 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 443 Recovery Functional Specification", RFC 4426, 444 DOI 10.17487/RFC4426, March 2006, 445 . 447 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 448 Ed., "RSVP-TE Extensions in Support of End-to-End 449 Generalized Multi-Protocol Label Switching (GMPLS) 450 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 451 . 453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 455 May 2017, . 457 9.2. Informative References 459 [G873.3] International Telecommunication Union, "Optical transport 460 network - Shared mesh protection", ITU-T Recommendation 461 G.873.3, September 2017. 463 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 464 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 465 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 466 December 2014, . 468 Authors' Addresses 469 Jia He 470 Huawei Technologies 471 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 472 Shenzhen 473 China 475 Email: hejia@huawei.com 477 Italo Busi 478 Huawei Technologies 480 Email: italo.busi@huawei.com 482 Jeong-dong Ryoo 483 ETRI 484 218 Gajeongno 485 Yuseong-gu, Daejeon 34129 486 South Korea 488 Phone: +82-42-860-5384 489 Email: ryoo@etri.re.kr 491 Bin Yeong Yoon 492 ETRI 494 Email: byyun@etri.re.kr 496 Peter Park 497 KT 499 Email: peter.park@kt.com