idnits 2.17.1 draft-helvoort-mpls-tp-ring-protection-switching-06.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 ([RFC6371]), 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 (April 18, 2014) is 3661 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) == Missing Reference: 'P1' is mentioned on line 615, but not defined == Missing Reference: 'W3' is mentioned on line 526, but not defined == Missing Reference: 'P4' is mentioned on line 528, but not defined == Missing Reference: 'W1' is mentioned on line 611, but not defined == Missing Reference: 'P6' is mentioned on line 354, but not defined == Missing Reference: 'W2' is mentioned on line 613, but not defined == Missing Reference: 'P3' is mentioned on line 572, but not defined Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group H. van Helvoort, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track J. Ryoo, Ed. 5 Expires: October 20, 2014 ETRI 7 April 18, 2014 9 MPLS-TP Ring Protection Switching (MRPS) 10 draft-helvoort-mpls-tp-ring-protection-switching-06.txt 12 Abstract 14 This document describes a mechanism to address the requirements for 15 protection of the Multi-Protocol Label Switching Transport Profile 16 (MPLS-TP) Label Switched Paths (LSP) in a ring topology. The 17 mechanism defined herein is designed to support point-to-point as 18 well as point-to-multipoint LSPs. 20 The MPLS-TP section layer OAM is used to monitor the connectivity 21 between each two adjacent nodes using the mechanisms defined in the 22 [RFC6371]. 24 The Automatic Protection Switching (APS) protocol is used for 25 coordination of protection switching actions between the ring nodes. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 20, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Contributing authors . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 63 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Ring protection schemes . . . . . . . . . . . . . . . . . . . 4 65 3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1.1. Wrapping protection scheme applicability . . . . . . 5 67 3.1.2. P-t-p LSP example . . . . . . . . . . . . . . . . . . 5 68 3.1.3. P-t-mp LSP example . . . . . . . . . . . . . . . . . 7 69 3.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2.1. Steering protection scheme applicability . . . . . . 11 71 3.2.2. P-t-p LSP example . . . . . . . . . . . . . . . . . . 11 72 3.2.3. P-t-mp LSP example . . . . . . . . . . . . . . . . . 13 73 4. MRPS characteristics . . . . . . . . . . . . . . . . . . . . 16 74 4.1. Switching types . . . . . . . . . . . . . . . . . . . . . 16 75 4.2. Operation types . . . . . . . . . . . . . . . . . . . . . 17 76 4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 17 77 4.3.1. Bandwidth sharing . . . . . . . . . . . . . . . . . . 17 78 4.3.2. Bandwidth and QoS considerations . . . . . . . . . . 17 79 4.3.3. Point-to-point and point-to-multipoint traffic . . . 18 80 5. APS protocol . . . . . . . . . . . . . . . . . . . . . . . . 18 81 5.1. Transmission and acceptance of APS requests . . . . . . . 20 82 5.2. APS PDU structure . . . . . . . . . . . . . . . . . . . . 20 83 5.3. Ring node APS states . . . . . . . . . . . . . . . . . . 21 84 5.3.1. Idle state . . . . . . . . . . . . . . . . . . . . . 21 85 5.3.2. Switching state . . . . . . . . . . . . . . . . . . . 22 86 5.3.3. Pass-through state . . . . . . . . . . . . . . . . . 22 87 5.3.4. APS state transitions . . . . . . . . . . . . . . . . 23 88 6. Protection switching triggers . . . . . . . . . . . . . . . . 25 89 6.1. Manual control . . . . . . . . . . . . . . . . . . . . . 25 90 6.1.1. Commands not signaled on the APS protocol . . . . . . 25 91 6.1.2. Commands using the APS protocol . . . . . . . . . . . 26 92 6.2. Automatically initiated commands . . . . . . . . . . . . 26 93 6.3. APS state machine . . . . . . . . . . . . . . . . . . . . 27 94 6.3.1. Initial states . . . . . . . . . . . . . . . . . . . 27 95 6.3.2. State transitions when local request is applied . . . 28 96 6.3.3. State transitions when remote request is applied . . 32 97 6.3.4. State Transitions when request addresses to another 98 node is received . . . . . . . . . . . . . . . . 35 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 104 10.2. Informative References . . . . . . . . . . . . . . . . . 38 105 Appendix A. Ring protection requirements compliance . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 108 1. Introduction 110 Ring topologies are well known in SDH and SONET networks and is 111 proven to be very effective and simple in terms of protection 112 switching. Similar to SDH networks, MPLS networks can be built over 113 ring topologies. Such networks allow for a simple, fast recovery 114 time, and efficient protection mechanisms similar to the protection 115 mechanisms in SDH, as well as high bandwidth utilization achievable 116 by using the packet switching statistical multiplexing. 118 MPLS shared protection ring can be viewed as equivalent to SDH MS 119 shared protection ring architecture [G.841]. 121 The protection ring consists of two counter-rotating rings, 122 transmitting in opposite directions relative to each other. Both 123 rings carry working and protection traffic. 125 The bandwidth on each ring is divided so that a part of ring capacity 126 is dedicated for the working traffic and another part is dedicated to 127 the protection traffic. The protection bandwidth on one ring is used 128 to transport the working traffic from the other ring in case of 129 failure. Part of ring bandwidth can also be dedicated to carry 130 unprotected non-preemptable traffic (NUT). 132 1.1. Contributing authors 134 Italo Busi (Alcatel-Lucent), Haiyan Zhang (Huawei Technologies), Han 135 Li (China Mobile Communications Corporation), Ruiquan Jing (China 136 Telecom). 138 2. Conventions Used in this Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2.1. Abbreviations 146 APS Automatic Protection Switching 147 CCW Counterclockwise 148 EXER Exercise 149 FS Forced Switch 150 LP Lockout of Protection 151 LW Lockout of Working 152 NMS Network Management System 153 MPLS Multi-Protocol Label Switching 154 MPLS-TP MPLS Transport Profile 155 MRPS MPLS-TP Ring Protection Switching 156 MS Manual Switch 157 NR No request 158 NUT Non-preemptable Unprotected Traffic 159 OAM Operation, Administration and Maintenance 160 PDU Payload Data Unit 161 PS Protection Switching 162 QoS Quality of Service 163 RR Reverse Request 164 SF Signal Fail 165 WTR Wait to Restore 167 3. Ring protection schemes 169 3.1. Wrapping 171 The Wrapping technique implies that the node detecting a failure 172 sends out an APS request to the (opposite to the failure) node 173 adjacent to the failure. The APS request is transmitted over the APS 174 communication protocol, as defined in [RFC6371]. When a node detects 175 a failure or receives an APS request through APS protocol addressed 176 to this node, the traffic of all working LSPs/tunnels transmitted 177 towards the failed span is switched to the protection LSPs/tunnels in 178 the opposite direction (away from the failure). This traffic travels 179 around the ring to the other node (adjacent to the failure) where it 180 is switched back onto the working LSPs/tunnels. The nodes that 181 performed the protection switching revert back to the normal traffic 182 flow when the failure or APS request is cleared. 184 For each normal or working MPLS-TP LSP/tunnel, the protection LSP/ 185 tunnel MUST be established in the opposite direction though all nodes 186 in the ring. Labels assigned for the protection LSPs/tunnels MUST be 187 associated with the labels assigned for working LSPs/tunnels to allow 188 proper traffic switching between the working and protection LSPs/ 189 tunnels. 191 3.1.1. Wrapping protection scheme applicability 193 Wrapping protection scheme provides for fast and simple recovery of 194 p-t-p and p-t-mp LSPs in case of single or multiple failures in the 195 ring. The protection mechanism in terms of nodes behavior, data 196 path, signaled APS protocol messages is the same in all cases. In 197 some scenarios with large networks additional latency may be 198 introduced during protection switching in the ring because protection 199 traffic travels along the all the ring. 201 3.1.2. P-t-p LSP example 203 +---+ [P1] +---+ 204 | F |-------------| A | <- LSP 1 205 +---+ +---+ 206 / \ 207 [P2]/ [W1]\[P6] 208 / \ 209 +---+ +---+ 210 | E | | B | 211 +---+ +---+ 212 \ / 213 [P3]\ [W2]/[P5] 214 \ / 215 +---+ [W3] +---+ 216 LSP 1 <-- | D |-------------| C | 217 +---+ [P4] +---+ 219 Figure 1: Labels allocation example for p-t-p LSP protection with 220 wrapping protection switching 222 Working labels: 223 A[W1]->B[W2]->C[W3]->D 225 Protection labels: 226 A[P1]->F[P2]->E[P3]->D[P4]->C[P5]->B[P6]->A 228 Working and protection labels association: 229 [W1]<->[P6] 230 [W2]<->[P5] 231 [W3]<->[P4] 233 3.1.2.1. Link failure example 235 +---+ [P1] +---+ 236 | F |-------------| A | <- LSP 1 237 +---+ +---+ 238 / \ 239 [P2]/ [W1]\[P6] 240 / \ 241 +---+ +---+ 242 | E | | B | 243 +---+ +---+ 244 \ / 245 [P3]\ X 246 \ / 247 +---+ [W3] +---+ 248 LSP 1 <-- | D |-------------| C | 249 +---+ [P4] +---+ 251 Figure 2: Wrapping protection switching operation for p-t-p LSP in 252 case of link failure 254 When the failure occurs between the nodes B and C, these nodes send 255 APS request to each other around the ring. Node B switches the 256 traffic of LSP 1 from working label [W1] to the protection label [P6] 257 in the opposite direction (CCW). This traffic travels around the 258 ring to the node C where it is switched from protection label [P4] to 259 the working label [W3] and sent to the node D where it is dropped 260 from the ring. 262 Traffic flow and labels use when the link failure occurs: 263 A[W1]->B[P6]->A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D 265 3.1.2.2. Node failure example 266 +---+ [P1] +---+ 267 | F |-------------| A | <- LSP 1 268 +---+ +---+ 269 / \ 270 [P2]/ X 271 / \ 272 +---+ +---+ 273 | E | | B | 274 +---+ +---+ 275 \ / 276 [P3]\ X 277 \ / 278 +---+ [W3] +---+ 279 LSP 1 <-- | D |-------------| C | 280 +---+ [P4] +---+ 282 Figure 3: Wrapping protection switching operation for p-t-p LSP in 283 case of node failure 285 When node B fails or becomes isolated because of two failed links, 286 nodes A and C send APS request to each other around the ring. Node A 287 switches the traffic of LSP 1 to the protection label [P1] in the 288 direction opposite to normal flow. This traffic travels around the 289 ring to the node C where it is switched from the protection label 290 [P4] to the working label [W3] and sent to the node D where it is 291 dropped from the ring. 293 Traffic flow and labels use when the node B failure occurs: 294 A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D 296 3.1.3. P-t-mp LSP example 297 +---+ [P1] +---+ 298 LSP 1 <-- | F |-------------| A | <- LSP 1 299 +---+ +---+ 300 / \ 301 [P2]/[W5] [W1]\[P6] 302 / \ 303 +---+ +---+ 304 | E | | B | 305 +---+ +---+ 306 \ / 307 [P3]\[W4] [W2]/[P5] 308 \ / 309 +---+ [W3] +---+ 310 LSP 1 <-- | D |-------------| C | --> LSP1 311 +---+ [P4] +---+ 313 Figure 4: Labels allocation example for p-t-mp LSP protection with 314 wrapping protection switching 316 Working labels: 317 A[W1]->B[W2]->C[W3]->D[W4]->E[W5]->F 318 | | | 319 v v v 320 LSP 1 LSP 1 LSP 1 322 Protection labels: 323 A[P1]->F[P2]->E[P3]->D[P4]->C[P5]->B[P6]->A 325 Working and protection labels association: 326 [W1]<->[P6] 327 [W2]<->[P5] 328 [W3]<->[P4] 329 [W4]<->[P3] 330 [W5]<->[P2] 332 3.1.3.1. Link failure example 333 +---+ [P1] +---+ 334 LSP 1 <-- | F |-------------| A | <- LSP 1 335 +---+ +---+ 336 / \ 337 [P2]/[W5] [W1]\[P6] 338 / \ 339 +---+ +---+ 340 | E | | B | 341 +---+ +---+ 342 \ / 343 [P3]\[W4] X 344 \ / 345 +---+ [W3] +---+ 346 LSP 1 <-- | D |-------------| C | --> LSP 1 347 +---+ [P4] +---+ 349 Figure 5: Wrapping protection switching operation for p-t-mp LSP in 350 case of link failure 352 When the failure occurs between the nodes B and C, these nodes send 353 APS request to each other around the ring. Node B switches the 354 traffic of LSP 1 from working label [W1] to the protection label [P6] 355 in the opposite direction (CCW). This traffic travels around the 356 ring to the node C where it is switched from protection label [P4] to 357 the working label [W3] and sent to the nodes D and F where it is 358 dropped from the ring. 360 Traffic flow and labels use when the link failure occurs: 361 A[W1]->B[P6]->A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D[W4]->E[W5]->F 362 | | | 363 v v v 364 LSP 1 LSP 1 LSP 1 366 3.1.3.2. Node failure example 367 +---+ [P1] +---+ 368 LSP 1 <-- | F |-------------| A | <- LSP 1 369 +---+ +---+ 370 / \ 371 [P2]/ X 372 / \ 373 +---+ +---+ 374 | E | | B | 375 +---+ +---+ 376 \ / 377 [P3]\ X 378 \ / 379 +---+ [W3] +---+ 380 LSP 1 <-- | D |-------------| C | --> LSP1 381 +---+ [P4] +---+ 383 Figure 6: Wrapping protection switching operation for p-t-mp LSP in 384 case of node failure 386 When node B fails or becomes isolated because of two failed links, 387 nodes A and C send APS request to each other around the ring. Node A 388 switches the traffic of LSP 1 to the protection label [P1] in the 389 direction opposite to normal flow. This traffic travels around the 390 ring to the node C where it is switched from the protection label 391 [P4] to the working label [W3] and sent to the nodes D and F where it 392 is dropped from the ring. 394 Traffic flow and labels use when the node B failure occurs: 395 A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D[W4]->E[W5]->F 396 | | | 397 v v v 398 LSP 1 LSP 1 LSP 1 400 3.2. Steering 402 The Steering technique implies that the node detecting a failure 403 sends an APS request to the node adjacent to the failure (away from 404 the failure). The APS request is processed by all intermediate nodes 405 in the ring. All nodes in the ring MUST analyze which LSPs are 406 affected by the failure or APS request. This analysis is based on 407 the ring node maps configured at each node in the ring and LSP maps 408 provided at each source node (that adds traffic onto the ring) and 409 sink node (that drops the traffic from the ring). For each affected 410 LSP the source node and the sink node switches the traffic from 411 working LSPs/tunnels to the protection LSPs/tunnels and restore 412 normal traffic flow when the failure or APS request is cleared. 414 3.2.1. Steering protection scheme applicability 416 Steering protection scheme provides for recovery of p-t-p and p-t-mp 417 LSPs in case of single or multiple failures in the ring. The 418 protection mechanism different for p-t-p and p-t-mp LSPs in terms of 419 nodes behavior and data path. Signaled APS protocol messages are the 420 same. Steering mechanism introduces less latency comparing to 421 wrapping during protection switching in the ring but it requires more 422 complex configuration. It also may affect the protection time 423 because of more complex operation of switching nodes. 425 3.2.2. P-t-p LSP example 427 +---+ [P1] +---+ 428 | F |-------------| A | <- LSP 1 429 +---+ +---+ 430 / \ 431 [P2]/ [W1]\ 432 / \ 433 +---+ +---+ 434 | E | | B | 435 +---+ +---+ 436 \ / 437 [P3]\ [W2]/ 438 \ / 439 +---+ [W3] +---+ 440 LSP 1 <-- | D |-------------| C | 441 +---+ +---+ 443 Figure 7: Labels allocation example for p-t-p LSP protection with 444 steering protection switching 446 Working labels: 447 A[W1]->B[W2]->C[W3]->D 449 Protection labels: 450 A[P1]->F[P2]->E[P3]->D 452 3.2.2.1. Link failure example 453 +---+ [P1] +---+ 454 | F |-------------| A | <- LSP 1 455 +---+ +---+ 456 / \ 457 [P2]/ \ 458 / \ 459 +---+ +---+ 460 | E | | B | 461 +---+ +---+ 462 \ / 463 [P3]\ X 464 \ / 465 +---+ +---+ 466 LSP 1 <-- | D |-------------| C | 467 +---+ +---+ 469 Figure 8: Steering protection switching operation for p-t-p LSP in 470 case of link failure 472 When the failure occurs between the nodes B and C, these nodes send 473 APS request to each other around the ring. Nodes A and D analyze 474 these requests and determine that LSP 1 is affected by the failure. 475 Node A switches the traffic of LSP 1 to the protection label [P1] in 476 the direction opposite to normal flow. This traffic travels around 477 the ring to the node D where it is dropped from the ring. 479 Traffic flow and labels use when the link failure occurs: 480 A[P1]->F[P2]->E[P3]->D 482 3.2.2.2. Node failure example 483 +---+ [P1] +---+ 484 | F |-------------| A | <- LSP 1 485 +---+ +---+ 486 / \ 487 [P2]/ X 488 / \ 489 +---+ +---+ 490 | E | | B | 491 +---+ +---+ 492 \ / 493 [P3]\ X 494 \ / 495 +---+ +---+ 496 LSP 1 <-- | D |-------------| C | 497 +---+ +---+ 499 Figure 9: Steering protection switching operation for p-t-p LSP in 500 case of node failure 502 When node B fails or becomes isolated because of two failed links, 503 nodes A and C send APS request to each other around the ring. Nodes 504 A and D analyze these requests and determine that LSP 1 is affected 505 by the failure. Node A switches the traffic of LSP 1 to the 506 protection label [P1] in the direction opposite to normal flow. This 507 traffic travels around the ring to the node D where it is dropped 508 from the ring. 510 Traffic flow in case of node B failure is presented below. 511 A[P1]->F[P2]->E[P3]->D 513 3.2.3. P-t-mp LSP example 514 +---+ [P1] +---+ 515 LSP 1 <-- | F |-------------| A | <- LSP 1 516 +---+ +---+ 517 / \ 518 [P2]/[W5] [W1]\ 519 / \ 520 +---+ +---+ 521 | E | | B | 522 +---+ +---+ 523 \ / 524 [P3]\[W4] [W2]/ 525 \ / 526 +---+ [W3] +---+ 527 LSP 1 <-- | D |-------------| C | -> LSP 1 528 +---+ [P4] +---+ 530 Figure 10: Labels allocation example for p-t-mp LSP protection with 531 steering protection switching 533 Working labels: 534 A[W1]->B[W2]->C[W3]->D[W4]->E[W5]->F 535 | | | 536 v v v 537 LSP 1 LSP 1 LSP 1 539 Protection labels: 540 A[P1]->F[P2]->E[P3]->D[P4]->C 541 | | | 542 v v v 543 LSP 1 LSP 1 LSP 1 545 3.2.3.1. Link failure example 546 +---+ [P1] +---+ 547 LSP 1 <-- | F |-------------| A | <- LSP 1 548 +---+ +---+ 549 / \ 550 [P2]/ [W1]\ 551 / \ 552 +---+ +---+ 553 | E | | B | 554 +---+ +---+ 555 \ / 556 [P3]\ [W2]/ 557 \ / 558 +---+ +---+ 559 LSP 1 <-- | D |------X------| C | -> LSP 1 560 +---+ +---+ 562 Figure 11: Steering protection switching operation for p-t-mp LSP in 563 case of link failure 565 When the failure occurs between the nodes C and D, these nodes send 566 APS request to each other around the ring. Nodes A, C, D and F 567 analyze these requests and determine that LSP 1 is affected by the 568 failure. Node A duplicates the traffic of LSP 1 to the working label 569 [W1] and the protection label [P1]. Node C detects that normal flow 570 of LSP 1 is not affected and continues receiving working label [W2] 571 without performing protection switching. Nodes D and F detect that 572 normal flow of LSP 1 is affected and switch to protection labels [P3] 573 and [P1] respectively. 575 Traffic flow and working labels use when the link failure occurs: 576 A[W1]->B[W2]->C->X 577 | 578 v 579 LSP 1 581 Traffic flow and protection labels use when the link failure occurs: 582 A[P1]->F[P2]->E[P3]->D->X 583 | | 584 v v 585 LSP 1 LSP 1 587 3.2.3.2. Node failure example 588 +---+ [P1] +---+ 589 LSP 1 <-- | F |-------------| A | <- LSP 1 590 +---+ +---+ 591 / \ 592 [P2]/ [W1]\ 593 / \ 594 +---+ +---+ 595 | E | | B | 596 +---+ +---+ 597 \ / 598 X [W2]/ 599 \ / 600 +---+ +---+ 601 | D |------X------| C | -> LSP 1 602 +---+ +---+ 604 Figure 12: Steering protection switching operation for p-t-mp LSP in 605 case of node failure 607 When node D fails or becomes isolated because of two failed links, 608 nodes E and C send APS request to each other around the ring. Nodes 609 A, C and F analyze these requests and determine that LSP 1 is 610 affected by the failure. Node A duplicates the traffic of LSP 1 to 611 the working label [W1] and the protection label [P1]. Node C detects 612 that normal flow of LSP 1 is not affected and continues receiving 613 working label [W2] without performing protection switching. Node F 614 detects that normal flow of LSP 1 is affected and switch to 615 protection label [P1]. 617 Traffic flow and working labels use when the node failure occurs: 618 A[W1]->B[W2]->C->X 619 | 620 v 621 LSP 1 623 Traffic flow and protection labels use when the node failure occurs: 624 A[P1]->F[P2]->E[P3]->X 625 | 626 v 627 LSP 1 629 4. MRPS characteristics 631 4.1. Switching types 633 MRPS mechanism MUST support bi-directional protection switching type. 634 In bi-directional switching, the traffic passing in both directions 635 the monitored MPLS-TP section layer, including the affected direction 636 and the unaffected direction, is switched to protection LSPs/tunnels. 638 4.2. Operation types 640 MRPS mechanism MUST support revertive protection operation type, 641 which implies that the traffic will returns to (or remains on) the 642 working LSPs/tunnels after the failure or APS request is cleared. 644 MRPS mechanism MAY support non-revertive protection operation type, 645 which implies that the traffic will remain on the protection LSPs/ 646 tunnels after the failure or APS request is cleared. 648 4.3. Traffic types 650 4.3.1. Bandwidth sharing 652 The bandwidth on each ring MUST be shared so that part of ring 653 bandwidth capacity is guaranteed for the normal traffic and part is 654 used for the protection traffic in case of failure on the ring. The 655 protection part of the ring bandwidth rotating in one direction is 656 used to carry the normal traffic from the ring rotating in other 657 direction in case of failure. 659 Part of ring bandwidth MAY also be dedicated to carry Non-preemptable 660 Unprotected Traffic (NUT). 662 4.3.2. Bandwidth and QoS considerations 664 The MRPS mechanism provides for the connectivity restoration of the 665 normal traffic affected by a ring failure. The protection mechanism 666 itself does not distinguish between different types of QoS associated 667 with the given LSPs. It is also not aware of the bandwidth allocated 668 or guaranteed for the protected or unprotected LSPs. 670 In the MPLS-TP ring, in order to guarantee the bandwidth and QoS of 671 the LSPs, normal or unprotected, traffic management and engineering 672 measures SHOULD be taken. For example, the bandwidth and QoS 673 parameters allocated for each protection LSP/tunnel can be equal to 674 the bandwidth and QoS parameters of the associated working LSP/ 675 tunnel. 677 Bandwidth and QoS parameters calculation and allocation for the 678 normal and protection LSPs/tunnels are out of scope of this document. 680 4.3.3. Point-to-point and point-to-multipoint traffic 682 Both point-to-point and drop-and-continue point-to-multipoint MPLS-TP 683 LSPs/tunnels MUST be protected by MRPS. The APS protocol 684 functionality as well as the node's reaction on different APS 685 requests in case of ring failure SHOULD be identical for p-t-p and 686 p-t-mp traffic. 688 5. APS protocol 690 The MRPS protection operation MUST be controlled with the help of the 691 APS protocol. The APS processes in the each of the individual nodes 692 that form the ring SHOULD communicate using MPLS-TP Section OAM APS 693 PDUs. 695 The APS protocol MUST carry the ring status information and APS 696 requests, both automatic and externally initiated commands, between 697 the ring nodes. 699 Each node on the ring MUST be uniquely identified by assigning it a 700 node ID. The maximum number of nodes on the ring supported by the 701 APS protocol is 127. The node ID SHOULD be independent of the order 702 in which the nodes appear on the ring. The node ID is used to 703 identity the source and destination nodes of each APS request. 705 Each node SHOULD have a ring map containing information about the 706 sequence of the nodes around the ring. The method of configuring the 707 nodes with the ring maps is TBD. 709 When no protection switches are active on the ring, each node MUST 710 dispatch periodically APS requests to the two adjacent nodes, 711 indicating No Request (NR). When a node determines that a protection 712 switching is required, it MUST send the appropriate APS request in 713 both directions. 715 +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) 716 -------| A |-------------| B |-------------| C |------- 717 (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ 719 Figure 13: APS communication between the ring nodes in case of no 720 failures in the ring 722 A destination node is a node that is adjacent to a node that 723 identified a failed span. When a node that is not the destination 724 node receives an APS request and it has no higher priority local 725 request, it MUST transfer the APS request as received. In this way, 726 the switching nodes can maintain direct APS protocol communication in 727 the ring. 729 +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) 730 -------| A |-------------| B |----- X -----| C |------- 731 (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ 733 Figure 14: APS communication between the ring nodes in case of 734 failure between nodes B and C 736 Note that in the case of a bidirectional failure such as a cable cut, 737 two nodes detect the failure and send each other an APS request in 738 opposite directions. 740 o In rings utilizing the wrapping protection, when the destination 741 node receives the APS request it MUST perform the switch from/to 742 the working LSPs/tunnels to/from the protection LSPs/tunnels if it 743 has no higher priority active APS request. 745 o In rings utilizing the steering protection, when a ring switch is 746 required, any node MUST perform the switches if its added/dropped 747 traffic is affected by the failure. Determination of the affected 748 traffic SHOULD be performed by examining the APS requests 749 (indicating the nodes adjacent to the failure or failures) and the 750 stored ring maps (indicating the relative position of the failure 751 and the added traffic destined towards that failure). 753 When the failure has cleared and the Wait-to-Restore (WTR) timer has 754 expired, the nodes sourcing APS requests MUST drop their respective 755 switches (tail end) and MUST source an APS request carrying NR code. 756 The node receiving from both directions such APS request (head end) 757 MUST drop its protection switches. 759 A protection switch MUST be initiated by one of the criteria 760 specified in Section 6. A failure of the APS protocol or controller 761 MUST NOT trigger a protection switch. 763 Ring switches MUST be preempted by higher priority APS requests. For 764 example, consider a protection switch that is active due to a manual 765 switch request on the given span, and another protection switch is 766 required due to a failure on another span. Then a APS request MUST 767 be generated, the former protection switch MUST be dropped, and the 768 latter protection switch established. 770 MRPS mechanism SHOULD support multiple protection switches in the 771 ring, resulting the ring being segmented into two or more separate 772 segments. This may happen when several APS requests of the same 773 priority exist in the ring due to multiple failures or external 774 switch commands. 776 Proper operation of the MRPS mechanism relies on all nodes having 777 knowledge of the state of the ring (nodes and spans) so that nodes do 778 not preempt existing APS request unless they have a higher-priority 779 APS request. In order to accommodate ring state knowledge, during 780 protection switch the APS requests MUST be sent in both directions. 782 5.1. Transmission and acceptance of APS requests 784 A new APS request MUST be transmitted immediately when a change in 785 the transmitted status occurs. 787 The first three APS protocol messages carrying new APS request SHOULD 788 be transmitted as fast as possible. For fast protection switching 789 within 50 ms, the interval of the first three APS protocol messages 790 SHOULD be 3.3 ms. Then APS requests SHOULD be transmitted with the 791 interval of 5 seconds. 793 5.2. APS PDU structure 795 Figure 15 depicts the format of an APS packet that is sent on the 796 G-ACh. The Channel Type field is set to indicate that the message is 797 an APS message. The ACH MUST NOT include the ACH TLV Header 798 [RFC5586] meaning that no ACH TLVs can be included in the message. 800 0 1 2 3 801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| APS Channel Type (0xXX) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | APS message (TBD) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Figure 15: G-ACh APS Packet 810 APS message structure is TBD. 812 The following fields MUST be provided: 814 o Destination Node ID: The destination node ID MUST always be set to 815 value of a node ID of the adjacent node. Valid destination node 816 ID values are 1-127. 818 o Source node ID: The source node ID MUST always be set to the value 819 of the node ID generating the APS request. Valid source node ID 820 values are 1-127. 822 o APS request code: A code consisting of four bits as specified 823 below. 825 +-------------+-----------------------------+----------+ 826 | Bits 4-1 | Condition, State | Priority | 827 | (MSB - LSB) | or external Request | | 828 +-------------------------------------------+----------+ 829 | 1 1 1 1 | Lockout of Protection (LP) | highest | 830 | 1 1 0 1 | Forced Switch (FS) | | 831 | 1 0 1 1 | Signal Fail (SF) | | 832 | 0 1 1 0 | Manual Switch (MS) | | 833 | 0 1 0 1 | Wait-To-Restore (WTR) | | 834 | 0 0 1 1 | Exerciser (EXER) | | 835 | 0 0 0 1 | Reverse Request (RR) | | 836 | 0 0 0 0 | No Request (NR) | lowest | 837 +-------------+-----------------------------+----------+ 839 5.3. Ring node APS states 841 Idle state: A node is in the idle state when it has no APS request 842 and is sourcing and receiving NR code to/from both directions. 844 Switching state: A node not in the idle or pass-through states is in 845 the switching state. 847 Pass-through state: A node is in the pass-through state when its 848 highest priority APS request is a request not destined to or sourced 849 by it. The pass-through is bidirectional. 851 5.3.1. Idle state 853 A node in the idle state MUST source the NR request in both 854 directions. 856 A node in the idle state MUST terminate APS requests flow in both 857 directions. 859 A node in the idle state MUST block the traffic flow on protection 860 LSPs/tunnels in both directions. 862 5.3.2. Switching state 864 A node in the switching state MUST source APS request to adjacent 865 node with its highest APS request code in both directions when it 866 detects a failure or receives an external command. 868 A node in the switching state MUST terminate APS requests flow in 869 both directions. 871 As soon as it receives an APS request from the short path, the node 872 to which it is addressed MUST acknowledge the APS request by replying 873 with the RR code on the short path, and with the received APS request 874 code on the long path. 876 This rule refers to the unidirectional failure detection: the RR 877 SHOULD be issued only when the node does not detect the failure 878 condition (i.e., the node is a head end), that is, it is not 879 applicable when a failure is detected bidirectionally, because, in 880 this latter case, both nodes send an APS request for the failure on 881 both paths (short and long). 883 The following switches MUST be allowed to coexist: 885 o LP with LP 887 o FS with FS 889 o SF with SF 891 o FS with SF 893 When multiple MS APS requests over different spans exist at the same 894 time, no switch SHOULD be executed and existing switches MUST be 895 dropped. The nodes MUST signal, anyway, the MS APS request code. 897 Multiple EXER request MUST be allowed to coexist in the ring. 899 A node in a ring switching state that receives the external command 900 LW for the affected span MUST drop its switch and MUST signal NR for 901 the locked span if there is no other APS request on another span. 902 Node still SHOULD signal relevant APS request for another span. 904 5.3.3. Pass-through state 906 When a node is in a pass-through state, it MUST transmit on one side, 907 the same APS request as it receives from the other side. 909 When a node is in a pass-through state, it MUST allow the traffic 910 flow on protection LSPs/tunnels in both directions. 912 5.3.4. APS state transitions 914 All state transitions are triggered by an incoming APS request 915 change, a WTR expiration, an externally initiated command, or locally 916 detected MPLS-TP section failure conditions. 918 APS requests due to a locally detected failure, an externally 919 initiated command, or received APS request shall pre-empt existing 920 APS requests in the prioritized order given in Section 5.2, unless 921 the requests are allowed to coexist. 923 5.3.4.1. Transitions between the idle and pass-through states 925 The transition from the idle state to pass-through state MUST be 926 triggered by a valid APS request change, in any direction, from the 927 NR code to any other code, as long as the new request is not destined 928 for the node itself. Both directions move then into a pass-through 929 state, so that, traffic entering the node through the protection LSPs 930 /tunnels are by-passed across the node. 932 A node MUST revert from pass-through state to the idle state when it 933 detects NR codes incoming from both directions. Both directions 934 revert simultaneously from the pass-through state to the idle state. 936 5.3.4.2. Transitions between the idle and switching states 938 Transition of a node from the idle state to the switching state MUST 939 be triggered by one of the following conditions: 941 o a valid APS request change from the NR code to any code received 942 on either the long or the short path and destined to this node 944 o an externally initiated command for this node 946 o the detection of an MPLS-TP section layer failure at this node. 948 Actions taken at a node in idle state upon transition to switching 949 state are: 951 o for all protection switch requests, except EXER and LP, the node 952 MUST execute the switch 954 o for EXER, and LP, the node MUST signal appropriate request but not 955 execute the switch. 957 A node MUST revert from the switching state to the idle state when it 958 detects NR codes received from both directions. 960 o At the tail end: When a WTR time expires or an externally 961 initiated command is cleared at a node, the node MUST drop its 962 switch, transit to Idle state and signal the NR code in both 963 directions. 965 o At the head end: Upon reception of the NR code, from both 966 directions, the head-end node MUST drop its switch, transition to 967 Idle state and signal the NR code in both directions. 969 5.3.4.3. Transitions between switching states 971 When a node that is currently executing any protection switch 972 receives a higher priority APS request (due to a locally detected 973 failure, an externally initiated command, or a ring protection switch 974 request destined to it) for the same span, it MUST upgrade the 975 priority of the switch it is executing to the priority of the 976 received APS request. 978 When a failure condition clears at a node, the node MUST enter WTR 979 condition and remain in it for the appropriate time-out interval, 980 unless: 982 o a different APS request of higher priority than WTR is received 984 o another failure is detected 986 o an externally initiated command becomes active. 988 The node MUST send out a WTR code on both the long and short paths. 990 When a node that is executing a switch in response to incoming SF APS 991 request (not due to a locally detected failure) receives a WTR code 992 (unidirectional failure case), it MUST send out RR code on the short 993 path and the WTR on the long path. 995 5.3.4.4. Transitions between switching and pass-through states 997 When a node that is currently executing a switch receives an APS 998 request for a non-adjacent span of higher priority than the switch it 999 is executing, it MUST drop its switch immediately and enter the pass- 1000 through state. 1002 The transition of a node from pass-through to switching state MUST be 1003 triggered by: 1005 o an equal, higher priority, or allowed coexisting externally 1006 initiated command 1008 o the detection of an equal, higher priority, or allowed coexisting 1009 failure 1011 o the receipt of an equal, higher priority, or allowed coexisting 1012 APS request destined to this node. 1014 6. Protection switching triggers 1016 Protection switching action MUST be conducted when: 1018 o they are initiated by operator control (e.g., manual switch, 1019 forced switch, and lockout of protection) without a higher 1020 priority APS request being in effect on addressed span or entire 1021 ring 1023 o an MPLS-TP Section SF is declared on the associated span and 1024 without a higher priority APS request (e.g., lockout of 1025 protection, forced switch) being in effect on addressed span or 1026 entire ring and the hold-off timer has expired 1028 o the wait to restore timer expires. 1030 6.1. Manual control 1032 Externally initiated commands are entered by the operator through the 1033 Network Management System (NMS) or the Craft interface. 1035 6.1.1. Commands not signaled on the APS protocol 1037 The node MUST support the following commands that are not transferred 1038 by the APS protocol: 1040 o Clear: This command clears the externally initiated command and 1041 WTR timer at the node to which the command was addressed. The 1042 node-to-node signaling following removal of the externally 1043 initiated commands MUST be performed using the NR code. 1045 o Lockout of Working: This command prevents the normal traffic 1046 transported over the addressed span from being switched to the 1047 protection LSPs/tunnels by disabling the node's capability of 1048 requesting the protection switching for this span in case of 1049 failure. If any normal traffic is already switched on the 1050 protection LSPs/tunnels, the switch MUST be dropped. If no other 1051 APS requests are active on the ring, the NR code MUST be 1052 transmitted. This command has no impact on any other span. If 1053 the node receives the APS request from the adjacent node from any 1054 side it MUST perform the requested switch. If the node receives 1055 the request addressed to the other node it MUST go to the pass- 1056 through state. 1058 6.1.2. Commands using the APS protocol 1060 The node MUST support the following commands that are transferred by 1061 the APS protocol: 1063 o Lockout of Protection (LP): This command prevents any protection 1064 activity and prevents using protection switches anywhere in the 1065 ring. All existing switches in the ring MUST be dropped. 1067 o Forced Switch to protection (FS): This command performs the ring 1068 switch of normal traffic from the working LSPs/tunnels to the 1069 protection LSPs/tunnels for the span between the node at which the 1070 command is initiated and the adjacent node to which the command is 1071 directed. This switch MUST occur regardless of the state of the 1072 spans adjacent to this node unless it is satisfying a higher 1073 priority APS request. 1075 o Manual Switch to protection (MS): This command performs the ring 1076 switch of the normal traffic from the working LSPs/tunnels to the 1077 protection LSPs/tunnels for the span between the node at which the 1078 command is initiated and the adjacent node to which the command is 1079 directed. This occurs if the node is not satisfying an equal or 1080 higher priority APS request. 1082 The node MAY support the following commands that are transferred by 1083 the APS protocol: 1085 o Exercise - (EXER): This command exercises ring protection 1086 switching on the addressed span without completing the actual 1087 switch. When the command issued the RR responses are checked, but 1088 no normal traffic is affected. 1090 6.2. Automatically initiated commands 1092 Automatically initiated commands can be initiated based on MPLS-TP 1093 section layer and equipment performance criteria and received APS 1094 requests. 1096 The node MUST support the following APS requests that are initiated 1097 automatically: 1099 o Signal Fail (SF): This command is issued when the MPLS-TP section 1100 detects signal failure condition. When the tail-end detects the 1101 failure it MUST generate the APS request towards the head-end. 1103 o Wait-To-Restore (WTR): This command is issued when MPLS-TP section 1104 detects that the SF condition has cleared. It is used to maintain 1105 the state during the WTR period unless it is pre-empted by a 1106 higher priority APS request. The Wait to Restore time SHOULD be 1107 configured by the operator in 1 minute steps between 0 and 72 1108 hours. The default value SHOULD be 5 minutes. 1110 o Reverse Request (RR): This command MUST be transmitted to the 1111 tail-end node over the short path as an acknowledgment for 1112 receiving the APS request. 1114 6.3. APS state machine 1116 6.3.1. Initial states 1117 +-----------------------------------+----------------+ 1118 | State | Signaled APS | 1119 +-----------------------------------+----------------+ 1120 | A | Idle | NR | 1121 | | Working: no switch | | 1122 | | Protection: no switch | | 1123 +-----+-----------------------------+----------------+ 1124 | B | Pass-trough | N/A | 1125 | | Working: no switch | | 1126 | | Protection: pass through | | 1127 +-----+-----------------------------+----------------+ 1128 | C | Switching - LP | LP | 1129 | | Working: no switch | | 1130 | | Protection: no switch | | 1131 +-----+-----------------------------+----------------+ 1132 | D | Idle - LW | NR | 1133 | | Working: no switch | | 1134 | | Protection: no switch | | 1135 +-----+-----------------------------+----------------+ 1136 | E | Switching - FS | FS | 1137 | | Working: switched | | 1138 | | Protection: switched | | 1139 +-----+-----------------------------+----------------+ 1140 | F | Switching - SF | SF | 1141 | | Working: switched | | 1142 | | Protection: switched | | 1143 +-----+-----------------------------+----------------+ 1144 | G | Switching - MS | MS | 1145 | | Working: switched | | 1146 | | Protection: switched | | 1147 +-----+-----------------------------+----------------+ 1148 | H | Switching - WTR | WTR | 1149 | | Working: switched | | 1150 | | Protection: switched | | 1151 +-----+-----------------------------+----------------+ 1152 | I | Switching - EXER | EXER | 1153 | | Working: no switch | | 1154 | | Protection: no switch | | 1155 +-----+-----------------------------+----------------+ 1157 6.3.2. State transitions when local request is applied 1159 In the state description below 'O' means that new local request will 1160 be rejected because of exiting request. 1162 ===================================================================== 1163 Initial state New request New state 1164 ------------- ----------- --------- 1165 A (Idle) LP C (Switching - LP) 1166 LW D (Idle - LW) 1167 FS E (Switching - FS) 1168 SF F (Switching - SF) 1169 Recover from SF N/A 1170 MS G (Switching - MS) 1171 Clear N/A 1172 WTR expires N/A 1173 EXER I (Switching - EXER) 1174 ===================================================================== 1175 Initial state New request New state 1176 ------------- ----------- --------- 1177 B (Pass-trough) LP C (Switching - LP) 1178 LW B (Pass-trough) 1179 FS O - if current state is due to 1180 LP sent by another node 1181 E (Switching - FS) - otherwise 1182 SF O - if current state is due to 1183 LP sent by another node 1184 F (Switching - SF) - otherwise 1185 Recover from SF N/A 1186 MS O - if current state is due to 1187 LP, SF or FS sent by 1188 another node 1189 G (Switching - MS) - otherwise 1190 Clear N/A 1191 WTR expires N/A 1192 EXER O 1193 ===================================================================== 1194 Initial state New request New state 1195 ------------- ----------- --------- 1196 C (Switching - LP) LP N/A 1197 LW O 1198 FS O 1199 SF O 1200 Recover from SF N/A 1201 MS O 1202 Clear A (Idle) - if there is no 1203 failure in the ring 1204 F (Switching - SF) - if there 1205 is a failure at this node 1206 B (Pass-trough) - if there is 1207 a failure at another node 1208 WTR expires N/A 1209 EXER O 1211 ===================================================================== 1212 Initial state New request New state 1213 ------------- ----------- --------- 1214 D (Idle - LW) LP C (Switching - LP) 1215 LW N/A - if on the same span 1216 D (Idle - LW) - if on another 1217 span 1218 FS O - if on the same span 1219 E (Switching - FS) - if on 1220 another span 1221 SF O - if on the addressed span 1222 F (Switching - SF) - if on 1223 another span 1224 Recover from SF N/A 1225 MS O - if on the same span 1226 G (Switching - MS) - if on 1227 another span 1228 Clear A (Idle) - if there is no 1229 failure on addressed span 1230 F (Switching - SF) - if there 1231 is a failure on this span 1232 WTR expires N/A 1233 EXER O 1234 ===================================================================== 1235 Initial state New request New state 1236 ------------- ----------- --------- 1237 E (Switching - FS) LP C (Switching - LP) 1238 LW O - if on another span 1239 D (Idle - LW) - if on the same 1240 span 1241 FS N/A - if on the same span 1242 E (Switching - FS) - if on 1243 another span 1244 SF O - if on the addressed span 1245 E (Switching - FS) - if on 1246 another span 1247 Recover from SF N/A 1248 MS O 1249 Clear A (Idle) - if there is no 1250 failure in the ring 1251 F (Switching - SF) - if there 1252 is a failure at this node 1253 B (Pass-trough) - if there is 1254 a failure at another node 1255 WTR expires N/A 1256 EXER O 1257 ===================================================================== 1258 Initial state New request New state 1259 ------------- ----------- --------- 1260 F (Switching - SF) LP C (Switching - LP) 1261 LW O - if on another span 1262 D (Idle - LW) - if on the same 1263 span 1264 FS E (Switching - FS) 1265 SF N/A - if on the same span 1266 F (Switching - SF) - if on 1267 another span 1268 Recover from SF H (Switching - WTR) 1269 MS O 1270 Clear N/A 1271 WTR expires N/A 1272 EXER O 1273 ===================================================================== 1274 Initial state New request New state 1275 ------------- ----------- --------- 1276 G (Switching - MS) LP C (Switching - LP) 1277 LW O - if on another span 1278 D (Idle - LW) - if on the same 1279 span 1280 FS E (Switching - FS) 1281 SF F (Switching - SF) 1282 Recover from SF N/A 1283 MS N/A - if on the same span 1284 G (Switching - MS) - if on 1285 another span release the 1286 switches but signal MS 1287 Clear A 1288 WTR expires N/A 1289 EXER O 1290 ===================================================================== 1291 Initial state New request New state 1292 ------------- ----------- --------- 1293 H (Switching - WTR) LP C (Switching - LP) 1294 LW D (Idle - W) 1295 FS E (Switching - FS) 1296 SF F (Switching - SF) 1297 Recover from SF N/A 1298 MS G (Switching - MS) 1299 Clear A 1300 WTR expires A 1301 EXER O 1302 ===================================================================== 1303 Initial state New request New state 1304 ------------- ----------- --------- 1305 I (Switching - EXER) LP C (Switching - LP) 1306 LW D (idle - W) 1307 FS E (Switching - FS) 1308 SF F (Switching - SF) 1309 Recover from SF N/A 1310 MS G (Switching - MS) 1311 Clear A 1312 WTR expires N/A 1313 EXER N/A - if on the same span 1314 I (Switching - EXER) 1315 ===================================================================== 1317 6.3.3. State transitions when remote request is applied 1319 The priority of remote request does not depend on the side from which 1320 the request is received. 1322 ===================================================================== 1323 Initial state New request New state 1324 ------------- ----------- --------- 1325 A (Idle) LP C (Switching - LP) 1326 FS E (Switching - FS) 1327 SF F (Switching - SF) 1328 MS G (Switching - MS) 1329 WTR N/A 1330 EXER I (Switching - EXER) 1331 RR N/A 1332 NR A (Idle) 1333 ===================================================================== 1334 Initial state New request New state 1335 ------------- ----------- --------- 1336 B (Pass-trough) LP C (Switching - LP) 1337 FS N/A - cannot happen when there 1338 is LP request in the ring 1339 E (Switching - FS) - otherwise 1340 SF N/A - cannot happen when there 1341 is LP request in the ring 1342 F (Switching - SF) - otherwise 1343 MS N/A - cannot happen when there 1344 is LP, FS or SF request 1345 in the ring 1346 G (Switching - MS) - otherwise 1347 WTR N/A - cannot happen when there 1348 is LP, FS, SF or MS 1349 request in the ring 1350 EXER N/A - cannot happen when there 1351 is LP, FS, SF, MS or WTR 1352 request in the ring 1354 I (Switching - EXER) - 1355 otherwise 1356 RR N/A 1357 NR A (Idle) - if received from 1358 both sides 1359 ===================================================================== 1360 Initial state New request New state 1361 ------------- ----------- --------- 1362 C (Switching - LP) LP C (Switching - LP) 1363 FS N/A - cannot happen when there 1364 is LP request in the ring 1365 SF N/A - cannot happen when there 1366 is LP request in the ring 1367 MS N/A - cannot happen when there 1368 is LP request in the ring 1369 WTR N/A 1370 EXER N/A - cannot happen when there 1371 is LP request in the ring 1372 RR C (Switching - LP) 1373 NR N/A 1374 ===================================================================== 1375 Initial state New request New state 1376 ------------- ----------- --------- 1377 D (Idle - LW) LP C (Switching - LP) 1378 FS E (Switching - FS) 1379 SF F (Switching - SF) 1380 MS G (Switching - MS) 1381 WTR N/A 1382 EXER I (Switching - EXER) 1383 RR N/A 1384 NR D (Idle - LW) 1385 ===================================================================== 1386 Initial state New request New state 1387 ------------- ----------- --------- 1388 E (Switching - FS) LP C (Switching - LP) 1389 FS E (Switching - FS) 1390 SF E (Switching - FS) 1391 MS N/A - cannot happen when there 1392 is FS request in the ring 1393 WTR N/A 1394 EXER N/A - cannot happen when there 1395 is FS request in the ring 1396 RR E (Switching - FS) 1397 NR N/A 1398 ===================================================================== 1399 Initial state New request New state 1400 ------------- ----------- --------- 1401 F (Switching - SF) LP C (Switching - LP) 1402 FS F (Switching - SF) 1403 SF F (Switching - SF) 1404 MS N/A - cannot happen when there 1405 is SF request in the ring 1406 WTR N/A 1407 EXER N/A - cannot happen when there 1408 is SF request in the ring 1409 RR F (Switching - SF) 1410 NR N/A 1411 ===================================================================== 1412 Initial state New request New state 1413 ------------- ----------- --------- 1414 G (Switching - MS) LP C (Switching - LP) 1415 FS E (Switching - FS) 1416 SF F (Switching - SF) 1417 MS G (Switching - MS) - release 1418 the switches but signal MS 1419 WTR N/A 1420 EXER N/A - cannot happen when there 1421 is MS request in the ring 1422 RR G (Switching - MS) 1423 NR N/A 1424 ===================================================================== 1425 Initial state New request New state 1426 ------------- ----------- --------- 1427 H (Switching - WTR) LP C (Switching - LP) 1428 FS E (Switching - FS) 1429 SF F (Switching - SF) 1430 MS G (Switching - MS) 1431 WTR H (Switching - WTR) 1432 EXER N/A - cannot happen when there 1433 is WTR request in the ring 1434 RR H (Switching - WTR) 1435 NR N/A 1436 ===================================================================== 1437 Initial state New request New state 1438 ------------- ----------- --------- 1439 I (Switching - EXER) LP C (Switching - LP) 1440 FS E (Switching - FS) 1441 SF F (Switching - SF) 1442 MS G (Switching - MS) 1443 WTR N/A 1444 EXER I (Switching - EXER) 1445 RR I (Switching - EXER) 1446 NR N/A 1447 ===================================================================== 1449 6.3.4. State Transitions when request addresses to another node is 1450 received 1452 The priority of remote request does not depend on the side from which 1453 the request is received. 1455 ===================================================================== 1456 Initial state New request New state 1457 ------------- ----------- --------- 1458 A (Idle) LP B (Pass-trough) 1459 FS B (Pass-trough) 1460 SF B (Pass-trough) 1461 MS B (Pass-trough) 1462 WTR B (Pass-trough) 1463 EXER B (Pass-trough) 1464 RR N/A 1465 NR N/A 1466 ===================================================================== 1467 Initial state New request New state 1468 ------------- ----------- --------- 1469 B (Pass-trough) LP B (Pass-trough) 1470 FS N/A - cannot happen when there 1471 is LP request in the ring 1472 B (Pass-trough) - otherwise 1473 SF N/A - cannot happen when there 1474 is LP request in the ring 1475 B (Pass-trough) - otherwise 1476 MS N/A - cannot happen when there 1477 is LP, FS or SF request 1478 in the ring 1479 B (Pass-trough) - otherwise 1480 WTR N/A - cannot happen when there 1481 is LP, FS, SF or MS 1482 request in the ring 1483 B (Pass-trough) - otherwise 1484 EXER N/A - cannot happen when there 1485 is LP, FS, SF, MS or WTR 1486 request in the ring 1487 B (Pass-trough) - otherwise 1488 RR N/A 1489 NR B (Pass-trough) 1490 ===================================================================== 1491 Initial state New request New state 1492 ------------- ----------- --------- 1493 C (Switching - LP) LP C (Switching - LP) 1494 FS N/A - cannot happen when there 1495 is LP request in the ring 1497 SF N/A - cannot happen when there 1498 is LP request in the ring 1499 MS N/A - cannot happen when there 1500 is LP request in the ring 1501 WTR N/A - cannot happen when there 1502 is LP in the ring 1503 EXER N/A - cannot happen when there 1504 is LP request in the ring 1505 RR N/A 1506 NR N/A 1507 ===================================================================== 1508 Initial state New request New state 1509 ------------- ----------- --------- 1510 D (Idle - LW) LP B (Pass-trough) 1511 FS B (Pass-trough) 1512 SF B (Pass-trough) 1513 MS B (Pass-trough) 1514 WTR B (Pass-trough) 1515 EXER B (Pass-trough) 1516 RR N/A 1517 NR N/A 1518 ===================================================================== 1519 Initial state New request New state 1520 ------------- ----------- --------- 1521 E (Switching - FS) LP B (Pass-trough) 1522 FS E (Switching - FS) 1523 SF E (Switching - FS) 1524 MS N/A - cannot happen when there 1525 is FS request in the ring 1526 WTR N/A - cannot happen when there 1527 is FS request in the ring 1528 EXER N/A - cannot happen when there 1529 is FS request in the ring 1530 RR N/A 1531 NR N/A 1532 ===================================================================== 1533 Initial state New request New state 1534 ------------- ----------- --------- 1535 F (Switching - SF) LP B (Pass-trough) 1536 FS F (Switching - SF) 1537 SF F (Switching - SF) 1538 MS N/A - cannot happen when there 1539 is SF request in the ring 1540 WTR N/A - cannot happen when there 1541 is SF request in the ring 1542 EXER N/A - cannot happen when there 1543 is SF request in the ring 1544 RR N/A 1545 NR N/A 1546 ===================================================================== 1547 Initial state New request New state 1548 ------------- ----------- --------- 1549 G (Switching - MS) LP B (Pass-trough) 1550 FS B (Pass-trough) 1551 SF B (Pass-trough) 1552 MS G (Switching - MS) - release 1553 the switches but signal MS 1554 WTR N/A - cannot happen when there 1555 is MS request in the ring 1556 EXER N/A - cannot happen when there 1557 is MS request in the ring 1558 RR N/A 1559 NR N/A 1560 ===================================================================== 1561 Initial state New request New state 1562 ------------- ----------- --------- 1563 H (Switching - WTR) LP B (Pass-trough) 1564 FS B (Pass-trough) 1565 SF B (Pass-trough) 1566 MS B (Pass-trough) 1567 WTR N/A 1568 EXER N/A - cannot happen when there 1569 is WTR request in the ring 1570 RR N/A 1571 NR N/A 1572 ===================================================================== 1573 Initial state New request New state 1574 I (Switching - EXER) LP B (Pass-trough) 1575 FS B (Pass-trough) 1576 SF B (Pass-trough) 1577 MS B (Pass-trough) 1578 WTR N/A 1579 EXER I (Switching - EXER) 1580 RR N/A 1581 NR N/A 1582 ===================================================================== 1584 7. IANA Considerations 1586 Channel Types for the Generic Associated Channel are allocated from 1587 the IANA PW Associated Channel Type registry defined in [RFC4446] and 1588 updated by [RFC5586]. 1590 IANA is requested to allocate further Channel Type as follows: 1592 o 0xXX Automatic Protection Switching (APS) 1594 Note to RFC Editor: this section may be removed on publication as an 1595 RFC. 1597 8. Security Considerations 1599 This document does not by itself raise any particular security 1600 considerations. 1602 9. Acknowledgements 1604 Special thanks to Igor Umansky for his contribution. 1606 10. References 1608 10.1. Normative References 1610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1611 Requirement Levels", RFC 2119, BCP 14, March 1997. 1613 10.2. Informative References 1615 [RFC5654] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 1616 "Requirements for the Transport Profile of MPLS", RFC 1617 5654, September 2009. 1619 [G.841] ITU-T, , "Types and characteristics of SDH network 1620 protection architectures", Recommendation G.841, Feb 2010. 1622 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 1623 Maintenance Framework for MPLS-Based Transport Networks", 1624 RFC 6371, September 2011. 1626 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1627 Associated Channel", RFC 5586, June 2009. 1629 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1630 Emulation (PWE3)", RFC 4446, BCP 116, April 2006. 1632 Appendix A. Ring protection requirements compliance 1634 Ring protection requirements are specified in the [RFC5654] 1635 Section 2.5.6. This section summarizes the coverage of these 1636 requirements by MRPS mechanism. 1638 Generic topology-specific requirement: 1640 91 Interoperability between the ring and mesh networks in term of 1641 protection switching is achieved by: 1643 * using a non-preemptable unprotected traffic type (NUT) in the 1644 ring for the LSPs traversing the ring that are protected with 1645 end-to-end linear protection. 1647 * implementing segmented linear protection on the ring edge 1648 nodes 1650 Optimization criteria: 1652 a. There is only one APS OAM session per ring. 1654 b. Only two network elements, which are adjacent to addressed span 1655 or node are involved in protection switching event. 1657 c. MRPS requires one protection label on each span to protect one 1658 working LSP. 1660 d. Management operations are applied per node/per span, rather than 1661 per path. Dedicated procedures for ring upgrade are supported by 1662 using operator commands, provided by the ring protection 1663 algorithm. Static provisioning of limited amount of parameters 1664 is considered. 1666 e. MRPS mechanism does not affect control plane. 1668 General criteria: 1670 92 MRPS mechanism operates provides for recovery of protected 1671 traffic within a ring domain without affecting other parts of the 1672 network. 1674 93 Current version of this draft describes protection mechanism 1675 operating in the single ring domain. Multiple rings interworking 1676 is for further study. 1678 94 Unidirectional and bidirectional paths are protected by MRPS, due 1679 to the fact that the protection mechanism is bidirectional. 1681 95 Unidirectional P2MP paths are protected with the same mechanism 1682 as unidirectional by wrapping scheme. Steering scheme provides 1683 different mechanisms for P2P and P2MP paths. 1685 96 Irrelevant for this draft. 1687 97 MRSP mechanism operates at the MPLS-TP section layer and does not 1688 depend on number of LSPs passing addressed section/span. 1690 98.A Configuration of protection LSP is proportional to the number 1691 of working LSPs. Operation of protection switching is 1692 independent of number of working/protection path. 1694 98.B Configuration of protection LSP is proportional to the number 1695 of nodes in the ring. Operation of protection switching is 1696 independent of number of nodes. 1698 98.C Configuration and operation of MRPS is done per ring and is 1699 independent of number or rings interconnects. 1701 99 MRPS mechanism operates in a ring protection domain without 1702 affecting attached networks. An MPRS ring may be connected to a 1703 general MPLS-TP network with no constraint. 1705 100 Recovery technique of MRPS relies on standard MPLS label swapping 1706 operation. Protection algorithm relies on well established MS- 1707 SPRing/BLSR mechanism. 1709 101 MRPS mechanism is agnostic to the server layer technology and the 1710 associated infrastructure. 1712 102 Protection switching in MRPS is bidirectional. 1714 103 Protection switching in MRPS is revertive in case or wrapping 1715 scheme and configurable in case of steering scheme. 1717 104 MRPS supports operator commands and automatic evens as protection 1718 triggers. Each one is identified via dedicated code in APS 1719 protocol. 1721 105 MRPS supports operator commands to lockout/disable the protection 1722 switching per span and per entire ring. 1724 106.A MRPS supports ring protection operation in case of multiple 1725 requests in the ring. 1727 106.B MRPS supports traffic protection in case multiple failures in 1728 the ring. 1730 107 Supported through wait-to-restore timer. 1732 108 Best effort traffic that can be carried in unprotected LSPs (via 1733 NUT feature) and in all of the protection bandwidth. 1735 109 Supported through sharing the protection bandwidth of each span 1736 between all other spans in the ring. 1738 Authors' Addresses 1740 Huub van Helvoort (editor) 1741 Huawei Technologies 1743 Email: huub.van.helvoort@huawei.com 1745 Jeong-dong Ryoo (editor) 1746 ETRI 1748 Email: ryoo@etri.re.kr 1750 Italo Busi 1751 Alcatel-Lucent 1753 Email: italo.busi@alcatel-lucent.com 1755 Haiyan Zhang 1756 Huawei Technologies 1758 Email: zhanghaiyan@huawei.com 1760 Han Li 1761 China Mobile Communications Corporation 1763 Email: lihan@chinamobile.com 1765 Ruiquan Jing 1766 China Telecom 1768 Email: jingrq@ctbri.com.cn