idnits 2.17.1 draft-ietf-mpls-tp-psc-itu-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 (November 27, 2013) is 3804 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) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-psc-updates-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group J. Ryoo, Ed. 3 Internet-Draft ETRI 4 Updates: 6378 (if approved) E. Gray, Ed. 5 Intended status: Standards Track Ericsson 6 Expires: May 31, 2014 H. van Helvoort 7 Huawei Technologies 8 A. D'Alessandro 9 Telecom Italia 10 T. Cheung 11 ETRI 12 E. Osborne 13 Cisco Systems, Inc. 14 November 27, 2013 16 MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's 17 Requirements 18 draft-ietf-mpls-tp-psc-itu-00.txt 20 Abstract 22 This document introduces alternate ways to perform certain operations 23 defined in RFC6378, "MPLS Transport Profile (MPLS-TP) Linear 24 Protection", and also defines additional behaviors. This set of 25 modified and additional behaviors together with the protocol defined 26 in RFC6378 meets the ITU-T's protection switching requirements. 28 This document introduces capabilities and modes. A capability is an 29 individual behavior. The capabilities of a node are advertised using 30 the method given in this document. A mode is a particular 31 combination of capabilities. Two modes are defined in this document: 32 Protection State Coordination (PSC) mode and Automatic Protection 33 Switching (APS) mode. 35 This document describes the behavior of the PSC protocol including 36 priority logic and state machine when all the capabilities associated 37 with the APS mode are enabled. 39 This document updates RFC6378 in that the capability advertisement 40 method defined here is an addition to that document. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 31, 2014. 59 Copyright Notice 61 Copyright (c) 2013 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 78 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Capability 1: Priority Modification . . . . . . . . . . . . . 5 80 4.1. Motivations for swapping priorities of FS and SF-P . . . 5 81 4.2. Motivation for raising the priority of Clear SF . . . . . 6 82 4.3. Motivation for introducing Freeze command . . . . . . . . 6 83 4.4. Updates to the PSC RFC . . . . . . . . . . . . . . . . . 6 84 5. Capability 2: Modification of Non-revertive Operation . . . . 7 85 6. Capability 3: Support of Manual Switch to Working Command . . 7 86 6.1. Motivation for adding Manual Switch to Working . . . . . 7 87 6.2. Terms modified to support MS-W . . . . . . . . . . . . . 8 88 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8 89 6.4. Equal priority resolution for MS . . . . . . . . . . . . 8 90 7. Capability 4: Support of protection against Signal Degrade . 9 91 7.1. Motivation for supporting protection against Signal 92 Degrade . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 7.2. Terms modified to support SD . . . . . . . . . . . . . . 9 94 7.3. Behavior of protection against SD . . . . . . . . . . . . 9 95 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11 96 8. Capability 5: Support of Exercise Command . . . . . . . . . . 12 97 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13 98 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 13 99 9.1.1. Sending the Capabilities TLV . . . . . . . . . . . . 14 100 9.1.2. Receiving the Capabilities TLV . . . . . . . . . . . 14 101 9.1.3. Handling Capabilities TLV errors . . . . . . . . . . 15 102 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16 104 9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16 105 9.3. Backward compatibility . . . . . . . . . . . . . . . . . 16 106 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17 107 10.1. Request field in PSC protocol message . . . . . . . . . 17 108 10.2. Priorities of local inputs and remote requests . . . . . 17 109 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19 110 11.1. State transition by local inputs . . . . . . . . . . . . 21 111 11.2. State transition by remote messages . . . . . . . . . . 22 112 12. Security considerations . . . . . . . . . . . . . . . . . . . 24 113 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 114 13.1. PSC Request Field . . . . . . . . . . . . . . . . . . . 24 115 13.2. PSC TLV . . . . . . . . . . . . . . . . . . . . . . . . 25 116 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 117 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 118 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 119 15.2. Informative References . . . . . . . . . . . . . . . . . 25 120 Appendix A. An example of out-of-service scenarios . . . . . . . 26 121 Appendix B. An example of sequence diagram showing 122 the problem with the priority level of Clear SF . . 27 123 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 28 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 126 1. Introduction 128 This document introduces alternate ways to perform certain operations 129 defined in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear 130 Protection", and also defines additional behaviors. This set of 131 modified and additional behaviors together with the protocol defined 132 in [RFC6378] meets the ITU-T's protection switching requirements. 134 Alternative behaviors are defined for the following capabilities: 136 1. Priority modification, 138 2. non-revertive behavior modification, 140 and the following capabilities have been added to define additional 141 behaviors: 143 3. support of Manual Switch to Working (MS-W) command, 144 4. support of protection against Signal Degrade (SD), and 146 5. support of Exercise command. 148 Priority modification includes priority swapping between Signal Fail 149 on the Protection path (SF-P) and Forced Switch (FS), and raising the 150 priority level of Clear SF. 152 Non-revertive behavior is modified to align with the behavior defined 153 in [RFC4427] as well as to meet the ITU-T's protection switching 154 requirements. 156 Support of Manual Switch to Working (MS-W) command to revert traffic 157 to the working path in non-revertive operation is covered in this 158 document. 160 Support of protection switching protocol against Signal Degrade (SD) 161 is covered in this document. The specifics for the method of 162 identifying SD is out of the scope of this document similarly to SF 163 for [RFC6378]. 165 Support of Exercise command to test if the Protection State 166 Coordination (PSC) communication is operating correctly is also 167 covered in this document. More specifically, the Exercise tests and 168 validates the linear protection mechanism and PSC protocol including 169 the aliveness of the Local Request logic, the PSC state machine and 170 the PSC message generation and reception, and the integrity of the 171 protection path, without triggering the actual traffic switching. 173 This document introduces capabilities and modes. A capability is an 174 individual behavior, The capabilities of a node are advertised using 175 the method given in this document. A mode is a particular 176 combination of capabilities. Two modes are defined in this document: 177 PSC mode and Automatic Protection Switching (APS) mode. 179 This document describes the behavior of the PSC protocol including 180 priority logic and state machine when all the capabilities associated 181 with the APS mode are enabled. 183 This document updates [RFC6378] in that the capability advertisement 184 method defined here is an addition to that document. For an existing 185 implementation of [RFC6378], it is recommended to be updated with the 186 bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability 187 adevertisement in this document. 189 2. Conventions Used in This Document 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 3. Acronyms 196 This document uses the following acronyms: 198 APS Automatic Protection Switching 199 EXER Exercise 200 FS Forced Switch 201 LO Lockout of protection 202 MS Manual Switch 203 MS-P Manual Switch to Protection 204 MS-W Manual Switch to Working 205 MPLS-TP MPLS Transport Profile 206 NR No Request 207 OC Operator Clear 208 PSC Protection State Coordination 209 RR Reverse Request 210 SD Signal Degrade 211 SD-P Signal Degrade on the Protection path 212 SD-W Signal Degrade on the Working path 213 SF Signal Fail 214 SFc Clear Signal Fail 215 SF-P Signal Fail on the Protection path 216 SF-W Signal Fail on the Working path 217 WTR Wait to Restore 219 4. Capability 1: Priority Modification 221 In this document, the priorities of Forced Switch (FS) and Signal 222 Fail on the Protection path (SF-P) are swapped and the priority of 223 Clear SF (SFc) is raised. In addition to the priority modification, 224 this document introduces the use of a Freeze command in Appendix C. 225 The reasons for these changes are explained in the following sub- 226 sections from technical and network operational aspects. 228 4.1. Motivations for swapping priorities of FS and SF-P 230 Defining the priority of FS higher than that of Signal Fail on the 231 Protection path (SF-P) can result in a situation where the protected 232 traffic is taken out-of-service. Setting the priority of any input 233 that is supposed to be signalled to the other end to be higher than 234 that of SF-P can result in unpredictable protection switching state, 235 when the protection path has failed and consequently the PSC 236 communication stopped. An example of the out-of-service scenarios is 237 shown in Appendix A 238 According to Section 2.4 of [RFC5654] it MUST be possible to operate 239 an MPLS-TP network without using a control plane. This means that 240 external switch commands, e.g., FS, can be transferred to the far end 241 only by using the PSC communication channel and should not rely on 242 the presence of a control plane. 244 As the priority of SF-P has been higher than FS in optical transport 245 networks and Ethernet transport networks, for network operators it is 246 important that the MPLS-TP protection switching preserves the network 247 operation behavior to which network operators have become accustomed. 248 Typically, the FS command is issued before network maintenance jobs, 249 (e.g., replacing optical cables or other network components). When 250 an operator pulls out a cable on the protection path by mistake, the 251 traffic should be protected and the operator expects this behavior 252 based on his/her experience on the traditional transport network 253 operations. 255 4.2. Motivation for raising the priority of Clear SF 257 The priority level of SFc defined in [RFC6378] can cause traffic 258 disruption when a node that has experienced local signal fails on 259 both working and protection paths is recovering from these failures. 261 An example of sequence diagram showing the problem with the priority 262 level of SFc as defined in [RFC6378] is shown in Appendix B. 264 4.3. Motivation for introducing Freeze command 266 With the priority swapping between FS and SF-P, the traffic is always 267 moved back to the working path when SF-P occurs in Protecting 268 Administrative state. In the case that network operators need an 269 option to control their networks so that the traffic can remain on 270 the protection path even when the PSC communication channel is 271 broken, the Freeze command, which is a local command (i.e., not 272 signalled to the other end) can be used. The use of the Freeze 273 command is described in Appendix C. 275 4.4. Updates to the PSC RFC 277 The list of local requests in order of priority should be modified as 278 follows: 280 (from higher to lower) 282 o Clear Signal Fail/Degrade 284 o Signal Fail on the Protection path 285 o Forced Switch 287 o Signal Fail on the Working path 289 The change of the PSC control logic including state machine due to 290 this priority modification is incorporated in the PSC control logic 291 description when all the capabilities are enabled in Section 10 and 292 Section 11. 294 5. Capability 2: Modification of Non-revertive Operation 296 Non-revertive mode of protection switching is defined in [RFC4427]. 297 In this mode, the traffic does not return to the working path when 298 switch-over requests are terminated. 300 However, PSC protocol defined in [RFC6378] supports this operation 301 only when recovering from a defect condition, but does not operate as 302 non-revertive when an operator's switch-over command such as Forced 303 Switch or Manual Switch is cleared. To be aligned with legacy 304 transport network behavior and [RFC4427], a node should go into the 305 Do-not-Revert (DNR) state not only when a failure condition on a 306 working path is cleared but also when an operator command requesting 307 switch-over is cleared. 309 The change of the PSC control logic including state machine due to 310 the modification of non-revertive operation is incorporated into the 311 PSC control logic description when all the capabilities are enabled 312 in Section 10 and Section 11. 314 6. Capability 3: Support of Manual Switch to Working Command 316 6.1. Motivation for adding Manual Switch to Working 318 Changing the non-revertive operation introduces necessity of a new 319 operator command to revert traffic to the working path when in Do- 320 not-Revert (DNR) state. When the traffic is on the protection path 321 in DNR state, a Manual Switch to Working (MS-W) command is issued to 322 switch the normal traffic back to the working path. According to 323 Section 4.3.3.6 (Do-not-Revert State) in [RFC6378], "to revert back 324 to Normal state, the administrator SHALL issue a Lockout of 325 protection (LO) command followed by a Clear command." However, using 326 LO command introduces the potential risk of an unprotected situation 327 while the Lockout of protection is in effect. 329 Manual Switch-over for recovery LSP/span command, defined in 330 [RFC4427] and also defined in [RFC5654], Requirement 83, as one of 331 the mandatory external commands, should be used for this purpose, but 332 is not included in [RFC6378]. Note that the "Manual Switch-over for 333 recovery LSP/span" command is the same as MS-W command. 335 6.2. Terms modified to support MS-W 337 The term "Manual Switch" and its acronym "MS" used in [RFC6378] are 338 replaced respectively by "Manual Switch to Protection" and "MS-P" by 339 this document to avoid confusion with "Manual Switch to Working" and 340 its acronym "MS-W". 342 Also, the term "Protecting administrative state" used in [RFC6378] is 343 replaced by "Switching administrative state" by this document to 344 include the case where traffic is switched back to the working path 345 by administrative Manual Switch to Working command. 347 6.3. Behavior of MS-P and MS-W 349 The MS-P and MS-W commands SHALL have the same priority. If one of 350 these commands is already issued and accepted, and the other command 351 that is issued afterwards SHALL be ignored. If two LERs are 352 requesting opposite operations simultaneously, i.e. one LER is 353 sending MS-P while the other LER is sending MS-W, the MS-W SHALL be 354 considered to have a higher priority than MS-P, and MS-P SHALL be 355 ignored. 357 Two commands, MS-P and MS-W are represented by the same Request Field 358 value, but differentiated by the FPath value. When traffic is 359 switched to the protection path, the FPath field SHALL indicate that 360 the working path is being blocked (i.e., FPath set to 1), and the 361 Path field SHALL indicate that user data traffic is being transported 362 on the protection path (i.e., Path set to 1). When traffic is 363 switched to the working path, the FPath field SHALL indicate that the 364 protection path is being blocked (i.e., FPath set to 0), and the Path 365 field SHALL indicate that user data traffic is being transported on 366 the working path (i.e., Path set to 0). 368 6.4. Equal priority resolution for MS 370 [RFC6378] defines only one rule for equal priority condition in 371 Section 4.3.2 as "The remote message from the far-end LER is assigned 372 a priority just below the similar local input." In order to support 373 the manual switch behavior described in Section 6.3, additional rules 374 for equal priority resolution are required. Since the support of 375 protection against signal degrades also requires a similar equal 376 priority resolution, the rules are described in Section 7.4. 378 The change of the PSC control logic including state machine due to 379 the support of MS-W command is incorporated into the PSC control 380 logic description when all the capabilities are enabled in Section 10 381 and Section 11. 383 7. Capability 4: Support of protection against Signal Degrade 385 7.1. Motivation for supporting protection against Signal Degrade 387 In MPLS-TP survivability framework [RFC6372], fault conditions 388 include both Signal Fail (SF) and Signal Degrade (SD) that can be 389 used to trigger protection switching. 391 [RFC6378], which defines the Protection State Coordination (PSC) 392 protocol, does not specify how the SF and SD are declared and 393 specifies the protection switching protocol associated with SF only. 395 The protection switching protocol associated with SD is covered in 396 this document, and the specifics for the method of identifying SD is 397 out of the scope of PSC protocol similarly to how to detect SF and 398 how MS and FS commands are initiated in a management system and 399 signalled to PSC. 401 7.2. Terms modified to support SD 403 Clear Signal Fail (SFc) includes the clearance of a degraded 404 condition in addition to the clearance of a failure condition 406 The second paragraph of Section 4.3.3.2 Unavailable State in 407 [RFC6378] shows the intention of including Signal Degrade on the 408 Protection path (SD-P) in the Unavailable state. Even though the 409 protection path can be partially available under the condition of the 410 Signal Degrade on the Protection path, this document follows the same 411 state grouping as [RFC6378] for SD on the protection path. 413 The bullet item "Protecting failure state" in Section 3.6. PSC 414 Control States in [RFC6378] includes the degraded condition in 415 Protection Failure state. This document follows the same state 416 grouping as [RFC6378] for Signal Degrade on the Working path (SD-W). 418 7.3. Behavior of protection against SD 420 In order to maintain the network operation behavior to which 421 transport network operators have become accustomed, the priorities of 422 SD-P and SD-W are defined to be equal as in other transport networks, 423 such as OTN and Ethernet. Once a switch has been completed due to 424 Signal Degrade on one path, it will not be overridden by Signal 425 Degrade on the other path (first come, first served behavior), to 426 avoid protection switching that cannot improve signal quality and 427 flapping. 429 Signal Degrade (SD) indicates that the transmitting end point has 430 identified a degradation of the signal, or integrity of the packet 431 transmission on either the working or protection path. The FPath 432 field SHALL identify the path that is reporting the degrade condition 433 (i.e., if protection path, then FPath is set to 0; if working path, 434 then FPath is set to 1), and the Path field SHALL indicate where the 435 data traffic is being transported (i.e., if working path is selected, 436 then Path is set to 0; if protection path is selected, then Path is 437 set to 1). 439 The Wait to Restore (WTR) timer is used when the protected domain is 440 configured for revertive behavior and started at the node that 441 recovers from a local degraded condition on the working path. 443 If the detection of a SD depends on the presence of user data 444 packets, such a condition declared on the working path is cleared 445 following protection switching to the protection path if a selector 446 bridge is used, possibly resulting in flapping. To avoid flapping, 447 the selector bridge should duplicate the user data traffic and feed 448 it to both working and protection paths under SD condition. In 449 revertive mode, when WTR timer expires the packet duplication will be 450 stopped and the user data traffic will be transported on the working 451 path only. In non-revertive mode, when SD is cleared the packet 452 duplication will be stopped and the user data traffic will be 453 transported on the protection path only. 455 When multiple SDs are detected simultaneously, either as local or 456 remote requests on both working and protection paths, the SD on the 457 standby path (the path from which the selector does not select the 458 user data traffic) is considered as having higher priority than the 459 SD on the active path (the path from which the selector selects the 460 user data traffic). Therefore, no unnecessary protection switching 461 is performed and the user data traffic continues to be selected from 462 the active path. 464 In the preceding paragraph, "simultaneously" relates to the 465 occurrence of SD on both the active and standby paths at input to the 466 Protection State Control Logic in Figure 1 of [RFC6378] at the same 467 time, or as long as a SD request has not been acknowledged by the 468 remote end in bidirectional protection switching. In other words, 469 when a local node that has transmitted a SD message receives a SD 470 message that indicates a different value of data path (Path) field 471 than the value of the Path field in the transmitted SD message, both 472 the local and the remote SD requests are considered to occur 473 simultaneously. 475 7.4. Equal priority resolution 477 In order to support the manual switch behavior described in 478 Section 6.3 and the protection against Signal Degrade described in 479 Section 7.3, the rules to resolve the equal priority requests are 480 required. 482 For local inputs with same priority, such as MS and SD, first-come, 483 first-served rule is applied. Once a local input is determined as 484 the highest priority local input, then a subsequent equal priority 485 local input requesting a different action, i.e., the same PSC Request 486 Field but different FPath value, to the PSC control logic will not be 487 presented to the PSC control logic as the highest local request. 488 Furthermore, in the case of MS, the subsequent MS local input 489 requesting a different action will be cancelled. 491 The remote message from the far-end LER is assigned a priority just 492 below the similar local input. For example, a remote Forced Switch 493 would have a priority just below a local Forced Switch but above a 494 local Signal Fail on working input assuming that the priority 495 modification is in place as in Section 4.4 497 However, if the LER is in a remote state due to a remote message, a 498 subsequent local input having the same priority but requesting 499 different action to the control logic, will be considered as having 500 lower priority than the remote message, and will be ignored. For 501 example, if the LER is in remote Unavailable state due to a remote 502 SD-P, then subsequent local SD-W input will be ignored. Likewise, if 503 the LER is in remote Switching administrative state due to a remote 504 MS-P, then subsequent local MS-W will be ignored and automatically 505 cancelled. 507 It should be noted that there is a reverse case where one LER 508 receives a local input and the other LER receives, simultaneously, an 509 input with the same priority but requesting different action. In 510 this case, each of the two LERs receives a subsequent remote message 511 having the same priority but requesting different action, while the 512 LER is in a local state due to the local input. In this case, a 513 priority must be set for the inputs with the same priority regardless 514 of its origin (local input or remote message). For example, one LER 515 receives SD-P as a local input and the other LER receives SP-W as a 516 local input, simultaneously. Likewise, one LER receives MS-P as a 517 local input and the other LER receives MS-W as a local input, 518 simultaneously. 520 When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be 521 considered as having higher priority than MS-P at both LERs. 523 When SD-W and SD-P occur simultaneously at both LERs, In this case, 524 the SD on the standby path (the path from which the selector does not 525 select the user data traffic) is considered as having higher priority 526 than the SD on the active path (the path from which the selector 527 selects the user data traffic) regardless of its origin (local or 528 remote message). Therefore, no unnecessary protection switching is 529 performed and the user data traffic continues to be selected from the 530 active path. Giving the higher priority to the SD on the standby 531 path SHALL also be applied to the Local Request logic when two SDs 532 for different paths happen to be presented to the Local Request logic 533 exactly at the same time. 535 The change of the PSC control logic including state machine due to 536 the support of protection against SD is incorporated into the PSC 537 control logic description when all the capabilities are enabled in 538 Section 10 and Section 11. 540 8. Capability 5: Support of Exercise Command 542 Exercise is a command to test if the PSC communication is operating 543 correctly. More specifically, the Exercise is to test and validate 544 the linear protection mechanism and PSC protocol including the 545 aliveness of the Local Request logic, the PSC state machine and the 546 PSC message generation and reception, and the integrity of the 547 protection path, without triggering the actual traffic switching. It 548 is used while the working path is either carrying the traffic or not. 549 It is lower priority than any "real" switch request. It is only 550 valid in bidirectional switching, since this is the only place where 551 one can get a meaningful test by looking for a response. 553 This command is documented in R84 of [RFC5654] and it has been 554 identified as a requirement from ITU-T. 556 A received EXER message indicates that the remote end point is 557 operating under an operator command to validate the protection 558 mechanism and PSC protocol including the aliveness of the Local 559 Request logic, the PSC state machine and the PSC message generation 560 and reception, and the integrity of the protection path, without 561 triggering the actual traffic switching. The valid response to EXER 562 message will be an Reverse Request (RR) with the corresponding FPath 563 and Path numbers. The near end will signal a Reverse Request (RR) 564 only in response to an EXER command from the far end. 566 When Exercise commands are input at both ends, an EXER, instead of 567 RR, is transmitted from both ends. 569 The following PSC Requests should be added to PSC Request field to 570 support Exercise: 572 (TBD2) Exercise - indicates that the transmitting end point is 573 exercising the protection channel and mechanism. FPath and Path 574 are set to the same value of the NR, RR or DNR request that EXER 575 replaces. 577 (TBD1) Reverse Request - indicates that the transmitting end point 578 is responding to an EXER command from the far end. FPath and Path 579 are set to the same value of the NR, RR or DNR request that EXER 580 replaces. 582 The priority of Exercise should be inserted between the priorities of 583 WTR Expires and No Request. 585 9. Capabilities and Modes 587 9.1. Capabilities 589 A Capability is an individual behavior whose use is signalled in a 590 Capabilities TLV, which is placed in Optional TLVs field inside PSC 591 messages shown in Figure 2 of [RFC6378]. The format of the 592 Capabilities TLV is: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type = Capabilities | Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Value = Options | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 The value of the Type field is TBD3 pending IANA allocation. 604 The value of the Length field is the length of the Options Value, and 605 is in octets. 607 The Value of the Capabilities TLV can be any length, as long as it is 608 a multiple of 4 octets. The length of the Value field MUST be the 609 minimum required to signal all the required capabilities. Section 4 610 to Section 8 discuss five capabilities that are signalled using the 5 611 most significant bits; if a node wishes to signal these five 612 capabilities, it MUST send an Options Value of 4 octets. A node 613 would send an Options Value greater than 4 octets only if it had more 614 than 32 Capabilities to indicate. All unused bits MUST be set to 615 zero. 617 If the bit assigned for an individual capability is set to 1, it 618 indicates the sending node's intent to use that capability in the 619 protected domain. If a bit is set to 0, the sending node does not 620 intend to use the indicated capability in the protected domain. Note 621 that it is not possible to distinguish between the intent not to use 622 a capability and a node's complete non-support (i.e. lack of 623 implementation) of a given capability. 625 This document defines five specific capabilities that are described 626 from Section 4 to Section 8. Each capability is assigned bit as 627 follows: 629 0x80000000: priority modification 631 0x40000000: modification of non-revertive behavior 633 0x20000000: support of Manual Switch to Working (MS-W) command 635 0x10000000: support of protection against Signal Degrade (SD) 637 0x08000000: support of Exercise command 639 9.1.1. Sending the Capabilities TLV 641 PSC sends messages in response to external events and in periodic 642 retransmission of current status. It may be expensive to send and to 643 parse an Capabilities TLV attached to a packet intended to trigger a 644 protection switch or other real- time behavior. However, if a node 645 does not periodically send its Capabilities TLV, the receiving node 646 cannot discriminate a deliberate omission of the Capabilities TLV for 647 performance reasons from an accidental omission due to an 648 implementation issue. To guard against this, a node MUST include its 649 Capabilities TLV in every PSC message that it sends. 651 9.1.2. Receiving the Capabilities TLV 653 A node MUST establish a receive timer for the Capabilities TLV. By 654 default this MUST be 3.5 times the periodic retransmission timer of 655 five seconds - i.e., 17.5 seconds. Both the periodic retransmission 656 time and the timeout SHOULD be configurable by the operator. When a 657 node receives a Capabilities TLV it resets the timer to 17.5 seconds. 658 If the timer expires, the node behaves as in Section 9.1.3. 660 [Editor's note: In other packet transport protection technologies, 661 Failure of Protocol defect (dFOP) is declared when no protocol 662 message is received on the protection path during at least 3.5 times 663 the periodic message transmission interval (i.e., at least 17.5 664 seconds) and there is no defect on the protection transport entity. 665 As the "Capabilities TLV" is included in the PSC message, this error 666 of not receiving the Capabilities TLV can be covered by dFOP. To be 667 discussed.] 668 When a node receives a Capabilities TLV it MUST compare it to its 669 most recent transmitted Capabilities TLV. If the two are equal, the 670 protected domain is said to be running in the mode indicated by that 671 set of capabilities (see Section 9.2). If the sent and received 672 Capabilities TLVs are not equal, this indicates a capabilities 673 mismatch. When this happens, the node MUST alert the operator and 674 MUST behave as in Section 9.1.3. 676 9.1.3. Handling Capabilities TLV errors 678 This section covers the two possible errors - a TLV timeout and a TLV 679 mismatch - and the error handling procedures in both cases. 681 9.1.3.1. Capabilities TLV Timeout 683 If the Capabilities TLV receive timer expires, a node is said to have 684 timed out. When this happens, the node MUST alert the operator and 685 MUST behave as in Section 9.1.3.3. 687 9.1.3.2. Capabilities TLV Mismatch 689 If the sent and received Capabilities TLVs are not equal, this 690 indicates a capabilities mismatch. When this happens, the node MUST 691 alert the operator and MUST behave as in Section 9.1.3.3. A node MAY 692 retain the received TLV for logging, alert or debug purposes. 694 9.1.3.3. Handling Capabilities TLV error conditions 696 When a node enters in Capabilities protocol error conditions, the 697 following actions MUST be taken: 699 1. Indicate the error condition (e.g., either mismatch or timeout) 700 to the operator by the usual alert mechanisms (e.g., syslog). 702 2. Not make any state transitions based on the contents of any PSC 703 Messages 705 To expand on point 2 - assume node A is receiving NR(0,0) from its 706 PSC peer node Z and is also receiving a mismatched set of 707 capabilities (e.g., received 0x4, transmitted 0x5). If node Z 708 detects a local SF-W and wants to initiate a protection switch (that 709 is, by sending SF(1,1)), node A MUST NOT react to this input by 710 changing its state. A node MAY increase the severity or urgency of 711 its alarms to the operator, but until the operator resolves the 712 mismatch in the Capabilities TLV the protected domain will likely 713 operate in an inconsistent state. 715 9.2. Modes 717 A Mode is a given set of Capabilities. Modes are shorthand; 718 referring to a set of capabilities by their individual values or by 719 the name of their mode does not change the protocol behavior. This 720 document defines two modes - PSC and APS. 722 9.2.1. PSC Mode 724 PSC Mode is defined as the lack of any Capabilities - that is, a 725 Capabilities set of 0x0. It is the behavior specified in RFC6378. 726 There are two ways to declare PSC Mode. A node can send a 727 Capabilities TLV of 0x0, or it can send no Capabilities TLV at all. 728 This is further explored in Section 9.3. 730 9.2.2. APS Mode 732 APS Mode is defined as the use of all of the five specific 733 capabilities, which are described from Section 4 to Section 8 in this 734 document. APS Mode is indicated with a Value of 0xF8000000. 736 9.3. Backward compatibility 738 As defined in Section 9.2.1, PSC Mode is indicated either with a 739 Capabilities TLV of 0x0 or the lack of Capabilities TLV. This is to 740 allow backward compatibility between two nodes - one which can send 741 the Capabilities TLV, and one which cannot. 743 [RFC6378] does not define how to handle an unrecognized TLV. There 744 may be some implementations that silently discard an unrecognized 745 TLV, and some that take more drastic steps like refusing to allow PSC 746 to operate. Thus, a node which has the ability to send and receive 747 the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode 748 Capabilities TLV and send no Capabilities TLV at all. An 749 implementation MUST be configurable between these two choices. 751 One question that arises from this dual definition of PSC Mode is, 752 what happens if a node which was sending a non-null Capabilities TLV 753 (e.g., APS Mode) sends PSC packets without any Capabilities TLV? 754 This case is handled as follows: 756 If a node has never, during the life of a PSC session, received a 757 Capabilities TLV from a neighbour, the lack of a Capabilities TLV is 758 treated as receipt of a PSC Capabilities TLV. This allows for 759 interop between nodes which support the PSC Mode TLV and nodes which 760 do not, and are thus implicitly operating in PSC Mode. 762 If a node has received a non-null Capabilities TLV (e.g., APS Mode) 763 during the life of a PSC session and then receives a PSC packet with 764 no Capabilities TLV, the receiving node MUST treat the lack of 765 Capabilities TLV as simply a lack of refresh. That is, the receipt 766 of a PSC packet with no Capabilities TLV simply does not reset the 767 receive timer defined in Section 9.1.2. 769 10. PSC Protocol in APS Mode 771 This section and Section 11 defines the behavior of PSC protocol when 772 all of the aforementioned capabilities are enabled, i.e., APS mode. 774 10.1. Request field in PSC protocol message 776 The values of "Request" field in the PSC protocol message, which is 777 shown in Figure 2 of [RFC6378], are defined as follows: 779 (14) Lockout of protection 781 (12) Forced Switch 783 (10) Signal Fail 785 (7) Signal Degrade 787 (5) Manual Switch 789 (4) Wait-to-Restore 791 (TBD2) Exercise 793 (TBD1) Reverse Request 795 (1) Do-not-Revert 797 (0) No Request 799 10.2. Priorities of local inputs and remote requests 801 Based on the description in Section 3 and Section 4.3.2 in [RFC6378], 802 the priorities of multiple outstanding local inputs are evaluated in 803 Local Request logic unit, where the highest priority local request is 804 determined. This high-priority local request is passed to the PSC 805 Control logic, that will determine the higher priority input (top 806 priority global request) between the highest priority local input and 807 the last received remote message. When a remote message comes to the 808 PSC Control logic, the top priority global request is determined 809 between this remote message and the highest priority local input 810 which is present. The top priority global request is used to 811 determine the state transition, which is described in Section 11. 813 The priorities for both local and remote requests are defined as 814 follows from highest to lowest: 816 o Operator Clear (Local only) 818 o Lockout of protection (Local and Remote) 820 o Clear Signal Fail/Degrade (Local only) 822 o Signal Fail on Protection path (Local and Remote) 824 o Forced Switch (Local and Remote) 826 o Signal Fail on Working path (Local and Remote) 828 o Signal Degrade on either Protection path or Working path (Local 829 and Remote) 831 o Manual Switch to either Protection path or Working path (Local and 832 Remote) 834 o WTR Expires (Local only) 836 o WTR (Remote only) 838 o Exercise (Local and Remote) 840 o Reverse Request (Remote only) 842 o Do-Not-Revert (Remote only) 844 o No Request (Remote and Local) 846 The remote request from the far-end LER is assigned a priority just 847 below the same local request. However, for the equal priority 848 requests, such as Signal Degrade on either Working or protection and 849 Manual Switch to either Protection or Working path, the following 850 equal priority resolution rules are defined: 852 o If two local inputs having same priority but requesting different 853 action come to the Local Request logic, then the input coming 854 first SHALL be considered to have a higher priority than the other 855 coming later (first-come, first-served). 857 o If the LER receives both a local input and a remote message with 858 the same priority and requesting the same action, i.e., the same 859 PSC Request Field and the same FPath value, then the local input 860 SHALL be considered to have a higher priority than the remote 861 message. 863 o If the LER receives both a local input and a remote message with 864 the same priority but requesting different actions, i.e., the same 865 PSC Request Field but different FPath value, then the first-come, 866 first-served rule SHALL be applied. If the remote message comes 867 first, then the state SHALL be a remote state and subsequent local 868 input is ignored. However, if the local input comes first, the 869 first-come, first-served rule cannot be applied and must be viewed 870 as simultaneous condition. This is because the subsequent remote 871 message will not be an acknowledge of the local input by the far- 872 end node. In this case, the priority SHALL be determined by rules 873 for each simultaneous condition. 875 o If the LER receives both MS-P and MS-W requests as both local 876 input and remote message and the LER is in a local Switching 877 administrative state, then the MS-W request SHALL be considered to 878 have a higher priority than the MS-P request. 880 o If the LER receives both SD-P and SD-W requests as both local 881 input and remote message and the LER is in a local state, then the 882 SD on the standby path (the path from which the selector does not 883 select the user data traffic) SHALL be considered as having higher 884 priority than the SD on the active path (the path from which the 885 selector selects the user data traffic) regardless of its origin 886 (local or remote message). This rule of giving the higher 887 priority to the SD on the standby path SHALL also be applied to 888 the Local Request logic when two SDs for different paths happen to 889 be presented to the Local Request logic exactly at the same time. 891 11. State Transition Tables in APS Mode 893 When there is a change in the highest-priority local request or in 894 remote PSC messages, the top priority global request is evaluated and 895 the state transition tables are looked up in PSC control logic. The 896 following rules are applied to the operation related to the state 897 transition table lookup. 899 o If the top priority global request, which determines the state 900 transition, is the highest priority local input, the local state 901 transition table SHALL be used to decide the next state of the 902 LER. Otherwise, remote messages state transition table SHALL be 903 used. 905 o If in remote state, the highest local defect condition (SF-P, 906 SF-W, SD-P or SD-W) SHALL always be reflected in the Request Field 907 and Fpath. 909 o Operator Clear command, Clear SF/SD (SFc) and WTR Expires are not 910 persistent. Once they appear to the local priority logic and 911 complete the operation, they will be disappeared. 913 o For the LER currently in the local state, if the top priority 914 global request is changed to OC or SFc causing the next state to 915 be Normal, WTR or DNR, then all the local and remote requests 916 should be re-evaluated as if the LER is in the state specified in 917 the footnotes to the state transition tables, before deciding the 918 final state. This re-evaluation is an internal operation confined 919 within the local LER, and PSC messages are generated according to 920 the final state. 922 o The WTR timer is started only when the LER which has recovered 923 from a local failure/degradation enters the WTR state. An LER 924 which is entering into the WTR state due to a remote WTR message 925 does not start the WTR timer. 927 The extended states, as they appear in the table, are as follows: 929 N Normal state 930 UA:LO:L Unavailable state due to local LO command 931 UA:P:L Unavailable state due to local SF-P 932 UA:DP:L Unavailable state due to local SD-P 933 UA:LO:R Unavailable state due to remote LO message 934 UA:P:R Unavailable state due to remote SF-P message 935 UA:DP:L Unavailable state due to local SD-P 936 PF:W:L Protecting failure state due to local SF-W 937 PF:DW:L Protecting failure state due to local SD-W 938 PF:W:R Protecting failure state due to remote SF-W message 939 PF:DW:R Protecting failure state due to remote SD-W message 940 SA:F:L Switching administrative state due to local FS command 941 SA:MW:L Switching administrative state due to local MS-W command 942 SA:MP:L Switching administrative state due to local MS-P command 943 SA:F:R Switching administrative state due to remote FS message 944 SA:MW:R Switching administrative state due to remote MS-W message 945 SA:MP:R Switching administrative state due to remote MS-P message 946 E::L Exercise state due to local EXER command 947 E::R Exercise state due to remote EXER message 948 WTR Wait-to-Restore state 949 DNR Do-not-Revert state 951 Each state corresponds to the transmission of a particular set of 952 Request, FPath and Path bits. The table below lists the message that 953 is generally sent in each particular state. If the message to be 954 sent in a particular state deviates from the table below, it is noted 955 in the footnotes to the state transition tables. 957 State REQ(FP,P) 958 ------- --------- 959 N NR(0,0) 960 UA:LO:L LO(0,0) 961 UA:P:L SF(0,0) 962 UA:DP:L SD(0,0) 963 UA:LO:R highest local request(local FPath,0) 964 UA:P:R highest local request(local FPath,0) 965 UA:DP:R highest local request(local FPath,0) 966 PF:W:L SF(1,1) 967 PF:DW:L SD(1,1) 968 PF:W:R highest local request(local FPath,1) 969 PF:DW:R highest local request(local FPath,1) 970 SA:F:L FS(1,1) 971 SA:MW:L MS(0,0) 972 SA:MP:L MS(1,1) 973 SA:F:R highest local request(local FPath,1) 974 SA:MW:R highest local request(local FPath,0) 975 SA:MP:R highest local request(local FPath,1) 976 WTR WTR(0,1) 977 DNR DNR(0,1) 978 E::L EXER(0,x), where x is the existing Path value 979 when Exercise command is issued. 980 E::R RR(0,x), where x is the existing Path value 981 when RR message is generated. 983 11.1. State transition by local inputs 985 | OC | LO | SFc | SF-P | FS | SF-W | 986 --------+-----+---------+-----+--------+--------+--------+ 987 N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 988 UA:LO:L | (1) | i | i | i | i | i | 989 UA:P:L | i | UA:LO:L | (1) | i | i | i | 990 UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L | 991 UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 992 UA:P:R | i | UA:LO:L | i | UA:P:L | PF:W:L | PF:W:L | 993 UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 994 PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i | 995 PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L | 996 PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 997 PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 998 SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i | 999 SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1000 SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1001 SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1002 SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1003 SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1004 WTR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1005 DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1006 E::L | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1007 E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1009 | SD-P | SD-W | MS-W | MS-P | WTRExp | EXER 1010 --------+---------+---------+---------+---------+--------+------ 1011 N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1012 UA:LO:L | i | i | i | i | i | i 1013 UA:P:L | i | i | i | i | i | i 1014 UA:DP:L | i | i | i | i | i | i 1015 UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i 1016 UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i 1017 UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i 1018 PF:W:L | i | i | i | i | i | i 1019 PF:DW:L | i | i | i | i | i | i 1020 PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i 1021 PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i 1022 SA:F:L | i | i | i | i | i | i 1023 SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i 1024 SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i 1025 SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i 1026 SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i 1027 SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i 1028 WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i 1029 DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1030 E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i 1031 E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1033 11.2. State transition by remote messages 1035 | LO | SF-P | FS | SF-W | SD-P | SD-W | 1036 --------+---------+--------+--------+--------+---------+---------+ 1037 N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1038 UA:LO:L | i | i | i | i | i | i | 1039 UA:P:L | UA:LO:R | i | i | i | i | i | 1040 UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (10) | 1041 UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1042 UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1043 UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R | 1044 PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i | 1045 PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (11) | i | 1046 PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R | 1047 PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1048 SA:F:L | UA:LO:R | UA:P:R | i | i | i | i | 1049 SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1050 SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1051 SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R | 1052 SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1053 SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1054 WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1055 DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1056 E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1057 E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1059 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 1060 --------+---------+---------+-----+------+----+-----+---- 1061 N | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1062 UA:LO:L | i | i | i | i | i | i | i 1063 UA:P:L | i | i | i | i | i | i | i 1064 UA:DP:L | i | i | i | i | i | i | i 1065 UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1066 UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1067 UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1068 PF:W:L | i | i | i | i | i | i | i 1069 PF:DW:L | i | i | i | i | i | i | i 1070 PF:W:R | SA:MW:R | SA:MP:R | (7) | E::R | i | (8) | (5) 1071 PF:DW:R | SA:MW:R | SA:MP:R | (7) | E::R | i | (8) | (5) 1072 SA:F:L | i | i | i | i | i | i | i 1073 SA:MW:L | i | i | i | i | i | i | i 1074 SA:MP:L | i | i | i | i | i | i | i 1075 SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N 1076 SA:MW:R | i | SA:MP:R | i | E::R | i | i | N 1077 SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N 1078 WTR | SA:MW:R | SA:MP:R | i | i | i | i | (9) 1079 DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1080 E::L | SA:MW:R | SA:MP:R | i | i | i | i | i 1081 E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N 1083 NOTES: 1085 (1) Re-evaluate to determine final state as if the LER is in the 1086 Normal state. 1088 (2) In the case that both local input and the last received remote 1089 message are no request after the occurrence of SFc, the LER 1090 enters into the WTR state when the domain is configured for 1091 revertive behavior, or the LER enters into the DNR state when 1092 the domain is configured for non-revertive behavior. In all the 1093 other cases, re-evaluate to determine the final state as if the 1094 LER is in the Normal state. 1096 (3) Re-evaluate to determine final state as if the LER is in the 1097 Normal state when the domain is configured for revertive 1098 behavior, or as if the LER is in the DNR state when the domain 1099 is configured for non-revertive behavior, 1101 (4) If Path value is 0, re-evaluate to determine final state as if 1102 the LER is in the Normal state. If Path value is 1, re-evaluate 1103 to determine final state as if the LER is in the DNR state 1105 (5) If the received NR message has Path=1, transition to WTR if 1106 domain configured for revertive behavior, else transition to 1107 DNR. 1109 (6) Remain in WTR, send NR(0,1). 1111 (7) Transition to WTR state and continue to send the current 1112 message. 1114 (8) Transition to DNR state and continue to send the current 1115 message. 1117 (9) If the receiving LER's WTR timer is running, maintain current 1118 state and message. If the WTR timer is not running, transition 1119 to N. 1121 (10) If the active path just before the SD is selected as the highest 1122 local input was the working path, then ignore. Otherwise, go to 1123 PF:DW:R and transmit SD(0,1) 1125 (11) If the received SD-P message has Path=1, ignore the message. If 1126 the received SD-P message has Path=0 and the active path just 1127 before the SD is selected as the highest local input was the 1128 working path, then go to UA:DP:R and transmit SD(1,0). If the 1129 received SD-P message has Path=0 and the active path just before 1130 the SD is selected as the highest local input was the protection 1131 path, then ignore the received SD-P message. 1133 12. Security considerations 1135 No specific security issue is raised in addition to those ones 1136 already documented in [RFC6378] 1138 13. IANA considerations 1140 13.1. PSC Request Field 1142 This document defines two new values in the "MPLS PSC Request 1143 Registry". 1145 The PSC Request Field is 4 bits, and the two new values have been 1146 allocated as follows: 1148 Value Description Reference 1149 ----- --------------------- --------------- 1150 TBD1 Reverse Request [this document] 1151 TBD2 Exercise [this document] 1153 [to be removed upon publication: It is requested to assign 2 1154 (=TBD1)for the Reverse Request value and 3 (=TBD2) for the Exercise 1155 value to be aligned with the priority levels of those two requests 1156 defined in this document.] 1158 13.2. PSC TLV 1160 This document defines a new value for the Capabilities TLV type in 1161 the "MPLS PSC TLV Registry". 1163 Type TLV Name Reference 1164 ----- --------------------- --------------- 1165 TBD3 Capabilities [this document] 1167 [Editor's note: Need to specify a registry for Value (=options) 1168 inside the Capabilities TLV in a later version of this draft] 1170 14. Acknowledgements 1172 15. References 1174 15.1. Normative References 1176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1177 Requirement Levels", BCP 14, RFC 2119, March 1997. 1179 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1180 and S. Ueno, "Requirements of an MPLS Transport Profile", 1181 RFC 5654, September 2009. 1183 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1184 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1185 Protection", RFC 6378, October 2011. 1187 [I-D.ietf-mpls-psc-updates] 1188 Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- 1189 updates-00 (work in progress), October 2013. 1191 15.2. Informative References 1193 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1194 Restoration) Terminology for Generalized Multi-Protocol 1195 Label Switching (GMPLS)", RFC 4427, March 2006. 1197 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1198 TP) Survivability Framework", RFC 6372, September 2011. 1200 Appendix A. An example of out-of-service scenarios 1202 The sequence diagram shown is an example of the out-of-service 1203 scenerios based on the priority level defined in [RFC6378]. The 1204 first PSC message which differs from the previous PSC message is 1205 shown. 1207 A Z 1208 | | 1209 (1) |-- NR(0,0) ------>| (1) 1210 |<----- NR(0,0) ---| 1211 | | 1212 | | 1213 | (FS issued at Z) | (2) 1214 (3) |<------ FS(1,1) --| 1215 |-- NR(0,1) ------>| 1216 | | 1217 | | 1218 (4) | (SF on P(A<-Z)) | 1219 | | 1220 | | 1221 | (Clear FS at Z) | (5) 1222 (6) | X <- NR(0,0) --| 1223 | | 1224 | | 1226 (1) Each end is in Normal state, and transmits NR (0,0) messages. 1228 (2) When a Forced Switch command is issued at node Z, node Z goes 1229 into local Protecting Administrative state (PA:F:L) and begins 1230 transmission of an FS (1,1) messages. 1232 (3) A remote Forced Switch message causes node A to go into remote 1233 Protecting Administrative state (PA:F:R), and node A begins 1234 transmitting NR (0,1) messages. 1236 (4) When node A detects a unidirectional Signal Fail on the 1237 Protection path, node A keeps sending NR (0,1) message because SF-P 1238 is ignored under the state PA:F:R. 1240 (5) When a Clear command is issued at node Z, node Z goes into Normal 1241 state and begins transmission of NR (0,0) messages. 1243 (6) But node A cannot receive PSC message because of local 1244 unidirectional Signal Fail on the Protection path. Because no valid 1245 PSC message is received, over a period of several successive message 1246 intervals, the last valid received message remains applicable and the 1247 node A continue to transmit an NR (0,1) message in the state of 1248 PA:F:R. 1250 Now, there exists a mismatch between the bridge/selector positions of 1251 node A (transmitting an NR (0,1)) and node Z (transmitting an NR 1252 (0,0)). It results in out-of-service even when there is neither 1253 signal fail on working path nor FS. 1255 Appendix B. An example of sequence diagram showing the problem with the 1256 priority level of Clear SF 1258 An example of sequence diagram showing the problem with the priority 1259 level of Clear SF defined in [RFC6378] is given below. The following 1260 sequence diagram is depicted for the case of bidirectional signal 1261 fails. However, other cases with unidirectional signal fails can 1262 result in the same problem. The first PSC message which differs from 1263 the previous PSC message is shown. 1265 A Z 1266 | | 1267 (1) |-- NR(0,0) ------>| (1) 1268 |<----- NR(0,0) ---| 1269 | | 1270 | | 1271 (2) | (SF on P(A<->Z)) | (2) 1272 |-- SF(0,0) ------>| 1273 |<------ SF(0,0) --| 1274 | | 1275 | | 1276 (3) | (SF on W(A<->Z)) | (3) 1277 | | 1278 | | 1279 (4) | (Clear SF-P) | (4) 1280 | | 1281 | | 1282 (5) | (Clear SF-W) | (5) 1283 | | 1284 | | 1286 (1) Each end is in Normal state, and transmits NR (0,0) messages. 1288 (2) When signal fail on protection (SF-P) occurs, each node enters 1289 into [UA:P:L] state and transmits SF (0,0) messages. Traffic remains 1290 on working path. 1292 (3) When signal fail on working (SF-W) occurs, each node remains in 1293 [UA:P:L] state as SF-W has a lower priority than SF-P. Traffic is 1294 still on the working path. Traffic cannot be delivered as both 1295 working and protection paths are experiencing signal fails. 1297 (4) When the signal fail on protection is cleared, local "Clear SF-P" 1298 request cannot be presented to the PSC control logic, which takes the 1299 highest priority local request and runs PSC state machine, as the 1300 priority of "Clear SF-P" is lower than that of SF-W. Consequently, 1301 there is no change in state, and the selector and/or bridge keep 1302 pointing at the working path, which has signal fail condition. 1304 Now, traffic cannot be delivered while the protection path is 1305 recovered and available. It should be noted that the same problem 1306 will occur in the case that the sequence of SF-P and SF-W events is 1307 changed. 1309 If we further continue with this sequence to see what will happen 1310 after SF-W is cleared, 1312 (5) When the signal fail on working is cleared, local "Clear SF-W" 1313 request can be passed to the PSC control logic (state machine) as 1314 there is no higher priority local request, but this will be ignored 1315 in the PSC control logic according to the state transition definition 1316 in [RFC6378]. There will be no change in state or protocol message 1317 transmitted. 1319 As the signal fail on working is now cleared and the selector and/or 1320 bridge are still pointing at the working path, traffic delivery is 1321 resumed. However, each node is in [UA:P:L] state and transmitting 1322 SF(0,0) message, while there exists no outstanding request for 1323 protection switching. Moreover, any future legitimate protection 1324 switching requests, such as SF-W, will be rejected as each node 1325 thinks the protection path is unavailable. 1327 Appendix C. Freeze Command 1329 The "Freeze" command applies only to the near end (local node) of the 1330 protection group and is not signalled to the far end. This command 1331 freezes the state of the protection group. Until the Freeze is 1332 cleared, additional near end commands are rejected and condition 1333 changes and received PSC information are ignored. 1335 "Clear Freeze" command clears the local freeze. When the Freeze 1336 command is cleared, the state of the protection group is recomputed 1337 based on the persistent condition of the local triggers. 1339 Because the freeze is local, if the freeze is issued at one end only, 1340 a failure of protocol can occur as the other end is open to accept 1341 any operator command or a fault condition. 1343 Authors' Addresses 1345 Jeong-dong Ryoo (editor) 1346 ETRI 1347 218 Gajeongno 1348 Yuseong-gu, Daejeon 305-700 1349 South Korea 1351 Phone: +82-42-860-5384 1352 Email: ryoo@etri.re.kr 1354 Eric Gray (editor) 1355 Ericsson 1357 Email: eric.gray@ericsson.com 1359 Huub van Helvoort 1360 Huawei Technologies 1361 Karspeldreef 4, 1362 Amsterdam 1101 CJ 1363 the Netherlands 1365 Phone: +31 20 4300936 1366 Email: huub.van.helvoort@huawei.com 1368 Alessandro D'Alessandro 1369 Telecom Italia 1370 via Reiss Romoli, 274 1371 Torino 10148 1372 Italy 1374 Phone: +39 011 2285887 1375 Email: alessandro.dalessandro@telecomitalia.it 1376 Taesik Cheung 1377 ETRI 1378 218 Gajeongno 1379 Yuseong-gu, Daejeon 305-700 1380 South Korea 1382 Phone: +82-42-860-5646 1383 Email: cts@etri.re.kr 1385 Eric Osborne 1386 Cisco Systems, Inc. 1388 Email: eosborne@cisco.com