idnits 2.17.1 draft-dj-mpls-tp-exer-psc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '...l Exercise input SHALL cause the LER t...' RFC 2119 keyword, line 173: '...ote EXER message SHALL cause the LER t...' RFC 2119 keyword, line 180: '...l Exercise input SHALL cause the LER t...' RFC 2119 keyword, line 183: '...ote EXER message SHALL cause the LER t...' RFC 2119 keyword, line 191: '...ser data traffic SHALL remain on the s...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 26, 2013) is 3857 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: '20' on line 395 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. D'Alessandro 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track J. Ryoo 5 Expires: March 30, 2014 ETRI 6 H. van Helvoort 7 Huawei Technologies 8 September 26, 2013 10 Supporting the Exercise command for PSC linear protection protocol 11 draft-dj-mpls-tp-exer-psc-02 13 Abstract 15 This draft indicates how IETF RFC6378 could be modified to address 16 the Exercise function. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 30, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Updates to the PSC RFC . . . . . . . . . . . . . . . . . . . 2 54 2.1. Updates to Section 2.1. Acronyms . . . . . . . . . . . . 3 55 2.2. Updates to Section 3.1. Local Request Logic . . . . . . . 3 56 2.3. Update to Section 3.2. Remote Requests . . . . . . . . . 3 57 2.4. Updates to Section 3.6. PSC Control States . . . . . . . 3 58 2.5. Updates to Section 4.2.2. PSC Request Field . . . . . . . 4 59 2.6. Updates to Section 4.3.2. Priority of Inputs . . . . . . 4 60 2.7. Updates to Section 4.3.3. Operation of PSC States . . . . 4 61 2.7.1. Updates to Section 4.3.3.1. Normal State . . . . . . 4 62 2.7.2. Updates to Section 4.3.3.6. Do-not-Revert State . . . 4 63 2.7.3. New subsection for Exercise State . . . . . . . . . . 4 64 2.8. Updates to Appendix A. PSC State Machine Tables . . . . . 6 65 2.9. Updates to Appendix B. Exercising the Protection Domain . 9 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 6.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Exercise is a command to test if the PSC communication is operating 77 correctly. More specifically, the Exercise is to test and validate 78 the linear protection mechanism and PSC protocol including the 79 aliveness of the Local Request logic, the PSC state machine and the 80 PSC message generation and reception, and the integrity of the 81 protection path, without triggering the actual traffic switching. It 82 is used while the working path is either carrying the traffic or not. 83 It is lower priority than any "real" switch request. It is only 84 valid in bidirectional switching, since this is the only place where 85 one can get a meaningful test by looking for a response. 87 This command is documented in R84 of [RFC5654] and it has been 88 identified as a requirement in the ITU's liaison statement "Liaison 89 Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear 90 protection switching for MPLS-TP networks " [LIAISON1205] and 91 "Recommendation ITU-T G.8131 revision - Linear protection switching 92 for MPLS-TP networks [LIAISON1234]. This draft is created as an 93 attempt to align PSC behaviour and functionalities to meet IETF and 94 ITU-T MPLS Transport Profile requirements. 96 2. Updates to the PSC RFC 97 This section describes the changes required to cover the exercise 98 functionality to the PSC protocol defined in [RFC6378] 100 2.1. Updates to Section 2.1. Acronyms 102 The following text should be added in Section 2.1 in [RFC6378]: 104 EXER Exercise 105 RR Reverse Request 107 2.2. Updates to Section 3.1. Local Request Logic 109 EXER should be included as an operator command. 111 The following text should be added: 113 o Exercise (EXER) - Exercise is a command to test if the PSC 114 communication is operating correctly. It is lower priority than 115 any "real" switch request. It is only valid in bidirectional 116 switching, since this is the only place where one can get a 117 meaningful test by looking for a response. 119 2.3. Update to Section 3.2. Remote Requests 121 The following text should be added: 123 o Remote EXER - indicates that the remote end point is operating 124 under an operator command to validate the protection mechanism and 125 PSC protocol including the aliveness of the Local Request logic, 126 the PSC state machine and the PSC message generation and 127 reception, and the integrity of the protection path, without 128 triggering the actual traffic switching. The valid response to 129 EXER message will be an RR with the corresponding FPath and Path 130 numbers. The near end will signal a Reverse Request (RR) only in 131 response to an EXER command from the far end. 133 When Exercise commands are input at both ends, an EXER, instead of 134 RR, is transmitted from both ends. 136 2.4. Updates to Section 3.6. PSC Control States 138 The following text should be added: 140 o Exercise state - The operator has issued the Exercise command to 141 test and validate the protection mechanism and PSC protocol 142 including the integrity of the protection path, without triggering 143 the actual traffic switching. 145 2.5. Updates to Section 4.2.2. PSC Request Field 147 The following PSC Requests should be added to PSC Request field: 149 (3) Exercise - indicates that the transmitting end point is 150 exercising the protection channel and mechanism. FPath and Path 151 are set to the same value of the NR, RR or DNR request that EXER 152 replaces. 154 (2) Reverse Request - indicates that the transmitting end point is 155 responding to an EXER command from the far end. FPath and Path 156 are set to the same value of the NR, RR or DNR request that EXER 157 replaces. 159 2.6. Updates to Section 4.3.2. Priority of Inputs 161 The priority of the Exercise should be inserted between the 162 priorities of WTR Expires and No Request. 164 2.7. Updates to Section 4.3.3. Operation of PSC States 166 2.7.1. Updates to Section 4.3.3.1. Normal State 168 Add the following text for Section 4.3.3.1. Normal State: 170 o A local Exercise input SHALL cause the LER to go into local 171 Exercise state and begin transmission of an EXER(0,0) message. 173 o A remote EXER message SHALL cause the LER to go into remote 174 Exercise state, and transmit an RR(0,0)message. 176 2.7.2. Updates to Section 4.3.3.6. Do-not-Revert State 178 Add the following text for Section 4.3.3.6. Do-not-Revert State: 180 o A local Exercise input SHALL cause the LER to go into local 181 Exercise state and begin transmission of an EXER(0,1) message. 183 o A remote EXER message SHALL cause the LER to go into remote 184 Exercise state, and transmit an RR(0,1)message. 186 2.7.3. New subsection for Exercise State 188 Add a new sub-section, Section 4.3.3.7. Exercise State, with the 189 following text: 191 In the Exercise state, the user data traffic SHALL remain on the same 192 path as the previous state, such as Normal state or Do-Not-Revert 193 state. The local end SHALL signal a RR message in response to a 194 remote EXER message. When both ends are in local Exercise state, 195 only the EXER messages are exchanged. 197 When in Exercise state, the following describe the reaction to local 198 input: 200 o A local Clear SHALL be ignored if in remote Exercise state. If in 201 local Exercise state, then this input SHALL cause the LER to go 202 into Normal state and being transmitting NR(0,0) when the LER is 203 configured for revertive mode. For non-revertive mode, the LER 204 goes into DNR state and begin transmitting DNR(0,1). 206 o A local Lockout of protection input SHALL cause the LER to go into 207 local Unavailable state and begin transmission of an LO(0,0) 208 message. 210 o A local Forced Switch input SHALL cause the LER to go into local 211 Protecting administrative state and begin transmission of an 212 FS(1,1) message. 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 o A local Signal Fail indication on the working path SHALL cause the 219 LER to go into local Protecting failure state and begin 220 transmission of an SF(1,1) message. 222 o A local Manual Switch input SHALL cause the LER to go into local 223 Protecting administrative state and begin transmission of an 224 MS(1,1) message. 226 o A local EXER input can be applied when the local end is in remote 227 EXER state. This SHALL cause the LER to remain in the EXER state, 228 but begin transmission of an EXER message instead of RR message. 230 o All other local inputs SHALL be ignored. 232 When in Exercise state, the following describe the reaction to remote 233 messages: 235 o A remote Lockout of protection message SHALL cause the LER to go 236 into remote Unavailable state and begin transmission of an NR(0,0) 237 message. 239 o A remote Forced Switch message SHALL cause the LER to go into 240 remote Protecting administrative state and begin transmission of 241 an NR(0,1) message. 243 o A remote Signal Fail message for the protection path SHALL cause 244 the LER to go into remote Unavailable state and begin transmission 245 of an NR(0,0) message. 247 o A remote Signal Fail message for the working path SHALL cause the 248 LER to go into remote Protecting failure state and begin 249 transmission of an NR(0,1) message. 251 o A remote Manual Switch message SHALL cause the LER to go into 252 remote Protecting administrative state and begin transmission of 253 an NR(0,1) message. 255 o A remote DNR(0,1) message received in remote Exercise state SHALL 256 cause the LER to go into DNR state and begin transmitting 257 DNR(0,1). A remote DNR(0,1) message in local Exercise state is 258 ignored. 260 o A remote NR(0,0) message received in remote Exercise state SHALL 261 cause the LER to go into Normal state and begin transmitting 262 NR(0,0). A remote NR message in local Exercise state is ignored. 264 o All other local inputs SHALL be ignored. 266 2.8. Updates to Appendix A. PSC State Machine Tables 268 Add the following extended states: 270 E::L = Exercise due to local EXER command 271 E::R = Exercise due to remote EXER message 273 Add the following messages: 275 State REQ(FP, P) 276 ----- ---------- 277 E::L EXER(0,0)for revertive, or EXER(0,1)for non-revertive 278 E::R RR(0,0) for revertive, or RR(0,1) for non-revertive 280 Add the following line to the local inputs describing the table 281 description rows: 283 EXER Exercise 285 Add the following line to the remote inputs describing the table 286 description rows: 288 EXER remote Exercise 289 RR Reverse Request 291 Modify the state machine as follows (only relevant cells are shown): 293 Part 1: Local input state machine 295 +-------+-----+-------+------+------+------+-----+------+------+----+ 296 | | OC | LO | SF-P | FS | SF-W | SFc | MS | WTRE | EX | 297 | | | | | | | | | xp | ER | 298 +-------+-----+-------+------+------+------+-----+------+------+----+ 299 | N | | | | | | | | | E: | 300 | | | | | | | | | | :L | 301 | | | | | | | | | | | 302 | UA:LO | | | | | | | | | i | 303 | :L | | | | | | | | | | 304 | | | | | | | | | | | 305 | UA:P: | | | | | | | | | i | 306 | L | | | | | | | | | | 307 | | | | | | | | | | | 308 | UA:LO | | | | | | | | | i | 309 | :R | | | | | | | | | | 310 | | | | | | | | | | | 311 | UA:P: | | | | | | | | | i | 312 | R | | | | | | | | | | 313 | | | | | | | | | | | 314 | PF:W: | | | | | | | | | i | 315 | L | | | | | | | | | | 316 | | | | | | | | | | | 317 | PF:W: | | | | | | | | | i | 318 | R | | | | | | | | | | 319 | | | | | | | | | | | 320 | PA:F: | | | | | | | | | i | 321 | L | | | | | | | | | | 322 | | | | | | | | | | | 323 | PA:M: | | | | | | | | | i | 324 | L | | | | | | | | | | 325 | | | | | | | | | | | 326 | PA:F: | | | | | | | | | i | 327 | R | | | | | | | | | | 328 | | | | | | | | | | | 329 | PA:M: | | | | | | | | | i | 330 | R | | | | | | | | | | 331 | | | | | | | | | | | 332 | WTR | | | | | | | | | i | 333 | | | | | | | | | | | 334 | DNR | | | | | | | | | E: | 335 | | | | | | | | | | :L | 336 | | | | | | | | | | | 337 | E::L | [20 | UA:LO | UA:P | PA:F | PF:W | i | PA:M | i | i | 338 | | ] | :L | :L | :L | :L | | :L | | | 339 | | | | | | | | | | | 340 | E::R | i | UA:LO | UA:P | PA:F | PF:W | i | PA:M | i | E: | 341 | | | :L | :L | :L | :L | | :L | | :L | 342 +-------+-----+-------+------+------+------+-----+------+------+----+ 344 Part 2: Remote messages state machine 346 +-------+-------+------+------+------+------+-----+----+---+----+---+ 347 | | LO | SF-P | FS | SF-W | MS | WTR | DN | N | EX | R | 348 | | | | | | | | R | R | ER | R | 349 +-------+-------+------+------+------+------+-----+----+---+----+---+ 350 | N | | | | | | | | | E: | i | 351 | | | | | | | | | | :R | | 352 | | | | | | | | | | | | 353 | UA:LO | | | | | | | | | i | i | 354 | :L | | | | | | | | | | | 355 | | | | | | | | | | | | 356 | UA:P: | | | | | | | | | i | i | 357 | L | | | | | | | | | | | 358 | | | | | | | | | | | | 359 | UA:LO | | | | | | | | | i | i | 360 | :R | | | | | | | | | | | 361 | | | | | | | | | | | | 362 | UA:P: | | | | | | | | | i | i | 363 | R | | | | | | | | | | | 364 | | | | | | | | | | | | 365 | PF:W: | | | | | | | | | i | i | 366 | L | | | | | | | | | | | 367 | | | | | | | | | | | | 368 | PF:W: | | | | | | | | | i | i | 369 | R | | | | | | | | | | | 370 | | | | | | | | | | | | 371 | PA:F: | | | | | | | | | i | i | 372 | L | | | | | | | | | | | 373 | | | | | | | | | | | | 374 | PA:M: | | | | | | | | | i | i | 375 | L | | | | | | | | | | | 376 | | | | | | | | | | | | 377 | PA:F: | | | | | | | | | i | i | 378 | R | | | | | | | | | | | 379 | | | | | | | | | | | | 380 | PA:M: | | | | | | | | | i | i | 381 | R | | | | | | | | | | | 382 | | | | | | | | | | | | 383 | WTR | | | | | | | | | i | i | 384 | | | | | | | | | | | | 385 | DNR | | | | | | | | | E: | i | 386 | | | | | | | | | | :R | | 387 | | | | | | | | | | | | 388 | E::L | UA:LO | UA:P | PA:F | PF:W | PA:M | i | i | i | i | i | 389 | | :R | :R | :R | :R | :R | | | | | | 390 | | | | | | | | | | | | 391 | E::R | UA:LO | UA:P | PA:F | PF:W | PA:M | i | DN | N | i | i | 392 | | :R | :R | :R | :R | :R | | R | | | | 393 +-------+-------+------+------+------+------+-----+----+---+----+---+ 395 [20] Transition to N for revertive mode, transition to DNR for non- 396 revervtive mode 398 2.9. Updates to Appendix B. Exercising the Protection Domain 400 Remove Appendix B. 402 3. IANA Considerations 404 This document makes no request of IANA. 406 Note to RFC Editor: this section may be removed on publication as an 407 RFC. 409 4. Security Considerations 411 No specific security issue is raised in addition to those ones 412 already documented in [RFC6378] 414 5. Acknowledgements 416 6. References 418 6.1. Normative References 420 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 421 and S. Ueno, "Requirements of an MPLS Transport Profile", 422 RFC 5654, September 2009. 424 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 425 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 426 Protection", RFC 6378, October 2011. 428 6.2. Informative References 430 [LIAISON1205] 431 ITU-T SG15, ., "Liaison Statement: Recommendation ITU-T 432 G.8131/Y.1382 revision - Linear protection switching for 433 MPLS-TP networks ", https://datatracker.ietf.org/liaison/ 434 1205/ , October 2012. 436 [LIAISON1234] 437 ITU-T SG15, ., "Liaison Statement: Recommendation ITU-T 438 G.8131 revision - Linear protection switching for MPLS-TP 439 networks ", https://datatracker.ietf.org/liaison/1234/ , 440 February 2013. 442 Authors' Addresses 444 Alessandro D'Alessandro 445 Telecom Italia 446 via Reiss Romoli, 274 447 Torino 10141 448 Italy 450 Phone: +30 011 2285887 451 Email: alessandro.dalessandro@telecomitalia.it 453 Jeong-dong Ryoo 454 ETRI 455 218 Gajeongno 456 Yuseong-gu, Daejeon 305-700 457 South Korea 459 Phone: +82-42-860-5384 460 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 4300832 469 Email: huub.van.helvoort@huawei.com