idnits 2.17.1 draft-ietf-mpls-tp-psc-itu-02.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 (February 8, 2014) is 3728 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: August 12, 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 February 8, 2014 16 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the 17 Operational Expectations of SDH, OTN and Ethernet Transport Network 18 Operators 19 draft-ietf-mpls-tp-psc-itu-02.txt 21 Abstract 23 This document describes alternate mechanisms to perform some of the 24 sub-functions of MPLS Transport Profile (MPLS-TP) linear protection 25 defined in RFC 6378, and also defines additional mechanisms. The 26 purpose of these alternate and additional mechanisms is to provide 27 operator control and experience that more closely models the behavior 28 of linear protection seen in other transport networks. 30 This document also introduces capabilities and modes for linear 31 protection. A capability is an individual behavior, and a mode is a 32 particular combination of capabilities. Two modes are defined in 33 this document: Protection State Coordination (PSC) mode and Automatic 34 Protection Switching (APS) mode. 36 This document describes the behavior of the PSC protocol including 37 priority logic and state machine when all the capabilities associated 38 with the APS mode are enabled. 40 This document updates RFC 6378 in that the capability advertisement 41 method defined here is an addition to that document. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on August 12, 2014. 60 Copyright Notice 62 Copyright (c) 2014 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 79 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Capability 1: Priority Modification . . . . . . . . . . . . . 6 81 4.1. Motivations for swapping priorities of FS and SF-P . . . 6 82 4.2. Motivation for raising the priority of SFc . . . . . . . 7 83 4.3. Motivation for introducing Freeze command . . . . . . . . 7 84 4.4. Procedures in support of Capability 1 . . . . . . . . . . 7 85 5. Capability 2: Non-revertive Behavior Modification . . . . . . 8 86 6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8 87 6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8 88 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9 89 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9 90 6.4. Equal priority resolution for MS . . . . . . . . . . . . 9 91 7. Capability 4: Support of Protection against SD . . . . . . . 10 92 7.1. Motivation for supporting protection against SD . . . . . 10 93 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10 94 7.3. Behavior of protection against SD . . . . . . . . . . . . 11 95 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12 97 8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13 98 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14 99 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 100 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15 101 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16 103 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16 104 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16 105 10.1. Request field in PSC protocol message . . . . . . . . . 16 106 10.2. Priorities of local inputs and remote requests . . . . . 16 107 10.3. Acceptance and retention of local inputs . . . . . . . . 19 108 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19 109 11.1. State transition by local inputs . . . . . . . . . . . . 22 110 11.2. State transition by remote messages . . . . . . . . . . 24 111 11.3. State transition for 1+1 unidirectional 112 protection . . . . . . . . . . . . . . . . . . . . . . . 26 113 12. Provisioning Mismatch and Protocol Failure in the APS Mode . 27 114 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 115 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 116 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28 117 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28 118 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 120 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 121 16.1. Normative References . . . . . . . . . . . . . . . . . . 29 122 16.2. Informative References . . . . . . . . . . . . . . . . . 29 123 Appendix A. An Example of Out-of-service Ccenarios . . . . . . . 30 124 Appendix B. An Example of Sequence Diagram Showing 125 the Problem with the Priority Level of SFc . . . . . 31 126 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33 127 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 130 1. Introduction 132 Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) 133 are described in RFC 6378 [RFC6378] to meet the requirements 134 described in RFC 5654 [RFC5654]. 136 This document describes alternate mechanisms to perform some of the 137 sub-functions of linear protection, and also defines additional 138 mechanisms. The purpose of these alternate and additional mechanisms 139 is to provide operator control and experience that more closely 140 models the behavior of linear protection seen in other transport 141 networks, such as Synchronous Digital Hierarchy (SDH), Optical 142 Transport Network (OTN) and Ethernet transport networks. Linear 143 protection for SDH, OTN, and Ethernet transport networks are defined 144 in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031 145 [G8031], respectively. 147 The reader of this document is assumed to be familiar with RFC 6378. 149 The alternative mechanisms described in this document are for the 150 following capabilities: 152 1. Priority modification, 154 2. non-revertive behavior modification, 156 and the following capabilities have been added to define additional 157 mechanisms: 159 3. support of Manual Switch to Working path (MS-W) command, 161 4. support of protection against Signal Degrade (SD), and 163 5. support of Exercise (EXER) command. 165 Priority modification includes priority swapping between Signal Fail 166 on Protection path (SF-P) and Forced Switch (FS), and raising the 167 priority level of Clear Signal Fail (SFc). 169 Non-revertive behavior is modified to align with the behavior defined 170 in RFC 4427 [RFC4427] as well as to follow the behavior of linear 171 protection seen in other transport networks. 173 Support of MS-W command to revert traffic to the working path in non- 174 revertive operation is covered in this document. 176 Support of protection switching protocol against SD is covered in 177 this document. The specifics for the method of identifying SD is out 178 of the scope of this document similarly to Signal Fail (SF) for RFC 179 6378. 181 Support of EXER command to test if the Protection State Coordination 182 (PSC) communication is operating correctly is also covered in this 183 document. More specifically, EXER command tests and validates the 184 linear protection mechanism and PSC protocol including the aliveness 185 of the priority logic, the PSC state machine and the PSC message 186 generation and reception, and the integrity of the protection path, 187 without triggering the actual traffic switching. 189 This document introduces capabilities and modes. A capability is an 190 individual behavior. The capabilities of a node are advertised using 191 the method given in this document. A mode is a particular 192 combination of capabilities. Two modes are defined in this document: 193 PSC mode and Automatic Protection Switching (APS) mode. 195 This document describes the behavior of the PSC protocol including 196 the priority logic and the state machine when all the capabilities 197 associated with the APS mode are enabled. The PSC protocol behavior 198 for the PSC mode is as defined in RFC 6378. 200 This document updates RFC 6378 by adding a capability advertisement 201 mechanism. It is recommended that existing implementations of RFC 202 6378 should be updated to support this capability. The backward 203 compatibility with existing implementations is described in 204 Section 9.2.1. 206 2. Conventions Used in This Document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC 2119 [RFC2119]. 212 3. Acronyms 213 This document uses the following acronyms: 215 APS Automatic Protection Switching 216 DNR Do-not-Revert 217 EXER Exercise 218 FS Forced Switch 219 LER Label Edge Router 220 LO Lockout of protection 221 MS Manual Switch 222 MS-P Manual Switch to Protection path 223 MS-W Manual Switch to Working path 224 MPLS-TP MPLS Transport Profile 225 NR No Request 226 OC Operator Clear 227 OTN Optical Transport Network 228 PSC Protection State Coordination 229 RR Reverse Request 230 SD Signal Degrade 231 SDH Synchronous Digital Hierarchy 232 SD-P Signal Degrade on Protection path 233 SD-W Signal Degrade on Working path 234 SF Signal Fail 235 SFc Clear Signal Fail 236 SFDc Clear Signal Fail or Degrade 237 SF-P Signal Fail on Protection path 238 SF-W Signal Fail on Working path 239 WTR Wait-to-Restore 241 4. Capability 1: Priority Modification 243 RFC 6378 [RFC6378] defines the priority of FS to be higher than that 244 of SF-P. That document also defines the priority of Clear SF (SFc) 245 to be low. This document defines the priority modification 246 capability whereby the priorities of FS and SF-P are swapped and the 247 priority of Clear SF (SFc) is raised. In addition, this capability 248 introduces the use of Freeze command as described in Appendix C. The 249 reasons for these changes are explained in the following sub-sections 250 from technical and network operational aspects. 252 4.1. Motivations for swapping priorities of FS and SF-P 254 Defining the priority of FS higher than that of SF-P can result in a 255 situation where the protected traffic is taken out-of-service. When 256 the protection path fails PSC communication may stop as a result. In 257 this case, if any input that is supposed to be signaled to the other 258 end has a higher priority than SF-P then this can result in 259 unpredictable protection switching state. An example of the out-of- 260 service scenarios is shown in Appendix A. 262 According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to 263 operate an MPLS-TP network without using a control plane. This means 264 that the PSC communication channel is very important for the transfer 265 of external switch commands (e.g., FS), and these commands should not 266 rely on the presence of a control plane. In consequence, the failure 267 of the PSC communication channel has higher priority than FS. 269 In other transport networks (such as SDH, OTN, and Ethernet transport 270 networks) the priority of SF-P has been higher than that of FS. It 271 is therefore important to offer network operators the option of 272 having the same behavior in their MPLS-TP network so that they can 273 have the same operational protection switching behavior to which they 274 have become accustomed. Typically, FS command is issued before 275 network maintenance jobs, (e.g., replacing optical cables or other 276 network components). When an operator pulls out a cable on the 277 protection path by mistake, the traffic should be protected and the 278 operator expects this behavior based on his/her experience on the 279 traditional transport network operations. 281 4.2. Motivation for raising the priority of SFc 283 The priority level of SFc defined in RFC 6378 can cause traffic 284 disruption when a node that has experienced local signal fails on 285 both the working and the protection paths is recovering from these 286 failures. 288 An example of sequence diagram showing the problem with the priority 289 level of SFc as defined in RFC 6378 is shown in Appendix B. 291 4.3. Motivation for introducing Freeze command 293 With the priority swapping between FS and SF-P, the traffic is always 294 moved back to the working path when SF-P occurs in Protecting 295 administrative state. In the case that network operators need an 296 option to control their networks so that the traffic can remain on 297 the protection path even when the PSC communication channel is 298 broken, the Freeze command, which is a local command (i.e., not 299 signaled to the other end) can be used. The use of the Freeze 300 command is described in Appendix C. 302 4.4. Procedures in support of Capability 1 304 When this capability is in use the list of local requests in order of 305 priority SHALL be as follows: 307 (from higher to lower) 309 o Clear Signal Fail 310 o Signal Fail on Protection path 312 o Forced Switch 314 o Signal Fail on Working path 316 This requires different PSC Control logic (including the state 317 machine) compared to that described in RFC 6378. Section 10 and 318 Section 11 show the PSC Control logic when all of the capabilities in 319 APS mode are enabled. 321 5. Capability 2: Non-revertive Behavior Modification 323 Non-revertive mode of protection switching is defined in RFC 4427 324 [RFC4427]. In this mode, the traffic does not return to the working 325 path when switch-over requests are terminated. 327 However, the PSC protocol defined in RFC 6378 [RFC6378] supports this 328 operation only when recovering from a defect condition: it does not 329 support the non-revertive function when an operator's switch-over 330 command, such as FS or Manual Switch (MS), is cleared. To be aligned 331 with the behavior in other transport networks and to be consistent 332 with RFC 4427, a node should go into the Do-not-Revert (DNR) state 333 not only when a failure condition on the working path is cleared, but 334 also when an operator command that requested switch-over is cleared. 336 This requires different PSC Control logic (including the state 337 machine) compared to that described in RFC 6378. Section 10 and 338 Section 11 show the PSC Control logic when all of the capabilities in 339 APS mode are enabled. 341 6. Capability 3: Support of MS-W Command 343 6.1. Motivation for adding MS-W 345 Changing the non-revertive operation as described in Section 5 346 introduces necessity of a new operator command to revert traffic to 347 the working path when in the DNR state. When the traffic is on the 348 protection path in the DNR state, a Manual Switch to Working (MS-W) 349 command is issued to switch the normal traffic back to working path. 350 According to Section 4.3.3.6 (Do-not-Revert State) in RFC 6378 351 [RFC6378], "to revert back to Normal state, the administrator SHALL 352 issue a Lockout of protection (LO) command followed by a Clear 353 command." However, using LO command introduces the potential risk of 354 an unprotected situation while the LO is in effect. 356 Manual Switch-over for recovery LSP/span command is defined in RFC 357 4427 [RFC4427]. Requirement 83 in RFC 5654 [RFC5654] states that the 358 external commands defined in RFC 4427 must be supported. No such 359 command is supported in PSC as defined in RFC 6378 so there is a need 360 to provide support for that feature. Note that the "Manual Switch- 361 over for recovery LSP/span" command is the same as the MS-W command. 363 6.2. Terminology to support MS-W 365 RFC 6378 uses the term "Manual Switch" and its acronym "MS". This 366 document uses the term "Manual Switch to Protection path" and "MS-P" 367 to have the same meaning, but avoid confusion with "Manual Switch to 368 Working path" and its acronym "MS-W". 370 Similarly, RFC 6378 uses the term "Protecting administrative state", 371 and this document uses "Switching administrative state" to cover the 372 same concept but also include the case where traffic is switched back 373 to the working path by administrative MS-W command. 375 6.3. Behavior of MS-P and MS-W 377 If one of the MS-P and MS-W commands is received and processed after 378 the other, the two commands SHALL have the same priority such that if 379 one of the commands is already issued and accepted, the command that 380 is issued afterwards SHALL be ignored. However, if two Label Edge 381 Routers (LERs) request opposite operations simultaneously (i.e., one 382 LER sends MS-P and the other sends MS-W), the MS-W SHALL be 383 considered to have a higher priority than MS-P, and MS-P SHALL NOT be 384 accepted and SHALL be cancelled. 386 Two commands, MS-P and MS-W are represented by the same Request field 387 value, but differentiated by the FPath value. When traffic is 388 switched to the protection path, the FPath field SHALL indicate that 389 the working path is being blocked (i.e., FPath set to 1), and the 390 Path field SHALL indicate that user data traffic is being transported 391 on the protection path (i.e., Path set to 1). When traffic is 392 switched to the working path, the FPath field SHALL indicate that the 393 protection path is being blocked (i.e., FPath set to 0), and the Path 394 field SHALL indicate that user data traffic is being transported on 395 the working path (i.e., Path set to 0). 397 When an MS command is in effect at an LER, any subsequent MS or EXER 398 command and any other lower priority requests SHALL be ignored. 400 6.4. Equal priority resolution for MS 402 RFC 6378 defines only one rule for equal priority condition in 403 Section 4.3.2 as "The remote message from the remote LER is assigned 404 a priority just below the similar local input." In order to support 405 the manual switch behavior described in Section 6.3, additional rules 406 for equal priority resolution are required. Since the support of 407 protection against signal degrade also requires a similar equal 408 priority resolution, the rules are described in Section 7.4. 410 Support of this function requires changes to the PSC Control logic 411 (including the state machine) compared to that shown in RFC 6378. 412 Section 10 and Section 11 show the PSC Control logic when all of the 413 capabilities in APS mode are enabled. 415 7. Capability 4: Support of Protection against SD 417 7.1. Motivation for supporting protection against SD 419 In MPLS-TP survivability framework [RFC6372], fault conditions 420 include both SF and SD that can be used to trigger protection 421 switching. 423 RFC 6378 [RFC6378], which defines the protection switching protocol 424 for MPLS-TP does not specify how the SF and SD are detected, and 425 specifies the protection switching protocol associated with SF only. 427 The PSC protocol associated with SD is covered in this document, but 428 the specifics for the method of identifying SD is out of the scope of 429 the protection protocol similar to the facts that how SF is detect 430 and how MS and FS commands are initiated in a management system and 431 signaled to protection switching are out of its scope. 433 7.2. Terminology to support SD 435 In this document the term Clear Signal Fail or Degrade (SFDc) is used 436 to indicate the clearance of either a degraded condition or a failure 437 condition. 439 The second paragraph of Section 4.3.3.2 Unavailable state in RFC 6378 440 shows the intention of including Signal Degrade on Protection path 441 (SD-P) in the Unavailable state. Even though the protection path can 442 be partially available under the condition of SD-P, this document 443 follows the same state grouping as RFC 6378 for SD-P. 445 The bullet item "Protecting failure state" in Section 3.6 in RFC 6378 446 includes the degraded condition in Protecting failure state. This 447 document follows the same state grouping as RFC 6378 for Signal 448 Degrade on Working path (SD-W). 450 7.3. Behavior of protection against SD 452 In order to make the behavior of MPLS-TP networks consistent with 453 that of other transport networks (such as SDH, OTN and Ethernet 454 transport networks), the priorities of SD-P and SD-W are defined to 455 be equal. Once a switch has been completed due to SD on one path, it 456 will not be overridden by SD on the other path (first come, first 457 served behavior), to avoid protection switching that cannot improve 458 signal quality. 460 SD indicates that the transmitting end point has identified a 461 degradation of the signal, or integrity of the packet transmission on 462 either the working path or the protection path. The FPath field 463 SHALL identify the path that is reporting the degrade condition 464 (i.e., if the protection path, then FPath is set to 0; if the working 465 path, then FPath is set to 1), and the Path field SHALL indicate 466 where the data traffic is being transported (i.e., if the working 467 path is selected, then Path is set to 0; if the protection path is 468 selected, then Path is set to 1). 470 The Wait-to-Restore (WTR) timer is used when the protected domain is 471 configured for revertive behavior and started at the node that 472 recovers from a local degraded condition on the working path. 474 Protection switching against SD is always provided by a selector 475 bridge duplicating user data traffic and feeding it to both the 476 working path and the protection path under SD condition. When a 477 local or remote SD occurs on either the working path or the 478 protection path, the LER SHALL duplicate user data traffic and SHALL 479 feed to both the working path and the protection path. The packet 480 duplication SHALL continue as long as any SD condition exists in the 481 protected domain, and SHALL stop when there is no SD condition. 482 Additionally, the packet duplication SHALL continue in the WTR state 483 in revertive mode. In non-revertive mode, the packet duplication 484 SHALL stop when there is no SD condition. 486 The selector bridge with the packet duplication under SD condition, 487 which is a non-permanent bridge, is considered to be a 1:1 protection 488 architecture. 490 Protection switching against SD does not introduce any modification 491 to the operation of the selector at the sink LER described in RFC 492 6378. The selector chooses either the working or protection path 493 from which to receive the normal traffic in both 1:1 and 1+1 494 architectures. The position of the selector, i.e., which path to 495 receive the traffic, is determined by the PSC protocol in 496 bidirectional switching or by the local input in unidirectional 497 switching. 499 7.4. Equal priority resolution 501 In order to support the manual switch behavior described in 502 Section 6.3 and the protection against Signal Degrade described in 503 Section 7.3, the rules to resolve the equal priority requests are 504 required. 506 For the equal priority local inputs, such as MS and SD, first-come, 507 first-served rule is applied. Once a local input is determined as 508 the highest priority local input, then a subsequent equal priority 509 local input requesting a different action, i.e., the action results 510 in the same PSC Request field but different FPath value, will not be 511 presented to the PSC Control logic as the highest local request. 512 Furthermore, in the case of MS command, the subsequent local MS 513 command requesting a different action will be cancelled. 515 If the LER is in a remote state due to a remote SD (or MS) message, a 516 subsequent local input having the same priority but requesting 517 different action to the PSC Control logic, will be considered as 518 having lower priority than the remote message, and will be ignored. 519 If the LER is in remote Switching administrative state due to a 520 remote MS-P, then subsequent local MS-W SHALL be ignored and 521 automatically cancelled. If the LER is in remote Unavailable state 522 due to a remote SD-P, then subsequent local SD-W input will be 523 ignored. However, the local SD-W SHALL appear in the Local Request 524 logic as long as the SD condition exists, but SHALL NOT be the top 525 priority global request, which determines the state transition at the 526 PSC Control logic. 528 There is a case where one LER receives a local input and the other 529 LER receives, simultaneously, a local input with the same priority 530 but requesting different action. In this case, each of the two LERs 531 receives a subsequent remote message having the same priority but 532 requesting different action, while the LER is in a local state due to 533 the local input. When this case happens, a priority must be set for 534 the inputs with the same priority regardless of its origin (local 535 input or remote message). 537 o When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL 538 be considered as having higher priority than MS-P at both LERs. 540 o When SD-W and SD-P occur simultaneously at both LERs, the SD on 541 the standby path (the path from which the selector does not select 542 the user data traffic) is considered as having higher priority 543 than the SD on the active path (the path from which the selector 544 selects the user data traffic) regardless of its origin (local or 545 remote message). Therefore, no unnecessary protection switching 546 is performed and the user data traffic continues to be selected 547 from the active path. 549 In the preceding paragraphs, the "simultaneously" refers to the case 550 a sent SD (or MS) request has not been confirmed by the remote end in 551 bidirectional protection switching. When a local node that has 552 transmitted a SD message receives a SD (or MS) message that indicates 553 a different value of data path (Path) field than the value of the 554 Path field in the transmitted SD (or MS) message, both the local and 555 the remote SD requests are considered to occur simultaneously. 557 The addition of support for protection against SD requires different 558 PSC Control logic (including the state machine) compared to that 559 shown in RFC 6378. Section 10 and Section 11 show the PSC Control 560 logic when all of the capabilities in APS mode are enabled. 562 8. Capability 5: Support of EXER Command 564 EXER is a command to test if the PSC communication is operating 565 correctly. More specifically, EXER is to test and validate the 566 linear protection mechanism and PSC protocol including the aliveness 567 of the Local Request logic, the PSC state machine and the PSC message 568 generation and reception, and the integrity of the protection path, 569 without triggering the actual traffic switching. It is used while 570 the working path is either carrying the traffic or not. It has lower 571 priority than any "real" switch request. It is only valid in 572 bidirectional switching, since this is the only place where one can 573 get a meaningful test by looking for a response. 575 This command is documented in R84 of RFC 5654 [RFC5654]. 577 A received EXER message indicates that the remote end point is 578 operating under an operator command to validate the protection 579 mechanism and PSC protocol including the aliveness of the Local 580 Request logic, the PSC state machine and the PSC message generation 581 and reception, and the integrity of the protection path, without 582 triggering the actual traffic switching. The valid response to EXER 583 message is an Reverse Request (RR) with the corresponding FPath and 584 Path numbers. The local LER SHALL signal a RR only in response to an 585 EXER command from the remote LER. 587 If EXER commands are input at both ends, then a race condition may 588 arise. This is resolved as follows: 590 o If an LER has issued EXER and receives EXER before receiving RR, 591 it 593 o MUST treat the received EXER as it would an RR, and 594 o SHOULD NOT respond with RR. 596 The following PSC Requests are added to the PSC Request field to 597 support the Exercise command (see also Section 14.1): 599 (3) Exercise - indicates that the transmitting end point is 600 exercising the protection channel and mechanism. FPath and Path 601 are set to the same value of the No Request (NR), RR or DNR 602 request that EXER replaces. 604 (2) Reverse Request - indicates that the transmitting end point is 605 responding to an EXER command from the remote LER. FPath and Path 606 are set to the same value of the NR or DNR request that RR 607 replaces. 609 The relative priorities of EXER and RR are shown in Section 10.2. 611 9. Capabilities and Modes 613 9.1. Capabilities 615 A Capability is an individual behavior whose use is signaled in a 616 Capabilities TLV, which is placed in Optional TLVs field inside the 617 PSC message shown in Figure 2 of RFC 6378 [RFC6378]. The format of 618 the Capabilities TLV is: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type = Capabilities | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Value = Flags | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Figure 1: Format of Capabilities TLV 630 The value of the Type field is TBD pending IANA allocation. 632 The value of the Length field is the length of the Flags field in 633 octets. The length of the Flags field MUST be a multiple of 4 octets 634 and MUST be the minimum required to signal all the required 635 capabilities. 637 Section 4 to Section 8 discuss five capabilities that are signaled 638 using the five most significant bits; if a node wishes to signal 639 these five capabilities, it MUST send a Flags field of 4 octets. A 640 node would send a Flags field greater than 4 octets only if it had 641 more than 32 Capabilities to indicate. All unused bits MUST be set 642 to zero. 644 If the bit assigned for an individual capability is set to 1, it 645 indicates the sending node's intent to use that capability in the 646 protected domain. If a bit is set to 0, the sending node does not 647 intend to use the indicated capability in the protected domain. Note 648 that it is not possible to distinguish between the intent not to use 649 a capability and a node's complete non-support (i.e., lack of 650 implementation) of a given capability. 652 This document defines five specific capabilities that are described 653 from Section 4 to Section 8. Each capability is assigned bit as 654 follows: 656 0x80000000: priority modification 658 0x40000000: non-revertive behavior modification 660 0x20000000: support of MS-W command 662 0x10000000: support of protection against SD 664 0x08000000: support of EXER command 666 If all the five capabilities should be used, an LER SHALL set 667 0xF8000000 in the Flags field. 669 9.1.1. Sending and receiving the Capabilities TLV 671 A node MUST include its Capabilities TLV in every PSC message that it 672 sends. The transmission and acceptance of the PSC message is 673 described in Section 4.1 of RFC 6378. 675 When a node receives a Capabilities TLV it MUST compare it to its 676 most recent transmitted Capabilities TLV. If the two are equal, the 677 protected domain is said to be running in the mode indicated by that 678 set of capabilities (see Section 9.2). If the sent and received 679 Capabilities TLVs are not equal, this indicates a capabilities 680 mismatch. When this happens, the node MUST alert the operator and 681 MUST NOT perform any protection switching until the operator resolves 682 the mismatch in the Capabilities TLV. 684 9.2. Modes 686 A mode is a given set of Capabilities. Modes are shorthand; 687 referring to a set of capabilities by their individual values or by 688 the name of their mode does not change the protocol behavior. This 689 document defines two modes - PSC and APS. 691 9.2.1. PSC mode 693 PSC mode is defined as the lack of any Capabilities - that is, a 694 Capabilities set of 0x0. It is the behavior specified in RFC 6378. 696 There are two ways to declare PSC mode. A node can send no 697 Capabilities TLV at all since there are no TLV units defined in RFC 698 6378, or it can send a Capabilities TLV with Flags value set to 0x0. 699 In order to allow backward compatibility between two nodes - one 700 which can send the Capabilities TLV, and one which cannot, a node 701 which has the ability to send and receive the PSC mode Capabilities 702 TLV MUST be able to both send the PSC mode Capabilities TLV and send 703 no Capabilities TLV at all. An implementation MUST be configurable 704 between these two choices. 706 9.2.2. APS mode 708 APS mode is defined as the use of all the five specific capabilities, 709 which are described from Section 4 to Section 8 in this document. 710 APS mode is indicated with the Flags value of 0xF8000000. 712 10. PSC Protocol in APS Mode 714 This section and Section 11 define the behavior of PSC protocol when 715 all of the aforementioned capabilities are enabled, i.e., APS mode. 717 10.1. Request field in PSC protocol message 719 This document defines two new values for the "Request" field in the 720 PSC protocol message that is shown in Figure 2 of RFC 6378 [RFC6378] 721 as follows: 723 (3) Exercise 725 (2) Reverse Request 727 See also Section 14.1 of this document. 729 10.2. Priorities of local inputs and remote requests 731 Based on the description in Section 3 and Section 4.3.2 in RFC 6378, 732 the priorities of multiple outstanding local inputs are evaluated in 733 the Local Request logic, where the highest priority local input 734 (highest local request) is determined. This highest local request is 735 passed to the PSC Control logic, that will determine the higher 736 priority input (top priority global request) between the highest 737 local request and the last received remote message. When a remote 738 message comes to the PSC Control logic, the top priority global 739 request is determined between this remote message and the highest 740 local request which is present. The top priority global request is 741 used to determine the state transition, which is described in 742 Section 11. In this document, in order to simplify the description 743 on the PSC Control logic, we strictly decouple the priority 744 evaluation from the state transition table lookup. 746 The priorities for both local and remote requests are defined as 747 follows from highest to lowest: 749 o Operator Clear (Local only) 751 o Lockout of protection (Local and Remote) 753 o Clear Signal Fail or Degrade (Local only) 755 o Signal Fail on Protection path (Local and Remote) 757 o Forced Switch (Local and Remote) 759 o Signal Fail on Working path (Local and Remote) 761 o Signal Degrade on either Protection path or Working path (Local 762 and Remote) 764 o Manual Switch to either Protection path or Working path (Local and 765 Remote) 767 o WTR Timer Expires (Local only) 769 o WTR (Remote only) 771 o Exercise (Local and Remote) 773 o Reverse Request (Remote only) 775 o Do-Not-Revert (Remote only) 777 o No Request (Remote and Local) 779 Note that the "Local only" requests are not signaled to the remote 780 LER. Likewise, the "Remote only" requests do not exist in the Local 781 Request logic as local inputs. For example, the priority of WTR only 782 applies to the received WTR message, which is generated from the 783 remote LER. The remote LER that is running the WTR timer in the WTR 784 state has no local request. 786 The remote request from the remote LER is assigned a priority just 787 below the same local request. However, for the equal priority 788 requests, such as SD and MS, the following equal priority resolution 789 rules are defined: 791 o If two local inputs having the same priority but requesting 792 different action come to the Local Request logic, then the input 793 coming first SHALL be considered to have a higher priority than 794 the other coming later (first-come, first-served). 796 o If the PSC Control logic has both the highest local request and a 797 remote message with the same priority and requesting the same 798 action, i.e., the same PSC Request field and the same FPath value, 799 then the local input SHALL be considered to have a higher priority 800 than the remote message. 802 o If the PSC Control logic has both the highest local request and a 803 remote message with the same priority but requesting different 804 action and the remote message exists when the highest local 805 request comes to the PSC Control logic, the highest local request 806 is ignored and the remote Request SHALL be the top priority global 807 request. 809 o If the PSC Control logic has both the highest local request and a 810 remote message with the same priority but requesting different 811 action and the highest local request exists when the remote 812 message comes to the PSC Control logic, the top priority global 813 request SHALL be determined by the following rules for each 814 simultaneous condition: 816 o For simultaneous MS requests, the MS-W request SHALL be considered 817 to have a higher priority than the MS-P request. The LER that has 818 local MS-W request SHALL maintain the local MS-W request as the 819 top priority global request, but the other LER that has local MS-P 820 request SHALL clear the MS-P command and internally generate 821 "Operator Clear" request. 823 o For simultaneous SD requests, the SD on the standby path (the path 824 from which the selector does not select the user data traffic) 825 SHALL be considered as having higher priority than the SD on the 826 active path (the path from which the selector selects the user 827 data traffic) regardless of its origin (local or remote message). 828 The LER that has the SD on the standby path SHALL maintain the 829 local SD on the standby path request as the top priority global 830 request. The other LER that has local SD on the active path SHALL 831 use the remote SD on the standby path as the top priority global 832 request to lookup the state transition table. The differentiation 833 of the active and standby paths is based upon which path had been 834 used for the user data traffic at the time just before an LER 835 selected its local SD as the top priority global request. 837 No Request is another exception to the rule of assigning a remote 838 request a priority just below the same local request. Since a 839 received NR message needs to be used in the state transition table 840 lookup when there is no outstanding local request, the received 841 remote NR request SHALL be the top priority global request when there 842 is no request in the local LER. 844 10.3. Acceptance and retention of local inputs 846 A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W, 847 SHALL be accepted and retained persistently in the Local Request 848 logic as long as the defect condition exists. If there is any higher 849 priority local input than the local defect input, the higher priority 850 local input is passed to the PSC Control logic as the highest local 851 request, but the local defect input cannot be removed but remains in 852 the Local Request logic. When the higher priority local input 853 disappears, the local defect will become the highest local request if 854 the defect condition still exists. 856 Operator Clear command, SFDc and WTR Timer Expires are not 857 persistent. Once they appear to the Local Request logic and complete 858 the operation, they SHALL be disappeared. 860 Operator LO, FS, MS, and EXER commands SHALL be rejected if there is 861 any higher priority local input in the Local Request logic. If a new 862 higher-priority local request (including an operator command) is 863 accepted, any previous lower-priority local operator command SHALL be 864 cancelled. When any higher-priority remote request is received, a 865 lower-priority local operator command SHALL be cancelled. The 866 cancelled operator command is forgotten and will never return, unless 867 the operator reissues the command. 869 11. State Transition Tables in APS Mode 871 When there is a change in the highest local request or in remote PSC 872 messages, the top priority global request SHALL be evaluated and the 873 state transition tables SHALL be looked up in the PSC Control logic. 874 The following rules are applied to the operation related to the state 875 transition table lookup. 877 o If the top priority global request, which determines the state 878 transition, is the highest local request, the local state 879 transition table in Section 11.1 SHALL be used to decide the next 880 state of the LER. Otherwise, remote messages state transition 881 table in Section 11.2 SHALL be used. 883 o If in remote state, the highest local defect condition (SF-P, 884 SF-W, SD-P or SD-W) SHALL always be reflected in the Request field 885 and Fpath. 887 o For the LER currently in the local state, if the top priority 888 global request is changed to Operator Clear (OC) or SFDc causing 889 the next state to be Normal, WTR or DNR, then all the local and 890 remote requests SHALL be re-evaluated as if the LER is in the 891 state specified in the footnotes to the state transition tables, 892 before deciding the final state. If there are no active requests, 893 the LER enters the state specified in the footnotes to the state 894 transition tables. This re-evaluation is an internal operation 895 confined within the local LER, and the PSC messages are generated 896 according to the final state. 898 o The WTR timer is started only when the LER which has recovered 899 from a local failure/degradation enters the WTR state. An LER 900 which is entering into the WTR state due to a remote WTR message 901 does not start the WTR timer. The WTR timer SHALL be stopped when 902 any local or remote request triggers the state change out of the 903 WTR state. 905 The extended states, as they appear in the table, are as follows: 907 N Normal state 908 UA:LO:L Unavailable state due to local LO command 909 UA:P:L Unavailable state due to local SF-P 910 UA:DP:L Unavailable state due to local SD-P 911 UA:LO:R Unavailable state due to remote LO message 912 UA:P:R Unavailable state due to remote SF-P message 913 UA:DP:R Unavailable state due to remote SD-P message 914 PF:W:L Protecting failure state due to local SF-W 915 PF:DW:L Protecting failure state due to local SD-W 916 PF:W:R Protecting failure state due to remote SF-W message 917 PF:DW:R Protecting failure state due to remote SD-W message 918 SA:F:L Switching administrative state due to local FS command 919 SA:MW:L Switching administrative state due to local MS-W command 920 SA:MP:L Switching administrative state due to local MS-P command 921 SA:F:R Switching administrative state due to remote FS message 922 SA:MW:R Switching administrative state due to remote MS-W message 923 SA:MP:R Switching administrative state due to remote MS-P message 924 E::L Exercise state due to local EXER command 925 E::R Exercise state due to remote EXER message 926 WTR Wait-to-Restore state 927 DNR Do-not-Revert state 929 Each state corresponds to the transmission of a particular set of 930 Request, FPath and Path bits. The table below lists the message that 931 is generally sent in each particular state. If the message to be 932 sent in a particular state deviates from the table below, it is noted 933 in the footnotes to the state transition tables. 935 State REQ(FP,P) 936 ------- --------- 937 N NR(0,0) 938 UA:LO:L LO(0,0) 939 UA:P:L SF(0,0) 940 UA:DP:L SD(0,0) 941 UA:LO:R highest local request(local FPath,0) 942 UA:P:R highest local request(local FPath,0) 943 UA:DP:R highest local request(local FPath,0) 944 PF:W:L SF(1,1) 945 PF:DW:L SD(1,1) 946 PF:W:R highest local request(local FPath,1) 947 PF:DW:R highest local request(local FPath,1) 948 SA:F:L FS(1,1) 949 SA:MW:L MS(0,0) 950 SA:MP:L MS(1,1) 951 SA:F:R highest local request(local FPath,1) 952 SA:MW:R NR(0,0) 953 SA:MP:R NR(0,1) 954 WTR WTR(0,1) 955 DNR DNR(0,1) 956 E::L EXER(0,x), where x is the existing Path value 957 when Exercise command is issued. 958 E::R RR(0,x), where x is the existing Path value 959 when RR message is generated. 961 Some operation examples of APS mode are shown in Appendix D. 963 In the state transition tables below, the letter 'i' stands for 964 "ignore", and is an indication to remain in the current state and 965 continue transmitting the current PSC message 967 11.1. State transition by local inputs 968 | OC | LO | SFDc | SF-P | FS | SF-W | 969 --------+-----+---------+------+--------+--------+--------+ 970 N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 971 UA:LO:L | (1) | i | i | i | i | i | 972 UA:P:L | i | UA:LO:L | (1) | i | i | i | 973 UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L | 974 UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 975 UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 976 UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 977 PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i | 978 PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L | 979 PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 980 PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 981 SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i | 982 SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 983 SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 984 SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 985 SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 986 SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 987 WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 988 DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 989 E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 990 E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 992 | SD-P | SD-W | MS-W | MS-P | WTRExp | EXER 993 --------+---------+---------+---------+---------+--------+------ 994 N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 995 UA:LO:L | i | i | i | i | i | i 996 UA:P:L | i | i | i | i | i | i 997 UA:DP:L | i | i | i | i | i | i 998 UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i 999 UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i 1000 UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i 1001 PF:W:L | i | i | i | i | i | i 1002 PF:DW:L | i | i | i | i | i | i 1003 PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i 1004 PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i 1005 SA:F:L | i | i | i | i | i | i 1006 SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i 1007 SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i 1008 SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i 1009 SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i 1010 SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i 1011 WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i 1012 DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1013 E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i 1014 E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1015 NOTES: 1017 (1) Re-evaluate to determine final state as if the LER is in the 1018 Normal state. If there are no active requests, the LER enters 1019 the Normal State. 1021 (2) In the case that both local input after SFDc and the last 1022 received remote message are no requests, the LER enters into the 1023 WTR state when the domain is configured for revertive behavior, 1024 or the LER enters into the DNR state when the domain is 1025 configured for non-revertive behavior. In all the other cases, 1026 where one or more active requests exist, re-evaluate to 1027 determine the final state as if the LER is in the Normal state. 1029 (3) Re-evaluate to determine final state as if the LER is in the 1030 Normal state when the domain is configured for revertive 1031 behavior, or as if the LER is in the DNR state when the domain 1032 is configured for non-revertive behavior. If there are no 1033 active requests, the LER enters either the Normal state when the 1034 domain is configured for revertive behavior or the DNR state 1035 when the domain is configured for non-revertive behavior. 1037 (4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if 1038 it is running. In APS mode, OC can cancel the WTR timer and 1039 hasten the state transition to the Normal state as in other 1040 transport networks. 1042 (5) If Path value is 0, re-evaluate to determine final state as if 1043 the LER is in the Normal state. If Path value is 1, re-evaluate 1044 to determine final state as if the LER is in the DNR state. If 1045 there are no active requests, the LER enters the Normal state 1046 when Path value is 0, or the DNR state when Path value is 1. 1048 (6) Remain in the WTR state and send NR(0,1). 1050 11.2. State transition by remote messages 1051 | LO | SF-P | FS | SF-W | SD-P | SD-W | 1052 --------+---------+--------+--------+--------+---------+---------+ 1053 N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1054 UA:LO:L | i | i | i | i | i | i | 1055 UA:P:L | UA:LO:R | i | i | i | i | i | 1056 UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) | 1057 UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1058 UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1059 UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R | 1060 PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i | 1061 PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i | 1062 PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R | 1063 PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i | 1064 SA:F:L | UA:LO:R | UA:P:R | i | i | i | i | 1065 SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1066 SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1067 SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R | 1068 SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1069 SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1070 WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1071 DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1072 E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1073 E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1075 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 1076 --------+---------+---------+-----+------+----+------+---- 1077 N | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1078 UA:LO:L | i | i | i | i | i | i | i 1079 UA:P:L | i | i | i | i | i | i | i 1080 UA:DP:L | i | i | i | i | i | i | i 1081 UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1082 UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1083 UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1084 PF:W:L | i | i | i | i | i | i | i 1085 PF:DW:L | i | i | i | i | i | i | i 1086 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1087 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1088 SA:F:L | i | i | i | i | i | i | i 1089 SA:MW:L | i | i | i | i | i | i | i 1090 SA:MP:L | i | i | i | i | i | i | i 1091 SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N 1092 SA:MW:R | i | SA:MP:R | i | E::R | i | i | N 1093 SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N 1094 WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12) 1095 DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1096 E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i 1097 E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N 1098 NOTES: 1100 (7) If the received SD-W message has Path=0, ignore the message. If 1101 the received SD-W message has Path=1, go to PF:DW:R state and 1102 transmit SD(0,1) 1104 (8) If the received SD-P message has Path=1, ignore the message. If 1105 the received SD-P message has Path=0, go to UA:DP:R state and 1106 transmit SD(1,0). 1108 (9) Transition to the WTR state and continue to send the current 1109 message. 1111 (10) Transition to the DNR state and continue to send the current 1112 message. 1114 (11) If the received NR message has Path=1, transition to the WTR 1115 state if domain configured for revertive behavior, else 1116 transition to the DNR state. If the received NR message has 1117 Path=0, transition to the Normal state. 1119 (12) If the receiving LER's WTR timer is running, maintain current 1120 state and message. If the WTR timer is not running, transition 1121 to the Normal state. 1123 (13) Transit to the WTR state and send NR(0,1) message. The WTR 1124 timer is not initiated. 1126 11.3. State transition for 1+1 unidirectional protection 1128 The state transition tables given in Section 11.1 and Section 11.2 1129 are for bidirectional protection switching, where remote PSC protocol 1130 messages are used to determine the protection switching actions. The 1131 1+1 unidirectional protection switching does not require the remote 1132 information in PSC protocol message and acts upon local inputs only. 1133 The state transition by local inputs in Section 11.1 SHALL be reused 1134 for the 1+1 unidirectional protection under the following conditions: 1136 o The value of Request field in the received remote message is 1137 ignored and always assumed to be no request. 1139 o Replace footnote (4) with "Stop the WTR timer and transit to the 1140 Normal state." 1142 o Replace footnote (6) with "Transit to the Normal state." 1144 o Exercise is not applicable. 1146 12. Provisioning Mismatch and Protocol Failure in the APS Mode 1148 The remote PSC message that is received from the remote LER is 1149 subject to the detection of provisioning mismatch and protocol 1150 failure conditions. In the APS mode, provisioning mismatches are 1151 handled as follows: 1153 o If the PSC message is received from the working path due to 1154 working/protection path configuration mismatch, the node MUST 1155 alert the operator and MUST NOT perform any protection switching 1156 until the operator resolves this path configuration mismatch. 1158 o In the case that the mismatch happens in two-bit "Protection Type 1159 (PT)" field, which indicates permanent/selector bridge type and 1160 uni/bidirectional switching type, 1162 * If the value of the PT field of one side is 2 (i.e., selector 1163 bridge) and the value of PT field of the other side is 1 or 3 1164 (i.e., permanent bridge), then this event MUST be notified to 1165 the operator and each node MUST NOT perform any protection 1166 switching until the operator resolves this bridge type 1167 mismatch. 1169 * If the bridge type matches but the switching type mismatches, 1170 i.e., one side has PT=1 (unidirectional switching) while the 1171 other side has PT=2 or 3 (bidirectional switching), then the 1172 node provisioned for bidirectional switching SHOULD fall back 1173 to unidirectional switching to allow interworking. The node 1174 SHOULD notify the operator of this event. 1176 o If the "Revertive (R)" bit mismatches, two sides will interwork 1177 and traffic is protected according to the state transition 1178 definition given in Section 11. The node SHOULD notify the 1179 operator of this event. 1181 o If the Capabilities TLV mismatches, the node MUST alert the 1182 operator and MUST NOT perform any protection switching until the 1183 operator resolves the mismatch in the Capabilities TLV. 1185 The followings are the protocol failure situations and the actions to 1186 be taken: 1188 o No match in sent "Data Path (Path)" and received "Data Path 1189 (Path)" for more than 50 ms: The node MAY continue to perform 1190 protection switching and SHOULD notify the operator of this event. 1192 o No PSC message is received on the protection path during at least 1193 3.5 times the long PSC message interval, (e.g. at least 17.5 1194 seconds with a default message interval of 5 seconds) and there is 1195 no defect on the protection path: The node MUST alert the operator 1196 and MUST NOT perform any protection switching until the operator 1197 resolves this defect. 1199 13. Security Considerations 1201 No specific security issue is raised in addition to those ones 1202 already documented in RFC 6378 [RFC6378] 1204 14. IANA Considerations 1206 14.1. MPLS PSC Request Registry 1208 In the "Multiprotocol Label Switching (MPLS) Operations, 1209 Administration, and Management (OAM) Parameters" registry, IANA 1210 maintains the "MPLS PSC Request Registry". 1212 IANA is requested to assign two new code points from this registry. 1213 The values shall be allocated as follows: 1215 Value Description Reference 1216 ----- --------------------- --------------- 1217 2 Reverse Request (this document) 1218 3 Exercise (this document) 1220 14.2. MPLS PSC TLV Registry 1222 In the "Multiprotocol Label Switching (MPLS) Operations, 1223 Administration, and Management (OAM) Parameters" registry, IANA 1224 maintains the "MPLS PSC TLV Registry". 1226 This document defines a new value for the Capabilities TLV type in 1227 the "MPLS PSC TLV Registry". 1229 Value Description Reference 1230 ------ --------------------- --------------- 1231 TBD Capabilities (this document) 1233 14.3. MPLS PSC Capability Flag Registry 1235 IANA is requested to create and maintain a new registry within the 1236 "Multiprotocol Label Switching (MPLS) Operations, Administration, and 1237 Management (OAM) Parameters" registry called "MPLS PSC Capability 1238 Flag Registry". All flags within this registry SHALL be allocated 1239 according to the "Standards Action" procedures as specified in RFC 1240 5226 [RFC5226]. 1242 The length of the flags MUST be a multiple of 4 octets. This 1243 document defines 4 octet flags. Flags greater than 4 octets SHALL be 1244 used only if more than 32 Capabilities need to be defined. Flags 1245 defined in this document are: 1247 Bit Hex Value Capability Reference 1248 ---- ---------- ----------------------------------- --------------- 1249 0 0x80000000 priority modification (this document) 1250 1 0x40000000 non-revertive behavior modification (this document) 1251 2 0x20000000 support of MS-W command (this document) 1252 3 0x10000000 support of protection against SD (this document) 1253 4 0x08000000 support of EXER command (this document) 1254 5-31 Unassigned (this document) 1256 15. Acknowledgements 1258 The authors would like to thank Yaacov Weingarten, Yuji Tochio, 1259 Malcolm Betts, Ross Callon and Qin Wu for their valuable comments and 1260 suggestions on this document. 1262 We would also like to acknowledge explicit text provided by Loa 1263 Andersson and Adrian Farrel. 1265 16. References 1267 16.1. Normative References 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, March 1997. 1272 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1273 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1274 May 2008. 1276 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1277 and S. Ueno, "Requirements of an MPLS Transport Profile", 1278 RFC 5654, September 2009. 1280 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1281 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1282 Protection", RFC 6378, October 2011. 1284 16.2. Informative References 1286 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1287 Restoration) Terminology for Generalized Multi-Protocol 1288 Label Switching (GMPLS)", RFC 4427, March 2006. 1290 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1291 TP) Survivability Framework", RFC 6372, September 2011. 1293 [G841] International Telecommunications Union, "Types and 1294 characteristics of SDH network protection architectures", 1295 ITU-T Recommendation G.841, October 1998. 1297 [G873.1] International Telecommunications Union, "Optical Transport 1298 Network (OTN): Linear protection", ITU-T Recommendation 1299 G.873.1, July 2011. 1301 [G8031] International Telecommunications Union, "Ethernet Linear 1302 Protection Switching", ITU-T Recommendation G.8031/Y.1342, 1303 June 2011. 1305 Appendix A. An Example of Out-of-service Ccenarios 1307 The sequence diagram shown is an example of the out-of-service 1308 scenarios based on the priority level defined in RFC 6378. The first 1309 PSC message which differs from the previous PSC message is shown. 1311 A Z 1312 | | 1313 (1) |-- NR(0,0) ------>| (1) 1314 |<----- NR(0,0) ---| 1315 | | 1316 | | 1317 | (FS issued at Z) | (2) 1318 (3) |<------ FS(1,1) --| 1319 |-- NR(0,1) ------>| 1320 | | 1321 | | 1322 (4) | (SF on P(A<-Z)) | 1323 | | 1324 | | 1325 | (Clear FS at Z) | (5) 1326 (6) | X <- NR(0,0) --| 1327 | | 1328 | | 1330 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1332 (2) When a FS command is issued at node Z, node Z goes into local 1333 Protecting administrative state (PA:F:L) and begins transmission of 1334 an FS(1,1) messages. 1336 (3) A remote FS message causes node A to go into remote Protecting 1337 administrative state (PA:F:R), and node A begins transmitting NR(0,1) 1338 messages. 1340 (4) When node A detects a unidirectional SF-P, node A keeps sending 1341 NR(0,1) message because SF-P is ignored under the PA:F:R state. 1343 (5) When a Clear command is issued at node Z, node Z goes into the 1344 Normal state and begins transmission of NR(0,0) messages. 1346 (6) But, node A cannot receive PSC message because of local 1347 unidirectional SF-P. Because no valid PSC message is received, over 1348 a period of several successive message intervals, the last valid 1349 received message remains applicable and the node A continue to 1350 transmit an NR(0,1) message in the PA:F:R state. 1352 Now, there exists a mismatch between the bridge/selector positions of 1353 node A (transmitting an NR(0,1)) and node Z (transmitting an 1354 NR(0,0)). It results in out-of-service even when there is neither 1355 SF-W nor FS. 1357 Appendix B. An Example of Sequence Diagram Showing the Problem with the 1358 Priority Level of SFc 1360 An example of sequence diagram showing the problem with the priority 1361 level of SFc defined in RFC 6378 is given below. The following 1362 sequence diagram is depicted for the case of bidirectional signal 1363 fails. However, other cases with unidirectional signal fails can 1364 result in the same problem. The first PSC message which differs from 1365 the previous PSC message is shown. 1367 A Z 1368 | | 1369 (1) |-- NR(0,0) ------>| (1) 1370 |<----- NR(0,0) ---| 1371 | | 1372 | | 1373 (2) | (SF on P(A<->Z)) | (2) 1374 |-- SF(0,0) ------>| 1375 |<------ SF(0,0) --| 1376 | | 1377 | | 1378 (3) | (SF on W(A<->Z)) | (3) 1379 | | 1380 | | 1381 (4) | (Clear SF-P) | (4) 1382 | | 1383 | | 1384 (5) | (Clear SF-W) | (5) 1385 | | 1386 | | 1388 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1390 (2) When SF-P occurs, each node enters into the UA:P:L state and 1391 transmits SF(0,0) messages. Traffic remains on the working path. 1393 (3) When SF-W occurs, each node remains in the UA:P:L state as SF-W 1394 has a lower priority than SF-P. Traffic is still on the working 1395 path. Traffic cannot be delivered as both the working path and the 1396 protection path are experiencing signal fails. 1398 (4) When SF-P is cleared, local "Clear SF-P" request cannot be 1399 presented to the PSC Control logic, which takes the highest local 1400 request and runs PSC state machine, since the priority of "Clear 1401 SF-P" is lower than that of SF-W. Consequently, there is no change 1402 in state, and the selector and/or bridge keep pointing at the working 1403 path, which has signal fail condition. 1405 Now, traffic cannot be delivered while the protection path is 1406 recovered and available. It should be noted that the same problem 1407 will occur in the case that the sequence of SF-P and SF-W events is 1408 changed. 1410 If we further continue with this sequence to see what will happen 1411 after SF-W is cleared, 1413 (5) When SF-W is cleared, local "Clear SF-W" request can be passed to 1414 the PSC Control logic as there is no higher priority local input, but 1415 this will be ignored in the PSC Control logic according to the state 1416 transition definition in RFC 6378. There will be no change in state 1417 or protocol message transmitted. 1419 As SF-W is now cleared and the selector and/or bridge are still 1420 pointing at the working path, traffic delivery is resumed. However, 1421 each node is the in UA:P:L state and transmitting SF(0,0) message, 1422 while there exists no outstanding request for protection switching. 1423 Moreover, any future legitimate protection switching requests, such 1424 as SF-W, will be rejected as each node thinks the protection path is 1425 unavailable. 1427 Appendix C. Freeze Command 1429 The "Freeze" command applies only to the local LER of the protection 1430 group and is not signaled to the remote LER. This command freezes 1431 the state of the protection group. Until the Freeze is cleared, 1432 additional local commands are rejected and condition changes and 1433 received PSC information are ignored. 1435 "Clear Freeze" command clears the local freeze. When the Freeze 1436 command is cleared, the state of the protection group is recomputed 1437 based on the persistent condition of the local triggers. 1439 Because the freeze is local, if the freeze is issued at one end only, 1440 a failure of protocol can occur as the other end is open to accept 1441 any operator command or a fault condition. 1443 Appendix D. Operation Examples of the APS Mode 1445 The sequence diagrams shown in this section are only a few examples 1446 of the APS mode operations. The first PSC protocol message which 1447 differs from the previous message is shown. The operation of hold- 1448 off timer is omitted. The Request, FPath and Path fields, whose 1449 values are changed during PSC message exchange are shown. For an 1450 example, SF(1, 0) represents an PSC message with the following field 1451 values: Request = SF, FPath = 1, and Path = 1. The values of the 1452 other fields remain unchanged from the initial configuration. 1453 W(A->Z) and P(A->Z) indicate the working path and the protection path 1454 in the direction of A to Z, respectively. 1456 Example 1. 1:1 bidirectional protection switching (revertive mode) - 1457 Unidirectional SF case 1458 A Z 1459 | | 1460 (1) |<---- NR(0,0)---->| (1) 1461 | | 1462 | | 1463 (2) | (SF on W(Z->A)) | 1464 |---- SF(1,1)----->| (3) 1465 (4) |<----- NR(0,1)----| 1466 | | 1467 | | 1468 (5) | (Clear SF-W) | 1469 |---- WTR(0,1)---->| 1470 /| | 1471 | | | 1472 WTR timer | | 1473 | | | 1474 \| | 1475 (6) |---- NR(0,1)----->| (7) 1476 (8) |<----- NR(0,0)----| 1477 |---- NR(0,0)----->| (9) 1478 | | 1480 (1) The protection domain is operating without any defect, and the 1481 working path is used for delivering the traffic in the Normal state. 1483 (2) SF-W occurs in the Z to A direction. Node A enters into the 1484 PF:W:L state and generates SF(1, 1) message. Selector and bridge of 1485 node A are pointing at the protection path. 1487 (3) Upon receiving SF(1, 1), node Z sets selector and bridge to the 1488 protection path. As there is no local request in node Z, node Z 1489 generates NR(0, 1) message in the PF:W:R state. 1491 (4) Node A confirms that the remote LER is also selecting protection 1492 path. 1494 (5) Node A detects clearing of SF condition, starts the WTR timer, 1495 and sends WTR(0, 1) message in the WTR state. 1497 (6) At expiration of the WTR timer, node A sets selector and bridge 1498 to the working path and sends NR(0, 1) message. 1500 (7) Node Z is notified that the remote request has been cleared. 1501 Node Z transits to the Normal state and sends NR(0,0) message. 1503 (8) Upon receiving NR(0,0) message, node A transits to the Normal 1504 state and sends NR(0,0) message. 1506 (9) It is confirmed that the remote LER is also selecting the working 1507 path. 1509 Example 2. 1:1 bidirectional protection switching (revertive mode) - 1510 Bidirectional SF case - Inconsistent WTR timers 1512 A Z 1513 | | 1514 (1) |<---- NR(0,0)---->| (1) 1515 | | 1516 | | 1517 (2) | (SF on W(A<->Z)) | (2) 1518 |<---- SF(1,1)---->| 1519 | | 1520 | | 1521 (3) | (Clear SF-W) | (3) 1522 |<---- NR(0,1)---->| 1523 (4) |<--- WTR(0,1) --->| (4) 1524 /| |\ 1525 | | | | 1526 WTR timer | | WTR timer 1527 | | | | 1528 | | |/ 1529 | |<------ NR(0,1)---| (5) 1530 | | | 1531 \| | 1532 (6) |--- NR(0,1)------>| 1533 |<------ NR(0,0)---| (7) 1534 (8) |--- NR(0,0)------>| 1535 | | 1537 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1539 (2) When SF-W occurs, each node enters into the PF:W:L state and 1540 transmits SF(1,1) messages. Traffic is switched to the protection 1541 path. Upon receiving SF(1,1), each node confirms that the remote LER 1542 is also sending and receiving the traffic from the protection path. 1544 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1545 transmits NR(0,1) messages as the last received message is SF-W. 1547 (4) Upon receiving NR(0,1) messages, each node goes into the WTR 1548 state, starts the WTR timer, and sends the WTR(0,1) messages. 1550 (5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as 1551 the last received APS message was WTR. When NR(0,1) arrives at node 1552 A, node A maintains the WTR state and keeps sending current WTR 1553 messages as described in the state transition table. 1555 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1557 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1558 Normal state, sets selector and bridge to the working path, and sends 1559 NR(0, 0) message. 1561 (8) The received NR(0,0) message causes node A to go to the Normal 1562 state. Now, the traffic is switched back to the working path. 1564 Example 3. 1:1 bidirectional protection switching - R bit mismatch 1566 This example shows that both sides will interwork and the traffic is 1567 protected when one side (node A) is configured as revertive mode and 1568 the other (node Z) is configured as non-revertive mode. The 1569 interworking is covered in the state transition tables. 1571 (revertive) A Z (non-revertive) 1572 | | 1573 (1) |<---- NR(0,0)---->| (1) 1574 | | 1575 | | 1576 (2) | (SF on W(A<->Z)) | (2) 1577 |<---- SF(1,1)---->| 1578 | | 1579 | | 1580 (3) | (Clear SF-W) | (3) 1581 |<---- NR(0,1)---->| 1582 (4) |<----- DNR(0,1)---| (4) 1583 /|-- WTR(0,1)------>| 1584 | |<----- NR(0,1)----| (5) 1585 | | | 1586 WTR timer | | 1587 | | | 1588 | | | 1589 \| | 1590 (6) |--- NR(0,1)------>| 1591 |<------ NR(0,0)---| (7) 1592 (8) |--- NR(0,0)------>| 1593 | | 1595 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1597 (2) When SF-W occurs, each node enters into the PF:W:L state and 1598 transmits SF(l,l) messages. Traffic is switched to the protection 1599 path. Upon receiving SF(1,1), each node confirms that the remote LER 1600 is also sending and receiving the traffic on the protection path. 1602 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1603 transmits NR(0,1) messages as the last received message is SF-W. 1605 (4) Upon receiving NR(0,1) messages, node A goes into the WTR state, 1606 starts the WTR timer, and sends WTR(0,1) messages. At the same time, 1607 node B transits to the DNR state and sends DNR(0,1) message. 1609 (5) When the WTR message arrives at node Z, node Z transits to the 1610 WTR state and send NR(0,1) message according to the state transition 1611 table. At the same time, the DNR message arrived at node Z is 1612 ignored according to the state transition table. Therefore, node Z, 1613 which is configured as non-revertive mode, is operating as if in 1614 revertive mode. 1616 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1618 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1619 Normal state, sets selector and bridge to the working path, and sends 1620 NR(0, 0) message. 1622 (8) The received NR(0,0) message causes node A to transits to the 1623 Normal state. Now, the traffic is switched back to the working path. 1625 Authors' Addresses 1627 Jeong-dong Ryoo (editor) 1628 ETRI 1629 218 Gajeongno 1630 Yuseong-gu, Daejeon 305-700 1631 South Korea 1633 Phone: +82-42-860-5384 1634 Email: ryoo@etri.re.kr 1636 Eric Gray (editor) 1637 Ericsson 1639 Email: eric.gray@ericsson.com 1640 Huub van Helvoort 1641 Huawei Technologies 1642 Karspeldreef 4, 1643 Amsterdam 1101 CJ 1644 the Netherlands 1646 Phone: +31 20 4300936 1647 Email: huub.van.helvoort@huawei.com 1649 Alessandro D'Alessandro 1650 Telecom Italia 1651 via Reiss Romoli, 274 1652 Torino 10148 1653 Italy 1655 Phone: +39 011 2285887 1656 Email: alessandro.dalessandro@telecomitalia.it 1658 Taesik Cheung 1659 ETRI 1660 218 Gajeongno 1661 Yuseong-gu, Daejeon 305-700 1662 South Korea 1664 Phone: +82-42-860-5646 1665 Email: cts@etri.re.kr 1667 Eric Osborne 1668 Cisco Systems, Inc. 1670 Email: eosborne@cisco.com