idnits 2.17.1 draft-ryoogray-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6378]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2013) is 3834 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) -- Looks like a reference, but probably isn't: '1' on line 1078 -- Looks like a reference, but probably isn't: '2' on line 1081 -- Looks like a reference, but probably isn't: '3' on line 1089 -- Looks like a reference, but probably isn't: '4' on line 1094 -- Looks like a reference, but probably isn't: '6' on line 1102 -- Looks like a reference, but probably isn't: '10' on line 1114 -- Looks like a reference, but probably isn't: '11' on line 1118 -- Looks like a reference, but probably isn't: '7' on line 1104 -- Looks like a reference, but probably isn't: '8' on line 1107 -- Looks like a reference, but probably isn't: '5' on line 1098 -- Looks like a reference, but probably isn't: '9' on line 1110 == Unused Reference: 'RFC5226' is defined on line 1188, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4427 ** Downref: Normative reference to an Informational RFC: RFC 6372 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). 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 Intended status: Standards Track E. Gray, Ed. 5 Expires: April 23, 2014 Ericsson 6 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 October 20, 2013 16 MPLS Transport Profile (MPLS-TP) Linear Protection in Support of ITU-T's 17 Requirements 18 draft-ryoogray-mpls-tp-psc-itu-00.txt 20 Abstract 22 This document contains the updates to [RFC6378], "MPLS Transport 23 Profile (MPLS-TP) Linear Protection", in an effort to satisfy the 24 ITU-T's protection switching requirements. The following 25 capabilities are required by ITU-T and described in this documents: 26 priority modification, modification of non-revertive behavior, 27 support of Manual Switch to Working (MS-W) command, support of 28 protection against Signal Degrade (SD), and support of Exercise 29 command. The behavior described in [RFC6378] are modified in order 30 to preserve the network operation behavior to which network operators 31 have become accustomed. 33 This document introduces capabilities and modes to PSC. A capability 34 is an individual behavior, and a node's set of capabilities are 35 signalled using the method given in this document. A mode is a 36 particular combination of capabilities. 38 This document describes the behavior of the Protection State 39 Coordination (PSC) protocol including priority logic and state 40 machine when all of the aforementioned capabilities are enabled. 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 April 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . 7 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 . 8 91 7.1. Motivation for supporting protection against Signal 92 Degrade . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 7.2. Terms modified to support SD . . . . . . . . . . . . . . 9 94 7.3. Behavior of protection against SD . . . . . . . . . . . . 9 95 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 25 113 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25 114 13.1. PSC Request Field . . . . . . . . . . . . . . . . . . . 25 115 13.2. PSC TLV . . . . . . . . . . . . . . . . . . . . . . . . 25 116 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 117 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 118 15.1. Normative References . . . . . . . . . . . . . . . . . . 26 119 15.2. Informative References . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . 29 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 126 1. Introduction 128 This document contains the updates to [RFC6378], "MPLS Transport 129 Profile (MPLS-TP) Linear Protection", in an effort to satisfy the 130 ITU-T's protection switching requirements. The behavior described in 131 [RFC6378] are modified in order to preserve the network operation 132 behavior to which network operators have become accustomed. 134 The following capabilities are required by ITU-T and described in 135 this documents: 137 1. Priority modification 139 2. modification of non-revertive behavior, 141 3. support of Manual Switch to Working (MS-W) command, 143 4. support of protection against Signal Degrade (SD), and 144 5. support of Exercise command. 146 Priority modification includes priority swapping between Signal Fail 147 on the Protection path (SF-P) and Forced Switch (FS), and raising the 148 priority level of Clear SF. 150 The modification of non-revertive behavior is needed to be aligned 151 with the behavior defined in [RFC4427] as well as to meet the ITU-T's 152 protection switching requirements. 154 Support of Manual Switch to Working (MS-W) command to revert traffic 155 to the working path in non-revertive operation is covered in this 156 document. 158 Support of protection switching protocol against Signal Degrade (SD) 159 is covered in this document. The specifics for the method of 160 identifying SD is out of the scope of this document similarly to SF 161 for [RFC6378]. 163 Support of Exercise command to test if the Protection State 164 Coordination (PSC) communication is operating correctly is also 165 covered in this document. More specifically, the Exercise tests and 166 validates the linear protection mechanism and PSC protocol including 167 the aliveness of the Local Request logic, the PSC state machine and 168 the PSC message generation and reception, and the integrity of the 169 protection path, without triggering the actual traffic switching. 171 This document addes Capabilities and Modes to PSC. A Capability is 172 an individual behavior whose use is signalled in a Capabilities TLV 173 inside PSC while a Mode is a predefined set of Capabilities.Two Modes 174 are defined: PSC and APS modes. 176 This document also describes the behavior of PSC protocol including 177 priority logic and state machine when all of the aforementioned 178 capabilities are enabled, i.e., APS mode. 180 2. Conventions Used in This Document 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Acronyms 188 This document uses the following acronyms: 190 APS Automatic Protection Switching 191 EXER Exercise 192 FS Forced Switch 193 LO Lockout of protection 194 MS Manual Switch 195 MS-P Manual Switch to Protection 196 MS-W Manual Switch to Working 197 MPLS-TP Transport Profile for MPLS 198 NR No Request 199 OC Operator Clear 200 PSC Protection State Coordination 201 RR Reverse Request 202 SD Signal Degrade 203 SD-P Signal Degrade on the Protection path 204 SD-W Signal Degrade on the Working path 205 SF Signal Fail 206 SFc Clear Signal Fail 207 SF-P Signal Fail on the Protection path 208 SF-W Signal Fail on the Working path 209 WTR Wait to Restore 211 4. Capability 1: Priority Modification 213 In this document, the priorities of Forced Switch (FS) and Signal 214 Fail on the Protection path (SF-P) are swapped and the priority of 215 Clear SF (SFc) is raised. In addition to the priority modification, 216 this document introduces the use of a Freeze command in Appendix C. 217 The reasons for these changes are explained in the following sub- 218 sections from technical and network operational aspects. 220 4.1. Motivations for swapping priorities of FS and SF-P 222 Defining the priority of FS higher than that of Signal Fail on the 223 Protection path (SF-P) can result in a situation where the protected 224 traffic is taken out-of-service. Setting the priority of any input 225 that is supposed to be signalled to the other end to be higher than 226 that of SF-P can result in unpredictable protection switching state, 227 when the protection path has failed and consequently the PSC 228 communication stopped. An example of the out-of-service scenarios is 229 shown in Appendix A 231 According to Section 2.4 of [RFC5654] it MUST be possible to operate 232 an MPLS-TP network without using a control plane. This means that 233 external switch commands, e.g. FS, can be transferred to the far end 234 only by using the PSC communication channel and should not rely on 235 the presence of a control plane. 237 As the priority of SF-P has been higher than FS in optical transport 238 networks and Ethernet transport networks, for network operators it is 239 important that the MPLS-TP protection switching preserves the network 240 operation behavior to which network operators have become accustomed. 241 Typically, the FS command is issued before network maintenance jobs, 242 (e.g., replacing optical cables or other network components). When 243 an operator pulls out a cable on the protection path by mistake, the 244 traffic should be protected and the operator expects this behavior 245 based on his/her experience on the traditional transport network 246 operations. 248 4.2. Motivation for raising the priority of Clear SF 250 The priority level of SFc defined in [RFC6378] can cause traffic 251 disruption when a node that has experienced local signal fails on 252 both working and protection paths is recovering from these failures. 254 An example of sequence diagram showing the problem with the priority 255 level of SFc as defined in [RFC6378] is shown in Appendix B. 257 4.3. Motivation for introducing Freeze command 259 With the priority swapping between FS and SF-P, the traffic is always 260 moved back to the working path when SF-P occurs in Protecting 261 Administrative state. In the case that network operators need an 262 option to control their networks so that the traffic can remain on 263 the protection path even when the PSC communication channel is 264 broken, the Freeze command, which is a local command (i.e., not 265 signalled to the other end) can be used. The use of the Freeze 266 command is described in Appendix C. 268 4.4. Updates to the PSC RFC 270 The list of local requests in order of priority should be modified as 271 follows: 273 (from higher to lower) 275 o Clear Signal Fail/Degrade 277 o Signal Fail on the Protection path 279 o Forced Switch 281 o Signal Fail on the Working path 283 The change of the PSC control logic including state machine due to 284 this priority modification is incorporated in the PSC control logic 285 description when all the capabilities are enabled in Section 10 and 286 Section 11. 288 5. Capability 2: Modification of Non-revertive Operation 290 Non-revertive mode of protection switching is defined in [RFC4427]. 291 In this mode, the traffic does not return to the working path when 292 switch-over requests are terminated. 294 However, PSC protocol defined in [RFC6378] supports this operation 295 only when recovering from a defect condition, but does not operate as 296 non-revertive when an operator's switch-over command such as Forced 297 Switch or Manual Switch is cleared. To be aligned with legacy 298 transport network behavior and [RFC4427], a node should go into the 299 Do-not-Revert (DNR) state not only when a failure condition on a 300 working path is cleared but also when an operator command requesting 301 switch-over is cleared. 303 The change of the PSC control logic including state machine due to 304 the modification of non-revertive operation is incorporated into the 305 PSC control logic description when all the capabilities are enabled 306 in Section 10 and Section 11. 308 6. Capability 3: Support of Manual Switch to Working Command 310 6.1. Motivation for adding Manual Switch to Working 312 Changing the non-revertive operation introduces necessity of a new 313 operator command to revert traffic to the working path when in Do- 314 not-Revert (DNR) state. When the traffic is on the protection path 315 in DNR state, a Manual Switch to Working (MS-W) command is issued to 316 switch the normal traffic back to the working path. According to 317 Section 4.3.3.6 (Do-not-Revert State) in [RFC6378], "to revert back 318 to Normal state, the administrator SHALL issue a Lockout of 319 protection (LO) command followed by a Clear command." However, using 320 LO command introduces the potential risk of an unprotected situation 321 while the Lockout of protection is in effect. 323 Manual Switch-over for recovery LSP/span command, defined in 324 [RFC4427] and also defined in [RFC5654], Requirement 83, as one of 325 the mandatory external commands, should be used for this purpose, but 326 is not included in [RFC6378]. Note that the "Manual Switch-over for 327 recovery LSP/span" command is the same as MS-W command. 329 6.2. Terms modified to support MS-W 331 The term "Manual Switch" and its acronym "MS" used in [RFC6378] are 332 replaced respectively by "Manual Switch to Protection" and "MS-P" by 333 this document to avoid confusion with "Manual Switch to Working" and 334 its acronym "MS-W". 336 Also, the term "Protecting administrative state" used in [RFC6378] is 337 replaced by "Switching administrative state" by this document to 338 include the case where traffic is switched back to the working path 339 by administrative Manual Switch to Working command. 341 6.3. Behavior of MS-P and MS-W 343 The MS-P and MS-W commands SHALL have the same priority. If one of 344 these commands is already issued and accepted, and the other command 345 that is issued afterwards SHALL be ignored. If two LERs are 346 requesting opposite operations simultaneously, i.e. one LER is 347 sending MS-P while the other LER is sending MS-W, the MS-W SHALL be 348 considered to have a higher priority than MS-P, and MS-P SHALL be 349 ignored. 351 Two commands, MS-P and MS-W are represented by the same Request Field 352 value, but differentiated by the FPath value. When traffic is 353 switched to the protection path, the FPath field SHALL indicate that 354 the working path is being blocked (i.e., FPath set to 1), and the 355 Path field SHALL indicate that user data traffic is being transported 356 on the protection path (i.e., Path set to 1). When traffic is 357 switched to the working path, the FPath field SHALL indicate that the 358 protection path is being blocked (i.e., FPath set to 0), and the Path 359 field SHALL indicate that user data traffic is being transported on 360 the working path (i.e., Path set to 0). 362 6.4. Equal priority resolution for MS 364 [RFC6378] defines only one rule for equal priority condition in 365 Section 4.3.2 as "The remote message from the far-end LER is assigned 366 a priority just below the similar local input." In order to support 367 the manual switch behavior described in Section 6.3, additional rules 368 for equal priority resolution are required. Since the support of 369 protection against signal degrades also requires a similar equal 370 priority resolution, the rules are described in Section 7.4. 372 The change of the PSC control logic including state machine due to 373 the support of MS-W command is incorporated into the PSC control 374 logic description when all the capabilities are enabled in Section 10 375 and Section 11. 377 7. Capability 4: Support of protection against Signal Degrade 379 7.1. Motivation for supporting protection against Signal Degrade 380 In MPLS-TP survivability framework [RFC6372], fault conditions 381 include both Signal Fail (SF) and Signal Degrade (SD) that can be 382 used to trigger protection switching. 384 [RFC6378], which defines the Protection State Coordination (PSC) 385 protocol, does not specify how the SF and SD are declared and 386 specifies the protection switching protocol associated with SF only. 388 The protection switching protocol associated with SD is covered in 389 this document, and the specifics for the method of identifying SD is 390 out of the scope of PSC protocol similarly to how to detect SF and 391 how MS and FS commands are initiated in a management system and 392 signalled to PSC. 394 7.2. Terms modified to support SD 396 Clear Signal Fail (SFc) includes the clearance of a degraded 397 condition in addition to the clearance of a failure condition 399 The second paragraph of Section 4.3.3.2 Unavailable State in 400 [RFC6378] shows the intention of including Signal Degrade on the 401 Protection path (SD-P) in the Unavailable state. Even though the 402 protection path can be partially available under the condition of the 403 Signal Degrade on the Protection path, this document follows the same 404 state grouping as [RFC6378] for SD on the protection path. 406 The bullet item "Protecting failure state" in Section 3.6. PSC 407 Control States in [RFC6378] includes the degraded condition in 408 Protection Failure state. This document follows the same state 409 grouping as [RFC6378] for Signal Degrade on the Working path (SD-W). 411 7.3. Behavior of protection against SD 413 In order to maintain the network operation behavior to which 414 transport network operators have become accustomed, the priorities of 415 SD-P and SD-W are defined to be equal as in other transport networks, 416 such as OTN and Ethernet. Once a switch has been completed due to 417 Signal Degrade on one path, it will not be overridden by Signal 418 Degrade on the other path (first come, first served behavior), to 419 avoid protection switching that cannot improve signal quality and 420 flapping. 422 Signal Degrade (SD) indicates that the transmitting end point has 423 identified a degradation of the signal, or integrity of the packet 424 transmission on either the working or protection path. The FPath 425 field SHALL identify the path that is reporting the degrade condition 426 (i.e., if protection path, then FPath is set to 0; if working path, 427 then FPath is set to 1), and the Path field SHALL indicate where the 428 data traffic is being transported (i.e., if working path is selected, 429 then Path is set to 0; if protection path is selected, then Path is 430 set to 1). 432 The Wait to Restore (WTR) timer is used when the protected domain is 433 configured for revertive behavior and started at the node that 434 recovers from a local degraded condition on the working path. 436 If the detection of a SD depends on the presence of user data 437 packets, such a condition declared on the working path is cleared 438 following protection switching to the protection path if a selector 439 bridge is used, possibly resulting in flapping. To avoid flapping, 440 the selector bridge should duplicate the user data traffic and feed 441 it to both working and protection paths under SD condition. In 442 revertive mode, when WTR timer expires the packet duplication will be 443 stopped and the user data traffic will be transported on the working 444 path only. In non-revertive mode, when SD is cleared the packet 445 duplication will be stopped and the user data traffic will be 446 transported on the protection path only. 448 When multiple SDs are detected simultaneously, either as local or 449 remote requests on both working and protection paths, the SD on the 450 standby path (the path from which the selector does not select the 451 user data traffic) is considered as having higher priority than the 452 SD on the active path (the path from which the selector selects the 453 user data traffic). Therefore, no unnecessary protection switching 454 is performed and the user data traffic continues to be selected from 455 the active path. 457 In the preceding paragraph, "simultaneously" relates to the 458 occurrence of SD on both the active and standby paths at input to the 459 Protection State Control Logic in Figure 1 of [RFC6378] at the same 460 time, or as long as a SD request has not been acknowledged by the 461 remote end in bidirectional protection switching. In other words, 462 when a local node that has transmitted a SD message receives a SD 463 message that indicates a different value of data path (Path) field 464 than the value of the Path field in the transmitted SD message, both 465 the local and the remote SD requests are considered to occur 466 simultaneously. 468 7.4. Equal priority resolution 470 In order to support the manual switch behavior described in 471 Section 6.3 and the protection against Signal Degrade described in 472 Section 7.3, the rules to resolve the equal priority requests are 473 required. 475 For local inputs with same priority, such as MS and SD, first-come, 476 first-served rule is applied. Once a local input is determined as 477 the highest priority local input, then a subsequent equal priority 478 local input requesting a different action, i.e., the same PSC Request 479 Field but different FPath value, to the PSC control logic will not be 480 presented to the PSC control logic as the highest local request. 481 Futhermore, in the case of MS, the subsequent MS local input 482 requesting a different action will be cancelled. 484 The remote message from the far-end LER is assigned a priority just 485 below the similar local input. For example, a remote Forced Switch 486 would have a priority just below a local Forced Switch but above a 487 local Signal Fail on working input assuming that the priority 488 modification is in place as in Section 4.4 490 However, if the LER is in a remote state due to a remote message, a 491 subsequent local input having the same priority but requesting 492 different action to the control logic, will be considered as having 493 lower priority than the remote message, and will be ignored. For 494 example, if the LER is in remote Unavailable state due to a remote 495 SD-P, then subsequent local SD-W input will be ignored. Likewise, if 496 the LER is in remote Switching administrative state due to a remote 497 MS-P, then subsequent local MS-W will be ignored and automatically 498 cancelled. 500 It should be noted that there is a reverse case where one LER 501 receives a local input and the other LER receives, simultaneously, an 502 input with the same priority but requesting different action. In 503 this case, each of the two LERs receives a subsequent remote message 504 having the same priority but requesting different action, while the 505 LER is in a local state due to the local input. In this case, a 506 priority must be set for the inputs with the same priority regardless 507 of its origin (local input or remote message). For example, one LER 508 receives SD-P as a local input and the other LER receives SP-W as a 509 local input, simultaneously. Likewise, one LER receives MS-P as a 510 local input and the other LER receives MS-W as a local input, 511 simultaneously. 513 When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be 514 considered as having higher priority than MS-P at both LERs. 516 When SD-W and SD-P occur simultaneously at both LERs, In this case, 517 the SD on the standby path (the path from which the selector does not 518 select the user data traffic) is considered as having higher priority 519 than the SD on the active path (the path from which the selector 520 selects the user data traffic) regardless of its origin (local or 521 remote message). Therefore, no unnecessary protection switching is 522 performed and the user data traffic continues to be selected from the 523 active path. Giving the higher priority to the SD on the standby 524 path SHALL also be applied to the Local Request logic when two SDs 525 for different paths happen to be presented to the Local Request logic 526 exactly at the same time. 528 The change of the PSC control logic including state machine due to 529 the support of protection against SD is incorporated into the PSC 530 control logic description when all the capabilities are enabled in 531 Section 10 and Section 11. 533 8. Capability 5: Support of Exercise Command 535 Exercise is a command to test if the PSC communication is operating 536 correctly. More specifically, the Exercise is to test and validate 537 the linear protection mechanism and PSC protocol including the 538 aliveness of the Local Request logic, the PSC state machine and the 539 PSC message generation and reception, and the integrity of the 540 protection path, without triggering the actual traffic switching. It 541 is used while the working path is either carrying the traffic or not. 542 It is lower priority than any "real" switch request. It is only 543 valid in bidirectional switching, since this is the only place where 544 one can get a meaningful test by looking for a response. 546 This command is documented in R84 of [RFC5654] and it has been 547 identified as a requirement from ITU-T. 549 A received EXER message indicates that the remote end point is 550 operating under an operator command to validate the protection 551 mechanism and PSC protocol including the aliveness of the Local 552 Request logic, the PSC state machine and the PSC message generation 553 and reception, and the integrity of the protection path, without 554 triggering the actual traffic switching. The valid response to EXER 555 message will be an Reverse Request (RR) with the corresponding FPath 556 and Path numbers. The near end will signal a Reverse Request (RR) 557 only in response to an EXER command from the far end. 559 When Exercise commands are input at both ends, an EXER, instead of 560 RR, is transmitted from both ends. 562 The following PSC Requests should be added to PSC Request field to 563 support Exercise: 565 (TBD2) Exercise - indicates that the transmitting end point is 566 exercising the protection channel and mechanism. FPath and Path 567 are set to the same value of the NR, RR or DNR request that EXER 568 replaces. 570 (TBD1) Reverse Request - indicates that the transmitting end point 571 is responding to an EXER command from the far end. FPath and Path 572 are set to the same value of the NR, RR or DNR request that EXER 573 replaces. 575 The priority of Exercise should be inserted between the priorities of 576 WTR Expires and No Request. 578 9. Capabilities and Modes 580 9.1. Capabilities 582 A Capability is an individual behavior whose use is signalled in a 583 Capabilities TLV, which is placed in Optional TLVs field inside PSC 584 messages shown in Figure 2 of [RFC6378]. The format of the 585 Capabilities TLV is: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type = Capabilities | Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Value = Options | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 The value of the Type field is TBD3 pending IANA allocation. 597 The value of the Length field is the length of the Options Value, and 598 is in octets. 600 The Value of the Capabilities TLV can be any length, as long as it is 601 a multiple of 4 octets. The length of the Value field MUST be the 602 minimum required to signal all the required capabilities. Section 4 603 to Section 8 discuss five capabilities that are signalled using the 5 604 most significant bits; if a node wishes to signal these five 605 capabilities, it MUST send an Options Value of 4 octets. A node 606 would send an Options Value greater than 4 octets only if it had more 607 than 32 Capabilities to indicate. All unused bits MUST be set to 608 zero. 610 If the bit assigned for an individual capability is set to 1, it 611 indicates the sending node's intent to use that capability in the 612 protected domain. If a bit is set to 0, the sending node does not 613 intend to use the indicated capability in the protected domain. Note 614 that it is not possible to distinguish between the intent not to use 615 a capability and a node's complete non-support (i.e. lack of 616 implementation) of a given capability. 618 This document defines five specific capabilities that are described 619 from Section 4 to Section 8. Each capability is assigned bit as 620 follows: 622 0x80000000: priority modification 624 0x40000000: modification of non-revertive behavior 626 0x20000000: support of Manual Switch to Working (MS-W) command 628 0x10000000: support of protection against Signal Degrade (SD) 630 0x08000000: support of Exercise command 632 9.1.1. Sending the Capabilities TLV 634 PSC sends messages in response to external events and in periodic 635 retransmission of current status. It may be expensive to send and to 636 parse an Capabilities TLV attached to a packet intended to trigger a 637 protection switch or other real- time behavior. However, if a node 638 does not periodically send its Capabilities TLV, the receiving node 639 cannot discriminate a deliberate omission of the Capabilities TLV for 640 performance reasons from an accidental omission due to an 641 implementation issue. To guard against this, a node MUST include its 642 Capabilities TLV in every PSC message that it sends. 644 9.1.2. Receiving the Capabilities TLV 646 A node MUST establish a receive timer for the Capabilities TLV. By 647 default this MUST be 3.5 times the periodic retransmission timer of 648 five seconds - i.e., 17.5 seconds. Both the periodic retransmission 649 time and the timeout SHOULD be configurable by the operator. When a 650 node receives a Capabilities TLV it resets the timer to 17.5 seconds. 651 If the timer expires, the node behaves as in Section 9.1.3. 653 [Editor's note: In other packet transport protection technologies, 654 Failure of Protocol defect (dFOP) is declared when no protocol 655 message is received on the protection path during at least 3.5 times 656 the periodic message transmission interval (i.e., at least 17.5 657 seconds) and there is no defect on the protection transport entity. 658 As the "Capabilities TLV" is included in the PSC message, this error 659 of not receiving the Capabilities TLV can be covered by dFOP. To be 660 discussed.] 662 When a node receives a Capabilities TLV it MUST compare it to its 663 most recent transmitted Capabilities TLV. If the two are equal, the 664 protected domain is said to be running in the mode indicated by that 665 set of capabilities (see Section 9.2). If the sent and received 666 Capabilities TLVs are not equal, this indicates a capabilities 667 mismatch. When this happens, the node MUST alert the operator and 668 MUST behave as in Section 9.1.3. 670 9.1.3. Handling Capabilities TLV errors 672 This section covers the two possible errors - a TLV timeout and a TLV 673 mismatch - and the error handling procedures in both cases. 675 9.1.3.1. Capabilities TLV Timeout 677 If the Capabilities TLV receive timer expires, a node is said to have 678 timed out. When this happens, the node MUST alert the operator and 679 MUST behave as in Section 9.1.3.3. 681 9.1.3.2. Capabilities TLV Mismatch 683 If the sent and received Capabilities TLVs are not equal, this 684 indicates a capabilities mismatch. When this happens, the node MUST 685 alert the operator and MUST behave as in Section 9.1.3.3. A node MAY 686 retain the received TLV for logging, alert or debug purposes. 688 9.1.3.3. Handling Capabilities TLV error conditions 690 When a node enters in Capabilities protocol error conditions, the 691 following actions MUST be taken: 693 1. Indicate the error condition (e.g. either mismatch or timeout) to 694 the operator by the usual alert mechanisms (e.g. syslog). 696 2. Not make any state transitions based on the contents of any PSC 697 Messages 699 To expand on point 2 - assume node A is receiving NR(0,0) from its 700 PSC peer node Z and is also receiving a mismatched set of 701 capabilities (e.g. received 0x4, transmitted 0x5). If node Z detects 702 a local SF-W and wants to initiate a protection switch (that is, by 703 sending SF(1,1)), node A MUST NOT react to this input by changing its 704 state. A node MAY increase the severity or urgency of its alarms to 705 the operator, but until the operator resolves the mismatch in the 706 Capabilities TLV the protected domain will likely operate in an 707 inconsistent state. 709 9.2. Modes 711 A Mode is a given set of Capabilities. Modes are shorthand; 712 referring to a set of capabilities by their individual values or by 713 the name of their mode does not change the protocol behavior. This 714 document defines two modes - PSC and APS. 716 9.2.1. PSC Mode 718 PSC Mode is defined as the lack of any Capabilities - that is, a 719 Capabilities set of 0x0. It is the behavior specified in RFC6378. 720 There are two ways to declare PSC Mode. A node can send a 721 Capabilities TLV of 0x0, or it can send no Capabilities TLV at all. 722 This is further explored in Section 9.3. 724 9.2.2. APS Mode 726 APS Mode is defined as the use of all of the five specific 727 capabilities, which are described from Section 4 to Section 8 in this 728 document. APS Mode is indicated with a Value of 0xF8000000. 730 9.3. Backward compatibility 732 As defined in Section 9.2.1, PSC Mode is indicated either with a 733 Capabilities TLV of 0x0 or the lack of Capabilities TLV. This is to 734 allow backward compatibility between two nodes - one which can send 735 the Capabilities TLV, and one which cannot. 737 [RFC6378] does not define how to handle an unrecognized TLV. There 738 may be some implementations that silently discard an unrecognized 739 TLV, and some that take more drastic steps like refusing to allow PSC 740 to operate. Thus, a node which has the ability to send and receive 741 the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode 742 Capabilities TLV and send no Capabilities TLV at all. An 743 implementation MUST be configurable between these two choices. 745 One question that arises from this dual definition of PSC Mode is, 746 what happens if a node which was sending a non-null Capabilities TLV 747 (e.g. APS Mode) sends PSC packets without any Capabilities TLV? This 748 case is handled as follows: 750 If a node has never, during the life of a PSC session, received a 751 Capabilities TLV from a neighbour, the lack of a Capabilities TLV is 752 treated as receipt of a PSC Capabilities TLV. This allows for 753 interop between nodes which support the PSC Mode TLV and nodes which 754 do not, and are thus implicitly operating in PSC Mode. 756 If a node has received a non-null Capabilities TLV (e.g. APS Mode) 757 during the life of a PSC session and then receives a PSC packet with 758 no Capabilities TLV, the receiving node MUST treat the lack of 759 Capabilities TLV as simply a lack of refresh. That is, the receipt 760 of a PSC packet with no Capabilities TLV simply does not reset the 761 receive timer defined in Section 9.1.2. 763 10. PSC Protocol in APS Mode 765 This section and Section 11 defines the behavior of PSC protocol when 766 all of the aforementioned capabilities are enabled, i.e., APS mode. 768 10.1. Request field in PSC protocol message 770 The values of "Request" field in the PSC protocol message, which is 771 shown in Figure 2 of [RFC6378], are defined as follows: 773 (14) Lockout of protection 775 (12) Forced Switch 777 (10) Signal Fail 779 (7) Signal Degrade 781 (5) Manual Switch 783 (4) Wait-to-Restore 785 (TBD2) Exercise 787 (TBD1) Reverse Request 789 (1) Do-not-Revert 791 (0) No Request 793 10.2. Priorities of local inputs and remote requests 795 Based on the description in Section 3 and Section 4.3.2 in [RFC6378], 796 the priorities of multiple outstanding local inputs are evaluated in 797 Local Request logic unit, where the highest priority local request is 798 determined. This high-priority local request is passed to the PSC 799 Control logic, that will determine the higher priority input (top 800 priority global request) between the highest priority local input and 801 the last received remote message. When a remote message comes to the 802 PSC Control logic, the top priority global request is determined 803 between this remote message and the highest priority local input 804 which is present. The top priority global request is used to 805 determine the state transition, which is described in Section 11. 807 The priorities for both local and remote requests are defined as 808 follows from highest to lowest: 810 o Operator Clear (Local only) 812 o Lockout of protection (Local and Remote) 814 o Clear Signal Fail/Degrade (Local only) 816 o Signal Fail on Protection path (Local and Remote) 818 o Forced Switch (Local and Remote) 820 o Signal Fail on Working path (Local and Remote) 822 o Signal Degrade on either Protection path or Working path (Local 823 and Remote) 825 o Manual Switch to either Protection path or Working path (Local and 826 Remote) 828 o WTR Expires (Local only) 830 o WTR (Remote only) 832 o Exercise (Local and Remote) 834 o Reverse Request (Remote only) 836 o Do-Not-Revert (Remote only) 838 o No Request (Remote and Local) 840 The remote request from the far-end LER is assigned a priority just 841 below the same local request. However, for the equal priority 842 requests, such as Signal Degrade on either Working or protection and 843 Manual Switch to either Protection or Working path, the following 844 equal priority resolution rules are defined: 846 o If two local inputs having same priority but requesting different 847 action come to the Local Request logic, then the input coming 848 first SHALL be considered to have a higher priority than the other 849 coming later (first-come, first-served). 851 o If the LER receives both a local input and a remote message with 852 the same priority and requesting the same action, i.e., the same 853 PSC Request Field and the same FPath value, then the local input 854 SHALL be considered to have a higher priority than the remote 855 message. 857 o If the LER receives both a local input and a remote message with 858 the same priority but requesting different actions, i.e., the same 859 PSC Request Field but different FPath value, then the first-come, 860 first-served rule SHALL be applied. If the remote message comes 861 first, then the state SHALL be a remote state and subsequent local 862 input is ignored. However, if the local input comes first, the 863 first-come, first-served rule cannot be applied and must be viewed 864 as simultaneous condition. This is because the subsequent remote 865 message will not be an acknowledge of the local input by the far- 866 end node. In this case, the priority SHALL be determined by rules 867 for each simultaneous condition. 869 o If the LER receives both MS-P and MS-W requests as both local 870 input and remote message and the LER is in a local Switching 871 administrative state, then the MS-W request SHALL be considered to 872 have a higher priority than the MS-P request. 874 o If the LER receives both SD-P and SD-W requests as both local 875 input and remote message and the LER is in a local state, then the 876 SD on the standby path (the path from which the selector does not 877 select the user data traffic) SHALL be considered as having higher 878 priority than the SD on the active path (the path from which the 879 selector selects the user data traffic) regardless of its origin 880 (local or remote message). This rule of giving the higher 881 priority to the SD on the standby path SHALL also be applied to 882 the Local Request logic when two SDs for different paths happen to 883 be presented to the Local Request logic exactly at the same time. 885 11. State Transition Tables in APS Mode 887 When there is a change in the highest-priority local request or in 888 remote PSC messages, the top priority global request is evaluated and 889 the state transition tables are looked up in PSC control logic. The 890 following rules are applied to the operation related to the state 891 transition table lookup. 893 o If the top priority global request, which determines the state 894 transition, is the highest priority local input, the local state 895 transition table SHALL be used to decide the next state of the 896 LER. Otherwise, remote messages state transition table SHALL be 897 used. 899 o If in remote state, the highest local defect condition (SF-P, 900 SF-W, SD-P or SD-W) SHALL always be reflected in the Request Field 901 and Fpath. 903 o Operator Clear command, Clear SF/SD (SFc) and WTR Expires are not 904 persistent. Once they appear to the local priority logic and 905 complete the operation, they will be disappeared. 907 o For the LER currently in the local state, if the top priority 908 global request is changed to OC or SFc causing the next state to 909 be Normal, WTR or DNR, then all the local and remote requests 910 should be re-evaluated as if the LER is in the state specified in 911 the footnotes to the state transition tables, before deciding the 912 final state. This re-evaluation is an internal operation confined 913 within the local LER, and PSC messages are generated according to 914 the final state. 916 o The WTR timer is started only when the LER which has recovered 917 from a local failure/degradation enters the WTR state. An LER 918 which is entering into the WTR state due to a remote WTR message 919 does not start the WTR timer. 921 The extended states, as they appear in the table, are as follows: 923 N Normal state 924 UA:LO:L Unavailable state due to local LO command 925 UA:P:L Unavailable state due to local SF-P 926 UA:DP:L Unavailable state due to local SD-P 927 UA:LO:R Unavailable state due to remote LO message 928 UA:P:R Unavailable state due to remote SF-P message 929 UA:DP:L Unavailable state due to local SD-P 930 PF:W:L Protecting failure state due to local SF-W 931 PF:DW:L Protecting failure state due to local SD-W 932 PF:W:R Protecting failure state due to remote SF-W message 933 PF:DW:R Protecting failure state due to remote SD-W message 934 SA:F:L Switching administrative state due to local FS command 935 SA:MW:L Switching administrative state due to local MS-W command 936 SA:MP:L Switching administrative state due to local MS-P command 937 SA:F:R Switching administrative state due to remote FS message 938 SA:MW:R Switching administrative state due to remote MS-W message 939 SA:MP:R Switching administrative state due to remote MS-P message 940 E::L Exercise state due to local EXER command 941 E::R Exercise state due to remote EXER message 942 WTR Wait-to-Restore state 943 DNR Do-not-Revert state 944 Each state corresponds to the transmission of a particular set of 945 Request, FPath and Path bits. The table below lists the message that 946 is generally sent in each particular state. If the message to be 947 sent in a particular state deviates from the table below, it is noted 948 in the footnotes to the state transition tables. 950 State REQ(FP,P) 951 ------- --------- 952 N NR(0,0) 953 UA:LO:L LO(0,0) 954 UA:P:L SF(0,0) 955 UA:DP:L SD(0,0) 956 UA:LO:R highest local request(local FPath,0) 957 UA:P:R highest local request(local FPath,0) 958 UA:DP:R highest local request(local FPath,0) 959 PF:W:L SF(1,1) 960 PF:DW:L SD(1,1) 961 PF:W:R highest local request(local FPath,1) 962 PF:DW:R highest local request(local FPath,1) 963 SA:F:L FS(1,1) 964 SA:MW:L MS(0,0) 965 SA:MP:L MS(1,1) 966 SA:F:R highest local request(local FPath,1) 967 SA:MW:R highest local request(local FPath,0) 968 SA:MP:R highest local request(local FPath,1) 969 WTR WTR(0,1) 970 DNR DNR(0,1) 971 E::L EXER(0,x), where x is the existing Path value 972 when Exercise command is issued. 973 E::R RR(0,x), where x is the existing Path value 974 when RR message is generated. 976 11.1. State transition by local inputs 978 | OC | LO | SFc | SF-P | FS | SF-W | 979 --------+-----+---------+-----+--------+--------+--------+ 980 N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 981 UA:LO:L | [1] | i | i | i | i | i | 982 UA:P:L | i | UA:LO:L | [1] | i | i | i | 983 UA:DP:L | i | UA:LO:L | [1] | UA:P:L | SA:F:L | PF:W:L | 984 UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 985 UA:P:R | i | UA:LO:L | i | UA:P:L | PF:W:L | PF:W:L | 986 UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 987 PF:W:L | i | UA:LO:L | [2] | UA:P:L | SA:F:L | i | 988 PF:DW:L | i | UA:LO:L | [2] | UA:P:L | SA:F:L | PF:W:L | 989 PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 990 PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 991 SA:F:L | [3] | UA:LO:L | i | UA:P:L | i | i | 992 SA:MW:L | [1] | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 993 SA:MP:L | [3] | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 994 SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 995 SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 996 SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 997 WTR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 998 DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 999 E::L | [4] | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1000 E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1002 | SD-P | SD-W | MS-W | MS-P | WTRExp | EXER 1003 --------+---------+---------+---------+---------+--------+------ 1004 N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1005 UA:LO:L | i | i | i | i | i | i 1006 UA:P:L | i | i | i | i | i | i 1007 UA:DP:L | i | i | i | i | i | i 1008 UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i 1009 UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i 1010 UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i 1011 PF:W:L | i | i | i | i | i | i 1012 PF:DW:L | i | i | i | i | i | i 1013 PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i 1014 PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i 1015 SA:F:L | i | i | i | i | i | i 1016 SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i 1017 SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i 1018 SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i 1019 SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i 1020 SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i 1021 WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | [6] | i 1022 DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1023 E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i 1024 E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1026 11.2. State transition by remote messages 1028 | LO | SF-P | FS | SF-W | SD-P | SD-W | 1029 --------+---------+--------+--------+--------+---------+---------+ 1030 N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1031 UA:LO:L | i | i | i | i | i | i | 1032 UA:P:L | UA:LO:R | i | i | i | i | i | 1033 UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | [10] | 1034 UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1035 UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1036 UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R | 1037 PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i | 1038 PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | [11] | i | 1039 PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R | 1040 PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1041 SA:F:L | UA:LO:R | UA:P:R | i | i | i | i | 1042 SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1043 SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1044 SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R | 1045 SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1046 SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1047 WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1048 DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1049 E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1050 E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1052 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 1053 --------+---------+---------+-----+------+----+-----+---- 1054 N | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1055 UA:LO:L | i | i | i | i | i | i | i 1056 UA:P:L | i | i | i | i | i | i | i 1057 UA:DP:L | i | i | i | i | i | i | i 1058 UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1059 UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1060 UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1061 PF:W:L | i | i | i | i | i | i | i 1062 PF:DW:L | i | i | i | i | i | i | i 1063 PF:W:R | SA:MW:R | SA:MP:R | [7] | E::R | i | [8] | [5] 1064 PF:DW:R | SA:MW:R | SA:MP:R | [7] | E::R | i | [8] | [5] 1065 SA:F:L | i | i | i | i | i | i | i 1066 SA:MW:L | i | i | i | i | i | i | i 1067 SA:MP:L | i | i | i | i | i | i | i 1068 SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N 1069 SA:MW:R | i | SA:MP:R | i | E::R | i | i | N 1070 SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N 1071 WTR | SA:MW:R | SA:MP:R | i | i | i | i | [9] 1072 DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1073 E::L | SA:MW:R | SA:MP:R | i | i | i | i | i 1074 E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N 1076 NOTES: 1078 [1] Re-evaluate to determine final state as if the LER is in the 1079 Normal state. 1081 [2] In the case that both local input and the last received remote 1082 message are no request after the occurrence of SFc, the LER 1083 enters into the WTR state when the domain is configured for 1084 revertive behavior, or the LER enters into the DNR state when 1085 the domain is configured for non-revertive behavior. In all the 1086 other cases, re-evaluate to determine the final state as if the 1087 LER is in the Normal state. 1089 [3] Re-evaluate to determine final state as if the LER is in the 1090 Normal state when the domain is configured for revertive 1091 behavior, or as if the LER is in the DNR state when the domain 1092 is configured for non-revertive behavior, 1094 [4] If Path value is 0, re-evaluate to determine final state as if 1095 the LER is in the Normal state. If Path value is 1, re-evaluate 1096 to determine final state as if the LER is in the DNR state 1098 [5] If the received NR message has Path=1, transition to WTR if 1099 domain configured for revertive behavior, else transition to 1100 DNR. 1102 [6] Remain in WTR, send NR(0,1). 1104 [7] Transition to WTR state and continue to send the current 1105 message. 1107 [8] Transition to DNR state and continue to send the current 1108 message. 1110 [9] If the receiving LER's WTR timer is running, maintain current 1111 state and message. If the WTR timer is not running, transition 1112 to N. 1114 [10] If the active path just before the SD is selected as the highest 1115 local input was the working path, then ignore. Otherwise, go to 1116 PF:DW:R and transmit SD(0,1) 1118 [11] If the received SD-P message has Path=1, ignore the message. If 1119 the received SD-P message has Path=0 and the active path just 1120 before the SD is selected as the highest local input was the 1121 working path, then go to UA:DP:R and transmit SD(1,0). If the 1122 received SD-P message has Path=0 and the active path just before 1123 the SD is selected as the highest local input was the protection 1124 path, then ignore the received SD-P message. 1126 12. Security considerations 1128 No specific security issue is raised in addition to those ones 1129 already documented in [RFC6378] 1131 13. IANA considerations 1133 13.1. PSC Request Field 1135 This document defines two new values in the "MPLS PSC Request 1136 Registry". 1138 The PSC Request Field is 4 bits, and the two new values have been 1139 allocated as follows: 1141 Value Description Reference 1142 ----- --------------------- --------------- 1143 TBD1 Reverse Request [this document] 1144 TBD2 Exercise [this document] 1146 [to be removed upon publication: It is requested to assign 2 1147 (=TBD1)for the Reverse Request value and 3 (=TBD2) for the Exercise 1148 value to be aligned with the priority levels of those two requests 1149 defined in this document.] 1151 13.2. PSC TLV 1153 This document defines a new value for the Capabilities TLV type in 1154 the "MPLS PSC TLV Registry". 1156 Type TLV Name Reference 1157 ----- --------------------- --------------- 1158 TBD3 Capabilities [this document] 1160 [Editor's note: Need to specify a registry for Value (=options) 1161 inside the Capabilities TLV in a later version of this draft] 1163 14. Acknowledgements 1165 15. References 1166 15.1. Normative References 1168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1169 Requirement Levels", BCP 14, RFC 2119, March 1997. 1171 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1172 Restoration) Terminology for Generalized Multi-Protocol 1173 Label Switching (GMPLS)", RFC 4427, March 2006. 1175 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1176 and S. Ueno, "Requirements of an MPLS Transport Profile", 1177 RFC 5654, September 2009. 1179 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1180 TP) Survivability Framework", RFC 6372, September 2011. 1182 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1183 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1184 Protection", RFC 6378, October 2011. 1186 15.2. Informative References 1188 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1189 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1190 May 2008. 1192 Appendix A. An example of out-of-service scenarios 1194 The sequence diagram shown is an example of the out-of-service 1195 scenerios based on the priority level defined in [RFC6378]. The 1196 first PSC message which differs from the previous PSC message is 1197 shown. 1199 A Z 1200 | | 1201 (1) |-- NR(0,0) ------>| (1) 1202 |<----- NR(0,0) ---| 1203 | | 1204 | | 1205 | (FS issued at Z) | (2) 1206 (3) |<------ FS(1,1) --| 1207 |-- NR(0,1) ------>| 1208 | | 1209 | | 1210 (4) | (SF on P(A<-Z)) | 1211 | | 1212 | | 1213 | (Clear FS at Z) | (5) 1215 (6) | X <- NR(0,0) --| 1216 | | 1217 | | 1219 (1) Each end is in Normal state, and transmits NR (0,0) messages. 1221 (2) When a Forced Switch command is issued at node Z, node Z goes 1222 into local Protecting Administrative state (PA:F:L) and begins 1223 transmission of an FS (1,1) messages. 1225 (3) A remote Forced Switch message causes node A to go into remote 1226 Protecting Administrative state (PA:F:R), and node A begins 1227 transmitting NR (0,1) messages. 1229 (4) When node A detects a unidirectional Signal Fail on the 1230 Protection path, node A keeps sending NR (0,1) message because SF-P 1231 is ignored under the state PA:F:R. 1233 (5) When a Clear command is issued at node Z, node Z goes into Normal 1234 state and begins transmission of NR (0,0) messages. 1236 (6) But node A cannot receive PSC message because of local 1237 unidirectional Signal Fail on the Protection path. Because no valid 1238 PSC message is received, over a period of several successive message 1239 intervals, the last valid received message remains applicable and the 1240 node A continue to transmit an NR (0,1) message in the state of 1241 PA:F:R. 1243 Now, there exists a mismatch between the bridge/selector positions of 1244 node A (transmitting an NR (0,1)) and node Z (transmitting an NR 1245 (0,0)). It results in out-of-service even when there is neither 1246 signal fail on working path nor FS. 1248 Appendix B. An example of sequence diagram showing the problem with the 1249 priority level of Clear SF 1251 An example of sequence diagram showing the problem with the priority 1252 level of Clear SF defined in [RFC6378] is given below. The following 1253 sequence diagram is depicted for the case of bidirectional signal 1254 fails. However, other cases with unidirectional signal fails can 1255 result in the same problem. The first PSC message which differs from 1256 the previous PSC message is shown. 1258 A Z 1259 | | 1260 (1) |-- NR(0,0) ------>| (1) 1261 |<----- NR(0,0) ---| 1262 | | 1263 | | 1264 (2) | (SF on P(A<->Z)) | (2) 1265 |-- SF(0,0) ------>| 1266 |<------ SF(0,0) --| 1267 | | 1268 | | 1269 (3) | (SF on W(A<->Z)) | (3) 1270 | | 1271 | | 1272 (4) | (Clear SF-P) | (4) 1273 | | 1274 | | 1275 (5) | (Clear SF-W) | (5) 1276 | | 1277 | | 1279 (1) Each end is in Normal state, and transmits NR (0,0) messages. 1281 (2) When signal fail on protection (SF-P) occurs, each node enters 1282 into [UA:P:L] state and transmits SF (0,0) messages. Traffic remains 1283 on working path. 1285 (3) When signal fail on working (SF-W) occurs, each node remains in 1286 [UA:P:L] state as SF-W has a lower priority than SF-P. Traffic is 1287 still on the working path. Traffic cannot be delivered as both 1288 working and protection paths are experiencing signal fails. 1290 (4) When the signal fail on protection is cleared, local "Clear SF-P" 1291 request cannot be presented to the PSC control logic, which takes the 1292 highest priority local request and runs PSC state machine, as the 1293 priority of "Clear SF-P" is lower than that of SF-W. Consequently, 1294 there is no change in state, and the selector and/or bridge keep 1295 pointing at the working path, which has signal fail condition. 1297 Now, traffic cannot be delivered while the protection path is 1298 recovered and available. It should be noted that the same problem 1299 will occur in the case that the sequence of SF-P and SF-W events is 1300 changed. 1302 If we further continue with this sequence to see what will happen 1303 after SF-W is cleared, 1305 (5) When the signal fail on working is cleared, local "Clear SF-W" 1306 request can be passed to the PSC control logic (state machine) as 1307 there is no higher priority local request, but this will be ignored 1308 in the PSC control logic according to the state transition definition 1309 in [RFC6378]. There will be no change in state or protocol message 1310 transmitted. 1312 As the signal fail on working is now cleared and the selector and/or 1313 bridge are still pointing at the working path, traffic delivery is 1314 resumed. However, each node is in [UA:P:L] state and transmitting 1315 SF(0,0) message, while there exists no outstanding request for 1316 protection switching. Moreover, any future legitimate protection 1317 switching requests, such as SF-W, will be rejected as each node 1318 thinks the protection path is unavailable. 1320 Appendix C. Freeze Command 1322 The "Freeze" command applies only to the near end (local node) of the 1323 protection group and is not signalled to the far end. This command 1324 freezes the state of the protection group. Until the Freeze is 1325 cleared, additional near end commands are rejected and condition 1326 changes and received PSC information are ignored. 1328 "Clear Freeze" command clears the local freeze. When the Freeze 1329 command is cleared, the state of the protection group is recomputed 1330 based on the persistent condition of the local triggers. 1332 Because the freeze is local, if the freeze is issued at one end only, 1333 a failure of protocol can occur as the other end is open to accept 1334 any operator command or a fault condition. 1336 Authors' Addresses 1338 Jeong-dong Ryoo (editor) 1339 ETRI 1340 218 Gajeongno 1341 Yuseong-gu, Daejeon 305-700 1342 South Korea 1344 Phone: +82-42-860-5384 1345 Email: ryoo@etri.re.kr 1347 Eric Gray (editor) 1348 Ericsson 1350 Email: eric.gray@ericsson.com 1351 Huub van Helvoort 1352 Huawei Technologies 1353 Karspeldreef 4, 1354 Amsterdam 1101 CJ 1355 the Netherlands 1357 Phone: +31 20 4300936 1358 Email: huub.van.helvoort@huawei.com 1360 Alessandro D'Alessandro 1361 Telecom Italia 1362 via Reiss Romoli, 274 1363 Torino 10148 1364 Italy 1366 Phone: +39 011 2285887 1367 Email: alessandro.dalessandro@telecomitalia.it 1369 Taesik Cheung 1370 ETRI 1371 218 Gajeongno 1372 Yuseong-gu, Daejeon 305-700 1373 South Korea 1375 Phone: +82-42-860-5646 1376 Email: cts@etri.re.kr 1378 Eric Osborne 1379 Cisco Systems, Inc. 1381 Email: eosborne@cisco.com