idnits 2.17.1 draft-rhd-mpls-tp-psc-priority-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2013) is 3900 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: '19' on line 282 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: February 22, 2014 Huawei Technologies 6 A. D'Alessandro 7 Telecom Italia 8 August 21, 2013 10 Priority Modification for the PSC Linear Protection 11 draft-rhd-mpls-tp-psc-priority-01.txt 13 Abstract 15 This document contains the modifications to the priorities of inputs 16 in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" in 17 an effort to satisfy the ITU-T's protection switching requirements 18 and correcting the problems that have been identified. 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 February 22, 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 1.1. Motivations for swapping priorities of FS and SF-P . . . 2 56 1.2. Motivation for raising the priority of Clear SF . . . . . 3 57 1.3. Motivation for introducing Freeze command . . . . . . . . 3 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Updates to the PSC RFC . . . . . . . . . . . . . . . . . . . 4 61 4.1. Updates to Section 4.3.2. Priority of Inputs . . . . . . 4 62 4.2. Updates to Section 4.3.3.2. Unavailable State . . . . . . 4 63 4.3. Updates to Section 4.3.3.3. Protecting Administrative 64 State . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.4. Updates to Appendix A. PSC State Machine Tables . . . . . 5 66 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 67 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. An exmaple of out-of-service scenarios . . . . . . . 7 71 Appendix B. An exmaple of sequence diagram showing 72 the problem with the priority level of Clear SF . . 8 73 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 This document contains the modifications to the priorities of inputs 79 in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" in 80 an effort to satisfy the ITU-T's protection switching requirements 81 and correcting the problems that have been identified. 83 In this document, the priorities of FS and SF-P are swapped and the 84 priority of Clear SF is raised. In addition to the prioririty 85 modification, this document introduces the use of a Freeze command in 86 an Appendix. The reasons for these changes are explained in the 87 following sub-sections from technical and network operational 88 aspects. 90 1.1. Motivations for swapping priorities of FS and SF-P 92 Defining the priority of FS higher than that of SF-P can result in a 93 situation where the protected traffic is taken out-of-service. 94 Setting the priority of any input that is supposed to be signaled to 95 the other end to be higher than that of SF-P can result in 96 unpredictable protection switching state, when the protection path 97 has failed and consequently the PSC communication stopped. An 98 example of the out-of-service scenarios is shown in Appendix A 100 According to Section 2.4 of [RFC5654] it MUST be possible to operate 101 an MPLS-TP network without using a control plane. This means that 102 external switch commands, e.g. FS, can be transferred to the far end 103 only by using the PSC communication channel and should not rely on 104 the presence of a control plane. 106 As the priority of SF-P has been higher than FS in optical transport 107 networks and Ethernet transport networks, for network operators it is 108 important that the MPLS-TP protection switching preserves the network 109 operation behaviour to which network operators have become 110 accustomed. Typically, the FS command is issued before network 111 maintenance jobs, replacing optical cables or other network 112 components. When an operator pulls out a cable on the protection 113 path by mistake, the traffic should be protected and the operator 114 expects this behaviour based on his/her experience on the traditional 115 transport network operations. 117 1.2. Motivation for raising the priority of Clear SF 119 The priority level of Clear SF defined in [RFC6378] can cause traffic 120 disruption when a node that has experienced local signal fails on 121 both working and protection paths is recovering from these failures. 123 An exmaple of sequence diagram showing the problem with the priority 124 level of Clear SF defined in [RFC6378] is shown in Appendix B. 126 1.3. Motivation for introducing Freeze command 128 With the priority swapping between FS and SF-P, the traffic is always 129 moved back to the working path when SF-P occurs in Protecting 130 Administrative State. In the case that network operators need an 131 option to control their networks so that the traffic can remain on 132 the protection path even when the PSC communication channel is 133 broken, the Freeze command, which is a local command and not signaled 134 to the other end, can be used. The use of the Freeze command is 135 described in Appendix C. 137 2. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Acronyms 144 This draft uses the following acronyms: 146 FS Forced Switch 147 MPLS-TP Transport Profile for MPLS 148 SF Signal Fail 149 SFc Clear Signal Fail 151 4. Updates to the PSC RFC 153 This section describes the changes required to modify the priorities 154 of FS, SF-P and Clear SF in the PSC protocol defined in [RFC6378] 156 4.1. Updates to Section 4.3.2. Priority of Inputs 158 The list of local requests in order of priority should be modified as 159 follows: 161 3 Clear Signal Fail/Degrade (OAM / control-plane / server 162 indication) 164 4 Signal Fail on protection (OAM / control-plane / server 165 indication) 167 5 Forced Switch (operator command) 169 6 Signal Fail on working (OAM / control-plane / server indication) 171 7 Signal Degrade on working (OAM / control-plane / server 172 indication) 174 4.2. Updates to Section 4.3.3.2. Unavailable State 176 Remove the following bullet items and their text: 178 o A local Forced Switch SHALL be ignored by the PSC Control logic 179 when in Unavailable state as a result of a (local or remote) 180 Lockout of protection. If in Unavailable state due to an SF on 181 protection, then the FS SHALL cause the LER to go into local 182 Protecting administrative state and begin transmitting an FS(1,1) 183 message. It should be noted that due to the unavailability of the 184 protection path (i.e., due to the SF condition) that this FS may 185 not be received by the far-end until the SF condition is cleared. 187 o A remote Forced Switch message SHALL be ignored by the PSC Control 188 logic when in Unavailable state as a result of a (local or remote) 189 Lockout of protection. If in Unavailable state due to a local or 190 remote SF on protection, then the FS SHALL cause the LER to go 191 into remote Protecting administrative state; if in Unavailable 192 state due to local SF, begin transmitting an SF(0,1) message. 194 4.3. Updates to Section 4.3.3.3. Protecting Administrative State 196 Remove the following text in the first paragraph: 198 The difference between a local FS and local MS affects what local 199 indicators may be received -- the Local Request logic will block 200 any local SF when under the influence of a local FS, whereas the 201 SF would override a local MS. 203 Replace the following bullet item text: 205 o A local Signal Fail indication on the protection path SHALL cause 206 the LER to go into local Unavailable state and begin transmission 207 of an SF(0,0) message, if the current state is due to a (local or 208 remote) Manual Switch operator command. If the LER is in (local 209 or remote) Protecting administrative state due to an FS situation, 210 then the SF on protection SHALL be ignored. 212 With: 214 o A local Signal Fail indication on the protection path SHALL cause 215 the LER to go into local Unavailable state and begin transmission 216 of an SF(0,0) message. 218 Replace the following bullet item text: 220 o A remote Signal Fail message indicating a failure on the 221 protection path SHALL cause the LER to go into remote Unavailable 222 state and begin transmitting an NR(0,0) message, if the Protecting 223 administrative state is due to a Manual Switch command. It should 224 be noted that this automatically cancels the current Manual Switch 225 command and data traffic is reverted to the working path. 227 With: 229 o A remote Signal Fail message indicating a failure on the 230 protection path SHALL cause the LER to go into remote Unavailable 231 state and begin transmitting an NR(0,0) message. It should be 232 noted that this automatically cancels the current Forced Switch or 233 Manual Switch command and data traffic is reverted to the working 234 path. 236 4.4. Updates to Appendix A. PSC State Machine Tables 238 Modify the state machine as follows (only modified cells are shown): 240 Part 1: Local input state machine 242 +---------+----+----+--------+----+------+-----+----+--------+ 243 | | OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp | 244 +---------+----+----+--------+----+------+-----+----+--------+ 245 | N | | | | | | | | | 246 | UA:LO:L | | | | | | | | | 247 | UA:P:L | | | | i | | | | | 248 | UA:LO:R | | | | | | | | | 249 | UA:P:R | | | | i | | | | | 250 | PF:W:L | | | | | | | | | 251 | PF:W:R | | | | | | | | | 252 | PA:F:L | | | UA:P:L | | | | | | 253 | PA:M:L | | | | | | | | | 254 | PA:F:R | | | UA:P:L | | | | | | 255 | PA:M:R | | | | | | | | | 256 | WTR | | | | | | | | | 257 | DNR | | | | | | | | | 258 +---------+----+----+--------+----+------+-----+----+--------+ 260 Part 2: Remote messages state machine 262 +---------+----+--------+----+------+----+-----+-----+----+ 263 | | LO | SF-P | FS | SF-W | MS | WTR | DNR | NR | 264 +---------+----+--------+----+------+----+-----+-----+----+ 265 | N | | | | | | | | | 266 | UA:LO:L | | | | | | | | | 267 | UA:P:L | | | i | | | | | | 268 | UA:LO:R | | | | | | | | | 269 | UA:P:R | | | i | | | | | | 270 | PF:W:L | | | | | | | | | 271 | PF:W:R | | | | | | | | | 272 | PA:F:L | | UA:P:R | | | | | | | 273 | PA:M:L | | | | | | | | | 274 | PA:F:R | | UA:P:R | | | | | | | 275 | PA:M:R | | | | | | | | | 276 | WTR | | | | | | | | | 277 | DNR | | | | | | | | | 278 +---------+----+--------+----+------+----+-----+-----+----+ 280 Remove the following item in the footnotes for the table: 282 [19] Transition to PA:F:R and send SF (0,1). 284 5. Security considerations 285 No specific security issue is raised in addition to those ones 286 already documented in [RFC6378] 288 6. IANA considerations 290 This document makes no request of IANA. 292 Note to RFC Editor: this section may be removed on publication as an 293 RFC. 295 7. Acknowledgements 297 8. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 303 and S. Ueno, "Requirements of an MPLS Transport Profile", 304 RFC 5654, September 2009. 306 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 307 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 308 Protection", RFC 6378, October 2011. 310 Appendix A. An exmaple of out-of-service scenarios 312 The sequence diagram shown is an example of the out-of-service 313 scenerios based on the priority level defined in [RFC6378]. The 314 first PSC message which differs from the previous PSC message is 315 shown. 317 A Z 318 | | 319 (1) |-- NR(0,0) ------>| (1) 320 |<----- NR(0,0) ---| 321 | | 322 | | 323 | (FS issued at Z) | (2) 324 (3) |<------ FS(1,1) --| 325 |-- NR(0,1) ------>| 326 | | 327 | | 328 (4) | (SF on P(A<-Z)) | 329 | | 330 | | 331 | (Clear FS at Z) | (5) 332 (6) | X <- NR(0,0) --| 333 | | 334 | | 336 (1) Each end is in Normal state, and transmits NR (0,0) messages. 338 (2) When a Forced Switch command is issued at node Z, node Z goes 339 into local Protecting Administrative state (PA:F:L) and begins 340 transmission of an FS (1,1) messages. 342 (3) A remote Forced Switch message causes node A to go into remote 343 Protecting Administrative state (PA:F:R), and node A begins 344 transmitting NR (0,1) messages. 346 (4) When node A detects a unidirectional Signal Fail on the 347 protection path, node A keeps sending NR (0,1) message because SF-P 348 is ignored under the state PA:F:R. 350 (5) When a Clear command is issued at node Z, node Z goes into Normal 351 state and begins transmission of NR (0,0) messages. 353 (6) But node A cannot receive PSC message because of local 354 unidirectional Signal Fail indication on the protection path. 355 Because no valid PSC message is received, over a period of several 356 continual messages intervals, the last valid received message remains 357 applicable and the node A continue to transmit an NR (0,1) message in 358 the state of PA:F:R. 360 Now, there exists a mismatch between the bridge/selector positions of 361 node A (transmitting an NR (0,1)) and node Z (transmitting an NR 362 (0,0)). It results in out-of-service even when there is neither 363 signal fail on working path nor FS. 365 Appendix B. An exmaple of sequence diagram showing the problem with the 366 priority level of Clear SF 368 An exmaple of sequence diagram showing the problem with the priority 369 level of Clear SF defined in [RFC6378] is given below. The following 370 sequence diagram is depicted for the case of bidirectional signal 371 fails. However, other cases with unidirectional signal fails can 372 result in the same problem. The first PSC message which differs from 373 the previous PSC message is shown. 375 A Z 376 | | 377 (1) |-- NR(0,0) ------>| (1) 378 |<----- NR(0,0) ---| 379 | | 380 | | 381 (2) | (SF on P(A<->Z)) | (2) 382 |-- SF(0,0) ------>| 383 |<------ SF(0,0) --| 384 | | 385 | | 386 (3) | (SF on W(A<->Z)) | (3) 387 | | 388 | | 389 (4) | (Clear SF-P) | (4) 390 | | 391 | | 392 (5) | (Clear SF-W) | (5) 393 | | 394 | | 396 (1) Each end is in Normal state, and transmits NR (0,0) messages. 398 (2) When signal fail on protection (SF-P) occurs, each node enters 399 into [UA:P:L] state and transmits SF (0,0) messages. Traffic remains 400 on working path. 402 (3) When signal fail on working (SF-W) occurs, each node remains in 403 [UA:P:L] state as SF-W has a lower priority than SF-P. Traffic is 404 still on the working path. Traffic cannot be delivered as both 405 working and protection paths are experiencing signal fails. 407 (4) When the signal fail on protection is cleared, local "Clear SF-P" 408 request cannot be presented to the PSC control logic, which takes the 409 highest priority local request and runs PSC state machine, as the 410 priority of "Clear SF-P" is lower than that of SF-W. Consequently, 411 there is no change in state, and the selector and/or bridge keep 412 pointing at the working path, which has signal fail condition. 414 Now, traffic cannot be delivered while the protection path is 415 recovered and available. It should be noted that the same problem 416 will occur in the case that the sequence of SF-P and SF-W events is 417 changed. 419 If we further continue with this sequence to see what will happen 420 after SF-W is cleared, 421 (5) When the signal fail on working is cleared, local "Clear SF-W" 422 request can be passed to the PSC control logic (state machine) as 423 there is no higher priority local request, but this will be ignored 424 in the PSC control logic according to the state transition definition 425 in [RFC6378]. There will be no change in state or protocol message 426 transmitted. 428 As the signal fail on working is now cleared and the selector and/or 429 bridge are still pointing at the working path, traffic delivery is 430 resumed. However, each node is in [UA:P:L] state and transmitting 431 SF(0,0) message, while there exists no outstanding request for 432 protection switching. Moreover, any future legitimate protection 433 switching requests, such as SF-W, will be rejected as each node 434 thinks the protection path is unavailable. 436 Appendix C. Freeze Command 438 The "Freeze" command applies only to the near end (local node) of the 439 protection group and is not signaled to the far end. This command 440 freezes the state of the protection group. Until the Freeze is 441 cleared, additional near end commands are rejected and condition 442 changes and received PSC information are ignored. 444 "Clear Freeze" command clears the local freeze. When the Freeze 445 command is cleared, the state of the protection group is recomputed 446 based on the persistent condition of the local triggers. 448 Because the freeze is local, if the freeze is issued at one end only, 449 a failure of protocol can occur as the other end is open to accept 450 any operator command or a fault condition. 452 Authors' Addresses 454 Jeong-dong Ryoo 455 ETRI 456 218 Gajeongno 457 Yuseong-gu, Daejeon 305-700 458 South Korea 460 Phone: +82-42-860-5384 461 Email: ryoo@etri.re.kr 462 Huub van Helvoort 463 Huawei Technologies 464 Karspeldreef 4, 465 Amsterdam 1101 CJ 466 the Netherlands 468 Phone: +31 20 4300936 469 Email: huub.van.helvoort@huawei.com 471 Alessandro D'Alessandro 472 Telecom Italia 473 via Reiss Romoli, 274 474 Torino 10141 475 Italy 477 Phone: +39 011 2285887 478 Email: alessandro.dalessandro@telecomitalia.it