idnits 2.17.1 draft-lin-teas-gmpls-proactive-protection-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: ---------------------------------------------------------------------------- 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 -- The document date (March 9, 2020) is 1510 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4426' is defined on line 650, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Yi Lin 2 Internet Draft Huawei Technologies 3 Intended status: Standards Track Bin Yeong Yoon 4 ETRI 5 Expires: September 2020 March 9, 2020 7 RSVP-TE Extensions in Support of Proactive Protection 8 draft-lin-teas-gmpls-proactive-protection-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 9, 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 This document describes protocol-specific procedures and extensions 51 for Generalized Multi-Protocol Label Switching (GMPLS) Resource 52 ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to 53 support Label Switched Path (LSP) Proactive Protection, which create 54 the protecting LSP after a failure is predicted and before it 55 becomes a real failure. 57 Table of Contents 59 1. Introduction .................................................. 2 60 2. Conventions used in this document ............................. 3 61 3. Overview of Predicted Failure and Related Recovery Methods .... 3 62 3.1. Predicted Failure ........................................ 3 63 3.2. Proactive Protection ..................................... 4 64 4. Modified PROTECTION Object Format ............................. 6 65 5. Extension to ERROR_SPEC Object ................................ 7 66 5.1. New Error Code / Sub-code ................................ 7 67 5.2. New TLVs in ERROR_SPEC Object ............................ 7 68 6. End-to-end Proactive Protection ............................... 8 69 6.1. Creation of the Protected LSP ............................ 8 70 6.2. Notification of Predicted Failure Event .................. 9 71 6.3. Tearing Down of the Protecting LSP ....................... 9 72 7. Proactive Segment Protection ................................. 10 73 7.1. Creation of the Protected LSP ........................... 10 74 7.2. Notification of Predicted Failure Event ................. 11 75 7.3. Tearing Down of the Segment Recovery LSP ................ 12 76 7.4. Priority and Resource Pre-emption ....................... 12 77 8. Consideration of Backward Compatibility ...................... 14 78 9. Security Considerations ...................................... 14 79 10. IANA Considerations.......................................... 14 80 11. References .................................................. 14 81 11.1. Normative References ................................... 14 82 11.2. Informative References ................................. 15 83 12. Authors' Addresses .......................................... 15 85 1. Introduction 87 [RFC4872] and [RFC4873] describe protocol-specific procedures and 88 extensions for GMPLS RSVP-TE signaling to support end-to-end LSP 89 recovery (including protection and restoration) and segment LSP 90 recovery, respectively. 92 Traditional protection solution (e.g., 1+1 or 1:1 protection) could 93 have very fast protection switch after failure happens, but takes 94 twice of resource in the network during the whole lifetime of the 95 LSP. On the other hand, the traditional restoration solution has 96 much higher resource use, but the recovery of the LSP is much 97 slower, due to the additional signaling time to create the 98 restoration LSP. 100 In order to reduce the recovery resource while keeping the very fast 101 protection switch, an approach is to use the failure prediction 102 technologies and to create 1+1 or 1:1 protection only when a 103 potential failure is predicted. This approach refers to "Proactive 104 Protection" in this document. 106 This document extends the RSVP-TE protocol to support the control of 107 the Proactive Protection. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Overview of Predicted Failure and Related Recovery Methods 119 3.1. Predicted Failure 121 In most cases, there will be some indications before a physical 122 failure happens in a network. For example, abnormal fluctuation of 123 noise of a lightpath, BER (Bit Error Rate) (before error correction) 124 rising, temperature rising of a transponder. 126 Therefore, by monitoring on certain physical parameters and 127 analyzing the change tendency using, for example, Machine Learning 128 (ML) or other technologies, a node is possible to predict whether 129 failure will happen in an upcoming period of time. 131 Note that a predicted failure is different from a Signal Degrade in 132 that: 134 - When Signal Degrade happens to a connection, the connection is 135 still available but the quality of the signal carried by this 136 connection has declined and is lower than the predetermined 137 threshold. For example, the BER of a connection rises and is out 138 of tolerance. 140 - When a predicted failure of a connection is inferred, no failure 141 nor degradation happens at present, but there is a trend that 142 after a period of time, failure will probably happen, which will 143 cause Signal Fail or Signal Degrade. 145 The methods to predict failures are outside the scope of this 146 document. 148 3.2. Proactive Protection 150 The "Proactive Protection" refers to an LSP protection approach 151 which create the protecting LSP after a failure is predicted and 152 before it becomes a real failure. Both end-to-end protection 153 (defined in [RFC4872] and segment protection (defined in [RFC4873]) 154 are applicable for the Proactive Protection. 156 The main procedure of Proactive Protection is shown in Figure 1: 158 |-> Predicted failure detected 159 | |-> Proactive Protecting path created 160 | | |-> Real failure happens, triggering 161 | | | protection switch 162 | | | 163 | | | |-> Protection switch finished 164 | | t3 | | 165 ---?---+********+******X*+===================================> t 166 t1 t2 | t4 t5 167 | 168 |-->Prediction: failure will happen after t3 170 Case 1: Predicted failure happens as predicted 172 |-> Predicted failure detected 173 | |-> Proactive Protecting path created 174 | | 175 | | Predicted failure disappeared 176 | | i.e., the predicted failure <-| 177 | | will not become real failure | |-> Protecting 178 | | | | path deleted 179 | | t3 | | 180 ---?---+********+**************************O***+-------------> t 181 t1 t2 | t6 t7 182 | 183 |-->Prediction: failure will happen after t3 185 Case 2: Predicted failure disappeared and will not happen 187 ?: Predicted failure 188 X: Real failure happen 189 O: Predicted failure disappeared 190 ----: No protecting path 191 ****: protecting path created, traffic carried by protected path 192 ====: protecting path created, traffic carried by protecting path 194 Figure 1: Overview of Proactive Protection 196 - t1: The protection source node of an LSP is notified that a 197 failure will probably happen after t3, so it starts to create 1+1 198 or 1:1 protection of the connection. Here the protection source 199 node can be the source node of the LSP (for end-to-end protection 200 case), or a branch node located between the source node and the 201 predicted failure point of the LSP (for segment protection case). 203 - t2: The 1+1 or 1:1 protecting path is created between the 204 protection source node and the protection destination node. Here 205 the protection destination node can be the destination node of the 206 LSP (for end-to-end protection case), or a merge node located 207 between the predicted failure point and the destination node of 208 the LSP (for segment protection case). 210 Note that at t2, since there is no real failure or signal 211 degradation happened, the protection switch will not be triggered, 212 and the traffic still remains in the protected path. 214 - t4: If real failure happens as predicted, the 1+1 or 1:1 215 protection switch will be triggered. 217 - t5: Protection switch finished and the traffic is now switched to 218 the protecting path. 220 - The intermediate node, which detected the predicted failure, will 221 continue to monitor the change tendency of the related physical 222 parameters to make further prediction before the predicted failure 223 becomes a real failure. If, at t6, the intermediate node finds 224 that the change tendency causing the predicted failure disappeared 225 and the status is stable enough, i.e., the intermediate node 226 confirms that the predicted failure will not become real failure, 227 it MAY send another notification to clear the predicted failure. 228 In this case, the protection source node MAY decide to tear down 229 the protecting path at t7 after t6, in order to save the network 230 resource. 232 4. Modified PROTECTION Object Format 234 This document modifies the PROTECTION object (C-Type=2) by adding 235 two new bits T and A in reserved fields, as shown in Figure 2 below: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Length | Class-Num(37) | C-Type (2) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |S|P|N|O|T| Res. | LSP Flags | Reserved | Link Flags| 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |I|R|A| Reserved | Seg.Flags | Reserved | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: The modified PROTECTION object (C-Type=2) 249 - T (Triggered End-to-end Proactive Protection): 1 bit, when set 250 (1), it indicates that the end-to-end Proactive Protection are 251 required. 253 Note that if T bit is set (1), the LSP Flags SHOULD be one of: 254 0x04 1:N Protection with Extra-Traffic 255 0x08 1+1 Unidirectional Protection 256 0x10 1+1 Bidirectional Protection 258 - A (proActive Segment Protection): 1 bit, when set (1), it 259 indicates that the Proactive Segment Protection are required. 261 Note that If A bit is set (1), the Seg. Flags SHOULD be one of: 262 0x04 1:N Protection with Extra-Traffic 263 0x08 1+1 Unidirectional Protection 264 0x10 1+1 Bidirectional Protection 266 See [RFC4872] and [RFC4873] for the definition of other fields. 268 5. Extension to ERROR_SPEC Object 270 5.1. New Error Code / Sub-code 272 Two new Error Sub-codes under Error Code "25 - Notify Error" are 273 defined in this document, which are used to notify the event of a 274 predicted failure and the event of disappearance of the previous 275 predicted failure: 277 Error Code = 25: "Notify Error" (see [RFC3209]) 279 Error Sub-code = TBA1: "Notify Error/LSP Local Predicted Failure" 281 Error Sub-code = TBA2: "Notify Error/LSP Local Predicted Failure 282 disappeared" 284 5.2. New TLVs in ERROR_SPEC Object 286 When predicting a failure, a certain time before which the failure 287 may happen may also be predicted. This time information is useful 288 for the source node to know how long it should wait for the 289 predicted failure to become a real failure, and to decide when it's 290 safe to tear down the protecting LSP if the predicted failure didn't 291 happen. 293 A new TLV in IPv4/IPv6 IF_ID ERROR_SPEC Object is defined in this 294 document, which is used to indicate the time before which the 295 predicted failure will probably become real failure. The format of 296 this new TLV is shown in Figure 3 below: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = TBA3 | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Predicted Failure ID | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 305 | Cause of the Predicted Failure | 306 ~ | Padding Bits ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: New TLV (type=TBA3) in ERROR_SPEC Object 311 - Type: TBA3 313 - Length: variable and MUST be equal or greater than 8, the total 314 length of the whole TLV in Byte, including the Type and Length 315 fields. 317 - Predicted Failure ID: an ID to identify the predicted failure, 318 which is unique within the scope of the node predicting the 319 failure. 321 - Cause of the Predicted Failure: the cause of the predicted failure 322 in text format. It SHOULD be a string of printable ASCII 323 characters, without a NULL terminator. This field is optional. If 324 there is no information for this field, the padding bits (16 bits) 325 will be filled immediately after the "Predicted Failure ID" field. 327 - Padding Bits: Added after the "Cause of the Predicted Failure" 328 field to make the whole TLV a multiple of four bytes if necessary. 329 Padding bits MUST be set to 0 and MUST be ignored on receipt. 331 Another new TLV in IPv4/IPv6 IF_ID ERROR_SPEC Object is defined in 332 this document, which is used to indicate the disappearance of the 333 previous predicted failure. The format of this new TLV is shown in 334 Figure 4 below: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type = TBA4 | Length = 8 | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Predicted Failure ID | Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 4: New TLV (type=TBA4) in ERROR_SPEC Object 346 - Type: TBA4 348 - Length: 8. 350 - Predicted Failure ID: the ID of the previous predicted failure 351 which is now disappeared. 353 - Reserved: MUST be zero. 355 6. End-to-end Proactive Protection 357 6.1. Creation of the Protected LSP 359 To create an LSP with recovery type of "End-to-end Proactive 360 Protection", the source node of the LSP generates a Path message 361 with a PROTECTION object included. The T bit in the PROTECTION 362 object MUST be set to 1 (End-to-end Proactive Protection), so that 363 all other nodes along the LSP can start the failure prediction 364 function on related links/nodes. 366 Note that the N bit in the PROTECTION object is used to indicate 367 whether the control plane message exchange is only used for 368 notification or for protection-switching purpose after real failure 369 happens, see [RFC4872]. In other words, the N bit have nothing to do 370 with the notification of a predicted failure before real failure 371 happens. 373 To allow the notification of predicted failure event to the source 374 node by the Notify message, the NOTIFY REQUEST object MUST also be 375 included in the Path message (see [RFC3473]), where the "Notify Node 376 Address" SHOULD be the address of the source node of the LSP. 378 6.2. Notification of Predicted Failure Event 380 When an intermediate node on an LSP infers that a failure will 381 happen and will affect the LSP, a Notify message will be sent to the 382 source node of the LSP, to inform such predicted failure event. A 383 new error code/sub-code "Notify Error/LSP Local Predicted Failure" 384 is used in the ERROR_SPEC object or IF_ID_ERROR_SPEC object in the 385 Notify message. 387 The Notify message SHOULD include a TLV (type = TBA3) in the IPv4 or 388 IPv6 IF_ID_ERROR_SPEC object, to indicate the ID and the cause of 389 the predicted failure. 391 On receiving the Notify message with error code/sub-code "Notify 392 Error/LSP Local Predicted Failure", the source node of the LSP 393 SHOULD trigger the procedure to create the protecting LSP, according 394 to the protection type indicated in the "LSP Flags" field of the 395 PROTECTION object in the Path message for the protected LSP. The 396 procedures of creating the protecting LSP and the protection 397 switching after real failure happens are described in [RFC4872], 398 except that the T bit in the PROTECTION object of this new Path 399 message MUST set to 1. 401 The source node SHOULD also store the ID of the predicted failure 402 and create the association between this ID and the created 403 protecting LSP locally. 405 6.3. Tearing Down of the Protecting LSP 407 After sending Notify message to the source node for notifying the 408 predicted failure, the intermediate node will continue to monitor 409 the change tendency of the related physical parameters to make 410 further prediction. If it confirms that the change tendency causing 411 the predicted failure disappeared and the predicted failure will not 412 become real failure, it MAY send another Notify message with error 413 code/sub-code "Notify Error/LSP Local Predicted Failure 414 disappeared", to clear the previous predicted failure. 416 The Notify message SHOULD include a TLV (type = TBA4) in the IPv4 or 417 IPv6 IF_ID_ERROR_SPEC object, to indicate the ID of the previous 418 predicted failure which is now disappeared. The value of this ID 419 MUST equal to the one in the previous Notify message sent to the 420 source node to notify this predicted failure. 422 On receiving the Notify message with error code/sub-code "Notify 423 Error/LSP Local Predicted Failure disappeared", the source node of 424 the LSP SHOULD check if it has received the Notify message from the 425 same intermediate node before, with the same ID of the predicted 426 failure: 428 - If yes, and if the protecting LSP has already been created, the 429 source node MAY trigger the procedure to tear down the protecting 430 LSP. See [RFC4872] about the process of tearing down a protecting 431 LSP. Note that the source node MAY wait for a certain period of 432 time before tearing down the protecting LSP, according to local 433 policy. Implementations SHOULD allow this policy to be configured 434 to provide a default across all LSPs on a node, but SHOULD also 435 allow it to be configured per LSP. 437 - If no, this Notify message can be simply ignored. 439 7. Proactive Segment Protection 441 7.1. Creation of the Protected LSP 443 To create an LSP with recovery type of "Proactive Segment 444 Protection", the source node of the LSP generates a Path message, 445 where: 447 - A PROTECTION object is included, where the A bit MUST be set to 1 448 (Proactive Segment Protection), so that all nodes along the 449 protected LSP can start the failure prediction function on related 450 links/nodes if supported. The "Seg. Flags" are used to indicate 451 the protection type of the Proactive Segment Protection. 453 - One or more SERO objects MAY included (i.e., explicit Proactive 454 Segment Protection), indicating the branch node and the merge node 455 of each segment recovery LSP. If no SERO object is included, it 456 indicates that the dynamic Proactive Segment Protection method is 457 used. 459 - A NOTIFY REQUEST object is included, where the Notify Node 460 Address" SHOULD be the address of the source node of the LSP. 462 For explicit Proactive Segment Protection, when a branch node 463 receives a Path message with A bit set to 1 in the PROTECTION 464 object, the branch node follows [RFC4873] to process the Path 465 message, except that the Path message for the recovery LSP will not 466 be generated and be sent at this stage. Also, one more NOTIFY 467 REQUEST object SHOULD be added to the Path message of the protected 468 LSP, which carries the address of this branch node. 470 For dynamic Proactive Segment Protection, when an intermediate node 471 receives a Path message with A bit set to 1 in the PROTECTION 472 object, the node will determine if it has the ability to be a branch 473 node, as described in Section 6.2 of [RFC4873]. If yes, it follows 474 the same procedure as what a branch node does in the case of 475 explicit Proactive Segment Protection, as described above. If not, 476 the node only follows the standard procedure to create the protected 477 LSP. 479 7.2. Notification of Predicted Failure Event 481 When an intermediate node between a pair of branch and merge nodes 482 on an LSP infers that a failure will happen and will affect the LSP, 483 a Notify message will be sent to the nearest branch node on the 484 upstream direction of the LSP, to inform such predicted failure 485 event. The error code/sub-code "Notify Error/LSP Local Predicted 486 Failure" is used in the ERROR_SPEC object or IF_ID_ERROR_SPEC object 487 in the Notify message. 489 Similar to End-to-end Proactive Protection, the Notify message 490 SHOULD include a TLV (type = TBA3) in the IPv4 or IPv6 491 IF_ID_ERROR_SPEC object, to indicate the ID and the cause of the 492 predicted failure. 494 On receiving the Notify message with error code/sub-code "Notify 495 Error/LSP Local Predicted Failure", the branch node on the protected 496 LSP SHOULD generate a new Path message, and send this new Path 497 message along the segment recovery LSP between the branch and the 498 merge nodes. The procedures of generating new Path message and 499 creating the segment recovery LSP are the same as what is described 500 in [RFC4873], except that the A bit in the PROTECTION object of this 501 new Path message MUST set to 1. 503 The branch node SHOULD also store the ID of the predicted failure 504 and create the association between this ID and the created segment 505 recovery LSP locally. 507 7.3. Tearing Down of the Segment Recovery LSP 509 After sending Notify message to the branch node for notifying the 510 predicted failure, the intermediate node will continue to monitor 511 the change tendency of the related physical parameters to make 512 further prediction. If it confirms that the change tendency causing 513 the predicted failure disappeared and the predicted failure will not 514 become real failure, it MAY send another Notify message with error 515 code/sub-code "Notify Error/LSP Local Predicted Failure 516 disappeared", to clear the previous predicted failure. 518 The Notify message SHOULD include a TLV (type = TBA4) in the IPv4 or 519 IPv6 IF_ID_ERROR_SPEC object, to indicate the ID of the previous 520 predicted failure which is now disappeared. The value of this ID 521 MUST equal to the one in the previous Notify message sent to the 522 branch node to notify this predicted failure. 524 On receiving the Notify message with error code/sub-code "Notify 525 Error/LSP Local Predicted Failure disappeared", the branch node of 526 the LSP SHOULD check if it has received the Notify message from the 527 same intermediate node before, with the same ID of the predicted 528 failure. 530 - If yes, and if the segment recovery LSP has already been created, 531 the branch node MAY trigger the procedure to tear down the segment 532 recovery LSP. See [RFC4873] about the process of tearing down a 533 segment recovery LSP. Note that the branch node MAY wait for a 534 certain period of time before tearing down the segment recovery 535 LSP, according to local policy. Implementations SHOULD allow this 536 policy to be configured to provide a default across all LSPs on a 537 node, but SHOULD also allow it to be configured per LSP. 539 - If no, this Notify message can be simply ignored. 541 7.4. Priority and Resource Pre-emption 543 It's possible that after recovery LSP is created and before the 544 predicted failure becomes a real failure, another real failure 545 happens on the LSP outside the protected segment. In this case, the 546 source node (or an intermediate node in the upstream direction of 547 the real failure) may start a restoration procedure to recover the 548 LSP. For the same protected LSP, since recovering from a real 549 failure always has higher priority than protecting against a 550 predicted failure which still hasn't happened, the restoration LSP 551 can pre-empt the resource of the segment recovery LSP. 553 As shown in Figure 5, assume that node B (branch node) was notified 554 of a predicted failure event between N-4 and M (merge node), and has 555 created the segment recovery LSP along B, N-1, N-2, N-3 and M. If 556 another failure between S (source node) and B happens before the 557 predicted failure becomes a real failure, node S will try to create 558 the restoration LSP. Since that resource is limited, the restoration 559 LSP can pre-empt the resource of the segment recovery LSP between N- 560 1 and N-3. 562 The nodes along the segment recovery LSP has enough information to 563 determine whether pre-emption is allowed. This is because these 564 nodes know that: 566 - The current segment recovery LSP is used for Proactive Segment 567 Protection through the A bit in the PROTECTION object; 569 - The segment recovery LSP and the restoration LSP are protecting 570 the same LSP through the association relationship. 572 |<------ Pre-emption ------>| 573 | | 574 *************************************************************** 575 *+---+ +---+ +---+ +---+ +---+* 576 *| +---------+N-1+---------+N-2+---------+N-3+---------+ |* 577 *+-+-+ +-+-+ +---+ +-+-+ +-+-+* 578 * | |###########################| | * 579 * | |# #| | * 580 * | |# #| | * 581 *+-+-+ +-+-+ +---+ +-+-+ +-+-+* 582 ***| S +----X----+ B +---------+N-4+----?----+ M +---------+ D |*** 583 +---+ +---+ +---+ +---+ +---+ 584 =================================================================== 586 S: Source node D: Destination node 587 B: Branch node M: Merge node 588 X: Real failure ?: Predicted failure (haven't happened yet) 590 =====: Protected LSP 591 #####: Segment Recovery LSP 592 *****: Restoration LSP 594 Figure 5: Resource pre-emption by restoration LSP 596 8. Consideration of Backward Compatibility 598 TBD. 600 [Editor's note]: will add some description about interwork with 601 legacy nodes which do not support the function of failure prediction 602 and reporting. 604 9. Security Considerations 606 TBD. 608 10. IANA Considerations 610 IANA assigns values to RSVP protocol parameters. Within the current 611 document, two new Error code/sub-code values are defined: 613 Error Code = 25: "Notify Error" (see [RFC3209]) 615 o "Notify Error/LSP Local Predicted Failure" (TBA1) 617 o "Notify Error/LSP Local Predicted Failure disappeared" (TBA2) 619 11. References 621 11.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, DOI 625 10.17487/RFC2119, March 1997. 627 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 628 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 629 Tunnels", RFC 3209, December 2001. 631 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 632 Switching (GMPLS) Signaling Resource ReserVation Protocol- 633 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 634 January 2003. 636 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 637 Ed., "RSVP-TE Extensions in Support of End-to-End 638 Generalized Multi-Protocol Label Switching (GMPLS) 639 Recovery", RFC 4872, May 2007. 641 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 642 "GMPLS Segment Recovery", RFC 4873, May 2007. 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 646 May 2017. 648 11.2. Informative References 650 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 651 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 652 Recovery Functional Specification," RFC 4426, March 2006. 654 12. Authors' Addresses 656 Yi Lin 657 Huawei Technologies 658 H1, Huawei Xiliu Beipo Village, Songshan Lake 659 Dongguan 660 Guangdong, 523808 China 661 Email: yi.lin@huawei.com 663 Bin Yeong Yoon 664 ETRI 665 Email: byyun@etri.re.kr