idnits 2.17.1 draft-ietf-teas-gmpls-signaling-smp-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4872, updated by this document, for RFC5378 checks: 2004-04-06) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2022) is 709 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 530, but not defined == Missing Reference: 'B' is mentioned on line 273, but not defined == Missing Reference: 'C' is mentioned on line 273, but not defined == Missing Reference: 'D' is mentioned on line 530, but not defined == Missing Reference: 'H' is mentioned on line 532, but not defined == Missing Reference: 'I' is mentioned on line 273, but not defined == Missing Reference: 'J' is mentioned on line 273, but not defined == Missing Reference: 'K' is mentioned on line 532, but not defined == Missing Reference: 'E' is mentioned on line 532, but not defined == Missing Reference: 'F' is mentioned on line 532, but not defined == Missing Reference: 'G' is mentioned on line 532, but not defined == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 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 Updates: 4872, 4873 (if approved) Huawei Technologies 5 Intended status: Standards Track J. Ryoo 6 Expires: October 21, 2022 B. Yoon 7 ETRI 8 P. Park 9 KT 10 April 19, 2022 12 GMPLS Signaling Extensions for Shared Mesh Protection 13 draft-ietf-teas-gmpls-signaling-smp-12 15 Abstract 17 ITU-T Recommendation G.808.3 defines the generic aspects of a Shared 18 Mesh Protection (SMP) mechanism, where the difference between SMP and 19 Shared Mesh Restoration (SMR) is also identified. ITU-T 20 Recommendation G.873.3 defines the protection switching operation and 21 associated protocol for SMP at the Optical Data Unit (ODU) layer. 22 RFC 7412 provides requirements for any mechanism that would be used 23 to implement SMP in a Multi-Protocol Label Switching - Transport 24 Profile (MPLS-TP) network. 26 This document updates RFC 4872 and RFC 4873 to provide the extensions 27 to the Generalized Multi-Protocol Label Switching (GMPLS) signaling 28 to support the control of the SMP. 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 October 21, 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 Revised 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 Revised BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 78 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5 80 5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6 81 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 82 5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 83 5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 84 5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 8 85 5.5. Notifying Availability of Shared Resources . . . . . . . 8 86 5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 9 87 6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 10 88 6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 10 89 6.2. Updates on Notification and Operational Bits . . . . . . 10 90 6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 11 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 11.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol 103 - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration 104 (SMR) mechanisms. SMR can be seen as a particular case of pre- 105 planned Label Switched Path (LSP) rerouting that reduces the recovery 106 resource requirements by allowing multiple protecting LSPs to share 107 common link and node resources. The recovery resources for the 108 protecting LSPs are pre-reserved during the provisioning phase, and 109 explicit restoration signaling is required to activate (i.e., commit 110 resource allocation at the data plane) a specific protecting LSP that 111 was instantiated during the provisioning phase. RFC 4873 [RFC4873] 112 details the encoding of the last 32-bit Reserved field of the 113 PROTECTION object defined in [RFC4872] 115 ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of 116 a shared mesh protection (SMP) mechanism, which are not specific to a 117 particular network technology in terms of architecture types, 118 preemption principle, and path monitoring methods, etc. ITU-T 119 Recommendation G.873.3 [G873.3] defines the protection switching 120 operation and associated protocol for SMP at the Optical Data Unit 121 (ODU) layer. RFC 7412 [RFC7412] provides requirements for any 122 mechanism that would be used to implement SMP in a Multi-Protocol 123 Label Switching - Transport Profile (MPLS-TP) network. 125 SMP differs from SMR in the activation/protection switching 126 operation. The former activates a protecting LSP via the automatic 127 protection switching (APS) protocol in the data plane when the 128 working LSP fails, while the latter does it via control plane 129 signaling. It is therefore necessary to distinguish SMP from SMR 130 during provisioning so that each node involved behaves appropriately 131 in the recovery phase when activation of a protecting LSP is done. 132 SMP has advantages with regard to the recovery speed compared with 133 SMR. 135 This document updates [RFC4872] and [RFC4873] to provide the 136 extensions to the Generalized Multi-Protocol Label Switching (GMPLS) 137 signaling to support the control of the SMP mechanism. Specifically, 138 it; 140 o defines a new LSP protection type, "Shared Mesh Protection," for 141 the LSP Flags field [RFC4872] of the PROTECTION object (see 142 Section 6.1), 144 o updates the definitions of the Notification (N) and Operational 145 (O) fields [RFC4872] of the PROTECTION object to take the new SMP 146 type into account (see Section 6.2), and 148 o updates the definition of the 16-bit Reserved field [RFC4873] of 149 the PROTECTION object to allocate 8 bits to signal the SMP 150 preemption priority (see Section 6.3). 152 Only the generic aspects for signaling SMP are addressed by this 153 document. The technology-specific aspects are expected to be 154 addressed by other documents. 156 RFC 8776 [RFC8776] defines a collection of common YANG data types for 157 Traffic Engineering (TE) configuration and state capabilities. It 158 defines several identities for LSP protection types. As this 159 document introduces a new LSP Protection Type, [RFC8776] is expected 160 to be updated to support the SMP specified in this document. 161 [I-D.ietf-teas-yang-te] defines a YANG data model for the 162 provisioning and management of TE tunnels, LSPs, and interfaces. It 163 includes some protection and restoration data nodes relevant to this 164 document. Management aspects of the SMP are outside the scope of 165 this document, and they are expected to be addressed by other 166 documents. 168 2. Conventions Used in This Document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 In addition, the reader is assumed to be familiar with the 177 terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 178 [RFC6372]. 180 3. SMP Definition 182 [G808.3] defines the generic aspects of an SMP mechanism. [G873.3] 183 defines the protection switching operation and associated protocol 184 for SMP at the ODU layer. [RFC7412] provides requirements for any 185 mechanism that would be used to implement SMP in a MPLS-TP network. 187 The SMP mechanism is based on pre-computed protecting LSPs that are 188 pre-configured into the network elements. Pre-configuration here 189 means pre-reserving resources for the protecting LSPs without 190 activating a particular protecting LSP (e.g., in circuit networks, 191 the cross-connects in the intermediate nodes of the protecting LSP 192 are not pre-established). Pre-configuring but not activating 193 protecting LSPs allows link and node resources to be shared by the 194 protecting LSPs of multiple working LSPs (that are themselves 195 disjoint and thus unlikely to fail simultaneously). Protecting LSPs 196 are activated in response to failures of working LSPs or operator's 197 commands by means of the APS protocol that operates in the data 198 plane. The APS protocol messages are exchanged along the protecting 199 LSP. SMP is always revertive. 201 SMP has a lot of similarity to SMR except that the activation in case 202 of SMR is achieved by control plane signaling during the recovery 203 operation, while SMP is done by the APS protocol in the data plane. 205 4. Operation of SMP with GMPLS Signaling Extension 207 Consider the following network topology: 209 A---B---C---D 210 \ / 211 E---F---G 212 / \ 213 H---I---J---K 215 Figure 1: An example of SMP topology 217 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the 218 protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 219 3209 [RFC3209], in order to achieve resource sharing during the 220 signaling of these protecting LSPs, they MUST have the same Tunnel 221 Endpoint Address (as part of their SESSION object). However, these 222 addresses are not the same in this example. Similar to SMR, this 223 document defines a new LSP Protection Type of the secondary LSP as 224 "Shared Mesh Protection" (see Section 6.1) to allow resource sharing 225 along nodes E, F, and G. Examples of shared resources include the 226 capacity of a link and the cross-connects in a node. In this case, 227 the protecting LSPs are not merged (which is useful since the paths 228 diverge at G), but the resources along E, F, G can be shared. 230 When a failure, such as Signal Fail (SF) and Signal Degrade (SD), 231 occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 232 end node (say node A) that detects the failure initiates the 233 protection switching operation. End node A will send a protection 234 switching request APS message (for example, SF) to its adjacent 235 (downstream) intermediate node (say node E) to activate the 236 corresponding protecting LSP and will wait for a confirmation message 237 from node E. 239 If the protection resource is available, node E will send the 240 confirmation APS message to the end node A and forward the switching 241 request APS message to its adjacent (downstream) node (say node F). 242 When the confirmation APS message is received by node A, the cross- 243 connection on node A is established. At this time traffic is bridged 244 to and selected from the protecting LSP at node A. After forwarding 245 the switching request APS message, node E will wait for a 246 confirmation APS message from node F, which triggers node E to set up 247 the cross-connection for the protecting LSP being activated. 249 If the protection resource is not available (due to failure or being 250 used by higher priority connections), the switching will not be 251 successful; the intermediate node (node E) MUST send a message to 252 notify the end node (node A) (see Section 5.5). If the resource is 253 in use by a lower priority protecting LSP, the lower priority service 254 will be removed and then the intermediate node will follow the 255 procedure as described for the case when the protection resource is 256 available for the higher priority protecting LSP. 258 If node E fails to allocate the protection resource, it MUST send a 259 message to notify node A (see Section 5.5). Then, node A will stop 260 bridging and selecting traffic to/from the protecting LSP and proceed 261 with the procedure of removing the protection allocation according to 262 the APS protocol. 264 5. GMPLS Signaling Extension for SMP 266 The following subsections detail how LSPs using SMP can be signaled 267 in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 268 3473 [RFC3473]). This signaling enables: 270 (1) the ability to identify a "secondary protecting LSP" (LSP 271 [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the 272 "secondary LSP") used to recover another "primary working LSP" 273 (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the 274 "protected LSP"), 276 (2) the ability to associate the secondary LSP with the protected 277 LSP, 279 (3) the capability to include information about the resources used 280 by the protected LSP while instantiating the secondary LSP, 282 (4) the capability to instantiate during the provisioning phase 283 several secondary LSPs efficiently, and 285 (5) the capability to support activation of a secondary LSP after 286 failure occurrence via APS protocol in the data plane. 288 5.1. Identifiers 290 To simplify association operations, both LSPs (i.e., the protected 291 and the secondary LSPs) belong to the same session. Thus, the 292 SESSION object MUST be the same for both LSPs. The LSP ID, however, 293 MUST be different to distinguish between the protected LSP and the 294 secondary LSP. 296 A new LSP Protection Type "Shared Mesh Protection" is defined (see 297 Section 6.1) for the LSP Flags of PROTECTION object (see [RFC4872]) 298 to set up the two LSPs. This LSP Protection Type value is applicable 299 only to bidirectional LSPs as required in [G808.3]. 301 5.2. Signaling Primary LSPs 303 The PROTECTION object (see [RFC4872]) is included in the Path message 304 during signaling of the primary working LSPs, with the LSP Protection 305 Type value set to "Shared Mesh Protection". 307 Primary working LSPs are signaled by setting in the PROTECTION object 308 the S bit to 0, the P bit to 0, and the N bit to 1, and in the 309 ASSOCIATION object, the Association ID to the associated secondary 310 protecting LSP_ID. 312 Note: N bit is set to indicate that the protection switching 313 signaling is done via data plane. 315 5.3. Signaling Secondary LSPs 317 The PROTECTION object (see [RFC4872]) is included in the Path message 318 during signaling of the secondary protecting LSPs, with the LSP 319 Protection Type value set to "Shared Mesh Protection". 321 Secondary protecting LSPs are signaled by setting in the PROTECTION 322 object the S bit, the P bit, and the N bit to 1, and in the 323 ASSOCIATION object, the Association ID to the associated primary 324 working LSP_ID, which MUST be known before signaling of the secondary 325 LSP. Moreover, the Path message used to instantiate the secondary 326 LSP MUST include at least one PRIMARY_PATH_ROUTE object (see 327 [RFC4872]) that further allows for recovery resource sharing at each 328 intermediate node along the secondary path. 330 With this setting, the resources for the secondary LSP MUST be pre- 331 reserved, but not committed at the data plane level, meaning that the 332 internals of the switch need not be established until explicit action 333 is taken to activate this LSP. Activation of a secondary LSP and 334 protection switching to the activated protecting LSP is done using 335 APS protocol in the data plane. 337 After protection switching completes the protecting LSP MUST be 338 signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION 339 object. At this point, the link and node resources MUST be allocated 340 for this LSP that becomes a primary LSP (ready to carry traffic). 341 The formerly working LSP MAY be signaled with the A bit set in the 342 ADMIN_STATUS object (see [RFC3473]). 344 Support for extra traffic in SMP is for further study. Therefore, 345 mechanisms to set up LSPs for extra traffic are outside the scope of 346 this document. 348 5.4. SMP Preemption Priority 350 The SMP preemption priority of a protecting LSP that the APS protocol 351 uses to resolve the competition for shared resources among multiple 352 protecting LSPs, is indicated in Preemption Priority field of the 353 PROTECTION object in the Path message of the protecting LSP. 355 The Setup and Holding priorities in the SESSION_ATTRIBUTE object can 356 be used by GMPLS to control LSP preemption, but, they are not used by 357 the APS to resolve the competition among multiple protecting LSPs. 358 This avoids the need to define a complex policy for defining Setup 359 and Holding priorities when used for both GMPLS control plane LSP 360 preemption and SMP shared resource competition resolution. 362 When an intermediate node on the protecting LSP receives the Path 363 message, the priority value in the Preemption Priority field MUST be 364 stored for that protecting LSP. When resource competition among 365 multiple protecting LSPs occurs, the APS protocol will use their 366 priority values to resolve the competition. A lower value has a 367 higher priority. 369 In SMP, a preempted LSP MUST NOT be terminated even after its 370 resources have been deallocated. Once the working LSP and the 371 protecting LSP are configured or pre-configured, the end node MUST 372 keep refreshing both working and protecting LSPs regardless of 373 failure or preempted situation. 375 5.5. Notifying Availability of Shared Resources 377 When a lower priority protecting LSP is preempted, the intermediate 378 node that performed preemption MUST send a Notify message with error 379 code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared 380 resources unavailable" (TBA1) to the end nodes of that protecting 381 LSP. Upon receipt of this Notify message, the end node MUST stop 382 sending and selecting traffic to/from its protecting LSP and try 383 switching the traffic to another protecting LSP, if available. 385 When a protecting LSP occupies the shared resources and they become 386 unavailable, the same Notify message MUST be generated by the 387 intermediate node to all the end nodes of the protecting LSPs that 388 have lower SMP preemption priorities than the one that has occupied 389 the shared resources. In case the shared resources become 390 unavailable due to a failure in the shared resources, the same Notify 391 message MUST be generated by the intermediate node to all the end 392 nodes of the protecting LSPs that have been configured to use the 393 shared resources. These end nodes, in case of a failure of the 394 working LSP, MUST avoid trying to switch traffic to these protecting 395 LSPs that have been configured to use the shared resources and try 396 switching the traffic to other protecting LSPs, if available. 398 When the shared resources become available, a Notify message with 399 error code "Notify Error" (25) and error sub-code "Shared resources 400 available" (TBA2) MUST be generated by the intermediate node. The 401 recipients of this Notify message are the end nodes of the lower 402 priority protecting LSPs that have been preempted and/or all the end 403 nodes of the protecting LSPs that have lower SMP preemption 404 priorities than the one that does not need the shared resources 405 anymore. Upon receipt of this Notify message, the end node is 406 allowed to reinitiate the protection switching operation as described 407 in Section 4, if it still needs the protection resource. 409 5.6. SMP APS Configuration 411 SMP relies on APS protocol messages being exchanged between the nodes 412 along the path to activate an SMP protecting LSP. 414 In order to allow the exchange of APS protocol messages, an APS 415 channel has to be configured between adjacent nodes along the path of 416 the SMP protecting LSP. This is done by other means than GMPLS 417 signaling, before any SMP protecting LSP has been set up. Therefore, 418 there are likely additional requirements for APS configuration which 419 are outside the scope of this document. 421 Depending on the APS protocol message format, the APS protocol may 422 use different identifiers than GMPLS signaling to identify the SMP 423 protecting LSP. 425 Since APS protocol is for further study in [G808.3], it can be 426 assumed that APS message format and identifiers are technology- 427 specific and/or vendor-specific. Therefore, additional requirements 428 for APS configuration are outside the scope of this document. 430 6. Updates to PROTECTION Object 432 GMPLS extension requirements for SMP introduce several updates to the 433 Protection Object (see [RFC4872]). 435 6.1. New Protection Type 437 A new LSP protection type "Shared Mesh Protection" is added in the 438 PROTECTION object. This LSP Protection Type value is applicable to 439 only bidirectional LSPs. 441 LSP (Protection Type) Flags: 443 0x20: Shared Mesh Protection 445 The rules defined in Section 14.2 of [RFC4872] ensure that all the 446 nodes along an SMP LSP are SMP aware. Therefore, there are no 447 backward compatibility issues. 449 6.2. Updates on Notification and Operational Bits 451 The definitions of the N and O bits in Section 14.1 of [RFC4872] are 452 replaced as follows: 454 Notification (N): 1 bit 456 When set to 1, this bit indicates that the control plane message 457 exchange is only used for notification during protection 458 switching. When set to 0 (default), it indicates that the control 459 plane message exchanges are used for protection-switching 460 purposes. The N bit is only applicable when the LSP Protection 461 Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 462 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional 463 Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be 464 set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set 465 to 1. 467 Operational (O): 1 bit 469 When set to 1, this bit indicates that the protecting LSP is 470 carrying traffic after protection switching. The O bit is only 471 applicable when the P bit is set to 1, and the LSP Protection Type 472 Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 473 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), 474 or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in 475 any other case. 477 6.3. Preemption Priority 479 [RFC4872] reserved a 32-bit field in the PROTECTION object header. 480 Subsequently, [RFC4873] allocated several fields from that field, and 481 left the remainder of the bits reserved. This specification further 482 allocates the preemption priority field from those formerly-reserved 483 bits. The 32-bit field in the PROTECTION object defined in [RFC4873] 484 are updated as follows: 486 0 1 2 3 487 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |I|R| Reserved | Seg.Flags | Reserved | Preempt Prio | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Preemption Priority (Preempt Prio): 8 bit 494 This field indicates the SMP preemption priority of a protecting 495 LSP, when the LSP Protection Type field indicates "Shared Mesh 496 Protection". The SMP preemption priority value is configured at 497 the end nodes of the protecting LSP by a network operator. A 498 lower value has a higher priority. The decision of how many 499 priority levels to be operated in an SMP network is a network 500 operator's choice. 502 See [RFC4873] for the definition of other fields. 504 7. IANA Considerations 506 IANA maintains a registry called "Resource Reservation Protocol 507 (RSVP) Parameters" with a subregistry called "Error Codes and 508 Globally-Defined Error Value Sub-Codes". Within this subregistry 509 there is a definition of the "Notify Error" error code (25). The 510 definition lists a number of error value sub-codes that may be used 511 with this error code. IANA is requested to allocate further error 512 value sub-codes for use with this error code as described in this 513 document. 515 Value Description Reference 516 ----- ---------------------------- --------------- 517 TBA1 Shared resources unavailable (this document) 518 TBA2 Shared resources available (this document) 520 8. Security Considerations 522 Since this document makes use of the exchange of RSVP messages 523 including a Notify message, the security threats discussed in 524 [RFC4872] also apply to this document. 526 Additionally, it may be possible to cause disruption to traffic on 527 one protecting LSP by targeting a link used by the primary LSP of 528 another, higher priority LSP somewhere completely different in the 529 network. For example, in Figure 1, assume that the preemption 530 priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] 531 and the protecting LSP [H,E,F,G,K] is being used to transport 532 traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be 533 disrupted. For this reason, it is important not only to use security 534 mechanisms as discussed in [RFC4872] but also to acknowledge that 535 detailed knowledge of a network's topology, including routes and 536 priorities of LSPs, can help an attacker better target or improve the 537 efficacy of an attack. 539 9. Acknowledgements 541 The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram, 542 Tom Petch, Ines Robles, John Scudder, Dale Worley, Dan Romascanu, 543 Eric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert, Francesca 544 Palombini, and Robert Wilton for their valuable comments and 545 suggestions on this document. 547 10. Contributor 549 The following person contributed significantly to the content of this 550 document and should be considered as a co-author. 552 Yuji Tochio 553 Fujitsu 554 Email: tochio@fujitsu.com 556 11. References 558 11.1. Normative References 560 [G808.3] International Telecommunication Union, "Generic protection 561 switching - Shared mesh protection", ITU-T Recommendation 562 G.808.3, October 2012. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 570 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 571 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 572 . 574 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 575 Switching (GMPLS) Signaling Resource ReserVation Protocol- 576 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 577 DOI 10.17487/RFC3473, January 2003, 578 . 580 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 581 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 582 Recovery Functional Specification", RFC 4426, 583 DOI 10.17487/RFC4426, March 2006, 584 . 586 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 587 Ed., "RSVP-TE Extensions in Support of End-to-End 588 Generalized Multi-Protocol Label Switching (GMPLS) 589 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 590 . 592 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 593 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 594 May 2007, . 596 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 597 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 598 May 2017, . 600 11.2. Informative References 602 [G873.3] International Telecommunication Union, "Optical transport 603 network - Shared mesh protection", ITU-T Recommendation 604 G.873.3, September 2017. 606 [I-D.ietf-teas-yang-te] 607 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 608 and O. G. D. Dios, "A YANG Data Model for Traffic 609 Engineering Tunnels, Label Switched Paths and Interfaces", 610 draft-ietf-teas-yang-te-29 (work in progress), February 611 2022. 613 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 614 Profile (MPLS-TP) Survivability Framework", RFC 6372, 615 DOI 10.17487/RFC6372, September 2011, 616 . 618 [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 619 Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) 620 Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, 621 December 2014, . 623 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 624 "Common YANG Data Types for Traffic Engineering", 625 RFC 8776, DOI 10.17487/RFC8776, June 2020, 626 . 628 Authors' Addresses 630 Jia He 631 Huawei Technologies 632 F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District 633 Shenzhen 634 China 636 Email: hejia@huawei.com 638 Italo Busi 639 Huawei Technologies 641 Email: italo.busi@huawei.com 643 Jeong-dong Ryoo 644 ETRI 645 218 Gajeongno 646 Yuseong-gu, Daejeon 34129 647 South Korea 649 Phone: +82-42-860-5384 650 Email: ryoo@etri.re.kr 652 Bin Yeong Yoon 653 ETRI 655 Email: byyun@etri.re.kr 657 Peter Park 658 KT 660 Email: peter.park@kt.com