idnits 2.17.1 draft-rhd-mpls-tp-psc-sd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6378]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC6378, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2013) is 3880 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 997 -- Looks like a reference, but probably isn't: '20' on line 998 -- Looks like a reference, but probably isn't: '21' on line 1000 -- Looks like a reference, but probably isn't: '22' on line 1001 -- Looks like a reference, but probably isn't: '23' on line 1001 -- Looks like a reference, but probably isn't: '24' on line 1003 -- Looks like a reference, but probably isn't: '25' on line 1008 -- Looks like a reference, but probably isn't: '26' on line 1008 -- Looks like a reference, but probably isn't: '27' on line 1005 -- Looks like a reference, but probably isn't: '28' on line 1022 -- Looks like a reference, but probably isn't: '29' on line 1022 -- Looks like a reference, but probably isn't: '30' on line 1022 -- Looks like a reference, but probably isn't: '31' on line 1022 -- Looks like a reference, but probably isn't: '32' on line 1022 -- Looks like a reference, but probably isn't: '33' on line 1025 -- Looks like a reference, but probably isn't: '34' on line 1025 -- Looks like a reference, but probably isn't: '35' on line 1025 -- Looks like a reference, but probably isn't: '36' on line 1025 -- Looks like a reference, but probably isn't: '37' on line 1027 -- Looks like a reference, but probably isn't: '38' on line 1027 -- Looks like a reference, but probably isn't: '39' on line 1027 -- Looks like a reference, but probably isn't: '40' on line 1027 -- Looks like a reference, but probably isn't: '41' on line 1027 -- Looks like a reference, but probably isn't: '42' on line 1028 -- Looks like a reference, but probably isn't: '43' on line 1029 -- Looks like a reference, but probably isn't: '44' on line 1029 -- Looks like a reference, but probably isn't: '45' on line 1029 -- Looks like a reference, but probably isn't: '46' on line 1029 -- Looks like a reference, but probably isn't: '47' on line 1029 -- Looks like a reference, but probably isn't: '14' on line 1051 -- Looks like a reference, but probably isn't: '15' on line 1051 ** Downref: Normative reference to an Informational RFC: RFC 6372 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group J. Ryoo 3 Internet-Draft ETRI 4 Intended status: Standards Track H. van Helvoort 5 Expires: March 15, 2014 Huawei Technologies 6 A. D'Alessandro 7 Telecom Italia 8 September 11, 2013 10 Supporting Signal Degrade in PSC Linear Protection 11 draft-rhd-mpls-tp-psc-sd-01.txt 13 Abstract 15 This document optionally updates [RFC6378], "MPLS Transport Profile 16 (MPLS-TP) Linear Protection", to support protection against signal 17 degrade (SD) in an effort to satisfy the ITU-T's protection switching 18 requirements. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 15, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Operation of Protection Switching against Signal Degrade . . 3 58 5. Updates to the PSC RFC . . . . . . . . . . . . . . . . . . . 4 59 5.1. Updates to Section 3.1. Local Request Logic . . . . . . . 4 60 5.2. Updates to Section 3.5. Wait-to-Restore (WTR) Timer . . . 5 61 5.3. Updates to Section 3.6. PSC Control States . . . . . . . 5 62 5.4. Updates to Section 4.2.2. PSC Request Field . . . . . . . 5 63 5.5. Updates to Section 4.2.3. Protection Type (PT) Field . . 6 64 5.6. Updates to Section 4.2.6. Data Path (Path) Field . . . . 6 65 5.7. Updates to Section 4.3.2. Priority of Inputs . . . . . . 7 66 5.8. Updates to Section 4.3.3.1 Normal State . . . . . . . . . 9 67 5.9. Updates to Section 4.3.3.2 Unavailable State . . . . . . 10 68 5.10. Updates to Section 4.3.3.3 Protecting Administrative 69 State . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.11. Updates to Section 4.3.3.4 Protecting Failure State . . . 16 71 5.12. Updates to Section 4.3.3.5 Wait-to-Restore State . . . . 19 72 5.13. Updates to Section 4.3.3.6 Do-not-Revert State . . . . . 20 73 5.14. Updates to Appendix A. PSC State Machine Tables . . . . . 21 74 6. Security considerations . . . . . . . . . . . . . . . . . . . 25 75 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 79 9.2. Informative References . . . . . . . . . . . . . . . . . 26 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 82 1. Introduction 84 This document optionally updates [RFC6378], "MPLS Transport Profile 85 (MPLS-TP) Linear Protection", to support protection against signal 86 degrade in an effort to satisfy the ITU-T's protection switching 87 requirements shown in the ITU-T's liaison statements [LIAISON1205] 88 and [LIAISON1234]. In MPLS-TP survivability framework [RFC6372], 89 fault conditions include both Signal Fail (SF) and Signal Degrade 90 (SD) that can be used to trigger protection switching. 92 [RFC6378], which defines the Protection State Coordination (PSC) 93 protocol, does not specify how the SF and SD are declared and 94 specifies the protection switching protocol associated with SF only. 96 This document is intended to cover the protection switching protocol 97 associated with SD, and the specifics for the method of identifying 98 SD is out of the scope of this document similarly to SF for 99 [RFC6378]. The updates specified in this document do not require any 100 changes to the protocol's packet format. 102 2. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Acronyms 110 This draft uses the following acronyms: 112 FS Forced Switch 113 LO Lockout of protection 114 MS Manual Switch 115 MPLS-TP Transport Profile for MPLS 116 PSC Protection State Coordination 117 SD Signal Degrade 118 SD-P Signal Degrade on the Protection path 119 SD-W Signal Degrade on the Working path 120 SF Signal Fail 121 SF-P Signal Fail on the Protection path 122 SF-W Signal Fail on the Working path 123 SFc Clear Signal Fail 125 4. Operation of Protection Switching against Signal Degrade 127 In order to maintain the network operation behavior to which 128 transport network operators have become accustomed, the priorities of 129 SD-P and SD-W are defined to be equal as in other transport networks, 130 such as OTN and Ethernet. Once a switch has been completed due to 131 signal degrade on one path, it will not be overridden by signal 132 degrade on the other path (first come, first served behavior), to 133 avoid protection switching that cannot improve signal quality and 134 flapping. 136 When multiple SDs are detected simultaneously, either as local or 137 remote requests on both working and protection paths, the SD on the 138 standby path (the path from which the selector does not select the 139 user data traffic) is considered as having higher priority than the 140 SD on the active path (the path from which the selector selects the 141 user data traffic). Therefore, no unnecessary protection switching 142 is performed and the user data traffic continues to be selected from 143 the active path. 145 In the preceding paragraph, "simultaneously" relates to the 146 occurrence of SD on both the active and standby paths at input to the 147 PSC Protection State Control Logic at the same time, or as long as a 148 SD request has not been acknowledged by the remote end in 149 bidirectional protection switching. In other words, when a local 150 node that has transmitted a SD message receives a SD message that 151 indicates a different value of data path (Path) field than the value 152 of the Path field in the transmitted SD message, both the local and 153 the remote SD requests are considered to occur simultaneously. 155 5. Updates to the PSC RFC 157 This section describes the changes required to support protection 158 against SD in the PSC protocol defined in [RFC6378] 160 5.1. Updates to Section 3.1. Local Request Logic 162 Replace the following two bullet item text: 164 o Signal Degrade (SD) - if any of the server-layer, control-plane, 165 or OAM indications signaled a degraded transmission condition on 166 either the protection path or one of the working paths. The 167 determination and actions for SD are for further study and may 168 appear in a separate document. All references to SD input are 169 placeholders for this extension. 171 o Clear Signal Fail (SFc) - if all of the server-layer, 172 controlplane, or OAM indications are no longer indicating a 173 failure condition on a path that was previously indicating a 174 failure condition. 176 With: 178 o Signal Degrade (SD) - if any of the server-layer, control-plane, 179 or OAM indications signaled a degraded transmission condition on 180 either the protection path or one of the working paths. 182 o Clear Signal Fail (SFc) - if all of the server-layer, 183 controlplane, or OAM indications are no longer indicating a 184 failure/degradation condition on a path that was previously 185 indicating a failure/degradation condition. 187 5.2. Updates to Section 3.5. Wait-to-Restore (WTR) Timer 189 Replace the following text in the first paragraph: 191 The WTR timer is used to delay reversion to Normal state when 192 recovering from a failure condition on the working path and the 193 protection domain is configured for revertive behavior. 195 With: 197 The WTR timer is used to delay reversion to Normal state when the 198 protection domain is configured for revertive behavior and 199 recovering from a failure or a degradation condition on the 200 working path. 202 5.3. Updates to Section 3.6. PSC Control States 204 The second paragraph of Section 4.3.3.2 Unavailable State in 205 [RFC6378] shows the intention of including the signal degrade on the 206 protection in the Unavailable state. Even though the protection path 207 can be partially available under the condition of the signal degrade 208 on the protection path, this document follows the same state grouping 209 as [RFC6378] for SD on the protection. 211 Replace the following bullet item text: 213 o Unavailable state - The protection path is unavailable -- either 214 as a result of an operator Lockout command or a failure condition 215 detected on the protection path. 217 With: 219 o Unavailable state - The protection path is unavailable -- either 220 as a result of an operator Lockout command or a failure/ 221 degradation condition detected on the protection path. 223 5.4. Updates to Section 4.2.2. PSC Request Field 225 Replace the following bullet item text: 227 o (7) Signal Degrade - indicates that the transmitting end point has 228 identified a degradation of the signal, or integrity of the packet 229 transmission on either the working or protection path. This 230 request is presented here only as a placeholder. The specifics 231 for the method of identifying this degradation is out of scope for 232 this document. The details of the actions to be taken for this 233 situation are left for future specification. 235 With: 237 o (7) Signal Degrade - indicates that the transmitting end point has 238 identified a degradation of the signal, or integrity of the packet 239 transmission on either the working or protection path. The FPath 240 field SHALL identify the path that is reporting the degrade 241 condition (i.e., if protection path, then FPath is set to 0; if 242 working path, then FPath is set to 1), and the Path field SHALL 243 indicate where the data traffic is being transported (i.e., if 244 working path is selected, then Path is set to 0; if protection 245 path is selected, then Path is set to 1). 247 5.5. Updates to Section 4.2.3. Protection Type (PT) Field 249 Add the following text at the end of Section 4.2.3: 251 If the detection of a SD depends on the presence of user data 252 packets, such a condition declared on the working path is cleared 253 following protection switching to the protection path if a 254 selector bridge is used, possibly resulting in flapping. To avoid 255 flapping, the selector bridge should duplicate the user data 256 traffic and feed it to both working and protection paths under SD 257 condition. 259 5.6. Updates to Section 4.2.6. Data Path (Path) Field 261 Replace the following bullet item text: 263 o 0: indicates that the protection path is not transporting user 264 data traffic (in 1:n architecture) or transporting redundant user 265 data traffic (in 1+1 architecture). 267 With: 269 o 0: indicates that the protection path is not transporting user 270 data traffic (in 1:n architecture) or transporting redundant user 271 data traffic (in 1+1 architecture or under SD condition in 1:n 272 architecture when the detection of a SD depends on the presence of 273 user data packets) 275 5.7. Updates to Section 4.3.2. Priority of Inputs 277 Replace the following bullet item text: 279 o Signal Degrade on working (OAM / control-plane / server 280 indication) 282 With: 284 o Signal Degrade on either working or protection (OAM / control- 285 plane / server indication) 287 Replace the following two paragraphs: 289 As was noted above, the Local Request logic SHALL always select 290 the local input indicator with the highest priority as the current 291 local request, i.e., only the highest priority local input will be 292 used to affect the control logic. All local inputs with lower 293 priority than this current local request will be ignored. 295 The remote message from the far-end LER is assigned a priority 296 just below the similar local input. For example, a remote Forced 297 Switch would have a priority just below a local Forced Switch but 298 above a local Signal Fail on protection input. As mentioned in 299 Section 3.6.1, the state transition is determined by the higher 300 priority input between the highest priority local input and the 301 remote message. This also determines the classification of the 302 state as local or remote. The following subsections detail the 303 transition based on the current state and the higher priority of 304 these two inputs. 306 With: 308 As was noted above, the Local Request logic SHALL always select 309 the local input indicator with the highest priority as the current 310 local request, i.e., only the highest priority local input will be 311 used to affect the control logic. All local inputs with lower 312 priority than this current local request will be ignored. For 313 local inputs with same priority, first-come, first-served rule is 314 applied. For example, once SD-P (or SD-W) local input is 315 determined as the highest priority local input, then subsequent 316 SD-W (or SD-P) local input will not be presented to the PSC 317 Control logic as the highest local request. 319 The remote message from the far-end LER is assigned a priority 320 just below the same local input. For example, a remote Forced 321 Switch would have a priority just below a local Forced Switch but 322 above a local Signal Fail on protection input. 324 However, if the LER is in a remote state due to a remote message, 325 a subsequent local input having the same priority but requesting 326 different action to the control logic, will be considered as 327 having lower priority than the remote message, and will be 328 ignored. For example, if the LER is in remote Unavailable state 329 due to a remote SD-P, then subsequent local SD-W input will be 330 ignored. 332 It should be noted that there is a reverse case where one LER 333 receives a local input and the other LER receives, simultaneously, 334 a local input with the same priority but requesting different 335 action. In this case, each of the two LERs receives a subsequent 336 remote message having the same priority but requesting different 337 action, while the LER is in a local state due to the local input. 338 In this case, a priority must be set for the inputs with the same 339 priority regardless of its origin (local input or remote message). 340 For example, one LER receives SD-P as a local input and the other 341 LER receives SP-W as a local input, simultaneously. In this case, 342 the SD on the standby path (the path from which the selector does 343 not select the user data traffic) is considered as having higher 344 priority than the SD on the active path (the path from which the 345 selector selects the user data traffic) regardless of its origin 346 (local or remote message). Therefore, no unnecessary protection 347 switching is performed and the user data traffic continues to be 348 selected from the active path. Giving the higher priority to the 349 SD on the standby path SHALL also be applied to the Local Request 350 logic when two SDs for different paths happen to be presented to 351 the Local Request logic exactly at the same time. 353 In order to resolve the equal priority conditions described above, 354 following rules are defined: 356 (a) If two local inputs having same priority but requesting 357 different action come to the Local Request logic, then the 358 input coming first SHALL be considered to have a higher 359 priority than the other coming later (first-come, first- 360 served). 362 (b) If the LER receives both a local input and a remote message 363 with the same priority and requesting the same action, i.e., 364 the same PSC Request Field and the same FPath value, then 365 the local input SHALL be considered to have a higher 366 priority than the remote message. 368 (c) If the LER receives both a local input and a remote message 369 with the same priority but requesting different actions, 370 i.e., the same PSC Request Field but different FPath value, 371 then the first-come, first-served rule SHALL be applied. If 372 the remote message comes first, then the state SHALL be a 373 remote state and subsequent local input is ignored. 374 However, if the local input comes first, the first-come, 375 first-served rule cannot be applied and must be viewed as 376 simultaneous condition. This is because the subsequent 377 remote message will not be an acknowledge of the local input 378 by the far-end node. In this case, the priority SHALL be 379 determined by rules for each simultaneous conditions. 381 (d) If the LER receives both SD-P and SD-W request either as 382 local input or remote message and the LER is in a local 383 state, then the SD on the standby path (the path from which 384 the selector does not select the user data traffic) is 385 considered as having higher priority than the SD on the 386 active path (the path from which the selector selects the 387 user data traffic) regardless of its origin (local or remote 388 message). This rule of giving the higher priority to the SD 389 on the standby path SHALL also be applied to the Local 390 Request logic when two SDs for different paths happen to be 391 presented to the Local Request logic exactly at the same 392 time 394 As mentioned in Section 3.6.1, the state transition is determined 395 by the higher priority input between the highest priority local 396 input and the remote message. This also determines the 397 classification of the state as local or remote. The following 398 subsections detail the transition based on the current state and 399 the higher priority of these two inputs. 401 5.8. Updates to Section 4.3.3.1 Normal State 403 Add the following bullet item text to the transitions in reaction to 404 a local input to the LER: 406 o A local Signal Degrade indication on the protection path (SD-P) 407 SHALL cause the LER to go into local Unavailable state and begin 408 transmission of an SD(0,0) message. 410 o A local Signal Degrade indication on the working path (SD-W) SHALL 411 cause the LER to go into local Protecting failure state and begin 412 transmission of an SD(1,1) message. 414 Add the following bullet item text to the transitions in reaction to 415 a remote message: 417 o A remote SD-P message SHALL cause the LER (LER-A) to go into 418 remote Unavailable state, while continuing to transmit the NR(0,0) 419 message. 421 o A remote SD-W message SHALL cause the LER to go into remote 422 Protecting failure state, and transmit an NR(0,1) message. 424 5.9. Updates to Section 4.3.3.2 Unavailable State 426 The second paragraph of Section 4.3.3.2 Unavailable State in 427 [RFC6378] shows the intention of including the signal degrade on the 428 protection in the Unavailable state. This document follows the same 429 state grouping as [RFC6378] for SD-P, even though the protection path 430 can be partially available under the condition of the signal degrade 431 on the protection path. 433 Replace the following text in the first paragraph of Section 4.3.3.2 434 Unavailable State for further clarification on SD on the protection 435 path: 437 When the protection path is unavailable -- either as a result of a 438 Lockout operator command, or as a result of a SF detected on the 439 protection path -- then the protection domain is in the 440 Unavailable state. 442 With: 444 When the protection path is unavailable -- either as a result of a 445 Lockout operator command, or as a result of a SF/SD detected on 446 the protection path -- then the protection domain is in the 447 Unavailable state. 449 When an LER is in this state due to degradation condition, the 450 user traffic should be duplicated and fed to both working and 451 protection paths if the detection of a SD depends on the presence 452 of user data packets. 454 Replace the following bullet item text in the transitions in reaction 455 to a local input: 457 o A local Forced Switch SHALL be ignored by the PSC Control logic 458 when in Unavailable state as a result of a (local or remote) 459 Lockout of protection. If in Unavailable state due to an SF on 460 protection, then the FS SHALL cause the LER to go into local 461 Protecting administrative state and begin transmitting an FS(1,1) 462 message. It should be noted that due to the unavailability of the 463 protection path (i.e., due to the SF condition) that this FS may 464 not be received by the far-end until the SF condition is cleared. 466 With: 468 o A local Forced Switch SHALL be ignored by the PSC Control logic 469 when in Unavailable state as a result of a (local or remote) 470 Lockout of protection. If in Unavailable state due to an SF/SD on 471 protection, then the FS SHALL cause the LER to go into local 472 Protecting administrative state and begin transmitting an FS(1,1) 473 message. It should be noted that due to the unavailability of the 474 protection path (i.e., due to the SF condition) that this FS may 475 not be received by the far-end until the SF condition is cleared. 477 Replace the following bullet item text in the transitions in reaction 478 to a local input: 480 o A local Signal Fail on the protection path input when in local 481 Unavailable state (by implication, this is due to a local SF on 482 protection) SHALL cause the LER to remain in local Unavailable 483 state and transmit an SF(0,0) message. 485 With: 487 o A local Signal Fail on the protection path input when in local 488 Unavailable state SHALL cause the LER to remain in local 489 Unavailable state and transmit an SF(0,0) message. 491 Replace the following bullet item text in the transitions in reaction 492 to a local input: 494 o A local Signal Fail on the working path input when in remote 495 Unavailable state SHALL cause the LER to remain in remote 496 Unavailable state and transmit an SF(1,0) message. 498 With: 500 o A local Signal Fail on the working path input when in local or 501 remote Unavailable state due to SD-P SHALL cause the LER to go to 502 local Protecting failure state. If the LER is in remote 503 Unavailable state due to SF-P or Lockout of protection, the LER 504 SHALL remain in remote Unavailable state and transmit an SF(1,0) 505 message. 507 Add the following bullet item text to the transitions in reaction to 508 a local input: 510 o A local Clear SD of the protection path in local Unavailable state 511 that is due to an SD on the protection path SHALL cause the LER to 512 go to Normal state. If the LER is in remote Unavailable state but 513 has an active local SD condition, then the local Clear SD SHALL 514 clear the SD local condition and the LER SHALL remain in remote 515 Unavailable state and begin transmitting NR(0,0) messages. In all 516 other cases, the local Clear SD SHALL be ignored. 518 o A local SD-P input when in local Unavailable state (by 519 implication, this is due to a local SD on protection) SHALL cause 520 the LER to remain in local Unavailable state and transmit an 521 SD(0,0) message. When in remote Unavailable state due to LO or 522 SF-P, the LER SHALL remain in remote unavailable state and begin 523 transmitting SD(0,0) messages. When in remote Unavailable state 524 due to SD-P, the LER SHALL enter to local Unavailable state and 525 begin transmitting SD(0,0) messages. 527 o A local SD-W input when in remote Unavailable state SHALL cause 528 the LER to remain in remote Unavailable state and transmit an 529 SD(1,0) message. 531 Replace the following bullet item text in the transitions in reaction 532 to a remote message: 534 o A remote Lockout of protection message SHALL cause the LER to 535 remain in Unavailable state (note that if the LER was previously 536 in local Unavailable state due to a Signal Fail on the protection 537 path, then it will now be in remote Unavailable state) and 538 continue transmission of the current message (either NR(0,0) or 539 LO(0,0) or SF(0,0)). 541 With: 543 o A remote Lockout of protection message SHALL cause the LER to 544 remain in Unavailable state (note that if the LER was previously 545 in local Unavailable state due to a Signal Fail on the protection 546 path or a Signal Degrade on the protection path, then it will now 547 be in remote Unavailable state) and continue transmission of the 548 current message (either NR(0,0) or LO(0,0) or SF(0,0) or SF(1,0) 549 or SD(0,0) or SD(1,0)). 551 Replace the following bullet item text in the transitions in reaction 552 to a remote message: 554 o A remote Forced Switch message SHALL be ignored by the PSC Control 555 logic when in Unavailable state as a result of a (local or remote) 556 Lockout of protection. If in Unavailable state due to a local or 557 remote SF on protection, then the FS SHALL cause the LER to go 558 into remote Protecting administrative state; if in Unavailable 559 state due to local SF, begin transmitting an SF(0,1) message. 561 With: 563 o A remote Forced Switch message SHALL be ignored by the PSC Control 564 logic when in Unavailable state as a result of a local Lockout of 565 protection. If in Unavailable state due to a remote Lockout of 566 protection, the LER SHALL go to remote Protecting Administrative 567 state and begin transmitting a message reflecting its local input 568 with Path=1. If in Unavailable state due to a local or remote 569 SF-P/SD-P, then the FS SHALL cause the LER to go into remote 570 Protecting administrative state; if in Unavailable state due to 571 local SF-P and SD-P, begin transmitting an SF(0,1) and SD(0,1) 572 message, respectively. 574 Replace the following bullet item text in the transitions in reaction 575 to a remote message: 577 o A remote Signal Fail message that indicates that the failure is on 578 the protection path SHALL cause the LER to remain in Unavailable 579 state and continue transmission of the current message (either 580 NR(0,0) or SF(0,0) or LO(0,0)). 582 With: 584 o A remote Signal Fail message that indicates that the failure is on 585 the protection path SHALL cause the LER to remain in Unavailable 586 state and continue transmission of the current message (either 587 NR(0,0) or LO(0,0) or SF(0,0) or SF(1,0) or SD(0,0) or SD(1,0) 589 Replace the following bullet item text in the transitions in reaction 590 to a remote message: 592 o A remote No Request, when the LER is in remote Unavailable state 593 and there is no active local Signal Fail SHALL cause the LER to go 594 into Normal state and continue transmission of the current 595 message. If there is a local Signal Fail on the protection path, 596 the LER SHALL remain in local Unavailable state and transmit an 597 SF(0,0) message. If there is a local Signal Fail on the working 598 path, the LER SHALL go into local Protecting Failure state and 599 transmit an SF(1,1) message. When in local Unavailable state, the 600 remote message SHALL be ignored. 602 With: 604 o A remote No Request, when the LER is in remote Unavailable state 605 and there is no active local Signal Fail or Signal Degrade SHALL 606 cause the LER to go into Normal state and continue transmission of 607 the current message. If there is a local Signal Fail on the 608 protection path, the LER SHALL remain in local Unavailable state 609 and transmit an SF(0,0) message. If there is a local Signal Fail 610 on the working path, the LER SHALL go into local Protecting 611 Failure state and transmit an SF(1,1) message. If there is a 612 local Signal Degrade on the protection path, the LER SHALL remain 613 in local Unavailable state and transmit an SD(0,0) message. If 614 there is a local Signal Degrade on the working path, the LER SHALL 615 go into local Protecting Failure state and transmit an SD(1,1) 616 message. When in local Unavailable state, the remote message 617 SHALL be ignored. 619 Add the following bullet item text to the transitions in reaction to 620 a remote message: 622 o A remote SF-W message SHALL be ignored if the LER is in local 623 Unavailable state due to LO or SF-P. When in local Unavailable 624 state due to SD-P, the LER SHALL enter to remote Protecting 625 Failure state and begin transmitting SD(0,1) messages. If the LER 626 is in remote Unavailable state, then the SF-W message and the 627 local input are reevaluated as if the LER is in the Normal state. 628 In the case that the LER is in remote Unavailable state due to 629 remote SD-P, the reevaluation will cause the LER to enter remote 630 Protecting Failure state and continue to send the current messages 631 with Path=1. 633 o A remote MS message SHALL be ignored if the LER is in local 634 Unavailable state. If the LER is in remote Unavailable state, 635 then the MS message and the local input are reevaluated as if the 636 LER is in the Normal state. 638 o A remote SD-P message shall be ignored if the LER is in local 639 Unavailable state. If the LER is in remote Unavailable state due 640 to LO or SF-P, then the SD-P message and the local input are 641 reevaluated as if the LER is in the Normal state. If the LER is 642 in remote Unavailable state due to SD-P, then the remote SD-P 643 message will be ignored 645 o A remote SD-W message shall be reevaluated with the local input as 646 if the LER is in the Normal state, A remote SD-W message shall be 647 ignored if the LER is in local Unavailable state due to LO or 648 SF-P. When in local Unavailable state due to SD-P, the LER shall 649 examine the Path value in the remote SD-W message. If the Path 650 value of the received SD-W message is the same as the Path value 651 that the LER indicates in its current outgoing PSC message, then 652 the LER shall ignore the SD-W message. Otherwise, as the local 653 SD-P and the remote SD-W are considered to occur simultaneously, 654 perform the followings: 656 * If the working path was the active path at the time when local 657 SD-P was selected as the highest local request, the LER remains 658 in the local Unavailabe state and continue transmission of the 659 current message. 661 * If the working path was the standby path at the time when local 662 SD-P was selected as the highest local request, the LER enters 663 into the remote Protection Failure state and begin transmitting 664 SD(0,1) messages. 666 5.10. Updates to Section 4.3.3.3 Protecting Administrative State 668 Add the following bullet item text to the transitions in reaction to 669 a local input: 671 o A local SD-P SHALL cause the LER to go to local Unavailabe state 672 and begin transmitting an SD(0,0) message, if the current state is 673 due to a (local or remote) MS command. If the LER is in remote 674 Protecting administrative state due to a remote Forced Switch 675 command, then this local indication SHALL cause the LER to remain 676 in remote Protecting administrative state and transmit an SD(0,1) 677 message. If the LER is in local Protecting administrative state 678 due to a local FS command, then this indication SHALL be ignored 679 (i.e., the indication should have been blocked by the Local 680 Request logic). 682 o A local SD-W SHALL cause the LER to go to local Unavailabe state 683 and begin transmitting an SD(1,1) message, it the current state is 684 due to a (local or remote) MS command. If the LER is in remote 685 Protecting administrative state due to a remote Forced Switch 686 command, then this local indication SHALL cause the LER to remain 687 in remote Protecting administrative state and transmit an SD(1,1) 688 message. If the LER is in local Protecting administrative state 689 due to a local FS command, then this indication SHALL be ignored 690 (i.e., the indication should have been blocked by the Local 691 Request logic). 693 Add the following bullet item text to the transitions in reaction to 694 a remote message: 696 o A remote SD-P SHALL cause the LER to go into remote Unavailable 697 state and begin transmitting an NR(0,0) message, if the Protecting 698 administrative state is due to a (local or remote) MS command. It 699 should be noted that this automatically cancels the current MS 700 command and data traffic is reverted to the working path. If the 701 LER is in remote Protecting administrative state due to a remote 702 FS command, then the SD-P message and the local input are 703 reevaluated as if the LER is in the Normal state. If the LER is 704 in local Protecting administrative state due to a local FS 705 command, then this indication SHALL be ignored (i.e., the 706 indication should have been blocked by the Local Request logic). 708 o A remote SD-W message SHALL cause the LER to go into remote 709 Unavailable state and begin transmitting an NR(0,1) message, if 710 the Protecting administrative state is due to a (local or remote) 711 MS command. If the LER is in remote Protecting administrative 712 state due to a remote FS command, then the SD-W message and the 713 local input are reevaluated as if the LER is in the Normal state. 714 If the LER is in local Protecting administrative state due to a 715 local FS command, then this indication SHALL be ignored 717 5.11. Updates to Section 4.3.3.4 Protecting Failure State 719 The bullet item of "Protecting failure state" in Section 3.6. PSC 720 Control States in [RFC6378] includes the degrade condition in 721 Protection failure state. This document follows the same state 722 grouping as [RFC6378] for SD on the working path. 724 Replace the following text in the first paragraph of Section 4.3.3.4 725 Protecting Failure State for further clarification on the SD on the 726 working path: 728 When the protection mechanism has been triggered and the 729 protection domain has performed a protection switch, the domain is 730 in the Protecting failure state. In this state, the normal data 731 traffic SHALL be transported on the protection path. When an LER 732 is in this state, it implies that there either was a local SF 733 condition or it received a remote SF PSC message. The SF 734 condition or message indicated that the failure is on the working 735 path. 737 This state may be overridden by the Unavailable state triggers, 738 i.e., Lockout of protection or SF on the protection path, or by 739 issuing an FS operator command. This state will be cleared when 740 the SF condition is cleared. In order to prevent flapping due to 741 an intermittent fault, the LER SHOULD employ a Wait-to-Restore 742 timer to delay return to Normal state until the network has 743 stabilized (see Section 3.5). 745 With: 747 When the protection mechanism has been triggered and the 748 protection domain has performed a protection switch, the domain is 749 in the Protecting failure state. In this state, the normal data 750 traffic SHALL be transported on the protection path. When an LER 751 is in this state, it implies that there either was a local SF/SD 752 condition or it received a remote SF/SD PSC message. The SF/SD 753 condition or message indicated that the failure/degradation is on 754 the working path. 756 This state may be overridden by the Unavailable state triggers, 757 i.e., Lockout of protection or SF on the protection path, or by 758 issuing an FS operator command. This state will be cleared when 759 the SF/SD condition is cleared. In order to prevent flapping due 760 to an intermittent fault, the LER SHOULD employ a Wait-to-Restore 761 timer to delay return to Normal state until the network has 762 stabilized (see Section 3.5). 764 When an LER is in this state due to degradation condition, the 765 user traffic should be duplicated and fed to both working and 766 protection paths if the detection of a SD depends on the presence 767 of user data packets. 769 Replace the following bullet item text in the transitions in reaction 770 to a local input: 772 o A local Clear SF SHALL be ignored if in remote Protecting failure 773 state. If in local Protecting failure state and the LER is 774 configured for revertive behavior, then this input SHALL cause the 775 LER to go into Wait-to-Restore state, start the WTR timer, and 776 begin transmitting a WTR(0,1) message. If in local Protecting 777 failure state and the LER is configured for non-revertive 778 behavior, then this input SHALL cause the LER to go into Do-not- 779 Revert state and begin transmitting a DNR(0,1) message. 781 With: 783 o A local Clear SF for clearing local SF-W SHALL be ignored if in 784 remote Protecting failure state due to remote SF-W. In local 785 Protecting failure state due to local SF-W, clearing local SF-W 786 SHALL cause the LER to go into WTR state, start the WTR timer, and 787 begin transmitting a WTR(0,1) message, if the LER is configured 788 for revertive behavior. Clear local SF-W in local Protecting 789 failure state due to local SF-W SHALL cause the LER to go into Do- 790 not- Revert state and begin transmitting a DNR(0,1) message for 791 non-revertive configuration. In local Protecting Failure state 792 due to local SD-W, if the SF/SD being cleared is SD-W and there is 793 no local SD-P, then go to WTR or DNR state depending on the 794 configuration for revertive behavior. If there is local SD-P when 795 local SD-W is cleared in local Protecting Failure state due to 796 SD-W, go to local Unavailable state and begin transmitting SD(0.0) 797 message. If the SF/SD being cleared is SD-P in local Protecting 798 Failure due to SD-W, then ignore. In remote Protection Failure 799 state due to remote SD-W, if the SF/SD being cleared is SD-P, then 800 remain in current state and begin transmitting NR(0,1), otherwise, 801 ignore. 803 Add the following bullet item text to the transitions in reaction to 804 a local input: 806 o A local SD-P SHALL be ignored if the LER is in local Protecting 807 Failure state. If in remote Protecting Failure state,the LER 808 SHALL remain in the current state and begin transmission of an 809 SD(0,1) message. 811 o A local SD-W SHALL be ignored if the LER is in local Protecting 812 Failure state. If in remote Protecting Failure state, the LER 813 SHALL remain in the current state and begin transmission of an 814 SD(1,1) message. 816 Add the following SD related sentences to the end of each bullet item 817 text for describing the reaction to remote PSC messages: 819 remote Lockout of protection: If the LER is in local Protecting 820 Failure state due to local SD-W, then go to remote Unavailable 821 state and begin sending SD(1,0) If in remote Protecting Failure 822 state due to remote SD-W, then go to remote Unavailable state and 823 continue to send the current message with Path=0. 825 remote Forced Switch: If the LER is in the Protecting Failure state 826 due to local or remote SD-W, go to remote Protecting 827 Administrative state and continue to send the current message. 829 remote Signal Fail on the protection path: If the LER is in the 830 Protecting Failure state due to local or remote SD-W, go to remote 831 Unavailable state and continue to send the current message with 832 Path=0. 834 Add the following bullet item text to the transitions in reaction to 835 a remote message: 837 o A remote SF-W message received in Protecting Failure state due to 838 local or remote SD-W SHALL cause the LER to remain in Protecting 839 Failure state and continue to send the current message. 841 o A remote SD-P message can cause the LER to react differently 842 depending on the cause and locality of current state as follows: 844 * In Protecting Failure state due to remote SF-W, if there is no 845 local request, transition to remote Unavailable state and send 846 NR(0,0). If there is local SD-W input, then transition to 847 remote Unavailable state and send SD(1,0) message. If the 848 local input is SD-P, then transition to local Unavailable state 849 and send SD(0,0) message. 851 * In Protecting Failure state due to remote SD-W, if the local 852 input is SD-P, then transition to local Unavailable state. 853 Else, transition to N state. 855 * In Protecting Failure state due to local SD-W, if the received 856 SD-P message has Path=1, ignore the message. If the received 857 SD-P message has Path=0 and the active path just before the 858 SD-W is selected as the highest local input was the working 859 path, then go to remote Unavailable state and transmit SD(1,0). 860 If the received SD-P message has Path=0 and the active path 861 just before the SD-W is selected as the highest local input was 862 the protection path, then ignore the received SD-P message. 864 o A remote Manual Switch message received in Protecting Failure due 865 to remote SD-W SHALL cause the LER to reevaluate the MS message 866 and local input as if the LER is in the Normal state. 868 5.12. Updates to Section 4.3.3.5 Wait-to-Restore State 870 Replace the following paragraph in Section 4.3.3.5 Wait-to-Restore 871 State: 873 o When recovering from a failure condition on the working path, the 874 Wait-to-Restore state is used by the PSC protocol to delay 875 reverting to the Normal state, for the period of the WTR timer to 876 allow the recovering failure to stabilize. While in the Wait-to- 877 Restore state, the data traffic SHALL continue to be transported 878 on the protection path. The natural transition from the Wait-to- 879 Restore state to Normal state will occur when the WTR timer 880 expires. 882 With: 884 o When recovering from a failure or degradation condition on the 885 working path, the Wait-to-Restore state is used by the PSC 886 protocol to delay reverting to the Normal state, for the period of 887 the WTR timer to allow the recovering failure/degradation to 888 stabilize. While in the Wait-to-Restore state, the data traffic 889 SHALL continue to be transported on the protection path. The 890 natural transition from the Wait-to-Restore state to Normal state 891 will occur when the WTR timer expires. 893 o When an LER is in this state following the recovery of degradation 894 condition, the user traffic will continue to be duplicated and fed 895 to both working and protection paths if the detection of a SD 896 depends on the presence of user data packets. 898 Add the following bullet item text to the transitions in reaction to 899 a local input: 901 o A local SD-P SHALL send the Stop command to the WTR timer, go into 902 local Unavailable state, and begin transmission of an SD(0,0) 903 message. 905 o A local SD-W SHALL send the Stop command to the WTR timer, go into 906 local Protecting failure state, and begin transmission of an 907 SD(1,1) message. 909 Add the following bullet item text to the transitions in reaction to 910 a remote PSC message: 912 o A remote SD-P message SHALL send the Stop command to the WTR 913 timer, go into remote Unavailable state, and begin transmission of 914 an NR(0,0) message. 916 o A remote SD-W message SHALL send the Stop command to the WTR 917 timer, go into remote Protecting failure state, and begin 918 transmission of an NR(0,1) message. 920 5.13. Updates to Section 4.3.3.6 Do-not-Revert State 922 Add the following bullet item text to the transitions in reaction to 923 a local input: 925 o A local SD-P SHALL cause the LER to go into local Unavailable 926 state, and begin transmission of an SD(0,0) message. 928 o A local SD-W SHALL cause the LER go into local Protecting failure 929 state, and begin transmission of an SD(1,1) message. 931 Add the following bullet item text to the transitions in reaction to 932 a remote PSC message: 934 o A remote SD-P message SHALL cause the LER to go into remote 935 Unavailable state, and begin transmission of an NR(0,0) message. 937 o A remote SD-W message SHALL cause the LER to go into remote 938 Protecting failure state, and begin transmission of an NR(0,1) 939 message. 941 5.14. Updates to Appendix A. PSC State Machine Tables 943 Add the following extended states: 945 UA:DP:L Unavailable state due to local SD on protection path 946 UA:DP:R Unavailable state due to remote SD-P message 947 PF:DW:L Protecting failure state due to local SD on working path 948 PF:DW:R Protecting failure state due to remote SD-W message 950 Add the following default messages: 952 State REQ(FP, P) 953 ------- ---------- 954 UA:DP:L SD(0,0) 955 UA:DP:R NR(0,0) 956 PF:DW:L SD(1,1) 957 PF:DW:R NR(0,1) 959 Add the following text before the state machine table: 961 The letter 'r' in the table below stands for reevaluation, and is 962 an indication to reevaluate all inputs (both the local input and 963 the remote message) as if the LER is in the Normal state. See 964 4.3.3. 966 Modify the state machine as follows (only modified cells are shown): 968 Part 1: Local input state machine 970 +---------+----+---------+--------+--------+--------+ 971 | | OC | LO | SF-P | FS | SF-W | 972 +---------+----+---------+--------+--------+--------+ 973 | N | | | | | | 974 | UA:LO:L | | | | | | 975 | UA:P:L | | | | | | 976 | UA:DP:L | i | UA:LO:L | UA:P:L | PA:F:L | PA:W:L | 977 | UA:LO:R | | | | | | 978 | UA:P:R | | | | | | 979 | UA:DP:R | i | UA:LO:L | UA:P:L | PA:F:L | PF:W:L | 980 | PF:W:L | | | | | | 981 | PF:DW:L | i | UA:LO:L | UA:P:L | PA:F:L | PF:W:L | 982 | PF:W:R | | | | | | 983 | PF:DW:R | i | UA:LO:L | UA:P:L | PA:F:L | PF:W:L | 984 | PA:F:L | | | | | | 985 | PA:M:L | | | | | | 986 | PA:F:R | | | | | | 987 | PA:M:R | | | | | | 988 | WTR | | | | | | 989 | DNR | | | | | | 990 +---------+----+---------+--------+--------+--------+ 992 +---------+---------+---------+------+----+--------+ 993 | | SD-P | SD-W | SFc | MS | WTRExp | 994 +---------+---------+---------+------+----+--------+ 995 | N | UA:DP:L | PF:DW:L | | | | 996 | UA:LO:L | i | i | | | | 997 | UA:P:L | i | i | [5] | | | 998 | UA:DP:L | i | i | [20] | i | i | 999 | UA:LO:R | [21] | [22] | | | | 1000 | UA:P:R | [21] | [22] | | | | 1001 | UA:DP:R | UA:DP:L | [22] | [23] | i | i | 1002 | PF:W:L | i | i | | | | 1003 | PF:DW:L | i | i | [24] | i | i | 1004 | PF:W:R | [25] | [26] | | | | 1005 | PF:DW:R | [25] | PF:DW:L | [27] | i | i | 1006 | PA:F:L | i | i | | | | 1007 | PA:M:L | UA:DP:L | PF:DW:L | | | | 1008 | PA:F:R | [25] | [26] | | | | 1009 | PA:M:R | UA:DP:L | PF:DW:L | | | | 1010 | WTR | UA:DP:L | PF:DW:L | | | | 1011 | DNR | UA:DP:L | PF:DW:L | | | | 1012 +---------+---------+---------+------+----+--------+ 1014 Part 2: Remote messages state machine 1016 +---------+------+------+------+------+---------+---------+ 1017 | | LO | SF-P | FS | SF-W | SD-P | SD-W | 1018 +---------+------+------+------+------+---------+---------+ 1019 | N | | | | | UA:DP:R | PF:DW:R | 1020 | UA:LO:L | | | | | i | i | 1021 | UA:P:L | | | | | i | i | 1022 | UA:DP:L | [28] | [29] | [30] | [31] | i | [32] | 1023 | UA:LO:R | | | | | r | r | 1024 | UA:P:R | | | | | r | r | 1025 | UA:DP:R | [33] | [34] | [35] | [36] | i | r | 1026 | PF:W:L | | | | | i | i | 1027 | PF:DW:L | [37] | [38] | [39] | [40] | [41] | i | 1028 | PF:W:R | | | | | [42] | i | 1029 | PF:DW:R | [43] | [44] | [45] | [46] | [47] | i | 1030 | PA:F:L | | | | | i | i | 1031 | PA:M:L | | | | | UA:DP:R | PF:DW:R | 1032 | PA:F:R | | | | | r | r | 1033 | PA:M:R | | | | | UA:DP:R | PF:DW:R | 1034 | WTR | | | | | UA:DP:R | PF:DW:R | 1035 | DNR | | | | | UA:DP:R | PF:DW:R | 1036 +---------+------+------+------+------+---------+---------+ 1038 +---------+----+------+------+----+ 1039 | | MS | WTR | DNR | NR | 1040 +---------+----+------+------+----+ 1041 | N | | | | | 1042 | UA:LO:L | | | | | 1043 | UA:P:L | | | | | 1044 | UA:DP:L | i | i | i | i | 1045 | UA:LO:R | | | | | 1046 | UA:P:R | | | | | 1047 | UA:DP:R | r | i | i | r | 1048 | PF:W:L | | | | | 1049 | PF:DW:L | i | i | i | i | 1050 | PF:W:R | | | | | 1051 | PF:DW:R | r | [14] | [15] | N | 1052 | PA:F:L | | | | | 1053 | PA:M:L | | | | | 1054 | PA:F:R | | | | | 1055 | PA:M:R | | | | | 1056 | WTR | | | | | 1057 | DNR | | | | | 1058 +---------+----+------+------+----+ 1060 Replace the following footnote: 1062 5 If the SF being cleared is SF-P, transition to N. If it's SF-W, 1063 ignore the clear. 1065 With: 1067 5 If the SF being cleared is SF-P, transition to N. Otherwise, 1068 ignore the clear. 1070 Add the following footnotes for the table: 1072 20 If the SF/SD being cleared is SD-P, transition to N. Otherwise, 1073 ignore the clear. 1075 21 Remain in the current state and transmit SD(0,0). 1077 22 Remain in the current state and transmit SD(1,0). 1079 23 If the SF/SD being cleared is SD-W, then remain in current state 1080 (UA:DP:R) and begin transmitting NR(0,0). Otherwise, ignore the 1081 SFc. 1083 24 If the SF/SD being cleared is SD-W and there is no local SD-P, 1084 then go to WTR or DNR depending on the configuration for 1085 revertive behavior. If there is local SD-P when local SD-W is 1086 cleared, go to UA:DP:L state. If the SF/SD being cleared is 1087 SD-P then ignore. 1089 25 Remain in the current state and transmit SD(0,1). 1091 26 Remain in the current state and transmit SD(1,1). 1093 27 If the SF/SD being cleared is SD-P, then remain in current state 1094 (PF:DW:R) and begin transmitting NR(0,1). Otherwise, ignore. 1096 28 Transition to (UA:LO:R) and continue sending SD(0,0) 1098 29 Transition to (UA:P:R) and continue sending SD(0,0) 1100 30 Transition to (PA:F:R) and send SD(0,1). 1102 31 Transition to (PF:W:R) and send SD(0,1) 1104 32 If the active path just before the SD is selected as the highest 1105 local input was the working path, then ignore. Otherwise, go to 1106 PF:DW:R and transmit SD(0,1) 1108 33 Transition to (UA:LO:R) state and continue to send the current 1109 message. 1111 34 Transition to (UA:P:R) state and continue to send the current 1112 message. 1114 35 Transition to (PA:F:R) state and continue to send the current 1115 message with Path=1. 1117 36 Transition to (PF:W:R) state and continue to send the current 1118 message with Path=1. 1120 37 Transition to (UA:LO:R) and send SD(1,0) 1122 38 Transition to (UA:P:R) and send SD(1,0) 1124 39 Transition to (PA:F:R) and continue to send the current message, 1125 SD(1,1). 1127 40 Transition to (PF:W:R) and continue to send the current message, 1128 SD(1,1). 1130 41 If the received SD-P message has Path=1, ignore the message. If 1131 the received SD-P message has Path=0 and the active path just 1132 before the SD is selected as the highest local input was the 1133 working path, then go to UA:DP:R and transmit SD(1,0). If the 1134 received SD-P message has Path=0 and the active path just before 1135 the SD is selected as the highest local input was the protection 1136 path, then ignore the received SD-P message. 1138 42 If there is no local request, transition to UA:DP:R and send 1139 NR(0,0). If the local input is SD-W, then transition to UA:DP:R 1140 and send SD(1,0) message. If the local input is SD-P, then 1141 transition to UA:DP:L and send SD(0,0) message. 1143 43 Transition to (UA:LO:R) state and continue to send the current 1144 message with Path=0. 1146 44 Transition to (UA:P:R) state and continue to send the current 1147 Message with Path=0. 1149 45 Transition to (PA:F:R) state and continue to send the current 1150 message. 1152 46 Transition to (PF:W:R) state and continue to send the current 1153 message. 1155 47 If the local input is SD-P, then transition to UA:DP:L. Else, 1156 transition to N state. 1158 6. Security considerations 1160 No specific security issue is raised in addition to those ones 1161 already documented in [RFC6378] 1163 7. IANA considerations 1165 This document makes no request of IANA. 1167 Note to RFC Editor: this section may be removed on publication as an 1168 RFC. 1170 8. Acknowledgements 1172 9. References 1174 9.1. Normative References 1176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1177 Requirement Levels", BCP 14, RFC 2119, March 1997. 1179 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1180 TP) Survivability Framework", RFC 6372, September 2011. 1182 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1183 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1184 Protection", RFC 6378, October 2011. 1186 9.2. Informative References 1188 [LIAISON1205] 1189 ITU-T SG15, ., "Liaison Statement: Recommendation ITU-T 1190 G.8131/Y.1382 revision - Linear protection switching for 1191 MPLS-TP networks ", https://datatracker.ietf.org/liaison/ 1192 1205/ , October 2012. 1194 [LIAISON1234] 1195 ITU-T SG15, ., "Liaison Statement: Recommendation ITU-T 1196 G.8131 revision - Linear protection switching for MPLS-TP 1197 networks ", https://datatracker.ietf.org/liaison/1234/ , 1198 February 2013. 1200 Authors' Addresses 1202 Jeong-dong Ryoo 1203 ETRI 1204 218 Gajeongno 1205 Yuseong-gu, Daejeon 305-700 1206 South Korea 1208 Phone: +82-42-860-5384 1209 Email: ryoo@etri.re.kr 1210 Huub van Helvoort 1211 Huawei Technologies 1212 Karspeldreef 4, 1213 Amsterdam 1101 CJ 1214 the Netherlands 1216 Phone: +31 20 4300832 1217 Email: huub.van.helvoort@huawei.com 1219 Alessandro D'Alessandro 1220 Telecom Italia 1221 via Reiss Romoli, 274 1222 Torino 10141 1223 Italy 1225 Phone: +39 011 2285887 1226 Email: alessandro.dalessandro@telecomitalia.it