idnits 2.17.1 draft-ietf-mpls-tp-shared-ring-protection-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 513 has weird spacing: '...l links xxx...' == Line 618 has weird spacing: '...l links xxx...' == Line 974 has weird spacing: '...aaaaaaa a/c...' -- The document date (June 15, 2016) is 2862 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'LSP1' is mentioned on line 750, but not defined == Missing Reference: 'LSP2' is mentioned on line 759, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cheng 3 Internet-Draft L. Wang 4 Intended status: Standards Track H. Li 5 Expires: December 17, 2016 China Mobile 6 H. Helvoort 7 Hai Gaoming BV 8 K. Liu 9 J. Dong 10 J. He 11 Huawei Technologies 12 F. Li 13 China Academy of Telecommunication Research, MIIT., China 14 J. Yang 15 ZTE Corporation P.R.China 16 J. Wang 17 Fiberhome Telecommunication Technologies Co., LTD. 18 June 15, 2016 20 MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology 21 draft-ietf-mpls-tp-shared-ring-protection-02 23 Abstract 25 This document describes requirements, architecture and solutions for 26 MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point- 27 to-point (P2P) services. The mechanism of MSRP is illustrated and 28 how it satisfies the requirements for optimized ring protection in 29 RFC 5654 is analyzed. This document also defines the Ring Protection 30 Switch (RPS) Protocol which is used to coordinate the protection 31 behavior of the nodes on MPLS ring. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on December 17, 2016. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements for MPLS-TP Ring Protection . . . . . . . . . . 4 75 2.1. Recovery of Multiple Failures . . . . . . . . . . . . . . 4 76 2.2. Smooth Upgrade from Linear Protection to Ring Protection 5 77 2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5 78 3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 79 4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 80 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 81 4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 82 4.1.2. Label Assignment and Distribution . . . . . . . . . . 8 83 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 84 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 85 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 86 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 13 88 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 15 89 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 18 90 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 18 91 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 20 92 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 20 93 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 22 94 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 23 95 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 24 96 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 24 97 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 26 98 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26 99 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 100 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 101 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 102 5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31 103 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 33 104 5.2.3. State transitions When Local Request is Applied . . . 34 105 5.2.4. State Transitions When Remote Request is Applied . . 37 106 5.2.5. State Transitions When Request Addresses to Another 107 Node is Received . . . . . . . . . . . . . . . . . . 40 108 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 43 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 110 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44 111 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 44 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 113 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 114 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 117 10.2. Informative References . . . . . . . . . . . . . . . . . 46 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 120 1. Introduction 122 As described in section 2.5.6.1 of [RFC5654], Ring Protection of 123 MPLS-TP requirements, several service providers have expressed much 124 interest in operating MPLS-TP in ring topologies and require a high- 125 level survivability function in these topologies. In operational 126 transport network deployment, MPLS-TP networks are often constructed 127 with ring topologies. It calls for an efficient and optimized ring 128 protection mechanism to achieve simple operation and fast, sub 50 ms, 129 recovery performance. 131 The requirements for MPLS-TP [RFC5654] state that recovery mechanisms 132 which are optimized for ring topologies could be further developed if 133 it can provide the following features: 135 a. Minimize the number of OAM entities for protection 137 b. Minimize the number of elements of recovery 139 c. Minimize the required label number 141 d. Minimize the amount of control and management-plane transactions 142 during maintenance operation 144 e. Minimize the impact on information exchange during protection if 145 a control plane is supported 147 This document specifies MPLS-TP Shared-Ring Protection mechanisms 148 that can meet all those requirements on ring protection listed in 149 [RFC5654]. 151 The basic concepts and architecture of Shared-Ring protection 152 mechanism are specified in this document. This document focuses on 153 the solutions for point-to-point transport paths. While the basic 154 concepts may also apply to point-to-multipoint transport paths, the 155 solution for point-to-multipoint transport paths is under study and 156 will be presented in a separate document. 158 2. Requirements for MPLS-TP Ring Protection 160 The requirements for MPLS-TP ring protection are specified in 161 [RFC5654]. This document elaborates on the requirements in detail. 163 2.1. Recovery of Multiple Failures 165 MPLS-TP is expected to be used in carrier grade metro networks and 166 backbone transport networks to provide mobile backhaul, business 167 services etc., in which the network survivability is very important. 168 According to R106 B in [RFC5654], MPLS-TP recovery mechanisms in a 169 ring SHOULD protect against multiple failures. The following text 170 provides some more detailed illustration about "multiple failures". 171 In metro and backbone networks, a single risk factor often affects 172 multiple links or nodes. Some examples of risk factors are given as 173 follows: 175 o multiple links use fibers in one cable or pipeline 177 o Several nodes share one power supply system 179 o Weather sensitive micro-wave system 181 Once one of the above risk factors happens, multiple links or nodes 182 failures may occur simultaneously and those failed links or nodes may 183 be located on a single ring as well as on interconnected rings. Ring 184 protection against multiple failures should cover both multiple 185 failures on a single ring and multiple failures on interconnected 186 rings, as long as the connectivity between the ingress and egress 187 node of the ring still exists. 189 2.2. Smooth Upgrade from Linear Protection to Ring Protection 191 It is beneficial for service providers to upgrade the protection 192 scheme from linear protection to ring protection in their MPLS-TP 193 network without service interruption. In-service insertion and 194 removal of a node on the ring should also be supported. Therefore, 195 the MPLS-TP ring protection mechanism is supposed to be developed and 196 optimized for compliance with this smooth upgrading principle. 198 2.3. Configuration Complexity 200 Ring protection can reduce the dependency of configuration on the 201 quantity of services, thus will simplify the network protection 202 configuration and operation effort. This is because the ring 203 protection makes use of the characteristics of ring topology and 204 mechanisms on the section layer. While in the application scenarios 205 of deploying linear protection in ring topology MPLS-TP network, the 206 configuration of protection has a close relationship with the 207 quantities of services carried. Especially in some large metro 208 networks with more than ten thousands of services in the access 209 nodes, the LSP linear protection capabilities of the metro core nodes 210 needs to be large enough to meet the network planning requirements, 211 which also leads to the complexity of network protection 212 configurations and operations. 214 3. Terminology and Notation 216 The following syntax will be used to describe the contents of the 217 label stack: 219 1. The label stack will be enclosed in square brackets ("[]"). 221 2. Each level in the stack will be separated by the '|' character. 222 It should be noted that the label stack may contain additional 223 layers. However, we only present the layers that are related to the 224 protection mechanism. 226 3. If the Label is assigned by Node X, the Node Name is enclosed in 227 bracket ("()") 229 4. Shared Ring Protection Architecture 231 4.1. Ring Tunnel 233 This document introduces a new logical layer of the ring for shared 234 ring protection in MPLS-TP networks. As shown in Figure 1, the new 235 logical layer consists of ring tunnels which provides a server layer 236 for the LSPs traverse the ring. Once a ring tunnel is established, 237 the configuration, management and protection of the ring are all 238 performed at the ring tunnel level. One port can carry multiple ring 239 tunnels, while one ring tunnel can carry multiple LSPs. 241 +------------- 242 +-------------| 243 +-------------| | 244 =====PW1======| | | 245 | | Ring | Physical 246 =====PW2======| LSP | Tunnel | Port 247 | | | 248 =====PW3======| | | 249 +-------------| | 250 +-------------| 251 +------------- 252 Figure 1. The logical layers of the ring 254 The label stack used in MPLS-TP Shared Ring Protection mechanism is 255 shown as below: 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Ring tunnel Label | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | LSP Label | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | PW Label | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Payload | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2. Label stack used in MPLS-TP Shared Ring Protection 268 4.1.1. Establishment of Ring Tunnel 270 The Ring tunnels are established based on the egress nodes. The 271 egress node is the node where traffic leaves the ring. LSPs which 272 have the same egress node on the ring share the same ring tunnels. 273 In other words, all the LSPs that traverse the ring and exit from the 274 same node share the same working ring tunnel and protection ring 275 tunnel. For each egress node, four ring tunnels are established: 277 o one clockwise working ring tunnel, which is protected by the 278 anticlockwise protection ring tunnel 280 o one anticlockwise protection ring tunnel 282 o one anticlockwise working ring tunnel, which is protected by the 283 clockwise protection ring tunnel 285 o one clockwise protection ring tunnel 287 The structure of the protection tunnels are determined by the 288 selected protection mechanism. This will be detailed in subsequent 289 sections. 291 As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, 292 Node A and Node B respectively, and all leave the ring at Node D. To 293 protect these LSPs that traverse the ring, a clockwise working ring 294 tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection 295 ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an 296 anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and 297 its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D 298 are established. For simplicity Figure 3 only shows RcW_D and RaP_D. 299 A similar provisioning should be applied for any other node on the 300 ring. In summary, for each node in Figure 3 when acting as egress 301 node, the ring tunnels are created as follows: 303 o To Node A: RcW_A, RaW_A, RcP_A, RaP_A 305 o To Node B: RcW_B, RaW_B, RcP_B, RaP_B 307 o To Node C: RcW_C, RaW_C, RcP_C, RaP_C 309 o To Node D: RcW_D, RaW_D, RcP_D, RaP_D 311 o To Node E: RcW_E, RaW_E, RcP_E, RaP_E 313 o To Node F: RcW_F, RaW_F, RcP_F, RaP_F 314 +---+#############+---+ 315 | F |-------------| A | +-- LSP2 316 +---+*************+---+ 317 #/* *\# 318 #/* *\# 319 #/* *\# 320 +---+ +---+ 321 LSP1-+ | E | | B |+-- LSP3 322 +---+ +---+ 323 #\ */# 324 #\ */# 325 #\ */# 326 +---+*************+---+ 327 LSP1 +--| D |-------------| C | 328 LSP2 +---+#############+---+ 329 LSP3 331 ---- physical links 332 **** RcW_D 333 #### RaP_D 335 Figure 3. Ring tunnels in MSRP 337 Through these working and protection ring tunnels, LSPs which enter 338 the ring from any node can reach any egress nodes on the ring, and 339 are protected from failures on the ring. 341 4.1.2. Label Assignment and Distribution 343 The ring tunnel labels are downstream-assigned labels as defined in 344 [RFC3031]. The ring tunnel labels can be either configured 345 statically, provisioned by a controller, or distributed dynamically 346 via a control protocol. 348 4.1.3. Forwarding Operation 350 When an MPLS-TP transport path, such as an LSP, enters the ring, the 351 ingress node on the ring pushes the working ring tunnel label 352 according to the egress node and sends the traffic to the next hop. 353 The transit nodes on the working ring tunnel swap the ring tunnel 354 labels and forward the packets to the next hop. When the packet 355 arrives at the egress node, the egress node pops the ring tunnel 356 label and forwards the packets based on the inner LSP label and PW 357 label. Figure 4 shows the label operation in the MPLS-TP shared ring 358 protection mechanism. Assume that LSP1 enters the ring at Node A and 359 exits from Node D, and the following label operations are executed. 361 1. Ingress node: Packets of LSP1 arrive at Node A with a label stack 362 [LSP1] and is supposed to be forwarded in the clockwise direction 363 of the ring. The clockwise working ring tunnel label RcW_D will 364 be pushed at Node A, the label stack for the forwarded packet at 365 Node A is changed to [RcW_D(B)|LSP1]. 367 2. Transit nodes: In this case, Node B and Node C forward the 368 packets by swapping the working ring tunnel labels. For example, 369 the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node 370 B. 372 3. Egress node: When the packet arrives at Node D (i.e. the egress 373 node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and 374 subsequently deals with the inner labels of LSP1. 376 +---+#####[RaP_D(F)]######+---+ 377 | F |---------------------| A | +-- LSP1 378 +---+*****[RcW_D(A)]******+---+ 379 #/* *\# 380 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)] 381 #/* *\# 382 +---+ +---+ 383 | E | | B | 384 +---+ +---+ 385 #\ */# 386 [RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)] 387 #\ */# 388 +---+*****[RcW_D(D)]****+---+ 389 LSP1 +-- | D |-------------------| C | 390 +---+#####[RaP_D(C)]####+---+ 392 -----physical links ****** RcW_D ###### RaP_D 394 Figure 4. Label operation of MSRP 396 4.2. Failure Detection 398 The MPLS-TP section layer OAM is used to monitor the connectivity 399 between each two adjacent nodes on the ring using the mechanisms 400 defined in [RFC6371]. Protection switching is triggered by the 401 failure detected on the ring by the OAM mechanisms. 403 Two end ports of a link form a Maintenance Entity Group (MEG), and an 404 MEG end point (MEP) function is installed in each ring port. CC OAM 405 packets are periodically exchanged between each pair of MEPs to 406 monitor the link health. Three consecutive CC packets losses will be 407 interpreted as a link failure. 409 A node failure is regarded as the failure of two links attached to 410 that node. The two nodes adjacent to the failed node detect the 411 failure in the links that are connected to the failed node. 413 4.3. Ring Protection 415 This section specifies the ring protection mechanisms in detail. In 416 general, the description uses the clockwise working ring tunnel and 417 the corresponding anti-clockwise protection ring tunnel as example, 418 but the mechanism is applicable in the same way to the anti-clockwise 419 working and clockwise protection ring tunnels. 421 In ring network, each working ring tunnel is associated with a 422 protection ring tunnel in the opposite direction, and every node can 423 obtain the ring topology either by configuration or via some topology 424 discovery mechanism. The ring topology and the connectivity (Intact 425 or Severed) between the adjacent ring nodes form the ring map. Each 426 ring node maintains the ring map and use it to peform ring 427 protection. 429 Taking the topology in Figure 4 as example, LSP1 enters the ring at 430 Node A and leaves the ring at Node D. In normal state, LSP1 is 431 carried by clockwise working ring tunnel (RcW_D) through the path 432 A->B->C->D, the label operation is: 434 [LSP1](original data traffic carried by LSP1) -> 435 [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| 436 LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D 437 the packet will be forwarded based on the label stack of LSP1. 439 Three typical ring protection mechanisms are specified in this 440 section: wrapping, short wrapping and steering. 442 In wrapping ring protection, node which detects a failure or accepts 443 a switch request switches the traffic impacted by the failure to the 444 opposite direction (away from the failure). In this way, the 445 impacted traffic is switched to the protection ring tunnel by the 446 switching node upstream to the failure, then travels around the ring 447 to the other switching node through the protection ring tunnel, where 448 it is switched back onto the working ring tunnel and reach the egress 449 node. 451 Short wrapping ring protection provides some optimization to wrapping 452 protection, in which the impacted traffic is only switched once to 453 the protection ring tunnel by the switching node upstream to the 454 failure. At the egress node, the traffic leave the ring from the 455 protection ring tunnel. This can reduce the traffic detour of 456 wrapping protection. 458 Steering ring protection implies that the node that detects a failure 459 sends a request along the ring to the other node adjacent to the 460 failure, and all nodes in the ring process this information. For the 461 impaced traffic, the ingress node (which adds traffic to the ring) 462 perform switching from working to the protection ring tunnel, and at 463 the egress node the traffic leaves the ring from the protection ring 464 tunnel. 466 The following sections describes these protection mechanisms in 467 detail. 469 4.3.1. Wrapping 471 With the wrapping mechanism, the protection ring tunnel is a closed 472 ring identified by the egress node. As shown in Figure 4, the RaP_D 473 is the anticlockwise protection ring tunnel for the clockwise working 474 ring tunnel RcW_D. As specified in the following sections, the 475 closed ring protection tunnel can protect both the link failure and 476 the node failure. 478 4.3.1.1. Wrapping for Link Failure 480 When a link failure between Node B and Node C occurs, if it is a bi- 481 directional failure, both Node B and Node C can detect the failure 482 via OAM mechanism; if it is a uni-directional failure, one of the two 483 nodes would detect the failure and it would inform the other node via 484 the Ring Protection Switch Protocol (RPS) which is specified in 485 section 5. Then Node B switches the clockwise working ring tunnel 486 (RcW_D) to the anticlockwise protection ring tunnel (RaP_D) and Node 487 C switches anticlockwise protection ring tunnel(RaP_D) back to the 488 clockwise working ring tunnel (RcW_D). The data traffic which enters 489 the ring at Node A and leaves the ring at Node D follows the path 490 A->B->A->F->E->D->C->D. The label operation is: 492 [LSP1](Original data traffic) -> [RcW_D(B)|LSP1](Node A) -> 493 [RaP_D(A)|LSP1](Node B) -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] 494 (Node F) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> 495 [RcW_D(D)|LSP1](Node C) -> [LSP1](data traffic leaves the ring). 497 +---+#####[RaP_D(F)]######+---+ 498 | F |---------------------| A | +-- LSP1 499 +---+*****[RcW_D(A)]******+---+ 500 #/* *\# 501 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 502 #/* *\# 503 +---+ +---+ 504 | E | | B | 505 +---+ +---+ 506 #\ *x# 507 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 508 #\ *x# 509 +---+*****[RcW_D(D)]****+---+ 510 LSP1 +-- | D |-------------------| C | 511 +---+#####[RaP_D(C)]####+---+ 513 -----physical links xxxx Failure Link 514 ****** RcW_D ###### RaP_D 516 Figure 5.Wrapping for link failure 518 4.3.1.2. Wrapping for Node Failure 520 As shown in Figure 6, when Node B fails, Node A detects the failure 521 between A and B and switches the clockwise work ring tunnel (RcW_D) 522 to the anticlockwise protection ring tunnel (RaP_D), Node C detects 523 the failure between C and B and switches the anticlockwise protection 524 ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). 525 The data traffic which enters the ring at Node A and exits at Node D 526 follows the path A->F->E->D->C->D. The label operation is: 528 [LSP1](original data traffic carried by LSP1) -> 529 [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 530 [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] 531 (NodeC) -> [LSP1](data traffic carried by LSP1). 533 In one special case where node D fails, all the ring tunnels with 534 node D as egress will become unusable. However, before the failure 535 location information is propagated to all the ring nodes, the 536 wrapping protection mechanism may cause temporary traffic loop: node 537 C detects the failure and switches the traffic from the clockwise 538 work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel 539 (RaP_D), node E also detects the failure and would switch the traffic 540 from anticlockwise protection ring tunnel (RaP_D) back to the 541 clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate 542 the temporary loop problem is: the TTL of the ring tunnel label is 543 set to 2*N by the ingress ring node of the traffic, where N is the 544 number of nodes on the ring. 546 +---+#####[RaP_D(F)]######+---+ 547 | F |---------------------| A | +-- LSP1 548 +---+*****[RcW_D(A)]******+---+ 549 #/* *\# 550 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 551 #/* *\# 552 +---+ xxxxx 553 | E | x B x 554 +---+ xxxxx 555 #\ */# 556 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 557 #\ */# 558 +---+*****[RcW_D(D)]****+---+ 559 LSP1 +-- | D |-------------------| C | 560 +---+#####[RaP_D(C)]####+---+ 562 -----physical links xxxxxx Failure Node 563 *****RcW_D ###### RaP_D 565 Figure 6. Wrapping for node failure 567 4.3.2. Short Wrapping 569 With the traditional wrapping protection scheme, protection switching 570 is executed at both nodes adjacent to the failure, consequently the 571 traffic will be wrapped twice. This mechanism will cause additional 572 latency and bandwidth consumption when traffic is switched to the 573 protection path. 575 With short wrapping protection, data traffic switching is executed 576 only at the node upstream to the failure, and data traffic leaves the 577 ring in the protection ring tunnel at the egress node. This scheme 578 can reduce the additional latency and bandwidth consumption when 579 traffic is switched to the protection path. 581 In the traditional wrapping solution, in normal state the protection 582 ring tunnel is a closed ring, while in the short wrapping solution, 583 the protection ring tunnel is ended at the egress node, which is 584 similar to the working ring tunnel. Short wrapping is easy to 585 implement in shared ring protection because both the working and 586 protection ring tunnels are terminated on the egress nodes. Figure 7 587 shows the clockwise working ring tunnel and the anticlockwise 588 protection ring tunnel with node D as the egress node. 590 4.3.2.1. Short Wrapping for Link Failure 592 As shown in Figure 7, in normal state, LSP1 is carried by the 593 clockwise working ring tunnel (RcW_D) through the path A->B->C->D. 594 When a link failure between Node B and Node C occurs, Node B switches 595 The working ring tunnel RcW_D to the protection ring tunnel RaP_D in 596 the opposite direction. The difference occurs in the protection ring 597 tunnel at egress node. In short wrapping protection, Rap_D ends in 598 Node D and then traffic will be forwarded based on the LSP labels. 599 Thus with short wrapping mechanism, LSP1 will follow the path 600 A->B->A->F->E->D when link failure between Node B and Node C happens. 602 +---+#####[RaP_D(F)]######+---+ 603 | F |---------------------| A | +-- LSP1 604 +---+*****[RcW_D(A)]******+---+ 605 #/* *\# 606 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 607 #/* *\# 608 +---+ +---+ 609 | E | | B | 610 +---+ +---+ 611 #\ *x# 612 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 613 #\ *x# 614 +---+*****[RcW_D(D)]****+---+ 615 LSP1 +-- | D |-------------------| C | 616 +---+ +---+ 618 ----- physical links xxxxx Failure Link 619 ****** RcW_D ###### RaP_D 621 Figure 7. Short wrapping for link failure 623 4.3.2.2. Short Wrapping for Node Failure 625 For the node failure which happens on a non-egress node, short 626 wrapping protection switching is similar to the link failure case as 627 described in the previous section. This section specifies the 628 scenario of egress node failure. 630 As shown in Figure 8, LSP1 enters the ring on node A, and leaves the 631 ring on node D. In normal state, LSP1 is carried by the clockwise 632 working ring tunnel (RcW_D) through the path A->B->C->D. When node D 633 fails, traffic of LSP1 cannot be protected by any ring tunnels which 634 use node D as the egress node. However, before the failure location 635 information is propagated to all the ring nodes, node C switches all 636 the traffic on the working ring tunnel RcW_D to the protection ring 637 tunnel RaP_D in the opposite direction. When the traffic arrives at 638 node E which also detects the failure of node D, the protection ring 639 tunnel RaP_D cannot be used to forward traffic to node D. Since with 640 short wrapping mechanism, protection switching can only be performed 641 once from the working ring tunnel to the protection ring tunnel, thus 642 node E MUST NOT switch the traffic which is already carried on the 643 protection ring tunnel back to the working ring tunnel in the 644 opposite direction. Instead, node E will discard the traffic 645 received on RaP_D locally. This can avoid the temporary traffic loop 646 when the failure happens on the egress node of the ring tunnel. This 647 also illustrates one of the benefits of having separate working and 648 protection ring tunnels in each ring direction. 650 +---+#####[RaP_D(F)]######+---+ 651 | F |---------------------| A | +-- LSP1 652 +---+*****[RcW_D(A)]******+---+ 653 #/* *\# 654 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 655 #/* *\# 656 +---+ +---+ 657 | E | | B | 658 +---+ +---+ 659 #\ */# 660 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 661 #\ */# 662 xxxxx*****[RcW_D(D)]****+---+ 663 LSP1 +-- x D x-------------------| C | 664 xxxxx +---+ 666 -----physical links xxxxxx Failure Node 667 *****RcW_D ###### RaP_D 669 Figure 8. Short Wrapping for egress node failure 671 4.3.3. Steering 673 With steering protection mechanism, the ingress node (which adds 674 traffic to the ring) perform switching from working to the protection 675 ring tunnel, and at the egress node the traffic leaves the ring from 676 the protection ring tunnel. 678 When a failure occurs in the ring, the node which detects the failure 679 via OAM mechanism sends the failure information in the opposite 680 direction of the failure hop by hop along the ring using RPS request 681 message. When a ring node receives the RPS message which identifies 682 a failure, it can quickly determine the location of the fault by 683 using the topology information that is maintained by the node and 684 update the ring map accordingly, then it can determine whether the 685 LSPs entering the ring locally need to switchover or not. For LSPs 686 that needs to switchover, it will switch the LSPs from the working 687 ring tunnels to its corresponding protection ring tunnels. 689 4.3.3.1. Steering for Link Failure 691 Ring map of F +--LSPl 692 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ 693 |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| 694 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ 695 |I|I|I|S|I|I| |I|I|S|I|I|I| 696 +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ 697 [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] 698 #/* [RcW_D(F)] *\# 699 +-+-+-+-+-+-+-+ #/* *\# 700 |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 701 +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ 702 |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| 703 +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 704 #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| 705 [RaP_D(D)] #\* */# +-+-+-+-+-+-+ 706 #\* */# [RaP_D(B)] 707 +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ 708 |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| 709 +-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ 710 |I|I|I|I|I|S| LSP2 |S|I|I|I|I|I| 711 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 713 ----- physical links ***** RcW_D ##### RaP_D 714 I: Intact S: Severed 715 Figure 9. Steering operation and protection switching 717 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 718 enters the ring from Node B, and both of them have the same 719 destination node D. 721 In normal state, LSP1 is carried by the clockwise working ring tunnel 722 (RcW_D) through the path A->B->C->D, the label operation is: [LSP1] 723 -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> 724 [RcW_D(D)|LSP1](NodeC) -> [LSP1](data traffic carried by LSP1) . 726 LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught 727 the path B->C->D, the label operation is: [LSP2] -> 728 [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](data 729 traffic carried by LSP2) . 731 If the link between nodes C and D fails, according to the fault 732 detection and distribution mechanisms, Node D will find out that 733 there is a failure in the link between C and D, and it will update 734 the link state of its ring topology, changing the link between C and 735 D from normal to fault. In the direction that opposite to the 736 failure position, Node D will send the state report message to Node 737 E, informing Node E of the fault between C and D, and E will update 738 the link state of its ring topology accordingly, changing the link 739 between C and D from normal to fault. In this way, the state report 740 message is sent hop by hop in the clockwise direction. Similar to 741 Node D, Node C will send the failure information in the anti- 742 clockwise direction. 744 When Node A receives the failure report message and updates the link 745 state of its ring topology, it is aware that there is a fault on the 746 clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the 747 ring locally and is carried by this ring tunnel, thus Node A will 748 decide to switch the LSP1 onto the anticlockwise protection ring 749 tunnel to node D (RaP_D). After the switchover, LSP1 will follow the 750 path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| 751 LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> 752 [LSP1](data traffic carried by LSP1). 754 The same procedure also applies to the operation of LSP2. When Node 755 B updates the link state of its ring topology, and finds out that the 756 working ring tunnel RcW_D has failed, it will switch the LSP2 to the 757 anticlockwise protection tunnel RaP_D. After the switchover, LSP2 758 goes through the path B->A->F->E->D, and the label operation is: 759 [LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> 760 [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data 761 traffic carried by LSP2). 763 Assume the link between nodes A and B breaks down, as shown in 764 Figure 10. Similar to the above failure case, Node B will detect a 765 fault in the link between A and B, and it will update its ring map, 766 changing the link state between A and B from normal to fault. The 767 state report message is sent hop by hop in the clockwise direction, 768 notifying every node that there is a fault between node A and B, and 769 every node updates the link state of its ring topology. As a result, 770 Node A will detect a fault in the working ring tunnel to node D, and 771 switch LSP1 to the protection ring tunnel, while Node B determine 772 that the working ring tunnel for LSP2 still works fine, and will not 773 perform the switchover. 775 /-- LSPl 776 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ 777 |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| 778 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ 779 |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| 780 +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ 781 [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] 782 #/* x +-- LSP2 783 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 784 |E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B| 785 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 786 |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| 787 +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ 788 [RaP_D(D)] #\* */# [RaP_D(B)] 789 +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 790 |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| 791 +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ 792 |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| 793 +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ 795 ----- physical links ***** RcW_D ##### RaP_D 797 Figure 10. Steering operation and protection switching (2) 799 4.3.3.2. Steering for Node Failure 801 For node failure which happens on a non-egress node, steering 802 protection switching is similar to the link failure case as described 803 in the previous section. 805 If the failure occurs at the egress node of the LSP, since the 806 ingress node can update its ring map according to the received RPS 807 messages, it will determine that the egress node is not reachable 808 after the failure, thus it will not send traffic to either the 809 working or protection tunnel, and traffic loop can be avoided. 811 4.4. Interconnected Ring Protection 813 4.4.1. Interconnected Ring Topology 815 Interconnected ring topology is widely used in MPLS-TP networks. 816 This document will discuss two typical interconnected ring 817 topologies: 819 1. Single-node interconnected rings 821 In single-node interconnected rings, the connection between 822 the two rings is through a single node. Because the 823 interconnection node is in fact a single point of failure, 824 this topology should be avoided in real transport networks. 825 Figure 11 shows the topology of single-node interconnected 826 rings. Node C is the interconnection node between Ring1 and 827 Ring2. 829 2. Dual-node interconnected rings 831 In dual-node interconnected rings, the connection between the 832 two rings is through two nodes. The two interconnection nodes 833 belong to both interconnected rings. This topology can 834 recover from one interconnection node failure. 836 Figure 11 shows the topology of single-node interconnected rings. 837 Node C is the interconnection node between Ring1 and Ring2. 839 +---+ +---+ +---+ +---+ 840 | A |------| B |----- -----| G |------| H | 841 +---+ +---+ \ / +---+ +---+ 842 | \ / | 843 | \ +---+ / | 844 | Ring1 | C | Ring2 | 845 | / +---+ \ | 846 | / \ | 847 +---+ +---+ / \ +---+ +---+ 848 | F |------| E |----- -----| J |------| I | 849 +---+ +---+ +---+ +---+ 851 Figure 11. Single-node interconnected rings 853 Figure 12 shows the topology of dual-node interconnected rings. 854 Nodes C and Node D are the interconnection nodes between Ring1 and 855 Ring2. 857 +---+ +---+ +---+ +---+ +---+ 858 | A |------| B |------| C |------| G |------| H | 859 +---+ +---+ +---+ +---+ +---+ 860 | | | | 861 | | | | 862 | Ring1 | | Ring2 | 863 | | | | 864 | | | | 865 +---+ +---+ +---+ +---+ +---+ 866 | F |------| E |------| D |------| J |------| I | 867 +---+ +---+ +---+ +---+ +---+ 869 Figure 12. Dual-node interconnected rings 871 4.4.2. Interconnected Ring Protection Mechanisms 873 Interconnected rings can be treated as two independent rings. Ring 874 protection switching (RPS) protocol operates on each ring 875 independently. Failure happened on one ring only triggers protection 876 switching on the ring itself and does not affect the other ring, 877 unless the failure is on the interconnection node. This way, 878 protection switching on each ring is the same as the mechanisms 879 described in section 4.3. 881 The service LSPs that traverse the interconnected rings use seperate 882 ring tunnels on each ring, and the LSPs on different rings are 883 stitched by the interconnection node. On the interconnection node, 884 the ring tunnel label of the source ring is popped, then LSP label is 885 swapped, after that the ring tunnel label of the destination ring is 886 pushed. 888 In the dual-node interconnected ring scenario, the two 889 interconnection nodes can be managed as a virtual node group. In 890 addition to the ring tunnels to each physical ring node, Each ring 891 SHOULD assign the working and protection ring tunnels to the virtual 892 interconnection node group. In addition, on both nodes in the 893 virtual interconnection node group, the same LSP label is assigned 894 for each traversed LSP. This way, any interconnection node in the 895 virtual node group can terminate the working or protection ring 896 tunnels targeted to the virtual node group, and stitch the service 897 LSP from the source ring tunnel to the destination ring tunnel. 899 When the service LSP passes through the interconnected rings, the 900 direction of the working ring tunnels used on both rings SHOULD be 901 the same. For example, if the service LSP uses the clockwise working 902 ring tunnel on Ring1, when the service LSP leaves Ring1 and enters 903 Ring2, the working ring tunnel used on Ring2 SHOULD also follow the 904 clockwise direction. 906 4.4.3. Ring Tunnels in Interconnected Rings 908 The same ring tunnels as described in section 4.1 are used in each 909 ring of the interconnected rings. In addition, ring tunnels to the 910 virtual interconnection node group are established on each ring of 911 the interconnected rings, i.e.: 913 o one clockwise working ring tunnel to the virtual interconnection 914 node group 916 o one anticlockwise protection ring tunnel to the virtual 917 interconnection node group 919 o one anticlockwise working ring tunnel to the virtual 920 interconnection node group 922 o one clockwise protection ring tunnel to the virtual 923 interconnection node group 925 These ring tunnels will terminated at any node in the virtual 926 interconnection node group. 928 For example, all the ring tunnels on Ring1 in Figure 13 are 929 provisioned as follows: 931 o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A 933 o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B 935 o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C 937 o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D 939 o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E 941 o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F 943 o To the virtual interconnection node group (including Node F and 944 Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A 946 All the ring tunnels on Ring2 in Figure 13 are provisioned as 947 follows: 949 o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A 951 o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F 953 o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G 955 o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H 957 o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I 959 o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J 961 o To the virtual interconnection node group (including Node F and 962 Node A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A 963 +---+cccccccccccc +---+ 964 | H |-------------| I |--->LSP1 965 +---+ +---+ 966 c/a a\ 967 c/a a\ 968 c/a a\ 969 +---+ +---+ 970 | G | Ring2 | J | 971 +---+ +---+ 972 c\a a/c 973 c\a a/c 974 c\a aaaaaaaaaaaaa a/c 975 +---+ccccccccccccc+---+ 976 | F |-------------| A | 977 +---+ccccccccccccc+---+ 978 c/aaaaaaaaaaaaaaaaaaa a\ 979 c/ a\ 980 c/ a\ 981 +---+ +---+ 982 | E | Ring1 | B | 983 +---+ +---+ 984 c\a a/c 985 c\a a/c 986 c\a a/c 987 +---+aaaaaaaaaaaa +---+ 988 LSP1--->| D |-------------| C | 989 +---+ccccccccccccc+---+ 991 ccccccccccc R1cW_F&A 992 aaaaaaaaaaa R1aP_F&A 993 ccccccccccc R2cW_I 994 aaaaaaaaaaa R2aP_I 995 Figure 13. Ring tunnels for the interconnected rings 997 4.4.4. Interconnected Ring Switching Procedure 999 As shown in Figure 13, for the service LSP1 which enters Ring1 at 1000 Node D and leaves Ring1 at Node F and continues to enter Ring2 at 1001 Node F and leaves Ring2 at Node I, the short wrapping protection 1002 scheme is described as below. 1004 In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. 1005 At the interconnection node F, the label used for the working ring 1006 tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the 1007 label used for the working ring tunnel R2cW_I in Ring2 will be pushed 1008 based the inner LSP label lookup. The working path that the service 1009 LSP1 follows is: LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. 1011 In case of link failure, for example, when a failure occurs on the 1012 link between Node F and Node E, Node E will detect the failure and 1013 execute protection switching as described in 4.3.2. The path that 1014 the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- 1015 >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 1017 In case of a non-interconnection node failure, for example, when the 1018 failure occurs at Node E in Ring1, Node D will detect the failure and 1019 execute protection switching as described in 4.3.2. The path that 1020 the service LSP1 follows after switching becomes: 1021 LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 1023 In case of an interconnection node failure, for example, when the 1024 failure occurs at the interconnection Node F. Node E in Ring1 will 1025 detect the failure, and execute protection switching as described in 1026 4.3.2. Node A in Ring2 will also detect the failure, and execute 1027 protection switching as described in 4.3.2. The path that the 1028 service traffic LSP1 follows after switching is: 1029 LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1. 1031 4.4.5. Interconnected Ring Detection Mechanism 1033 As show in Figure 13, in normal state the service traffic LSP1 1034 traverses D->E->F in Ring1 and F->G->H->I in Ring2. Node A and F are 1035 the interconnection nodes. When both the link between Node F and 1036 Node G and the link between Node F and Node A fail, the ring tunnel 1037 from Node F to Node I in Ring2 becomes unreachable. However, the 1038 other interconnection node A is still available, and LSP1 can still 1039 reach Node I via node A. 1041 In order to achieve this, the interconnection nodes need to know the 1042 ring topology of each ring so that they can judge whether a node is 1043 reachable. This judgment is based on the knowledge of ring map and 1044 the fault location as described in section 3.4. The ring map can be 1045 obtained from the NMS or topology discovery mechanisms. The fault 1046 location can be obtained by transmitting the fault information around 1047 the ring. The nodes that detect the failure will transmit the fault 1048 information in the opposite direction hop by hop using the RPS 1049 protocol message. When the interconnection node receives the message 1050 that informs the failure, it will quickly calculate the location of 1051 the fault according to the topology information that is maintained by 1052 itself and determines whether the LSPs entering the ring at itself 1053 can reach the destination. If the destination node is reachable, the 1054 LSP will leave the source ring and enter the destination ring. If 1055 the destination node is not reachable, the LSP will switch to the 1056 anticlockwise protection ring tunnel. 1058 In Figure 13, Node F determines that the ring tunnel to Node I is 1059 unreachable, the service LSP1 for which the destination node on the 1060 ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A) 1061 and consequently the service traffic LSP1 traverses the 1062 interconnected rings at Node A. Node A will pop the ring tunnel 1063 label of Ring1 and push the ring tunnel label of Ring2 and send the 1064 traffic to Node I via ring tunnel (R2aW_I). 1066 5. Ring Protection Coordination Protocol 1068 5.1. RPS Protocol 1070 The MSRP protection operation MUST be controlled with the help of the 1071 Ring Protection Switch Protocol (RPS). The RPS processes in each of 1072 the individual ring nodes that form the ring SHOULD communicate using 1073 the G-ACh channel. 1075 The RPS protocol MUST carry the ring status information and RPS 1076 requests, either automatically initiated or externally initiated, 1077 between the ring nodes. 1079 Each node on the ring MUST be uniquely identified by assigning it a 1080 node ID. The node ID MUST be unique on each ring. The maximum 1081 number of nodes on the ring supported by the RPS protocol is 127. 1082 The node ID SHOULD be independent of the order in which the nodes 1083 appear on the ring. The node ID is used to identity the source and 1084 destination nodes of each RPS request. 1086 Every node obtains the ring topology either by configuration or via 1087 some topology discovery mechanism. The ring map consists of the ring 1088 topology information, and connectivity status (Intact or Severed) 1089 between the adjacent ring nodes, which is determined via the OAM 1090 message exchanged between the adjacent nodes. The ring map is used 1091 by every ring node to determine the switchover behavior of the ring 1092 tunnels. 1094 When no protection switching is active on the ring, each node MUST 1095 dispatch periodically RPS requests to the two adjacent nodes, 1096 indicating No Request (NR). When a node determines that a protection 1097 switching is required, it MUST send the appropriate RPS request in 1098 both directions. 1100 +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) 1101 -------| A |-------------| B |-------------| C |------- 1102 (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ 1104 Figure 14. RPS communication between the ring nodes in case of 1105 no failure in the ring 1107 A destination node is a node that is adjacent to a node that 1108 identified a failed span. When a node that is not the destination 1109 node receives an RPS request and it has no higher priority local 1110 request, it MUST transfer in the same direction the RPS request as 1111 received. In this way, the switching nodes can maintain direct RPS 1112 protocol communication in the ring. 1114 +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) 1115 -------| A |-------------| B |----- X -----| C |------- 1116 (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ 1118 Figure 15. RPS communication between the ring nodes in case of 1119 failure between nodes B and C 1121 Note that in the case of a bidirectional failure such as a cable cut, 1122 the two adjacent nodes detect the failure and send each other an RPS 1123 request in opposite directions. 1125 o In rings utilizing the wrapping protection. When the destination 1126 node receives the RPS request it MUST perform the switch from/to 1127 the working ring tunnels to/from the protection ring tunnels if it 1128 has no higher priority active RPS request. 1130 o In rings utilizing the short wrapping protection. Only the node 1131 which is directly upstream to the failure on the working ring 1132 tunnel perform the switch from the working ring tunnels to the 1133 protection ring tunnels. This may be triggered by local failure 1134 detection or the received RPS request. 1136 o In rings utilizing the steering protection. When a ring switch is 1137 required, any node MUST perform the switches if its added/dropped 1138 traffic is affected by the failure. Determination of the affected 1139 traffic SHOULD be performed by examining the RPS requests 1140 (indicating the nodes adjacent to the failure or failures) and the 1141 stored ring maps (indicating the relative position of the failure 1142 and the added traffic destined towards that failure). 1144 When the failure has cleared and the Wait-to-Restore (WTR) timer has 1145 expired, the nodes sourcing RPS requests MUST drop their respective 1146 switches (tail end) and MUST source an RPS request carrying the NR 1147 code. The node receiving from both directions such RPS request (head 1148 end) MUST drop its protection switches. 1150 A protection switch MUST be initiated by one of the criteria 1151 specified in Section 5.2. A failure of the RPS protocol or 1152 controller MUST NOT trigger a protection switch. 1154 Ring switches MUST be preempted by higher priority RPS requests. For 1155 example, consider a protection switch that is active due to a manual 1156 switch request on the given span, and another protection switch is 1157 required due to a failure on another span. Then an RPS request MUST 1158 be generated, the former protection switch MUST be dropped, and the 1159 latter protection switch established. 1161 MSRP mechanism SHOULD support multiple protection switches in the 1162 ring, resulting the ring being segmented into two or more separate 1163 segments. This may happen when several RPS requests of the same 1164 priority exist in the ring due to multiple failures or external 1165 switch commands. 1167 Proper operation of the MSRP mechanism relies on all nodes having 1168 knowledge of the state of the ring (nodes and spans) so that nodes do 1169 not preempt existing RPS request unless they have a higher-priority 1170 RPS request. In order to accommodate ring state knowledge, during a 1171 protection switch the RPS requests MUST be sent in both directions. 1173 5.1.1. Transmission and Acceptance of RPS Requests 1175 A new RPS request MUST be transmitted immediately when a change in 1176 the transmitted status occurs. 1178 The first three RPS protocol messages carrying new RPS request SHOULD 1179 be transmitted as fast as possible. For fast protection switching 1180 within 50 ms, the interval of the first three RPS protocol messages 1181 SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted 1182 with the interval of 5 seconds. 1184 5.1.2. RPS PDU Format 1186 Figure 17 depicts the format of an RPS packet that is sent on the 1187 G-ACh. The Channel Type field is set to indicate that the message is 1188 an RPS message. The ACH MUST NOT include the ACH TLV Header 1189 [RFC5586] meaning that no ACH TLVs can be included in the message. 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Dest Node ID | Src Node ID | Request | Reserved | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 16. G-ACh RPS Packet Format 1200 The following fields MUST be provided: 1202 o Destination Node ID: The destination node ID MUST always be set to 1203 value of the node ID of the adjacent node. The Node ID MUST be 1204 unique on each ring. Valid destination node ID values are 1-127. 1206 o Source node ID: The source node ID MUST always be set to the ID 1207 value of the node generating the RPS request. The Node ID MUST be 1208 unique on each ring. Valid source node ID values are 1-127. 1210 o RPS request code: A code consisting of eight bits as specified 1211 below: 1213 +------------------+-----------------------------+----------+ 1214 | Bits | Condition, State | Priority | 1215 | (MSB - LSB) | or external Request | | 1216 +------------------+-----------------------------+----------+ 1217 | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | 1218 | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | 1219 | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | 1220 | 0 0 0 0 0 1 1 0 | Manual Switch (MS) | | 1221 | 0 0 0 0 0 1 0 1 | Wait-To-Restore (WTR) | | 1222 | 0 0 0 0 0 0 1 1 | Exercise (EXER) | | 1223 | 0 0 0 0 0 0 0 1 | Reverse Request (RR) | | 1224 | 0 0 0 0 0 0 0 0 | No Request (NR) | lowest | 1225 +------------------+-----------------------------+----------+ 1227 5.1.3. Ring Node RPS States 1229 Idle state: A node is in the idle state when it has no RPS request 1230 and is sourcing and receiving NR code to/from both directions. 1232 Switching state: A node not in the idle or pass-through states is in 1233 the switching state. 1235 Pass-through state: A node is in the pass-through state when its 1236 highest priority RPS request is a request not destined to it or 1237 sourced by it. The pass-through is bidirectional. 1239 5.1.3.1. Idle State 1241 A node in the idle state MUST source the NR request in both 1242 directions. 1244 A node in the idle state MUST terminate RPS requests flow in both 1245 directions. 1247 A node in the idle state MUST block the traffic flow on protection 1248 ring tunnels in both directions. 1250 5.1.3.2. Switching State 1252 A node in the switching state MUST source RPS request to adjacent 1253 node with its highest RPS request code in both directions when it 1254 detects a failure or receives an external command. 1256 A node in the switching state MUST terminate RPS requests flow in 1257 both directions. 1259 As soon as it receives an RPS request from the short path, the node 1260 to which it is addressed MUST acknowledge the RPS request by replying 1261 with the RR code on the short path, and with the received RPS request 1262 code on the long path. Here the short path refers to the shorter 1263 span on the ring between the source and destination node of the RPS 1264 request, and the long path refers to the longer span on the ring 1265 between the source and destination node of the RPS request. 1267 This rule refers to the unidirectional failure detection: the RR 1268 SHOULD be issued only when the node does not detect the failure 1269 condition (i.e., the node is a head end), that is, it is not 1270 applicable when a bidirectional failure is detected, because, in this 1271 case, both nodes adjacent to the failure will send an RPS request for 1272 the failure on both paths (short and long). 1274 The following switches MUST be allowed to coexist: 1276 o LP and LP 1278 o FS and FS 1280 o SF and SF 1282 o FS and SF 1284 When multiple MS RPS requests over different spans exist at the same 1285 time, no switch SHOULD be executed and existing switches MUST be 1286 dropped. The nodes MUST signal, anyway, the MS RPS request code. 1288 Multiple EXER requests MUST be allowed to coexist in the ring. 1290 A node in a ring switching state that receives the external command 1291 LP for the affected span MUST drop its switch and MUST signal NR for 1292 the locked span if there is no other RPS request on another span. 1293 Node still SHOULD signal relevant RPS request for another span. 1295 5.1.3.3. Pass-through State 1297 When a node is in a pass-through state, it MUST transfer the received 1298 RPS Request in the same direction. 1300 When a node is in a pass-through state, it MUST enable the traffic 1301 flow on protection ring tunnels in both directions. 1303 5.1.4. RPS State Transitions 1305 All state transitions are triggered by an incoming RPS request 1306 change, a WTR expiration, an externally initiated command, or locally 1307 detected MPLS-TP section failure conditions. 1309 RPS requests due to a locally detected failure, an externally 1310 initiated command, or received RPS request shall pre-empt existing 1311 RPS requests in the prioritized order given in Section 5.1.2, unless 1312 the requests are allowed to coexist. 1314 5.1.4.1. Transitions Between Idle and Pass-through States 1316 The transition from the idle state to pass-through state MUST be 1317 triggered by a valid RPS request change, in any direction, from the 1318 NR code to any other code, as long as the new request is not destined 1319 to the node itself. Both directions move then into a pass-through 1320 state, so that, traffic entering the node through the protection Ring 1321 tunnels are transferred transparently through the node. 1323 A node MUST revert from pass-through state to the idle state when it 1324 detects NR codes incoming from both directions. Both directions 1325 revert simultaneously from the pass-through state to the idle state. 1327 5.1.4.2. Transitions Between Idle and Switching States 1329 Transition of a node from the idle state to the switching state MUST 1330 be triggered by one of the following conditions: 1332 o A valid RPS request change from the NR code to any code received 1333 on either the long or the short path and destined to this node 1335 o An externally initiated command for this node 1337 o The detection of an MPLS-TP section layer failure at this node 1339 Actions taken at a node in the idle state upon transition to 1340 switching state are: 1342 o For all protection switch requests, except EXER and LP, the node 1343 MUST execute the switch 1345 o For EXER, and LP, the node MUST signal appropriate request but not 1346 execute the switch 1348 A node MUST revert from the switching state to the idle state when it 1349 detects NR codes received from both directions. 1351 o At the tail end: When a WTR time expires or an externally 1352 initiated command is cleared at a node, the node MUST drop its 1353 switch, transit to the Idle State and signal the NR code in both 1354 directions. 1356 o At the head end: Upon reception of the NR code, from both 1357 directions, the head-end node MUST drop its switch, transition to 1358 Idle State and signal the NR code in both directions. 1360 5.1.4.3. Transitions Between Switching States 1362 When a node that is currently executing any protection switch 1363 receives a higher priority RPS request (due to a locally detected 1364 failure, an externally initiated command, or a ring protection switch 1365 request destined to it) for the same span, it MUST update the 1366 priority of the switch it is executing to the priority of the 1367 received RPS request. 1369 When a failure condition clears at a node, the node MUST enter WTR 1370 condition and remain in it for the appropriate time-out interval, 1371 unless: 1373 o A different RPS request with a higher priority than WTR is 1374 received 1376 o Another failure is detected 1378 o An externally initiated command becomes active 1380 The node MUST send out a WTR code on both the long and short paths. 1382 When a node that is executing a switch in response to incoming SF RPS 1383 request (not due to a locally detected failure) receives a WTR code 1384 (unidirectional failure case), it MUST send out RR code on the short 1385 path and the WTR on the long path. 1387 5.1.4.4. Transitions Between Switching and Pass-through States 1389 When a node that is currently executing a switch receives an RPS 1390 request for a non-adjacent span of higher priority than the switch it 1391 is executing, it MUST drop its switch immediately and enter the pass- 1392 through state. 1394 The transition of a node from pass-through to switching state MUST be 1395 triggered by: 1397 o An equal priority, a higher priority, or an allowed coexisting 1398 externally initiated command 1400 o The detection of an equal priority, a higher priority, or an 1401 allowed coexisting automatic initiated command 1403 o The receipt of an equal, a higher priority, or an allowed 1404 coexisting RPS request destined to this node 1406 5.2. RPS State Machine 1408 5.2.1. Switch Initiation Criteria 1410 5.2.1.1. Administrative Commands 1412 Administrative commands can be initiated by the network operator 1413 through the Network Management System (NMS). The operator command 1414 may be transmitted to the appropriate node via the MPLS-TP RPS 1415 message. 1417 The following commands can be transferred by the RPS message: 1419 o Lockout of Protection (LP): This command prevents any protection 1420 activity and prevents using ring switches anywhere in the ring. 1421 If any ring switches exist in the ring, this command causes the 1422 switches to drop. 1424 o Forced Switch to protection (FS): This command performs the ring 1425 switch of normal traffic from the working entity to the protection 1426 entity for the span between the node at which the command is 1427 initiated and the adjacent node to which the command is directed. 1428 This switch occurs regardless of the state of the MPLS-TP section 1429 for the requested span, unless a higher priority switch request 1430 exists. 1432 o Manual Switch to protection (MS): This command performs the ring 1433 switch of the normal traffic from the working entity to the 1434 protection entity for the span between the node at which the 1435 command is initiated and the adjacent node to which the command is 1436 directed. This occurs if the MPLS-TP section for the requested 1437 span is not satisfying an equal or higher priority switch request. 1439 o Exercise - Ring (EXER): This command exercises ring protection 1440 switching on the addressed span without completing the actual 1441 switch. The command is issued and the responses (RR) are checked, 1442 but no normal traffic is affected. 1444 The following commands are not transferred by the RPS message: 1446 o Clear: This command clears the administrative command and Wait-To- 1447 Restore timer (WTR) at the node to which the command was 1448 addressed. The node-to-node signaling after the removal of the 1449 externally initiated commands is performed using the no-request 1450 code (NR). 1452 o Lockout of Working: This command prevents the normal traffic 1453 transported over the addressed span from being switched to the 1454 protection entity by disabling the node's capability of requesting 1455 switch for this span in case of failure. If any normal traffic is 1456 already switched on the protection entity, the switch is dropped. 1457 If no other switch requests are active on the ring, the no-request 1458 code (NR) is transmitted. This command has no impact on any other 1459 span. If the node receives the switch request from the adjacent 1460 node from any side it will perform the requested switch. If the 1461 node receives the switch request addressed to the other node, it 1462 will enter the pass-through state. 1464 5.2.1.2. Automatically Initiated Commands 1466 Automatically initiated commands can be initiated based on MPLS-TP 1467 section layer OAM indication and the received switch requests. 1469 The node can initiate the following switch requests automatically: 1471 o Signal Fail (SF): This command is issued when the MPLS-TP section 1472 layer OAM detects signal failure condition. 1474 o Wait-To-Restore (WTR): This command is issued when MPLS-TP section 1475 detects that the SF condition has cleared. It is used to maintain 1476 the state during the WTR period unless it is pre-empted by a 1477 higher priority switch request. The WTR time may be configured by 1478 the operator in 1 minute steps between 0 and 12 minutes; the 1479 default value is 5 minutes. 1481 o Reverse Request (RR): This command is transmitted to the source 1482 node of the received RPS message over the short path as an 1483 acknowledgment for receiving the switch request. 1485 5.2.2. Initial States 1487 +-----------------------------------+----------------+ 1488 | State | Signaled RPS | 1489 +-----------------------------------+----------------+ 1490 | A | Idle | NR | 1491 | | Working: no switch | | 1492 | | Protection: no switch | | 1493 +-----+-----------------------------+----------------+ 1494 | B | Pass-trough | N/A | 1495 | | Working: no switch | | 1496 | | Protection: pass through | | 1497 +-----+-----------------------------+----------------+ 1498 | C | Switching - LP | LP | 1499 | | Working: no switch | | 1500 | | Protection: no switch | | 1501 +-----+-----------------------------+----------------+ 1502 | D | Idle - LW | NR | 1503 | | Working: no switch | | 1504 | | Protection: no switch | | 1505 +-----+-----------------------------+----------------+ 1506 | E | Switching - FS | FS | 1507 | | Working: switched | | 1508 | | Protection: switched | | 1509 +-----+-----------------------------+----------------+ 1510 | F | Switching - SF | SF | 1511 | | Working: switched | | 1512 | | Protection: switched | | 1513 +-----+-----------------------------+----------------+ 1514 | G | Switching - MS | MS | 1515 | | Working: switched | | 1516 | | Protection: switched | | 1517 +-----+-----------------------------+----------------+ 1518 | H | Switching - WTR | WTR | 1519 | | Working: switched | | 1520 | | Protection: switched | | 1521 +-----+-----------------------------+----------------+ 1522 | I | Switching - EXER | EXER | 1523 | | Working: no switch | | 1524 | | Protection: no switch | | 1525 +-----+-----------------------------+----------------+ 1527 5.2.3. State transitions When Local Request is Applied 1529 In the state description below 'O' means that new local request will 1530 be rejected because of exiting request. 1532 ===================================================================== 1533 Initial state New request New state 1534 ------------- ----------- --------- 1535 A (Idle) LP C (Switching - LP) 1536 LW D (Idle - LW) 1537 FS E (Switching - FS) 1538 SF F (Switching - SF) 1539 Recover from SF N/A 1540 MS G (Switching - MS) 1541 Clear N/A 1542 WTR expires N/A 1543 EXER I (Switching - EXER) 1544 ===================================================================== 1545 Initial state New request New state 1546 ------------- ----------- --------- 1547 B (Pass-trough) LP C (Switching - LP) 1548 LW B (Pass-trough) 1549 FS O - if current state is due to 1550 LP sent by another node 1551 E (Switching - FS) - otherwise 1552 SF O - if current state is due to 1553 LP sent by another node 1554 F (Switching - SF) - otherwise 1555 Recover from SF N/A 1556 MS O - if current state is due to 1557 LP, SF or FS sent by 1558 another node 1559 G (Switching - MS) - otherwise 1560 Clear N/A 1561 WTR expires N/A 1562 EXER O 1563 ===================================================================== 1564 Initial state New request New state 1565 ------------- ----------- --------- 1566 C (Switching - LP) LP N/A 1567 LW O 1568 FS O 1569 SF O 1570 Recover from SF N/A 1571 MS O 1572 Clear A (Idle) - if there is no 1573 failure in the ring 1574 F (Switching - SF) - if there 1575 is a failure at this node 1576 B (Pass-trough) - if there is 1577 a failure at another node 1578 WTR expires N/A 1579 EXER O 1580 ===================================================================== 1581 Initial state New request New state 1582 ------------- ----------- --------- 1583 D (Idle - LW) LP C (Switching - LP) 1584 LW N/A - if on the same span 1585 D (Idle - LW) - if on another 1586 span 1587 FS O - if on the same span 1588 E (Switching - FS) - if on 1589 another span 1590 SF O - if on the addressed span 1591 F (Switching - SF) - if on 1592 another span 1593 Recover from SF N/A 1594 MS O - if on the same span 1595 G (Switching - MS) - if on 1596 another span 1597 Clear A (Idle) - if there is no 1598 failure on addressed span 1599 F (Switching - SF) - if there 1600 is a failure on this span 1601 WTR expires N/A 1602 EXER O 1603 ===================================================================== 1604 Initial state New request New state 1605 ------------- ----------- --------- 1606 E (Switching - FS) LP C (Switching - LP) 1607 LW O - if on another span 1608 D (Idle - LW) - if on the same 1609 span 1610 FS N/A - if on the same span 1611 E (Switching - FS) - if on 1612 another span 1613 SF O - if on the addressed span 1614 E (Switching - FS) - if on 1615 another span 1616 Recover from SF N/A 1617 MS O 1618 Clear A (Idle) - if there is no 1619 failure in the ring 1620 F (Switching - SF) - if there 1621 is a failure at this node 1622 B (Pass-trough) - if there is 1623 a failure at another node 1624 WTR expires N/A 1625 EXER O 1626 ===================================================================== 1627 Initial state New request New state 1628 ------------- ----------- --------- 1629 F (Switching - SF) LP C (Switching - LP) 1630 LW O - if on another span 1632 D (Idle - LW) - if on the same 1633 span 1634 FS E (Switching - FS) 1635 SF N/A - if on the same span 1636 F (Switching - SF) - if on 1637 another span 1638 Recover from SF H (Switching - WTR) 1639 MS O 1640 Clear N/A 1641 WTR expires N/A 1642 EXER O 1643 ===================================================================== 1644 Initial state New request New state 1645 ------------- ----------- --------- 1646 G (Switching - MS) LP C (Switching - LP) 1647 LW O - if on another span 1648 D (Idle - LW) - if on the same 1649 span 1650 FS E (Switching - FS) 1651 SF F (Switching - SF) 1652 Recover from SF N/A 1653 MS N/A - if on the same span 1654 G (Switching - MS) - if on 1655 another span release the 1656 switches but signal MS 1657 Clear A 1658 WTR expires N/A 1659 EXER O 1660 ===================================================================== 1661 Initial state New request New state 1662 ------------- ----------- --------- 1663 H (Switching - WTR) LP C (Switching - LP) 1664 LW D (Idle - W) 1665 FS E (Switching - FS) 1666 SF F (Switching - SF) 1667 Recover from SF N/A 1668 MS G (Switching - MS) 1669 Clear A 1670 WTR expires A 1671 EXER O 1672 ===================================================================== 1673 Initial state New request New state 1674 ------------- ----------- --------- 1675 I (Switching - EXER) LP C (Switching - LP) 1676 LW D (idle - W) 1677 FS E (Switching - FS) 1678 SF F (Switching - SF) 1679 Recover from SF N/A 1680 MS G (Switching - MS) 1681 Clear A 1682 WTR expires N/A 1683 EXER N/A - if on the same span 1684 I (Switching - EXER) 1685 ===================================================================== 1687 5.2.4. State Transitions When Remote Request is Applied 1689 The priority of a remote request does not depend on the side from 1690 which the request is received. 1692 ===================================================================== 1693 Initial state New request New state 1694 ------------- ----------- --------- 1695 A (Idle) LP C (Switching - LP) 1696 FS E (Switching - FS) 1697 SF F (Switching - SF) 1698 MS G (Switching - MS) 1699 WTR N/A 1700 EXER I (Switching - EXER) 1701 RR N/A 1702 NR A (Idle) 1703 ===================================================================== 1704 Initial state New request New state 1705 ------------- ----------- --------- 1706 B (Pass-trough) LP C (Switching - LP) 1707 FS N/A - cannot happen when there 1708 is LP request in the ring 1709 E (Switching - FS) - otherwise 1710 SF N/A - cannot happen when there 1711 is LP request in the ring 1712 F (Switching - SF) - otherwise 1713 MS N/A - cannot happen when there 1714 is LP, FS or SF request 1715 in the ring 1716 G (Switching - MS) - otherwise 1717 WTR N/A - cannot happen when there 1718 is LP, FS, SF or MS 1719 request in the ring 1720 EXER N/A - cannot happen when there 1721 is LP, FS, SF, MS or WTR 1722 request in the ring 1723 I (Switching - EXER) - 1724 otherwise 1725 RR N/A 1726 NR A (Idle) - if received from 1727 both sides 1728 ===================================================================== 1729 Initial state New request New state 1730 ------------- ----------- --------- 1731 C (Switching - LP) LP C (Switching - LP) 1732 FS N/A - cannot happen when there 1733 is LP request in the ring 1734 SF N/A - cannot happen when there 1735 is LP request in the ring 1736 MS N/A - cannot happen when there 1737 is LP request in the ring 1738 WTR N/A 1739 EXER N/A - cannot happen when there 1740 is LP request in the ring 1741 RR C (Switching - LP) 1742 NR N/A 1743 ===================================================================== 1744 Initial state New request New state 1745 ------------- ----------- --------- 1746 D (Idle - LW) LP C (Switching - LP) 1747 FS E (Switching - FS) 1748 SF F (Switching - SF) 1749 MS G (Switching - MS) 1750 WTR N/A 1751 EXER I (Switching - EXER) 1752 RR N/A 1753 NR D (Idle - LW) 1754 ===================================================================== 1755 Initial state New request New state 1756 ------------- ----------- --------- 1757 E (Switching - FS) LP C (Switching - LP) 1758 FS E (Switching - FS) 1759 SF E (Switching - FS) 1760 MS N/A - cannot happen when there 1761 is FS request in the ring 1762 WTR N/A 1763 EXER N/A - cannot happen when there 1764 is FS request in the ring 1765 RR E (Switching - FS) 1766 NR N/A 1767 ===================================================================== 1768 Initial state New request New state 1769 ------------- ----------- --------- 1770 F (Switching - SF) LP C (Switching - LP) 1771 FS F (Switching - SF) 1772 SF F (Switching - SF) 1773 MS N/A - cannot happen when there 1774 is SF request in the ring 1775 WTR N/A 1776 EXER N/A - cannot happen when there 1777 is SF request in the ring 1778 RR F (Switching - SF) 1779 NR N/A 1780 ===================================================================== 1781 Initial state New request New state 1782 ------------- ----------- --------- 1783 G (Switching - MS) LP C (Switching - LP) 1784 FS E (Switching - FS) 1785 SF F (Switching - SF) 1786 MS G (Switching - MS) - release 1787 the switches but signal MS 1788 WTR N/A 1789 EXER N/A - cannot happen when there 1790 is MS request in the ring 1791 RR G (Switching - MS) 1792 NR N/A 1793 ===================================================================== 1794 Initial state New request New state 1795 ------------- ----------- --------- 1796 H (Switching - WTR) LP C (Switching - LP) 1797 FS E (Switching - FS) 1798 SF F (Switching - SF) 1799 MS G (Switching - MS) 1800 WTR H (Switching - WTR) 1801 EXER N/A - cannot happen when there 1802 is WTR request in the ring 1803 RR H (Switching - WTR) 1804 NR N/A 1805 ===================================================================== 1806 Initial state New request New state 1807 ------------- ----------- --------- 1808 I (Switching - EXER) LP C (Switching - LP) 1809 FS E (Switching - FS) 1810 SF F (Switching - SF) 1811 MS G (Switching - MS) 1812 WTR N/A 1813 EXER I (Switching - EXER) 1814 RR I (Switching - EXER) 1815 NR N/A 1816 ===================================================================== 1818 5.2.5. State Transitions When Request Addresses to Another Node is 1819 Received 1821 The priority of a remote request does not depend on the side from 1822 which the request is received. 1824 ===================================================================== 1825 Initial state New request New state 1826 ------------- ----------- --------- 1827 A (Idle) LP B (Pass-trough) 1828 FS B (Pass-trough) 1829 SF B (Pass-trough) 1830 MS B (Pass-trough) 1831 WTR B (Pass-trough) 1832 EXER B (Pass-trough) 1833 RR N/A 1834 NR N/A 1835 ===================================================================== 1836 Initial state New request New state 1837 ------------- ----------- --------- 1838 B (Pass-trough) LP B (Pass-trough) 1839 FS N/A - cannot happen when there 1840 is LP request in the ring 1841 B (Pass-trough) - otherwise 1842 SF N/A - cannot happen when there 1843 is LP request in the ring 1844 B (Pass-trough) - otherwise 1845 MS N/A - cannot happen when there 1846 is LP, FS or SF request 1847 in the ring 1848 B (Pass-trough) - otherwise 1849 WTR N/A - cannot happen when there 1850 is LP, FS, SF or MS 1851 request in the ring 1852 B (Pass-trough) - otherwise 1853 EXER N/A - cannot happen when there 1854 is LP, FS, SF, MS or WTR 1855 request in the ring 1856 B (Pass-trough) - otherwise 1857 RR N/A 1858 NR B (Pass-trough) 1859 ===================================================================== 1860 Initial state New request New state 1861 ------------- ----------- --------- 1862 C (Switching - LP) LP C (Switching - LP) 1863 FS N/A - cannot happen when there 1864 is LP request in the ring 1865 SF N/A - cannot happen when there 1866 is LP request in the ring 1867 MS N/A - cannot happen when there 1868 is LP request in the ring 1869 WTR N/A - cannot happen when there 1870 is LP in the ring 1871 EXER N/A - cannot happen when there 1872 is LP request in the ring 1873 RR N/A 1874 NR N/A 1875 ===================================================================== 1876 Initial state New request New state 1877 ------------- ----------- --------- 1878 D (Idle - LW) LP B (Pass-trough) 1879 FS B (Pass-trough) 1880 SF B (Pass-trough) 1881 MS B (Pass-trough) 1882 WTR B (Pass-trough) 1883 EXER B (Pass-trough) 1884 RR N/A 1885 NR N/A 1886 ===================================================================== 1887 Initial state New request New state 1888 ------------- ----------- --------- 1889 E (Switching - FS) LP B (Pass-trough) 1890 FS E (Switching - FS) 1891 SF E (Switching - FS) 1892 MS N/A - cannot happen when there 1893 is FS request in the ring 1894 WTR N/A - cannot happen when there 1895 is FS request in the ring 1896 EXER N/A - cannot happen when there 1897 is FS request in the ring 1898 RR N/A 1899 NR N/A 1900 ===================================================================== 1901 Initial state New request New state 1902 ------------- ----------- --------- 1903 F (Switching - SF) LP B (Pass-trough) 1904 FS F (Switching - SF) 1905 SF F (Switching - SF) 1906 MS N/A - cannot happen when there 1907 is SF request in the ring 1908 WTR N/A - cannot happen when there 1909 is SF request in the ring 1910 EXER N/A - cannot happen when there 1911 is SF request in the ring 1912 RR N/A 1913 NR N/A 1914 ===================================================================== 1915 Initial state New request New state 1916 ------------- ----------- --------- 1917 G (Switching - MS) LP B (Pass-trough) 1918 FS B (Pass-trough) 1919 SF B (Pass-trough) 1920 MS G (Switching - MS) - release 1921 the switches but signal MS 1922 WTR N/A - cannot happen when there 1923 is MS request in the ring 1924 EXER N/A - cannot happen when there 1925 is MS request in the ring 1926 RR N/A 1927 NR N/A 1928 ===================================================================== 1929 Initial state New request New state 1930 ------------- ----------- --------- 1931 H (Switching - WTR) LP B (Pass-trough) 1932 FS B (Pass-trough) 1933 SF B (Pass-trough) 1934 MS B (Pass-trough) 1935 WTR N/A 1936 EXER N/A - cannot happen when there 1937 is WTR request in the ring 1938 RR N/A 1939 NR N/A 1940 ===================================================================== 1941 Initial state New request New state 1942 I (Switching - EXER) LP B (Pass-trough) 1943 FS B (Pass-trough) 1944 SF B (Pass-trough) 1945 MS B (Pass-trough) 1946 WTR N/A 1947 EXER I (Switching - EXER) 1948 RR N/A 1949 NR N/A 1950 ===================================================================== 1952 5.3. RPS and PSC Comparison on Ring Topology 1954 This section provides comparison between RPS and PSC [RFC6378] 1955 [RFC6974] on ring topologies. This can be helpful to explain the 1956 reason of defining a new protocol for ring protection switching. 1958 The PSC protocol [RFC6378] is designed for point-to-point LSPs, on 1959 which the protection switching can only be performed on one or both 1960 of the end points of the LSP. While RPS is designed for ring 1961 tunnels, which consist of multiple ring nodes, and the failure could 1962 happen on any segment of the ring, thus RPS SHOULD be capable of 1963 identifying and handling the different failures on the ring, and 1964 coordinating the protection switching behavior of all the nodes on 1965 the ring. As specified in section 5, this is achieved with the 1966 introduction of the "Pass-Through" state for the ring nodes, and the 1967 location of the protection request is identified via the Node IDs in 1968 the RPS Request message. 1970 Taking a ring topology with N nodes as example: 1972 With the mechanism specified in [RFC6974], on every ring-node, a 1973 linear protection configuration has to be provisioned with every 1974 other node in the ring, i.e. with (N-1) other nodes. This means that 1975 on every ring node there will be (N-1) instances of the PSC protocol. 1976 And in order to detect faults and to transport the PSC message, each 1977 instance shall have a MEP on the working path and a MEP on the 1978 protection path respectively. This means that every node on the ring 1979 needs to be configured with (N-1) * 2 MEPs. 1981 With the mechanism defined in this document, on every ring node there 1982 will only be a single instance of the RPS protocol. In order to 1983 detect faults and to transport the RPS message, each node only needs 1984 to have a MEP on the section to its adjacent nodes respectively. In 1985 this way, every ring-node only needs to be configured with 2 MEPs. 1987 As shown in the above example, RPS is designed for ring topologies 1988 and can achieve ring protection efficiently with minimum protection 1989 instances and OAM entities, which meets the requirements on topology 1990 specific recovery mechanisms as specified in [RFC5654]. 1992 6. IANA Considerations 1994 IANA is requested to administer the assignment of new values defined 1995 in this document and summarized in this section. 1997 6.1. G-ACh Channel Type 1999 The Channel Types for the Generic Associated Channel (GACH) are 2000 allocated from the IANA PW Associated Channel Type registry defined 2001 in [RFC4446] and updated by [RFC5586]. 2003 IANA is requested to allocate a new GACH Channel Type as follows: 2005 Value| Description | Reference 2006 ------+---------------------------+-------------- 2007 TBD | Ring Protection Switching |this document 2008 | Protocol (RPS) | 2009 ------+---------------------------+-------------- 2011 6.2. RSP Request Codes 2013 IANA is requested to create a new sub-registry under the 2014 "Multiprotocol Label Switching (MPLS) Operations, Administration, and 2015 Management (OAM) Parameters" registry called the "MPLS RPS Request 2016 Code Registry". All code points within this registry shall be 2017 allocated according to the "Standards Action" procedure as specified 2018 in [RFC5226]. 2020 The RPS Request Field is 8 bits, the allocated values are as follows: 2022 Value Description Reference 2023 ------- --------------------------- --------------- 2024 0 No Request (NR) this document 2025 1 Reverse Request (RR) this document 2026 2 not assigned 2027 3 Exercise (EXER) this document 2028 4 not assigned 2029 5 Wait-To-Restore (WTR) this document 2030 6 Manual Switch (MS) this document 2031 7-10 not assigned 2032 11 Signal Fail (SF) this document 2033 12 not assigned 2034 13 Forced Switch (FS) this document 2035 14 not assigned 2036 15 Lockout of Protection (LP) this document 2037 16-255 not assigned 2039 7. Security Considerations 2041 The RPS protocol defined in this document is carried in the G-ACh 2042 [RFC5586], which is a generalization of the Associated Channel 2043 defined in [RFC4385]. The security considerations specified in these 2044 documents apply to the proposed RPS mechanism. 2046 8. Contributing Authors 2048 Wen Ye, Minxue Wang, Sheng Liu (China Mobile) 2050 Guanghui Sun (Huawei) 2052 9. Acknowledgements 2054 The authors would like to thank Gregory Mirsky, Yimin Shen, Eric 2055 Osborne and Spencer Jackson for their valuable comments and 2056 suggestions. 2058 10. References 2060 10.1. Normative References 2062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2063 Requirement Levels", BCP 14, RFC 2119, 2064 DOI 10.17487/RFC2119, March 1997, 2065 . 2067 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2068 Label Switching Architecture", RFC 3031, 2069 DOI 10.17487/RFC3031, January 2001, 2070 . 2072 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 2073 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 2074 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 2075 February 2006, . 2077 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 2078 Emulation (PWE3)", BCP 116, RFC 4446, 2079 DOI 10.17487/RFC4446, April 2006, 2080 . 2082 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 2083 "MPLS Generic Associated Channel", RFC 5586, 2084 DOI 10.17487/RFC5586, June 2009, 2085 . 2087 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 2088 Sprecher, N., and S. Ueno, "Requirements of an MPLS 2089 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 2090 September 2009, . 2092 10.2. Informative References 2094 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2095 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2096 DOI 10.17487/RFC5226, May 2008, 2097 . 2099 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2100 Administration, and Maintenance Framework for MPLS-Based 2101 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2102 September 2011, . 2104 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 2105 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 2106 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 2107 October 2011, . 2109 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 2110 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 2111 "Applicability of MPLS Transport Profile for Ring 2112 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 2113 . 2115 Authors' Addresses 2117 Weiqiang Cheng 2118 China Mobile 2120 Email: chengweiqiang@chinamobile.com 2122 Lei Wang 2123 China Mobile 2125 Email: wangleiyj@chinamobile.com 2127 Han Li 2128 China Mobile 2130 Email: lihan@chinamobile.com 2132 Huub van Helvoort 2133 Hai Gaoming BV 2135 Email: huubatwork@gmail.com 2136 Kai Liu 2137 Huawei Technologies 2139 Email: alex.liukai@huawei.com 2141 Jie Dong 2142 Huawei Technologies 2144 Email: jie.dong@huawei.com 2146 Jia He 2147 Huawei Technologies 2149 Email: hejia@huawei.com 2151 Fang Li 2152 China Academy of Telecommunication Research, MIIT., China 2154 Email: lifang@ritt.cn 2156 Jian Yang 2157 ZTE Corporation P.R.China 2159 Email: yang.jian90@zte.com.cn 2161 Junfang Wang 2162 Fiberhome Telecommunication Technologies Co., LTD. 2164 Email: wjf@fiberhome.com.cn