idnits 2.17.1 draft-ietf-mpls-tp-psc-itu-03.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 24, 2014) is 3686 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 28, 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 24, 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-03.txt 21 Abstract 23 This document describes alternate mechanisms to perform some of the 24 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 28, 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. Motivation for swapping priorities of FS and SF-P . . . . 6 82 4.2. Motivation for raising the priority of SFc . . . . . . . 6 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 . . . . . . 7 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 . . . . . . . . . . . . . . . 8 89 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8 90 6.4. Equal priority resolution for MS . . . . . . . . . . . . 9 91 7. Capability 4: Support of Protection against SD . . . . . . . 9 92 7.1. Motivation for supporting protection against SD . . . . . 9 93 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10 94 7.3. Behavior of protection against SD . . . . . . . . . . . . 10 95 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11 97 8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13 98 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 15 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.2.1. Equal priority requests . . . . . . . . . . . . . . 18 108 10.3. Acceptance and retention of local inputs . . . . . . . . 19 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 . . . . . . . . . . 23 112 11.3. State transition for 1+1 unidirectional 113 protection . . . . . . . . . . . . . . . . . . . . . . . 25 114 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 26 115 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 116 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 117 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 27 118 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 27 119 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 27 120 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 122 16.1. Normative References . . . . . . . . . . . . . . . . . . 28 123 16.2. Informative References . . . . . . . . . . . . . . . . . 28 124 Appendix A. An Example of Out-of-service Scenarios . . . . . . . 29 125 Appendix B. An Example of Sequence Diagram Showing 126 the Problem with the Priority Level of SFc . . . . . 30 127 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 32 128 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 32 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 131 1. Introduction 133 Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) 134 are described in RFC 6378 [RFC6378] to meet the requirements 135 described in RFC 5654 [RFC5654]. 137 This document describes alternate mechanisms to perform some of the 138 functions of linear protection, and also defines additional 139 mechanisms. The purpose of these alternate and additional mechanisms 140 is to provide operator control and experience that more closely 141 models the behavior of linear protection seen in other transport 142 networks, such as Synchronous Digital Hierarchy (SDH), Optical 143 Transport Network (OTN) and Ethernet transport networks. Linear 144 protection for SDH, OTN, and Ethernet transport networks are defined 145 in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031 146 [G8031], respectively. 148 The reader of this document is assumed to be familiar with [RFC6378]. 150 The alternative mechanisms described in this document are for the 151 following capabilities: 153 1. Priority modification, 155 2. non-revertive behavior modification, 157 and the following capabilities have been added to define additional 158 mechanisms: 160 3. support of Manual Switch to Working path (MS-W) command, 162 4. support of protection against Signal Degrade (SD), and 164 5. support of Exercise (EXER) command. 166 The priority modification includes raising the priority of Signal 167 Fail on Protection path (SF-P) relative to Forced Switch (FS), and 168 raising the priority level of Clear Signal Fail (SFc) above SF-P. 170 Non-revertive behavior is modified to align with the behavior defined 171 in RFC 4427 [RFC4427] as well as to follow the behavior of linear 172 protection seen in other transport networks. 174 Support of MS-W command to revert traffic to the working path in non- 175 revertive operation is covered in this document. 177 Support of protection switching protocol against SD is covered in 178 this document. The specifics for the method of identifying SD is out 179 of the scope for this document and is treated similarly to Signal 180 Fail (SF) in [RFC6378]. 182 Support of EXER command to test if the Protection State Coordination 183 (PSC) communication is operating correctly is also covered in this 184 document. EXER command tests and validates the linear protection 185 mechanism and PSC protocol including the aliveness of the priority 186 logic, the PSC state machine and the PSC message generation and 187 reception, and the integrity of the protection path, without 188 triggering the actual traffic switching. 190 This document introduces capabilities and modes. A capability is an 191 individual behavior. The capabilities of a node are advertised using 192 the method given in this document. A mode is a particular 193 combination of capabilities. Two modes are defined in this document: 194 PSC mode and Automatic Protection Switching (APS) mode. 196 This document describes the behavior, the priority logic, and the 197 state machine of the PSC protocol when all the capabilities 198 associated with the APS mode are enabled. The PSC protocol behavior 199 for the PSC mode is as defined in [RFC6378]. 201 This document updates [RFC6378] by adding a capability advertisement 202 mechanism. It is recommended that existing implementations of the 203 PSC protocol be updated to support this capability. Backward 204 compatibility with existing implementations is described in 205 Section 9.2.1. 207 2. Conventions Used in This Document 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 3. Acronyms 215 This document uses the following acronyms: 217 APS Automatic Protection Switching 218 DNR Do-not-Revert 219 EXER Exercise 220 FS Forced Switch 221 LO Lockout of protection 222 MS Manual Switch 223 MS-P Manual Switch to Protection path 224 MS-W Manual Switch to Working path 225 MPLS-TP MPLS Transport Profile 226 NR No Request 227 OC Operator Clear 228 OTN Optical Transport Network 229 PSC Protection State Coordination 230 RR Reverse Request 231 SD Signal Degrade 232 SDH Synchronous Digital Hierarchy 233 SD-P Signal Degrade on Protection path 234 SD-W Signal Degrade on Working path 235 SF Signal Fail 236 SFc Clear Signal Fail 237 SFDc Clear Signal Fail or Degrade 238 SF-P Signal Fail on Protection path 239 SF-W Signal Fail on Working path 240 WTR Wait-to-Restore 242 4. Capability 1: Priority Modification 244 [RFC6378] defines the priority of FS to be higher than that of SF-P. 245 That document also defines the priority of Clear SF (SFc) to be low. 246 This document defines the priority modification capability whereby 247 the relative priorities of FS and SF-P are swapped and the priority 248 of Clear SF (SFc) is raised. In addition, this capability introduces 249 the Freeze command as described in Appendix C. The rationale for 250 these changes is detailed in the following sub-sections from both the 251 technical and network operational aspects. 253 4.1. Motivation for swapping priorities of FS and SF-P 255 Defining the priority of FS higher than that of SF-P can result in a 256 situation where the protected traffic is taken out-of-service. When 257 the protection path fails PSC communication may stop as a result. In 258 this case, if any input that is supposed to be signaled to the other 259 end has a higher priority than SF-P then this can result in 260 unpredictable protection switching state. An example scenario that 261 may result in an out-of-service situation is presented in Appendix A 262 of this document. 264 According to Section 2.4 of [RFC5654] it MUST be possible to operate 265 an MPLS-TP network without using a control plane. This means that 266 the PSC communication channel is very important for the transfer of 267 external switching commands (e.g., FS), and these commands should not 268 rely on the presence of a control plane. In consequence, the failure 269 of the PSC communication channel has higher priority than FS. 271 In other transport networks (such as SDH, OTN, and Ethernet transport 272 networks) the priority of SF-P has been higher than that of FS. It 273 is therefore important to offer network operators the option of 274 having the same behavior in their MPLS-TP networks so that they can 275 have the same operational protection switching behavior to which they 276 have become accustomed. Typically, FS command is issued before 277 network maintenance jobs, (e.g., replacing optical cables or other 278 network components). When an operator pulls out a cable on the 279 protection path, by mistake, the traffic should continue to be 280 protected and the operator expects this behavior based on his/her 281 experience on the traditional transport network operations. 283 4.2. Motivation for raising the priority of SFc 285 The priority level of SFc defined in [RFC6378] can cause traffic 286 disruption when a node that has experienced local signal fails on 287 both the working and the protection paths is recovering from these 288 failures. 290 An example of sequence diagram highlighting the problem with the 291 priority level of SFc as defined in [RFC6378] is presented in 292 Appendix B. 294 4.3. Motivation for introducing Freeze command 296 With the priority swapping between FS and SF-P, the traffic is always 297 moved back to the working path when SF-P occurs in Protecting 298 Administrative state. In case network operators need an option to 299 control their networks so that the traffic can remain on the 300 protection path even when the PSC communication channel is broken, 301 the Freeze command can be used. Freeze is defined to be a "local" 302 command that is not signaled to the remote node. The use of the 303 Freeze command is described in Appendix C. 305 4.4. Procedures in support of Capability 1 307 When the modified priorities specified in this document is in use, 308 the list of local requests in order of priority SHALL be as follows: 310 (from highest to lowest) 312 o Clear Signal Fail 314 o Signal Fail on Protection path 316 o Forced Switch 318 o Signal Fail on Working path 320 This requires modification to the PSC Control Logic (including the 321 state machine) relative to that described in [RFC6378]. Sections 10 322 and 11 present the PSC Control Logic when all capabilities of APS 323 mode are enabled. 325 5. Capability 2: Non-revertive Behavior Modification 327 Non-revertive operation of protection switching is defined in 328 [RFC4427]. In this operation, the traffic does not return to the 329 working path when switch-over requests are terminated. 331 However, the PSC protocol defined in [RFC6378] supports this 332 operation only when recovering from a defect condition: it does not 333 support the non-revertive function when an operator's switch-over 334 command, such as FS or Manual Switch (MS), is cleared. To be aligned 335 with the behavior in other transport networks and to be consistent 336 with [RFC4427], a node should go into the Do-not-Revert (DNR) state 337 not only when a failure condition on the working path is cleared, but 338 also when an operator command that requested switch-over is cleared. 340 This requires modification to the PSC Control Logic (including the 341 state machine) relative to that described in [RFC6378]. Sections 10 342 and 11 present the PSC Control Logic when all capabilities of APS 343 mode are enabled. 345 6. Capability 3: Support of MS-W Command 347 6.1. Motivation for adding MS-W 349 Changing the non-revertive operation as described in Section 5 350 introduces necessity of a new operator command to revert traffic to 351 the working path when in the DNR state. When the traffic is on the 352 protection path in the DNR state, a Manual Switch to Working (MS-W) 353 command is issued to switch the normal traffic back to the working 354 path. According to Section 4.3.3.6 (Do-not-Revert State) in 355 [RFC6378], "to revert back to the Normal state, the administrator 356 SHALL issue a Lockout of protection (LO) command followed by a Clear 357 command." However, using LO command introduces the potential risk of 358 an unprotected situation while the LO is in effect. 360 Manual Switch-over for recovery LSP/span command is defined in 361 [RFC4427]. Requirement 83 in [RFC5654] states that the external 362 commands defined in [RFC4427] MUST be supported. Since there is no 363 support for this external command in [RFC6378], this functionality 364 should be added to PSC. This support is provided by introducing the 365 MS-W command. The MS-W command, as described here, corresponds to 366 the "Manual Switch- over for recovery LSP/span" command. 368 6.2. Terminology to support MS-W 370 [RFC6378] uses the term "Manual Switch" and its acronym "MS". This 371 document uses the term "Manual Switch to Protection path" and "MS-P" 372 to have the same meaning, while avoiding confusion with "Manual 373 Switch to Working path" and its acronym "MS-W". 375 Similarly, we modify the name of "Protecting Administrative" state 376 (as defined in [RFC6378]) to be "Switching Administrative" state to 377 include the case where traffic is switched to the working path as a 378 result of the external MS-W command. 380 6.3. Behavior of MS-P and MS-W 382 MS-P and MS-W SHALL have the same priority. We consider different 383 instances of determining the priority of the commands when they are 384 received either in succession or simultaneously. 386 o When two commands are received in succession, the command that is 387 received after the initial command is accepted SHALL be cancelled. 389 o If two nodes simultaneously receive commands that indicate 390 opposite operations (i.e., one node receives MS-P and the other 391 node receives MS-W) and transmit the indications to the remote 392 node, the MS-W SHALL be considered to have a higher priority, and 393 the MS-P SHALL be cancelled and discarded. 395 Two commands, MS-P and MS-W are transmitted using the same Request 396 field value, but SHALL indicate in the Fault Path (FPath) value the 397 path that the traffic is being diverted from. When traffic is 398 switched to the protection path, the FPath field value SHALL be set 399 to 1, indicating that traffic is being diverted from the working 400 path. When traffic is switched to the working path, the FPath field 401 value SHALL be set to 0, indicating that traffic is being diverted 402 from the protection path. The Data Path (Path) field SHALL indicate 403 where user data traffic is being transported (i.e., if the working 404 path is selected, then Path is set to 0; if the protection path is 405 selected, then Path is set to 1). 407 When an MS command is in effect at a node, any subsequent MS or EXER 408 command and any other lower priority requests SHALL be ignored. 410 6.4. Equal priority resolution for MS 412 [RFC6378] defines only one rule for equal priority condition in 413 Section 4.3.2 as "The remote message from the remote LER is assigned 414 a priority just below the similar local input." In order to support 415 the manual switch behavior described in Section 6.3, additional rules 416 for equal priority resolution are required. Since the support of 417 protection against signal degrade also requires a similar equal 418 priority resolution, the rules are described in Section 7.4. 420 Support of this function requires changes to the PSC Control Logic 421 (including the state machine) relative to that shown in [RFC6378]. 422 Sections 10 and 11 present the PSC Control Logic when all 423 capabilities of APS mode are enabled. 425 7. Capability 4: Support of Protection against SD 427 7.1. Motivation for supporting protection against SD 429 In the MPLS-TP Survivability Framework [RFC6372], both SF and SD 430 fault conditions can be used to trigger protection switching. 432 [RFC6378], which defines the protection switching protocol for MPLS- 433 TP, does not specify how the SF and SD are detected, and specifies 434 the protection switching protocol associated with SF only. 436 The PSC protocol associated with SD is covered in this document, but 437 the specifics for the method of identifying SD is out of scope for 438 the protection protocol in the same way that SF detection and MS or 439 FS command initiation are out of scope. 441 7.2. Terminology to support SD 443 In this document the term Clear Signal Fail or Degrade (SFDc) is used 444 to indicate the clearance of either a degraded condition or a failure 445 condition. 447 The second paragraph of Section 4.3.3.2 Unavailable state in 448 [RFC6378] shows the intention of including Signal Degrade on 449 Protection path (SD-P) in the Unavailable state. Even though the 450 protection path can be partially available under the condition of 451 SD-P, this document follows the same state grouping as [RFC6378] for 452 SD-P. 454 The bullet item on the Protecting Failure state in Section 3.6 of 455 [RFC6378] includes the degraded condition in the Protecting Failure 456 state. This document follows the same state grouping as [RFC6378] 457 for Signal Degrade on Working path (SD-W). 459 7.3. Behavior of protection against SD 461 To better align the behavior of MPLS-TP networks with that of other 462 transport networks (such as SDH, OTN, and Ethernet transport 463 networks) we define the followings: 465 o The priorities of SD-P and SD-W SHALL be equal. 467 o Once a switch has been completed due to SD on one path, it will 468 not be overridden by SD on the other path (first come, first 469 served behavior), to avoid protection switching that cannot 470 improve signal quality. 472 The SD message indicates that the transmitting node has identified a 473 degradation of the signal, or integrity of the packet transmission on 474 either the working path or the protection path. The FPath field 475 SHALL identify the path that is reporting the degraded condition 476 (i.e., if the protection path, then FPath is set to 0; if the working 477 path, then FPath is set to 1), and the Path field SHALL indicate 478 where the data traffic is being transported (i.e., if the working 479 path is selected, then Path is set to 0; if the protection path is 480 selected, then Path is set to 1). 482 When the SD condition is cleared and the protected domain is 483 recovering from the situation, the Wait-to-Restore (WTR) timer SHALL 484 be used if the protected domain is configured for revertive behavior. 485 The WTR timer SHALL be started at the node that recovers from a local 486 degraded condition on the working path. 488 Protection switching against SD is always provided by a selector 489 bridge duplicating user data traffic and feeding it to both the 490 working path and the protection path under SD condition. When a 491 local or remote SD occurs on either the working path or the 492 protection path, the node SHALL duplicate user data traffic and SHALL 493 feed to both the working path and the protection path. The packet 494 duplication SHALL continue as long as any SD condition exists in the 495 protected domain. The packet duplication SHALL continue in the WTR 496 state in revertive operation and SHALL stop when the node leaves the 497 WTR state. In non-revertive operation, the packet duplication SHALL 498 stop when the SD condition is cleared. 500 The selector bridge with the packet duplication under SD condition, 501 which is a non-permanent bridge, is considered to be a 1:1 protection 502 architecture. 504 Protection switching against SD does not introduce any modification 505 to the operation of the selector at the sink node described in 506 [RFC6378]. The selector chooses either the working or protection 507 path from which to receive the normal traffic in both 1:1 and 1+1 508 architectures. The position of the selector, i.e., which path to 509 receive the traffic, is determined by the PSC protocol in 510 bidirectional switching or by the local input in unidirectional 511 switching. 513 7.4. Equal priority resolution 515 In order to support the MS behavior described in Section 6.3 and the 516 protection against SD described in Section 7.3, it is necessary to 517 expand the rules for treating equal priority inputs. 519 For equal priority local inputs, such as MS and SD, apply a simple 520 first-come, first-served rule. Once a local input is determined as 521 the highest priority local input, then a subsequent equal priority 522 local input requesting a different action, i.e., the action results 523 in the same PSC Request field but different FPath value, will not be 524 presented to the PSC Control Logic as the highest local request. 525 Furthermore, in the case of MS command, the subsequent local MS 526 command requesting a different action will be cancelled. 528 If a node is in a remote state due to a remote SD (or MS) message, a 529 subsequent local input having the same priority but requesting a 530 different action to the PSC Control Logic, will be considered as 531 having lower priority than the remote message, and will be ignored. 532 For examples, if a node is in remote Switching Administrative state 533 due to a remote MS-P, then any subsequent local MS-W SHALL be ignored 534 and automatically cancelled. If a node is in remote Unavailable 535 state due to a remote SD-P, then any subsequent local SD-W input will 536 be ignored. However, the local SD-W SHALL continue to appear in the 537 Local Request Logic as long as the SD condition exists, but SHALL NOT 538 be the top priority global request, which determines the state 539 transition at the PSC Control Logic. 541 Cases where two end-points of the protected domain simultaneously 542 receive local triggers of the same priority that request different 543 actions (for example, one node receives SD-P and the other receives 544 SD-W) may occur. Subsequently, each node will receive a remote 545 message with the opposing action indication. To address these cases, 546 we define the following priority resolution rules: 548 o When MS-W and MS-P occur simultaneously at both nodes, MS-W SHALL 549 be considered as having higher priority than MS-P at both nodes. 551 o When SD-W and SD-P occur simultaneously at both nodes, the SD on 552 the standby path (the path from which the selector does not select 553 the user data traffic) is considered as having higher priority 554 than the SD on the active path (the path from which the selector 555 selects the user data traffic) regardless of its origin (local or 556 remote message). Therefore, no unnecessary protection switching 557 is performed and the user data traffic continues to be selected 558 from the active path. 560 In the preceding paragraphs, the "simultaneously" refers to the case 561 a sent SD (or MS) request has not been confirmed by the remote end in 562 bidirectional protection switching. When a local node that has 563 transmitted a SD message receives a SD (or MS) message that indicates 564 a different value of Path field from the value of Path field in the 565 transmitted SD (or MS) message, both the local and remote SD requests 566 are considered to occur simultaneously. 568 The addition of support for protection against SD requires 569 modification to the PSC Control Logic (including the state machine) 570 relative to that described in [RFC6378]. Sections 10 and 11 present 571 the PSC Control Logic when all capabilities of APS mode are enabled. 573 8. Capability 5: Support of EXER Command 575 The EXER command is used to verify the correct operation of the PSC 576 communication, such as the aliveness of the Local Request Logic, the 577 integrity of the PSC Control Logic, the PSC message generation and 578 reception mechanism, and the integrity of the protection path. EXER 579 does not trigger any actual traffic switching. 581 The command is only relevant for bidirectional protection switching, 582 since it is dependent upon receiving a response from the remote node. 583 The EXER command is assigned lower priority than any switching 584 message. It may be used regardless of the traffic usage of the 585 working path. 587 When a node receives a remote EXER message, it SHOULD respond with a 588 Reverse Request (RR) message with the FPath and Path fields set 589 according to the current condition of the node. The RR message SHALL 590 be generated only in response to a remote EXER message. 592 This command is documented in R84 of [RFC5654]. 594 If EXER commands are input at both ends, then a race condition may 595 arise. This is resolved as follows: 597 o If a node has issued EXER and receives EXER before receiving RR, 598 it MUST treat the received EXER as it would an RR, and SHOULD NOT 599 respond with RR. 601 The following PSC Requests are added to the PSC Request field to 602 support the Exercise command (see also Section 14.1): 604 (3) Exercise - indicates that the transmitting end point is 605 exercising the protection channel and mechanism. FPath and Path 606 are set to the same value of the No Request (NR), RR or DNR 607 request that EXER replaces. 609 (2) Reverse Request - indicates that the transmitting end point is 610 responding to an EXER command from the remote node. FPath and 611 Path are set to the same value of the NR or DNR request that RR 612 replaces. 614 The relative priorities of EXER and RR are defined in Section 10.2. 616 9. Capabilities and Modes 617 9.1. Capabilities 619 A Capability is an individual behavior whose use is signaled in a 620 Capabilities TLV, which is placed in Optional TLVs field inside the 621 PSC message shown in Figure 2 of [RFC6378]. The format of the 622 Capabilities TLV is: 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type = Capabilities | Length | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Value = Flags | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 1: Format of Capabilities TLV 634 The value of the Type field is TBD pending IANA allocation. 636 The value of the Length field is the length of the Flags field in 637 octets. The length of the Flags field MUST be a multiple of 4 octets 638 and MUST be the minimum required to signal all the required 639 capabilities. 641 Section 4 to Section 8 discuss five capabilities that are signaled 642 using the five most significant bits; if a node wishes to signal 643 these five capabilities, it MUST send a Flags field of 4 octets. A 644 node would send a Flags field greater than 4 octets only if it had 645 more than 32 Capabilities to indicate. All unused bits MUST be set 646 to zero. 648 If the bit assigned for an individual capability is set to 1, it 649 indicates the sending node's intent to use that capability in the 650 protected domain. If a bit is set to 0, the sending node does not 651 intend to use the indicated capability in the protected domain. Note 652 that it is not possible to distinguish between the intent not to use 653 a capability and a node's complete non-support (i.e., lack of 654 implementation) of a given capability. 656 This document defines five specific capabilities that are described 657 in Section 4 to Section 8. Each capability is assigned bit as 658 follows: 660 0x80000000: priority modification 662 0x40000000: non-revertive behavior modification 664 0x20000000: support of MS-W command 665 0x10000000: support of protection against SD 667 0x08000000: support of EXER command 669 If all the five capabilities should be used, a node SHALL set the 670 Flags field to 0xF8000000. 672 9.1.1. Sending and receiving the Capabilities TLV 674 A node MUST include its Capabilities TLV in every PSC message that it 675 transmits. The transmission and acceptance of the PSC message is 676 described in Section 4.1 of [RFC6378]. 678 When a node receives a Capabilities TLV it MUST compare the Flags 679 value to its most recent Flags value transmitted by the node. If the 680 two are equal, the protected domain is said to be running in the mode 681 indicated by that set of capabilities (see Section 9.2). If the sent 682 and received Capabilities TLVs are not equal, this indicates a 683 capabilities TLV mismatch. When this happens, the node MUST alert 684 the operator and MUST NOT perform any protection switching until the 685 operator resolves the mismatch between the two end-points. 687 9.2. Modes 689 A mode is a given set of Capabilities. Modes are shorthand; 690 referring to a set of capabilities by their individual values or by 691 the name of their mode does not change the protocol behavior. This 692 document defines two modes - PSC and APS. 694 9.2.1. PSC mode 696 PSC mode is defined as the lack of support for any of the additional 697 capabilities defined in this document - that is, a Capabilities set 698 of 0x0. It is the behavior specified in [RFC6378]. 700 There are two ways to declare PSC mode. A node can send no 701 Capabilities TLV at all since there are no TLV units defined in 702 [RFC6378], or it can send a Capabilities TLV with Flags value set to 703 0x0. In order to allow backward compatibility between two end-points 704 - one which supports sending the Capabilities TLV, and one which does 705 not, the node that has the ability to send and process the PSC mode 706 Capabilities TLV MUST be able to both send the PSC mode Capabilities 707 TLV and send no Capabilities TLV at all. An implementation MUST be 708 configurable between these two options. 710 9.2.2. APS mode 712 APS mode is defined as the use of all the five specific capabilities, 713 which are described in Section 4 to Section 8 in this document. APS 714 mode is indicated with the Flags value of 0xF8000000. 716 10. PSC Protocol in APS Mode 718 This section and the following section define the behavior of PSC 719 protocol when all of the aforementioned capabilities are enabled, 720 i.e., APS mode. 722 10.1. Request field in PSC protocol message 724 This document defines two new values for the "Request" field in the 725 PSC protocol message that is shown in Figure 2 of [RFC6378] as 726 follows: 728 (3) Exercise 730 (2) Reverse Request 732 See also Section 14.1 of this document. 734 10.2. Priorities of local inputs and remote requests 736 Based on the description in Sections 3 and 4.3.2 in [RFC6378], the 737 priorities of multiple outstanding local inputs are evaluated in the 738 Local Request Logic, where the highest priority local input (highest 739 local request) is determined. This highest local request is passed 740 to the PSC Control Logic, that will determine the higher priority 741 input (top priority global request) between the highest local request 742 and the last received remote message. When a remote message comes to 743 the PSC Control Logic, the top priority global request is determined 744 between this remote message and the highest local request which is 745 present. The top priority global request is used to determine the 746 state transition, which is described in Section 11. In this 747 document, in order to simplify the description on the PSC Control 748 Logic, we strictly decouple the priority evaluation from the state 749 transition table lookup. 751 The priorities for both local and remote requests are defined as 752 follows from highest to lowest: 754 o Operator Clear (Local only) 756 o Lockout of protection (Local and Remote) 757 o Clear Signal Fail or Degrade (Local only) 759 o Signal Fail on Protection path (Local and Remote) 761 o Forced Switch (Local and Remote) 763 o Signal Fail on Working path (Local and Remote) 765 o Signal Degrade on either Protection path or Working path (Local 766 and Remote) 768 o Manual Switch to either Protection path or Working path (Local and 769 Remote) 771 o WTR Timer Expiry (Local only) 773 o WTR (Remote only) 775 o Exercise (Local and Remote) 777 o Reverse Request (Remote only) 779 o Do-Not-Revert (Remote only) 781 o No Request (Remote and Local) 783 Note that the "Local only" requests are not tranmitted to the remote 784 node. Likewise, the "Remote only" requests do not exist in the Local 785 Request Logic as local inputs. For example, the priority of WTR only 786 applies to the received WTR message, which is generated from the 787 remote node. The remote node that is running the WTR timer in the 788 WTR state has no local request. 790 The remote SF and SD on either the working path or the protection 791 path and the remote MS to either the working path or the protection 792 path are indicated by the values of the Request and FPath fields in 793 the PSC message. 795 The remote request from the remote node is assigned a priority just 796 below the same local request except NR and equal priority requests, 797 such as SD and MS. Since a received NR message needs to be used in 798 the state transition table lookup when there is no outstanding local 799 request, the remote NR request SHALL have a higher priority than the 800 local NR. For the equal priority requests, see Section 10.2.1. 802 10.2.1. Equal priority requests 804 As stated in Section 10.2, the remote request from the remote node is 805 assigned a priority just below the same local request. However, for 806 equal priority requests, such as SD and MS, the priority SHALL be 807 evaluated as described in this section. 809 For equal priority local requests, first-come, first-served rule 810 SHALL be applied. Once a local request appears in the Local Request 811 Logic, a subsequent equal priority local request requesting a 812 different action, i.e., the action results in the same Request value 813 but a different FPath value, SHALL be considered to have a lower 814 priority. Furthermore, in the case of MS command, the subsequent 815 local MS command requesting a different action SHALL be rejected and 816 cleared. 818 When the priority is evaluated in the PSC Control Logic between the 819 highest local request and a remote request, the following equal 820 priority resolution rules SHALL be applied: 822 o If two requests request the same action, i.e., the same Request 823 and FPath values, then the local request SHALL be considered to 824 have a higher priority than the remote request. 826 o When the highest local request comes to the PSC Control Logic, if 827 the remote request that requests a different action exists, then 828 the highest local request SHALL be ignored and the remote request 829 SHALL remain to be the top priority global request. In the case 830 of MS command, the local MS command requesting a different action 831 SHALL be cancelled. 833 o When the remote request comes to the PSC Control Logic, if the 834 highest local request that requests a different action exists, 835 then the top priority global request SHALL be determined by the 836 following rules: 838 * For MS requests, the MS-W request SHALL be considered to have a 839 higher priority than the MS-P request. The node that has local 840 MS-W request SHALL maintain the local MS-W request as the top 841 priority global request. The other node that has local MS-P 842 request SHALL cancel the MS-P command and SHALL generate 843 "Operator Clear" internally as the top priority global request. 845 * For SD requests, the SD on the standby path (the path from 846 which the selector does not select the user data traffic) SHALL 847 be considered to have a higher priority than the SD on the 848 active path (the path from which the selector selects the user 849 data traffic) regardless of its origin (local or remote 850 message). The node that has the SD on the standby path SHALL 851 maintain the local SD on the standby path request as the top 852 priority global request. The other node that has local SD on 853 the active path SHALL use the remote SD on the standby path as 854 the top priority global request to lookup the state transition 855 table. The differentiation of the active and standby paths is 856 based upon which path had been selected for the user data 857 traffic "when each node detected its local SD". 859 10.3. Acceptance and retention of local inputs 861 A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W, 862 SHALL be accepted and retained persistently in the Local Request 863 Logic as long as the defect condition exists. If there is any higher 864 priority local input than the local defect input, the higher priority 865 local input is passed to the PSC Control Logic as the highest local 866 request, but the local defect input cannot be removed but remains in 867 the Local Request Logic. When the higher priority local input is 868 cleared, the local defect will become the highest local request if 869 the defect condition still exists. 871 Operator Clear (OC) command, SFDc and WTR Timer Expiry are not 872 persistent. Once they appear to the Local Request Logic and complete 873 all the operations in the protection switching control, they SHALL 874 disappear. 876 LO, FS, MS, and EXER commands SHALL be rejected if there is any 877 higher priority local input in the Local Request Logic. If a new 878 higher-priority local request (including an operator command) is 879 accepted, any previous lower-priority local operator command SHALL be 880 cancelled. When any higher-priority remote request is received, a 881 lower-priority local operator command SHALL be cancelled. The 882 cancelled operator command is cleared. If the operators wish to 883 renew the cancelled command then they should reissue the command. 885 11. State Transition Tables in APS Mode 887 When there is a change in the highest local request or in remote PSC 888 messages, the top priority global request SHALL be evaluated and the 889 state transition tables SHALL be looked up in the PSC Control Logic. 890 The 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 local request, the local state 895 transition table in Section 11.1 SHALL be used to decide the next 896 state of the node. Otherwise, the remote state transition table 897 in Section 11.2 SHALL be 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 and 901 Fpath fields. 903 o For the node currently in the local state, if the top priority 904 global request is changed to OC or SFDc causing the next state to 905 be Normal, WTR or DNR, then all the local and remote requests 906 SHALL be re-evaluated as if the node is in the state specified in 907 the footnotes to the state transition tables, before deciding the 908 final state. If there are no active requests, the node enters the 909 state specified in the footnotes to the state transition tables. 910 This re-evaluation is an internal operation confined within the 911 local node, and the PSC messages are generated according to the 912 final state. 914 o The WTR timer is started only when the node which has recovered 915 from a local failure or degradation enters the WTR state. A node 916 which is entering into the WTR state due to a remote WTR message 917 does not start the WTR timer. The WTR timer SHALL be stopped when 918 any local or remote request triggers the state change out of the 919 WTR state. 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:R Unavailable state due to remote SD-P message 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 WTR Wait-to-Restore state 941 DNR Do-not-Revert state 942 E::L Exercise state due to local EXER command 943 E::R Exercise state due to remote EXER message 945 Each state corresponds to the transmission of a particular set of 946 Request, FPath and Path fields. The table below lists the message 947 that is generally sent in each particular state. If the message to 948 be sent in a particular state deviates from the table below, it is 949 noted in the footnotes to the state transition tables. 951 State Request(FPath,Path) 952 ------- ------------------------------------ 953 N NR(0,0) 954 UA:LO:L LO(0,0) 955 UA:P:L SF(0,0) 956 UA:DP:L SD(0,0) 957 UA:LO:R highest local request(local FPath,0) 958 UA:P:R highest local request(local FPath,0) 959 UA:DP:R highest local request(local FPath,0) 960 PF:W:L SF(1,1) 961 PF:DW:L SD(1,1) 962 PF:W:R highest local request(local FPath,1) 963 PF:DW:R highest local request(local FPath,1) 964 SA:F:L FS(1,1) 965 SA:MW:L MS(0,0) 966 SA:MP:L MS(1,1) 967 SA:F:R highest local request(local FPath,1) 968 SA:MW:R NR(0,0) 969 SA:MP:R NR(0,1) 970 WTR WTR(0,1) 971 DNR DNR(0,1) 972 E::L EXER(0,x), where x is the existing Path value 973 when Exercise command is issued. 974 E::R RR(0,x), where x is the existing Path value 975 when RR message is generated. 977 Some operation examples of APS mode are shown in Appendix D. 979 In the state transition tables below, the letter 'i' stands for 980 "ignore", and is an indication to remain in the current state and 981 continue transmitting the current PSC message 983 11.1. State transition by local inputs 984 | OC | LO | SFDc | SF-P | FS | SF-W | 985 --------+-----+---------+------+--------+--------+--------+ 986 N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 987 UA:LO:L | (1) | i | i | i | i | i | 988 UA:P:L | i | UA:LO:L | (1) | i | i | i | 989 UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L | 990 UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 991 UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 992 UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 993 PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i | 994 PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L | 995 PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 996 PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 997 SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i | 998 SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 999 SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1000 SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1001 SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1002 SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1003 WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1004 DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1005 E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1006 E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1008 | SD-P | SD-W | MS-W | MS-P | WTRExp | EXER 1009 --------+---------+---------+---------+---------+--------+------ 1010 N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1011 UA:LO:L | i | i | i | i | i | i 1012 UA:P:L | i | i | i | i | i | i 1013 UA:DP:L | i | i | i | i | i | i 1014 UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i 1015 UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i 1016 UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i 1017 PF:W:L | i | i | i | i | i | i 1018 PF:DW:L | i | i | i | i | i | i 1019 PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i 1020 PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i 1021 SA:F:L | i | i | i | i | i | i 1022 SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i 1023 SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i 1024 SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i 1025 SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i 1026 SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i 1027 WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i 1028 DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1029 E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i 1030 E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1031 NOTES: 1033 (1) Re-evaluate to determine final state as if the node is in the 1034 Normal state. If there are no active requests, the node enters 1035 the Normal State. 1037 (2) In the case that both local input after SFDc and the last 1038 received remote message are no requests, the node enters into 1039 the WTR state when the domain is configured for revertive 1040 behavior, or the node enters into the DNR state when the domain 1041 is configured for non-revertive behavior. In all the other 1042 cases, where one or more active requests exist, re-evaluate to 1043 determine the final state as if the node is in the Normal state. 1045 (3) Re-evaluate to determine final state as if the node is in the 1046 Normal state when the domain is configured for revertive 1047 behavior, or as if the node is in the DNR state when the domain 1048 is configured for non-revertive behavior. If there are no 1049 active requests, the node enters either the Normal state when 1050 the domain is configured for revertive behavior or the DNR state 1051 when the domain is configured for non-revertive behavior. 1053 (4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if 1054 it is running. In APS mode, OC can cancel the WTR timer and 1055 hasten the state transition to the Normal state as in other 1056 transport networks. 1058 (5) If Path value is 0, re-evaluate to determine final state as if 1059 the node is in the Normal state. If Path value is 1, re- 1060 evaluate to determine final state as if the node is in the DNR 1061 state. If there are no active requests, the node enters the 1062 Normal state when Path value is 0, or the DNR state when Path 1063 value is 1. 1065 (6) Remain in the WTR state and send NR(0,1). 1067 11.2. State transition by remote messages 1068 | LO | SF-P | FS | SF-W | SD-P | SD-W | 1069 --------+---------+--------+--------+--------+---------+---------+ 1070 N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1071 UA:LO:L | i | i | i | i | i | i | 1072 UA:P:L | UA:LO:R | i | i | i | i | i | 1073 UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) | 1074 UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1075 UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1076 UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R | 1077 PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i | 1078 PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i | 1079 PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R | 1080 PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i | 1081 SA:F:L | UA:LO:R | UA:P:R | i | i | i | i | 1082 SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1083 SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1084 SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R | 1085 SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1086 SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1087 WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1088 DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1089 E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1090 E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1092 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 1093 --------+---------+---------+-----+------+----+------+---- 1094 N | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1095 UA:LO:L | i | i | i | i | i | i | i 1096 UA:P:L | i | i | i | i | i | i | i 1097 UA:DP:L | i | i | i | i | i | i | i 1098 UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1099 UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1100 UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1101 PF:W:L | i | i | i | i | i | i | i 1102 PF:DW:L | i | i | i | i | i | i | i 1103 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1104 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1105 SA:F:L | i | i | i | i | i | i | i 1106 SA:MW:L | i | i | i | i | i | i | i 1107 SA:MP:L | i | i | i | i | i | i | i 1108 SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N 1109 SA:MW:R | i | SA:MP:R | i | E::R | i | i | N 1110 SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N 1111 WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12) 1112 DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1113 E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i 1114 E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N 1115 NOTES: 1117 (7) If the received SD-W message has Path=0, ignore the message. If 1118 the received SD-W message has Path=1, go to the PF:DW:R state 1119 and transmit SD(0,1) 1121 (8) If the received SD-P message has Path=1, ignore the message. If 1122 the received SD-P message has Path=0, go to the UA:DP:R state 1123 and transmit SD(1,0). 1125 (9) Transition to the WTR state and continue to send the current 1126 message. 1128 (10) Transition to the DNR state and continue to send the current 1129 message. 1131 (11) If the received NR message has Path=1, transition to the WTR 1132 state if domain configured for revertive behavior, else 1133 transition to the DNR state. If the received NR message has 1134 Path=0, transition to the Normal state. 1136 (12) If the receiving node's WTR timer is running, maintain current 1137 state and message. If the WTR timer is not running, transition 1138 to the Normal state. 1140 (13) Transit to the WTR state and send NR(0,1) message. The WTR 1141 timer is not initiated. 1143 11.3. State transition for 1+1 unidirectional protection 1145 The state transition tables given in Sections 11.1 and 11.2 are for 1146 bidirectional protection switching, where remote PSC protocol 1147 messages are used to determine the protection switching actions. 1+1 1148 unidirectional protection switching does not require the remote 1149 information in PSC protocol message and acts upon local inputs only. 1150 The state transition by local inputs in Section 11.1 SHALL be reused 1151 for 1+1 unidirectional protection under the following conditions: 1153 o The value of Request field in the received remote message is 1154 ignored and always assumed to be no request. 1156 o Replace footnote (4) with "Stop the WTR timer and transit to the 1157 Normal state." 1159 o Replace footnote (6) with "Transit to the Normal state." 1161 o Exercise command is not relevant. 1163 12. Provisioning Mismatch and Protocol Failure in APS Mode 1165 The remote PSC message that is received from the remote node is 1166 subject to the detection of provisioning mismatch and protocol 1167 failure conditions. In APS mode, provisioning mismatches are handled 1168 as follows: 1170 o If the PSC message is received from the working path due to 1171 working/protection path configuration mismatch, the node MUST 1172 alert the operator and MUST NOT perform any protection switching 1173 until the operator resolves this path configuration mismatch. 1175 o In the case that the mismatch happens in two-bit "Protection Type 1176 (PT)" field, which indicates permanent/selector bridge type and 1177 uni/bidirectional switching type, 1179 * If the value of the PT field of one side is 2 (i.e., selector 1180 bridge) and the value of PT field of the other side is 1 or 3 1181 (i.e., permanent bridge), then this event MUST be notified to 1182 the operator and each node MUST NOT perform any protection 1183 switching until the operator resolves this bridge type 1184 mismatch. 1186 * If the bridge type matches but the switching type mismatches, 1187 i.e., one side has PT=1 (unidirectional switching) while the 1188 other side has PT=2 or 3 (bidirectional switching), then the 1189 node provisioned for bidirectional switching SHOULD fall back 1190 to unidirectional switching to allow interworking. The node 1191 SHOULD notify the operator of this event. 1193 o If the "Revertive (R)" bit mismatches, two sides will interwork 1194 and traffic is protected according to the state transition 1195 definition given in Section 11. The node SHOULD notify the 1196 operator of this event. 1198 o If the Capabilities TLV mismatches, the node MUST alert the 1199 operator and MUST NOT perform any protection switching until the 1200 operator resolves the mismatch in the Capabilities TLV. 1202 The followings are the protocol failure situations and the actions to 1203 be taken: 1205 o No match in sent "Data Path (Path)" and received "Data Path 1206 (Path)" for more than 50 ms: The node MAY continue to perform 1207 protection switching and SHOULD notify the operator of this event. 1209 o No PSC message is received on the protection path during at least 1210 3.5 times the long PSC message interval, (e.g. at least 17.5 1211 seconds with a default message interval of 5 seconds) and there is 1212 no defect on the protection path: The node MUST alert the operator 1213 and MUST NOT perform any protection switching until the operator 1214 resolves this defect. 1216 13. Security Considerations 1218 This document introduces no new security risks. [RFC6378] points out 1219 that MPLS relies on assumptions about traffic injection difficulty 1220 and assumes that the control plane does not have end-to-end security. 1221 [RFC5920] describes MPLS security issues and generic methods for 1222 securing traffic privacy and integrity. MPLS use should conform such 1223 advice. 1225 14. IANA Considerations 1227 14.1. MPLS PSC Request Registry 1229 In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA 1230 maintains the "MPLS PSC Request Registry". 1232 IANA is requested to assign two new code points from this registry. 1233 The values shall be allocated as follows: 1235 Value Description Reference 1236 ----- --------------------- --------------- 1237 2 Reverse Request (this document) 1238 3 Exercise (this document) 1240 14.2. MPLS PSC TLV Registry 1242 In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA 1243 maintains the "MPLS PSC TLV Registry". 1245 This document defines a new value for the Capabilities TLV type in 1246 the "MPLS PSC TLV Registry". 1248 Value Description Reference 1249 ------ --------------------- --------------- 1250 TBD Capabilities (this document) 1252 14.3. MPLS PSC Capability Flag Registry 1254 IANA is requested to create and maintain a new registry within the 1255 "Generic Associated Channel (G-ACh) Parameters" registry called "MPLS 1256 PSC Capability Flag Registry". All flags within this registry SHALL 1257 be allocated according to the "Standards Action" procedures as 1258 specified in RFC 5226 [RFC5226]. 1260 The length of the flags MUST be a multiple of 4 octets. This 1261 document defines 4 octet flags. Flags greater than 4 octets SHALL be 1262 used only if more than 32 Capabilities need to be defined. Flags 1263 defined in this document are: 1265 Bit Hex Value Capability Reference 1266 ---- ---------- ----------------------------------- --------------- 1267 0 0x80000000 priority modification (this document) 1268 1 0x40000000 non-revertive behavior modification (this document) 1269 2 0x20000000 support of MS-W command (this document) 1270 3 0x10000000 support of protection against SD (this document) 1271 4 0x08000000 support of EXER command (this document) 1272 5-31 Unassigned (this document) 1274 15. Acknowledgements 1276 The authors would like to thank Yaacov Weingarten, Yuji Tochio, 1277 Malcolm Betts, Ross Callon, Qin Wu and Xian Zhang for their valuable 1278 comments and suggestions on this document. 1280 We would also like to acknowledge explicit text provided by Loa 1281 Andersson and Adrian Farrel. 1283 16. References 1285 16.1. Normative References 1287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1288 Requirement Levels", BCP 14, RFC 2119, March 1997. 1290 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1291 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1292 May 2008. 1294 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1295 and S. Ueno, "Requirements of an MPLS Transport Profile", 1296 RFC 5654, September 2009. 1298 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1299 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1300 Protection", RFC 6378, October 2011. 1302 16.2. Informative References 1304 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1305 Restoration) Terminology for Generalized Multi-Protocol 1306 Label Switching (GMPLS)", RFC 4427, March 2006. 1308 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1309 Networks", RFC 5920, July 2010. 1311 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1312 TP) Survivability Framework", RFC 6372, September 2011. 1314 [G841] International Telecommunications Union, "Types and 1315 characteristics of SDH network protection architectures", 1316 ITU-T Recommendation G.841, October 1998. 1318 [G873.1] International Telecommunications Union, "Optical Transport 1319 Network (OTN): Linear protection", ITU-T Recommendation 1320 G.873.1, July 2011. 1322 [G8031] International Telecommunications Union, "Ethernet Linear 1323 Protection Switching", ITU-T Recommendation G.8031/Y.1342, 1324 June 2011. 1326 Appendix A. An Example of Out-of-service Scenarios 1328 The sequence diagram shown is an example of the out-of-service 1329 scenarios based on the priority level defined in [RFC6378]. The 1330 first PSC message which differs from the previous PSC message is 1331 shown. 1333 A Z 1334 | | 1335 (1) |-- NR(0,0) ------>| (1) 1336 |<----- NR(0,0) ---| 1337 | | 1338 | | 1339 | (FS issued at Z) | (2) 1340 (3) |<------ FS(1,1) --| 1341 |-- NR(0,1) ------>| 1342 | | 1343 | | 1344 (4) | (SF on P(A<-Z)) | 1345 | | 1346 | | 1347 | (Clear FS at Z) | (5) 1348 (6) | X <- NR(0,0) --| 1349 | | 1350 | | 1352 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1354 (2) When a FS command is issued at node Z, node Z goes into local 1355 Protecting Administrative state (PA:F:L) and begins transmission of 1356 an FS(1,1) messages. 1358 (3) A remote FS message causes node A to go into remote Protecting 1359 Administrative state (PA:F:R), and node A begins transmitting NR(0,1) 1360 messages. 1362 (4) When node A detects a unidirectional SF-P, node A keeps sending 1363 NR(0,1) message because SF-P is ignored under the PA:F:R state. 1365 (5) When a Clear command is issued at node Z, node Z goes into the 1366 Normal state and begins transmission of NR(0,0) messages. 1368 (6) But, node A cannot receive PSC message because of local 1369 unidirectional SF-P. Because no valid PSC message is received, over 1370 a period of several successive message intervals, the last valid 1371 received message remains applicable and the node A continue to 1372 transmit an NR(0,1) message in the PA:F:R state. 1374 Now, there exists a mismatch between the bridge/selector positions of 1375 node A (transmitting an NR(0,1)) and node Z (transmitting an 1376 NR(0,0)). It results in out-of-service even when there is neither 1377 SF-W nor FS. 1379 Appendix B. An Example of Sequence Diagram Showing the Problem with the 1380 Priority Level of SFc 1382 An example of sequence diagram showing the problem with the priority 1383 level of SFc defined in [RFC6378] is given below. The following 1384 sequence diagram is depicted for the case of bidirectional signal 1385 fails. However, other cases with unidirectional signal fails can 1386 result in the same problem. The first PSC message which differs from 1387 the previous PSC message is shown. 1389 A Z 1390 | | 1391 (1) |-- NR(0,0) ------>| (1) 1392 |<----- NR(0,0) ---| 1393 | | 1394 | | 1395 (2) | (SF on P(A<->Z)) | (2) 1396 |-- SF(0,0) ------>| 1397 |<------ SF(0,0) --| 1398 | | 1399 | | 1400 (3) | (SF on W(A<->Z)) | (3) 1401 | | 1402 | | 1403 (4) | (Clear SF-P) | (4) 1404 | | 1405 | | 1406 (5) | (Clear SF-W) | (5) 1407 | | 1408 | | 1410 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1412 (2) When SF-P occurs, each node enters into the UA:P:L state and 1413 transmits SF(0,0) messages. Traffic remains on the working path. 1415 (3) When SF-W occurs, each node remains in the UA:P:L state as SF-W 1416 has a lower priority than SF-P. Traffic is still on the working 1417 path. Traffic cannot be delivered as both the working path and the 1418 protection path are experiencing signal fails. 1420 (4) When SF-P is cleared, local "Clear SF-P" request cannot be 1421 presented to the PSC Control Logic, which takes the highest local 1422 request and runs PSC state machine, since the priority of "Clear 1423 SF-P" is lower than that of SF-W. Consequently, there is no change 1424 in state, and the selector and/or bridge keep pointing at the working 1425 path, which has signal fail condition. 1427 Now, traffic cannot be delivered while the protection path is 1428 recovered and available. It should be noted that the same problem 1429 will occur in the case that the sequence of SF-P and SF-W events is 1430 changed. 1432 If we further continue with this sequence to see what will happen 1433 after SF-W is cleared, 1435 (5) When SF-W is cleared, local "Clear SF-W" request can be passed to 1436 the PSC Control Logic as there is no higher priority local input, but 1437 this will be ignored in the PSC Control Logic according to the state 1438 transition definition in [RFC6378]. There will be no change in state 1439 or protocol message transmitted. 1441 As SF-W is now cleared and the selector and/or bridge are still 1442 pointing at the working path, traffic delivery is resumed. However, 1443 each node is in the UA:P:L state and transmitting SF(0,0) message, 1444 while there exists no outstanding request for protection switching. 1445 Moreover, any future legitimate protection switching requests, such 1446 as SF-W, will be rejected as each node thinks the protection path is 1447 unavailable. 1449 Appendix C. Freeze Command 1451 The "Freeze" command applies only to the local node of the protection 1452 group and is not signaled to the remote node. This command freezes 1453 the state of the protection group. Until the Freeze is cleared, 1454 additional local commands are rejected and condition changes and 1455 received PSC information are ignored. 1457 "Clear Freeze" command clears the local freeze. When the Freeze 1458 command is cleared, the state of the protection group is recomputed 1459 based on the persistent condition of the local triggers. 1461 Because the freeze is local, if the freeze is issued at one end only, 1462 a failure of protocol can occur as the other end is open to accept 1463 any operator command or a fault condition. 1465 Appendix D. Operation Examples of the APS Mode 1467 The sequence diagrams shown in this section are only a few examples 1468 of the APS mode operations. The first PSC protocol message which 1469 differs from the previous message is shown. The operation of hold- 1470 off timer is omitted. The Request, FPath and Path fields, whose 1471 values are changed during PSC message exchange are shown. For an 1472 example, SF(1,0) represents an PSC message with the following field 1473 values: Request=SF, FPath=1 and Path=1. The values of the other 1474 fields remain unchanged from the initial configuration. W(A->Z) and 1475 P(A->Z) indicate the working path and the protection path in the 1476 direction of A to Z, respectively. 1478 Example 1. 1:1 bidirectional protection switching (revertive 1479 operation) - Unidirectional SF case 1480 A Z 1481 | | 1482 (1) |<---- NR(0,0)---->| (1) 1483 | | 1484 | | 1485 (2) | (SF on W(Z->A)) | 1486 |---- SF(1,1)----->| (3) 1487 (4) |<----- NR(0,1)----| 1488 | | 1489 | | 1490 (5) | (Clear SF-W) | 1491 |---- WTR(0,1)---->| 1492 /| | 1493 | | | 1494 WTR timer | | 1495 | | | 1496 \| | 1497 (6) |---- NR(0,1)----->| (7) 1498 (8) |<----- NR(0,0)----| 1499 |---- NR(0,0)----->| (9) 1500 | | 1502 (1) The protected domain is operating without any defect, and the 1503 working path is used for delivering the traffic in the Normal state. 1505 (2) SF-W occurs in the Z to A direction. Node A enters into the 1506 PF:W:L state and generates SF(1,1) message. Selector and bridge of 1507 node A are pointing at the protection path. 1509 (3) Upon receiving SF(1,1), node Z sets selector and bridge to the 1510 protection path. As there is no local request in node Z, node Z 1511 generates NR(0,1) message in the PF:W:R state. 1513 (4) Node A confirms that the remote node is also selecting the 1514 protection path. 1516 (5) Node A detects clearing of SF condition, starts the WTR timer, 1517 and sends WTR(0,1) message in the WTR state. 1519 (6) At expiration of the WTR timer, node A sets selector and bridge 1520 to the working path and sends NR(0,1) message. 1522 (7) Node Z is notified that the remote request has been cleared. 1523 Node Z transits to the Normal state and sends NR(0,0) message. 1525 (8) Upon receiving NR(0,0) message, node A transits to the Normal 1526 state and sends NR(0,0) message. 1528 (9) It is confirmed that the remote node is also selecting the 1529 working path. 1531 Example 2. 1:1 bidirectional protection switching (revertive 1532 operation) - Bidirectional SF case - Inconsistent WTR timers 1534 A Z 1535 | | 1536 (1) |<---- NR(0,0)---->| (1) 1537 | | 1538 | | 1539 (2) | (SF on W(A<->Z)) | (2) 1540 |<---- SF(1,1)---->| 1541 | | 1542 | | 1543 (3) | (Clear SF-W) | (3) 1544 |<---- NR(0,1)---->| 1545 (4) |<--- WTR(0,1) --->| (4) 1546 /| |\ 1547 | | | | 1548 WTR timer | | WTR timer 1549 | | | | 1550 | | |/ 1551 | |<------ NR(0,1)---| (5) 1552 | | | 1553 \| | 1554 (6) |--- NR(0,1)------>| 1555 |<------ NR(0,0)---| (7) 1556 (8) |--- NR(0,0)------>| 1557 | | 1559 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1561 (2) When SF-W occurs, each node enters into the PF:W:L state and 1562 transmits SF(1,1) messages. Traffic is switched to the protection 1563 path. Upon receiving SF(1,1), each node confirms that the remote 1564 node is also sending and receiving the traffic from the protection 1565 path. 1567 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1568 transmits NR(0,1) messages as the last received message is SF-W. 1570 (4) Upon receiving NR(0,1) messages, each node goes into the WTR 1571 state, starts the WTR timer, and sends the WTR(0,1) messages. 1573 (5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as 1574 the last received APS message was WTR. When NR(0,1) arrives at node 1575 A, node A maintains the WTR state and keeps sending current WTR 1576 messages as described in the state transition table. 1578 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1580 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1581 Normal state, sets selector and bridge to the working path, and sends 1582 NR(0,0) message. 1584 (8) The received NR(0,0) message causes node A to go to the Normal 1585 state. Now, the traffic is switched back to the working path. 1587 Example 3. 1:1 bidirectional protection switching - R bit mismatch 1589 This example shows that both sides will interwork and the traffic is 1590 protected when one side (node A) is configured as revertive operation 1591 and the other (node Z) is configured as non-revertive operation. The 1592 interworking is covered in the state transition tables. 1594 (revertive) A Z (non-revertive) 1595 | | 1596 (1) |<---- NR(0,0)---->| (1) 1597 | | 1598 | | 1599 (2) | (SF on W(A<->Z)) | (2) 1600 |<---- SF(1,1)---->| 1601 | | 1602 | | 1603 (3) | (Clear SF-W) | (3) 1604 |<---- NR(0,1)---->| 1605 (4) |<----- DNR(0,1)---| (4) 1606 /|-- WTR(0,1)------>| 1607 | |<----- NR(0,1)----| (5) 1608 | | | 1609 WTR timer | | 1610 | | | 1611 | | | 1612 \| | 1613 (6) |--- NR(0,1)------>| 1614 |<------ NR(0,0)---| (7) 1615 (8) |--- NR(0,0)------>| 1616 | | 1618 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1620 (2) When SF-W occurs, each node enters into the PF:W:L state and 1621 transmits SF(l,l) messages. Traffic is switched to the protection 1622 path. Upon receiving SF(1,1), each node confirms that the remote 1623 node is also sending and receiving the traffic on the protection 1624 path. 1626 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1627 transmits NR(0,1) messages as the last received message is SF-W. 1629 (4) Upon receiving NR(0,1) messages, node A goes into the WTR state, 1630 starts the WTR timer, and sends WTR(0,1) messages. At the same time, 1631 node Z transits to the DNR state and sends DNR(0,1) message. 1633 (5) When the WTR message arrives at node Z, node Z transits to the 1634 WTR state and send NR(0,1) message according to the state transition 1635 table. At the same time, the DNR message arrived at node Z is 1636 ignored according to the state transition table. Therefore, node Z, 1637 which is configured as non-revertive operation, is operating as if in 1638 revertive operation. 1640 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1642 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1643 Normal state, sets selector and bridge to the working path, and sends 1644 NR(0,0) message. 1646 (8) The received NR(0,0) message causes node A to transits to the 1647 Normal state. Now, the traffic is switched back to the working path. 1649 Authors' Addresses 1651 Jeong-dong Ryoo (editor) 1652 ETRI 1653 218 Gajeongno 1654 Yuseong-gu, Daejeon 305-700 1655 South Korea 1657 Phone: +82-42-860-5384 1658 Email: ryoo@etri.re.kr 1660 Eric Gray (editor) 1661 Ericsson 1663 Email: eric.gray@ericsson.com 1664 Huub van Helvoort 1665 Huawei Technologies 1666 Karspeldreef 4, 1667 Amsterdam 1101 CJ 1668 the Netherlands 1670 Phone: +31 20 4300936 1671 Email: huub.van.helvoort@huawei.com 1673 Alessandro D'Alessandro 1674 Telecom Italia 1675 via Reiss Romoli, 274 1676 Torino 10148 1677 Italy 1679 Phone: +39 011 2285887 1680 Email: alessandro.dalessandro@telecomitalia.it 1682 Taesik Cheung 1683 ETRI 1684 218 Gajeongno 1685 Yuseong-gu, Daejeon 305-700 1686 South Korea 1688 Phone: +82-42-860-5646 1689 Email: cts@etri.re.kr 1691 Eric Osborne 1692 Cisco Systems, Inc. 1694 Email: eosborne@cisco.com