idnits 2.17.1 draft-ietf-mpls-tp-shared-ring-protection-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 477 has weird spacing: '...l links xxx...' == Line 584 has weird spacing: '...l links xxx...' == Line 930 has weird spacing: '...aaaaaaa a/c...' == Line 1899 has weird spacing: '...itching this...' -- The document date (October 10, 2015) is 3120 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 716, but not defined == Missing Reference: 'LSP2' is mentioned on line 723, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6371 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 8 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: April 12, 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 October 10, 2015 20 MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology 21 draft-ietf-mpls-tp-shared-ring-protection-00 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 April 12, 2016. 56 Copyright Notice 58 Copyright (c) 2015 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 4 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 . . . . . . . . . . . . . . . . . . . . . . 10 87 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12 88 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14 89 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17 90 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17 91 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 18 92 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19 93 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21 94 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22 95 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23 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. Initial States . . . . . . . . . . . . . . . . . . . 31 103 5.2.2. State transitions When Local Request is Applied . . . 32 104 5.2.3. State Transitions When Remote Request is Applied . . 36 105 5.2.4. State Transitions When Request Addresses to Another 106 Node is Received . . . . . . . . . . . . . . . . . . 39 107 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 41 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 109 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 42 110 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 43 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 112 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 43 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 116 10.2. Informative References . . . . . . . . . . . . . . . . . 44 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 119 1. Introduction 121 As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP 122 requirements , several service providers have expressed much interest 123 in operating MPLS-TP in ring topologies and require a high-level 124 survivability function in these topologies. In operational transport 125 network deployment, MPLS-TP networks are often constructed with ring 126 topologies. It calls for an efficient and optimized ring protection 127 mechanism to achieve simple operation and fast, sub 50 ms, recovery 128 performance. 130 The requirements for MPLS-TP [RFC5654] state that recovery mechanisms 131 which are optimized for ring topologies could be further developed if 132 it can provide the following features: 134 a. Minimize the number of OAM entities for protection 136 b. Minimize the number of elements of recovery 138 c. Minimize the required label number 140 d. Minimize the amount of control and management-plane transactions 141 during maintenance operation 143 e. Minimize the impact on information exchange during protection if 144 a control plane is supported 146 This document specifies MPLS-TP Shared-Ring Protection mechanisms 147 that can meet all those requirements on ring protection listed in 148 [RFC5654]. 150 The basic concepts and architecture of Shared-Ring protection 151 mechanism are specified in this document. This document focuses on 152 the solutions for point-to-point transport paths. While the basic 153 concepts may also apply to point-to-multipoint transport paths, the 154 solution for point-to-multipoint transport paths is under study and 155 will be presented in a separate document. 157 2. Requirements for MPLS-TP Ring Protection 159 The requirements for MPLS-TP ring protection are specified in 160 [RFC5654]. This document elaborates on the requirements in detail. 162 2.1. Recovery of Multiple Failures 164 MPLS-TP is expected to be used in carrier grade metro networks and 165 backbone transport networks to provide mobile backhaul, business 166 services etc., in which the network survivability is very important. 167 According to R106 B in [RFC5654], MPLS-TP recovery mechanisms in a 168 ring SHOULD protect against multiple failures. The following text 169 provides some more detailed illustration about "multiple failures". 170 In metro and backbone networks, a single risk factor often affects 171 multiple links or nodes. Some examples of risk factors are given as 172 follows: 174 o multiple links use fibers in one cable or pipeline 176 o Several nodes share one power supply system 178 o Weather sensitive micro-wave system 180 Once one of the above risk factors happens, multiple links or nodes 181 failures may occur simultaneously and those failed links or nodes may 182 be located on a single ring as well as on interconnected rings. Ring 183 protection against multiple failures should cover both multiple 184 failures on a single ring and multiple failures on interconnected 185 rings, as long as the connectivity between the ingress and egress 186 node of the ring still exists. 188 2.2. Smooth Upgrade from Linear Protection to Ring Protection 190 It is beneficial for service providers to upgrade the protection 191 scheme from linear protection to ring protection in their MPLS-TP 192 network without service interruption. In-service insertion and 193 removal of a node on the ring should also be supported. Therefore, 194 the MPLS-TP ring protection mechanism is supposed to be developed and 195 optimized for compliance with this smooth upgrading principle. 197 2.3. Configuration Complexity 199 Ring protection can reduce the dependency of configuration on the 200 quantity of services, thus will simplify the network protection 201 configuration and operation effort. This is because the ring 202 protection makes use of the characteristics of ring topology and 203 mechanisms on the section layer. While in the application scenarios 204 of deploying linear protection in ring topology MPLS-TP network, the 205 configuration of protection has a close relationship with the 206 quantities of services carried. Especially in some large metro 207 networks with more than ten thousands of services in the access 208 nodes, the LSP linear protection capabilities of the metro core nodes 209 needs to be large enough to meet the network planning requirements, 210 which also leads to the complexity of network protection 211 configurations and operations. 213 3. Terminology and Notation 215 The following syntax will be used to describe the contents of the 216 label stack: 218 1. The label stack will be enclosed in square brackets ("[]"). 220 2. Each level in the stack will be separated by the '|' character. 221 It should be noted that the label stack may contain additional 222 layers. However, we only present the layers that are related to the 223 protection mechanism. 225 3. If the Label is assigned by Node X, the Node Name is enclosed in 226 bracket ("()") 228 4. Shared Ring Protection Architecture 230 4.1. Ring Tunnel 232 This document introduces a new logical layer of the ring for shared 233 ring protection in MPLS-TP networks. As shown in Figure 1, the new 234 logical layer consists of ring tunnels which provides a server layer 235 for the LSPs traverse the ring. Once a ring tunnel is established, 236 the configuration, management and protection of the ring are all 237 performed at the ring tunnel level. One port can carry multiple ring 238 tunnels, while one ring tunnel can carry multiple LSPs. 240 +------------- 241 +-------------| 242 +-------------| | 243 =====PW1======| | | 244 | | Ring | Physical 245 =====PW2======| LSP | Tunnel | Port 246 | | | 247 =====PW3======| | | 248 +-------------| | 249 +-------------| 250 +------------- 251 Figure 1. The logical layers of the ring 253 The label stack used in MPLS-TP Shared Ring Protection mechanism is 254 shown as below: 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Ring tunnel Label | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | LSP Label | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | PW Label | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Payload | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2. Label stack used in MPLS-TP Shared Ring Protection 267 4.1.1. Establishment of Ring Tunnel 269 The Ring tunnels are established based on the egress node. The 270 egress node is the node where traffic leaves the ring. LSPs which 271 have the same egress node on the ring share the same ring tunnels. 272 In other words, all the LSPs that traverse the ring and exit from the 273 same node share the same working ring tunnel and protection ring 274 tunnel. For each egress node, four ring tunnels are established: 276 o one clockwise working ring tunnel, which is protected by the 277 anticlockwise protection ring tunnel 279 o one anticlockwise protection ring tunnel 281 o one anticlockwise working ring tunnel, which is protected by the 282 clockwise protection ring tunnel 284 o one clockwise protection ring tunnel 285 The structure of the protection tunnels are determined by the 286 selected protection mechanism. This will be detailed in subsequent 287 sections. 289 As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, 290 Node A and Node B, respectively, and all leave the ring at Node D. 291 To protect these LSPs that traverse the ring, a clockwise working 292 ring tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise 293 protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are 294 established, Also, an anti-clockwise working ring tunnel (RaW_D) via 295 C->B->A->F->E->D, and its clockwise protection ring tunnel (RcP_D) 296 via D->E->F->A->B->C->D are established. For simplicity Figure 3 297 only shows RcW_D and RaP_D. A similar provisioning should be applied 298 for any other node on the ring. In summary, for each node in 299 Figure 3 when acting as egress node, the ring tunnels are created as 300 follows: 302 o To Node A: RcW_A, RaW_A, RcP_A, RaP_A 304 o To Node B: RcW_B, RaW_B, RcP_B, RaP_B 306 o To Node C: RcW_C, RaW_C, RcP_C, RaP_C 308 o To Node D: RcW_D, RaW_D, RcP_D, RaP_D 310 o To Node E: RcW_E, RaW_E, RcP_E, RaP_E 312 o To Node F: RcW_F, RaW_F, RcP_F, RaP_F 313 +---+#############+---+ 314 | F |-------------| A | +-- LSP2 315 +---+*************+---+ 316 #/* *\# 317 #/* *\# 318 #/* *\# 319 +---+ +---+ 320 LSP1-+ | E | | B |+-- LSP3 321 +---+ +---+ 322 #\ */# 323 #\ */# 324 #\ */# 325 +---+*************+---+ 326 LSP1 +--| D |-------------| C | 327 LSP2 +---+#############+---+ 328 LSP3 330 ---- physical links 331 **** RcW_D 332 #### RaP_D 334 Figure 3. Ring tunnels in MSRP 336 Through these working and protection ring tunnels, LSPs which enter 337 the ring from any node can reach any egress nodes on the ring, and 338 are protected from failures on the ring. 340 4.1.2. Label Assignment and Distribution 342 The ring tunnel labels are downstream-assigned labels as defined in 343 [RFC3031]. The ring tunnel labels can be either configured 344 statically, provisioned by a controller, or distributed dynamically 345 via a control protocol. 347 4.1.3. Forwarding Operation 349 When an MPLS-TP transport path, such as an LSP, enters the ring, the 350 ingress node on the ring pushes the working ring tunnel label 351 according to the egress node and sends the traffic to the next hop. 352 The transit nodes on the working ring tunnel swap the ring tunnel 353 labels and forward the packets to the next hop. When the packet 354 arrives at the egress node, the egress node pops the ring tunnel 355 label and forwards the packets based on the inner LSP label and PW 356 label. Figure 4 shows the label operation in the MPLS-TP shared ring 357 protection mechanism. Assume that LSP1 enters the ring at Node A and 358 exits from Node D, and the following label operations are executed. 360 1. Ingress node: Packets of LSP1 arrive at Node A with a label stack 361 [LSP1] and is supposed to be forwarded in the clockwise direction 362 of the ring. The clockwise working ring tunnel label RcW_D will 363 be pushed at Node A, the label stack for the forwarded packet at 364 Node A is changed to [RcW_D(B)|LSP1]. 366 2. Transit nodes: In this case, Node B and Node C forward the 367 packets by swapping the working ring tunnel labels. For example, 368 the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node 369 B. 371 3. Egress node: When the packet arrives at Node D (i.e. the egress 372 node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and 373 subsequently deals with the inner labels of LSP1. 375 +---+#####[RaP_D(F)]######+---+ 376 | F |---------------------| A | +-- LSP1 377 +---+*****[RcW_D(A)]******+---+ 378 #/* *\# 379 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)] 380 #/* *\# 381 +---+ +---+ 382 | E | | B | 383 +---+ +---+ 384 #\ */# 385 [RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)] 386 #\ */# 387 +---+*****[RcW_D(D)]****+---+ 388 LSP1 +-- | D |-------------------| C | 389 +---+#####[RaP_D(C)]####+---+ 391 -----physical links ****** RcW_D ###### RaP_D 393 Figure 4. Label operation of MSRP 395 4.2. Failure Detection 397 The MPLS-TP section layer OAM is used to monitor the connectivity 398 between each two adjacent nodes on the ring using the mechanisms 399 defined in [RFC6371]. Protection switching is triggered by the 400 failure detected on the ring by the OAM mechanisms. 402 Two end ports of a link form a Maintenance Entity Group (MEG), and an 403 MEG end point (MEP) function is installed in each ring port. CC OAM 404 packets are periodically exchanged between each pair of MEPs to 405 monitor the link health. Three consecutive CC packets losses will be 406 interpreted as a link failure. 408 A node failure is regarded as the failure of two links attached to 409 that node. The two nodes adjacent to the failed node detect the 410 failure in the links that are connected to the failed node. 412 4.3. Ring Protection 414 This section specifies the ring protection mechanisms in detail. In 415 general, the description uses the clockwise working ring tunnel and 416 the corresponding anti-clockwise protection ring tunnel as example, 417 but the mechanism is applicable in the same way to the anti-clockwise 418 working and clockwise protection ring tunnels. 420 Taking the topology in Figure 4 as example, the LSP1 enters the ring 421 at Node A and leaves the ring at Node D. In normal state, LSP1 is 422 carried by clockwise working ring tunnel (RcW_D) through the path 423 A->B->C->D, the label operation is: 425 [LSP1](original data traffic carried by LSP1) -> 426 [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| 427 LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D 428 the packet will be forwarded based on label stack of LSP1. 430 The following sections describes the protection mechanisms used in 431 ring topology. 433 4.3.1. Wrapping 435 With the wrapping mechanism, the protection ring tunnel is a closed 436 ring identified by the egress node. As shown in Figure 4, the RaP_D 437 is the anticlockwise protection ring tunnel for the clockwise working 438 ring tunnel RcW_D. As specified in the following sections, the 439 closed ring protection tunnel can protect both the link failure and 440 the node failure. 442 4.3.1.1. Wrapping for Link Failure 444 When a link failure between Node B and Node C occurs, if it is a bi- 445 directional failure, both Node B and Node C can detect the failure 446 via OAM mechanism; if it is a uni-directional failure, one of the two 447 nodes would detect the failure and it would inform the other node via 448 the Ring Protection Switch Protocol (RPS) which is specified in 449 section 5. Then Node B switches the clockwise working ring tunnel 450 (RcW_D) to the anticlockwise protection ring tunnel (RaP_D) and Node 451 C switches anticlockwise protection ring tunnel(RaP_D) to the 452 clockwise working ring tunnel(RcW_D). The data traffic which enters 453 the ring at Node A and leaves the ring at Node D follows the path 454 A->B->A->F->E->D->C->D. The label operation is: 456 [LSP1](Original data traffic) -> [RcW_D(B)|LSP1](Node A) -> 457 [RaP_D(A)|LSP1](Node B) -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] 458 (Node F) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> 459 [RcW_D(D)|LSP1](Node C) -> [LSP1](data traffic leaves the ring). 461 +---+#####[RaP_D(F)]######+---+ 462 | F |---------------------| A | +-- LSP1 463 +---+*****[RcW_D(A)]******+---+ 464 #/* *\# 465 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 466 #/* *\# 467 +---+ +---+ 468 | E | | B | 469 +---+ +---+ 470 #\ *x# 471 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 472 #\ *x# 473 +---+*****[RcW_D(D)]****+---+ 474 LSP1 +-- | D |-------------------| C | 475 +---+#####[RaP_D(C)]####+---+ 477 -----physical links xxxx Failure Link 478 ****** RcW_D ###### RaP_D 480 Figure 5.Wrapping for link failure 482 4.3.1.2. Wrapping for Node Failure 484 As shown in Figure 6, when Node B fails, Node A detects the failure 485 between A and B and switches the clockwise work ring tunnel (RcW_D) 486 to the anticlockwise protection ring tunnel (RaP_D), Node C detects 487 the failure between C and B and switches the anticlockwise protection 488 ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). 489 The data traffic which enters the ring at Node A and exits at Node D 490 follows the path A->F->E->D->C->D. The label operation is: 492 [LSP1](original data traffic carried by LSP1) -> 493 [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 494 [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] 495 (NodeC) -> [LSP1](data traffic carried by LSP1). 497 In one special case where node D fails, all the ring tunnels with 498 node D as egress will become unusable. However, before the failure 499 location is propagated to all the ring nodes, the wrapping protection 500 mechanism may cause temporary traffic loop: node C detects the 501 failure and switches the traffic from the clockwise work ring tunnel 502 (RcW_D) to the anticlockwise protection ring tunnel (RaP_D), node E 503 also detects the failure and would switch the traffic from 504 anticlockwise protection ring tunnel (RaP_D) back to the clockwise 505 work ring tunnel (RcW_D). A possible mechanism to mitigate the 506 temporary loop problem is: the TTL of the ring tunnel label is set to 507 2*N by the ingress ring node of the traffic, where N is the number of 508 nodes on the ring. 510 +---+#####[RaP_D(F)]######+---+ 511 | F |---------------------| A | +-- LSP1 512 +---+*****[RcW_D(A)]******+---+ 513 #/* *\# 514 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 515 #/* *\# 516 +---+ xxxxx 517 | E | x B x 518 +---+ xxxxx 519 #\ */# 520 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 521 #\ */# 522 +---+*****[RcW_D(D)]****+---+ 523 LSP1 +-- | D |-------------------| C | 524 +---+#####[RaP_D(C)]####+---+ 526 -----physical links xxxxxx Failure Node 527 *****RcW_D ###### RaP_D 529 Figure 6. Wrapping for node failure 531 4.3.2. Short Wrapping 533 With the traditional wrapping protection scheme, Protection switching 534 is executed at both nodes detecting the failure, consequently the 535 traffic will be wrapped twice. This mechanism will cause additional 536 latency and bandwidth consumption when traffic is switched to the 537 protection path. 539 With short wrapping protection, data traffic switching is executed 540 only at the upstream node detecting the failure, and data traffic 541 leaves the ring in the protection ring tunnel at the egress node. 542 This scheme can reduce the additional latency and bandwidth 543 consumption when traffic is switched to the protection path. 545 In the traditional wrapping solution, the protection ring tunnel is a 546 closed ring in normal state, while in the short wrapping solution, 547 the protection ring tunnel is ended at the egress node, which is 548 similar to the working ring tunnel. Short wrapping is easy to 549 implement in shared ring protection because both the working and 550 protection ring tunnels are terminated on the egress nodes. Figure 7 551 shows the clockwise working ring tunnel and the anticlockwise 552 protection ring tunnel with node D as the egress node. 554 4.3.2.1. Short Wrapping for Link Failure 556 As shown in Figure 7, in normal state, LSP1 is carried by the 557 clockwise working ring tunnel (RcW_D) through the path A->B->C->D. 558 When a link failure between Node B and Node C occurs, Node B switches 559 The working ring tunnel RcW_D to the protection ring tunnel RaP_D in 560 the opposite direction. The difference occurs in the protection ring 561 tunnel at egress node. In short wrapping protection, Rap_D ends in 562 Node D and then traffic will be forwarded based on the LSP labels. 563 Thus with short wrapping mechanism, LSP1 will follow the path 564 A->B->A->F->E->D when link failure between Node B and Node C happens. 565 For node failure, the protection with short wrapping is similar to 566 the mechanism with link failure. 568 +---+#####[RaP_D(F)]######+---+ 569 | F |---------------------| A | +-- LSP1 570 +---+*****[RcW_D(A)]******+---+ 571 #/* *\# 572 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 573 #/* *\# 574 +---+ +---+ 575 | E | | B | 576 +---+ +---+ 577 #\ *x# 578 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 579 #\ *x# 580 +---+*****[RcW_D(D)]****+---+ 581 LSP1 +-- | D |-------------------| C | 582 +---+ +---+ 584 ----- physical links xxxxx Failure Link 585 ****** RcW_D ###### RaP_D 587 Figure 7. Short wrapping for link failure 589 4.3.2.2. Short Wrapping for Node Failure 591 For the failure scenarios which happen on a non-egress node, short 592 wrapping protection switching is similar to the link failure as 593 described in the previous section. This section specifies the 594 scenario of egress node failure. 596 As shown in Figure 8, LSP1 enters the ring on node A, and leaves the 597 ring on node D. in normal state, LSP1 is carried by the clockwise 598 working ring tunnel (RcW_D) through the path A->B->C->D. When node D 599 fails, traffic of LSP1 cannot be protected by any ring tunnels which 600 use node D as the egress node. However, before the failure location 601 is propagated to all the ring nodes, node C switches all the traffic 602 on the working ring tunnel RcW_D to the protection ring tunnel RaP_D 603 in the opposite direction. When the traffic arrives at node E which 604 also detects the failure of node D, the protection ring tunnel RaP_D 605 cannot be used to forward traffic to node D. Since with short 606 wrapping mechanism, protection switching can only be performed once 607 from the working ring tunnel to the protection ring tunnel, thus node 608 E MUST NOT switch the traffic which is already carried on the 609 protection ring tunnel back to the working ring tunnel in the 610 opposite direction. Instead, node E will discard the traffic 611 received on RaP_D locally. This can avoid the temporary traffic loop 612 when the faiulre happens on the egress node of the ring tunnel. This 613 also illustrates one of the benefits of having separate working and 614 protection ring tunnels in each ring direction. 616 +---+#####[RaP_D(F)]######+---+ 617 | F |---------------------| A | +-- LSP1 618 +---+*****[RcW_D(A)]******+---+ 619 #/* *\# 620 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 621 #/* *\# 622 +---+ +---+ 623 | E | | B | 624 +---+ +---+ 625 #\ */# 626 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 627 #\ */# 628 xxxxx*****[RcW_D(D)]****+---+ 629 LSP1 +-- x D x-------------------| C | 630 xxxxx +---+ 632 -----physical links xxxxxx Failure Node 633 *****RcW_D ###### RaP_D 635 Figure 8. Short Wrapping for egress node failure 637 4.3.3. Steering 639 In ring topology, each working ring tunnel is associated with a 640 protection ring tunnel in the opposite direction, and every node can 641 obtain the ring topology either by configuration or via some topology 642 discovery mechanism. The ring topology and the connectivity (Intact 643 or Severed) between the adjacent ring nodes form the ring map. Every 644 ring node maintains its ring map. When a failure occurs in the ring, 645 the nodes that detect the failure via OAM mechanism will transmit the 646 failure information in the opposite direction of the failure hop by 647 hop along the ring. When a node receives the message that identifies 648 a failure, it can quickly determine the location of the fault by 649 using the topology information that is maintained by the node and 650 upate the ring map accordingly, then it can determine whether the 651 LSPs entering the ring locally need to switchover or not. For LSPs 652 that needs to switchover, it will switch the LSPs from the working 653 ring tunnels to its corresponding protection ring tunnels. 655 Ring map of F +--LSPl 656 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ 657 |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| 658 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ 659 |I|I|I|S|I|I| |I|I|S|I|I|I| 660 +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ 661 [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] 662 #/* [RcW_D(F)] *\# 663 +-+-+-+-+-+-+-+ #/* *\# 664 |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 665 +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ 666 |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| 667 +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 668 #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| 669 [RaP_D(D)] #\* */# +-+-+-+-+-+-+ 670 #\* */# [RaP_D(B)] 671 +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ 672 |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| 673 +-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ 674 |I|I|I|I|I|S| LSP2 |S|I|I|I|I|I| 675 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 677 ----- physical links ***** RcW_D ##### RaP_D 678 I: Intact S: Severed 679 Figure 9. Steering operation and protection switching 681 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 682 enters the ring from Node B, and both of them have the same 683 destination node D. 685 In the normal state, LSP1 is carried by the clockwise working ring 686 tunnel (RcW_D) through the path A->B->C->D, the label operation is: 687 [LSP1] -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> 688 [RcW_D(D)|LSP1](NodeC) -> [LSP1] (data traffic carried by LSP1) . 690 LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught 691 the path B->C->D, the label operation is: [LSP2] -> 692 [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2] (data 693 traffic carried by LSP2) . 695 If the link between nodes C and D fails, according to the fault 696 detection and distribution mechanisms, Node D will find out that 697 there is a failure in the link between C and D, and it will update 698 the link state of its ring topology, changing the link between C and 699 D from normal to fault. In the direction that opposite to the 700 failure position, Node D will send the state report message to Node 701 E, informing Node E of the fault between C and D, and E will update 702 the link state of its ring topology accordingly, changing the link 703 between C and D from normal to fault. In this way, the state report 704 message is sent hop by hop in the clockwise direction. Similar to 705 Node D, Node C will send the failure information in the anti- 706 clockwise direction. 708 When Node A receives the failure report message and updates the link 709 state of its ring topology, it is aware that there is a fault on the 710 clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the 711 ring locally and is carried by this ring tunnel, thus Node A will 712 decide to switch the LSP1 onto the anticlockwise protection ring 713 tunnel to node D (RaP_D). After the switchover, LSP1 will follow the 714 path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| 715 LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> 716 [LSP1] (data traffic carried by LSP1). 718 The same also apply to the operation of LSP2. When Node B updates 719 the link state of its ring topology, and finds out that the working 720 ring tunnel RcW_D has failed, it will switch the LSP2 to the 721 anticlockwise protection tunnel RaP_D. After the switchover, LSP2 722 goes through the path B->A->F->E->D, and the label operation is: 723 [LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> 724 [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data 725 traffic carried by LSP2). 727 Then assume the link between nodes A and B breaks down, as shown in 728 Figure 10. Similar to the above failure case, Node B will detect a 729 fault in the link between A and B, and it will update the link state 730 of its ring topology, changing the link state between A and B from 731 normal to fault. The state report message is sent hop by hop in the 732 clockwise direction, notifying every node that there is a fault 733 between node A and B, and every node updates the link state of its 734 ring topology. As a result, Node A will detect a fault in the 735 working ring tunnel to node D, and switch LSP1 to the protection ring 736 tunnel, while Node B determine that the working ring tunnel for LSP2 737 still works fine, and will not perform the switchover. 739 /-- LSPl 740 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ 741 |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| 742 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ 743 |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| 744 +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ 745 [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] 746 #/* x +-- LSP2 747 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 748 |E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B| 749 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 750 |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| 751 +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ 752 [RaP_D(D)] #\* */# [RaP_D(B)] 753 +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 754 |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| 755 +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ 756 |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| 757 +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ 759 ----- physical links ***** RcW_D ##### RaP_D 761 Figure 10. Steering operation and protection switching (2) 763 4.4. Interconnected Ring Protection 765 4.4.1. Interconnected Ring Topology 767 Interconnected ring topology is often used in MPLS-TP networks. This 768 document will discuss two typical interconnected ring topologies: 770 1. Single-node interconnected rings 772 In single-node interconnected rings, the connection between 773 the two rings is through a single node. Because the 774 interconnection node is in fact a single point of failure, 775 this topology should be avoided in real transport networks. 776 Figure 10 shows the topology of single-node interconnected 777 rings. Node C is the interconnection node between Ring1 and 778 Ring2. 780 2. Dual-node interconnected rings 782 In dual-node interconnected rings, the connection between the 783 two rings is through two nodes. The two interconnection nodes 784 belong to both interconnected rings. This topology can 785 recover from one interconnection node failure. 787 Figure 11 shows the topology of single-node interconnected rings. 788 Node C is the interconnection node between Ring1 and Ring2. 790 +---+ +---+ +---+ +---+ 791 | A |------| B |----- -----| G |------| H | 792 +---+ +---+ \ / +---+ +---+ 793 | \ / | 794 | \ +---+ / | 795 | Ring1 | C | Ring2 | 796 | / +---+ \ | 797 | / \ | 798 +---+ +---+ / \ +---+ +---+ 799 | F |------| E |----- -----| J |------| I | 800 +---+ +---+ +---+ +---+ 802 Figure 11. Single-node interconnected rings 804 Figure 12 shows the topology of dual-node interconnected rings. 805 Nodes C and Node D are the interconnection nodes between Ring1 and 806 Ring2. 808 +---+ +---+ +---+ +---+ +---+ 809 | A |------| B |------| C |------| G |------| H | 810 +---+ +---+ +---+ +---+ +---+ 811 | | | | 812 | | | | 813 | Ring1 | | Ring2 | 814 | | | | 815 | | | | 816 +---+ +---+ +---+ +---+ +---+ 817 | F |------| E |------| D |------| J |------| I | 818 +---+ +---+ +---+ +---+ +---+ 820 Figure 12. Dual-node interconnected rings 822 4.4.2. Interconnected Ring Protection Mechanisms 824 Interconnected rings can be treated as two independent rings. Ring 825 protection switching (RPS) protocol operates on each ring 826 independently. Failure in one ring only triggers protection 827 switching on the ring itself and does not affect the other ring. 828 This way, protection switching on each ring is the same as the 829 mechanisms described in section 4.3. 831 The service LSPs that traverse the interconnected rings via the 832 interconnection nodes MUST use different ring tunnels in different 833 rings, and the service LSPs traversing the interconnected rings are 834 stitched by the interconnection node. On the interconnection node, 835 the ring tunnel label used in the source ring will be popped, the 836 service LSP label will be swapped, and the ring tunnel label of the 837 destination ring will be pushed. 839 In the dual-node interconnected ring scenario, the two 840 interconnection nodes can be managed as a virtual interconnection 841 node group. Each ring should assign working and protection ring 842 tunnels for the virtual interconnection node group. Both the 843 interconnection nodes in the virtual interconnection node group can 844 terminate the working ring tunnel of each ring. The protection ring 845 tunnel is used to protect the working ring tunnel of each ring and 846 can be terminated by any node in the virtual interconnection node 847 group. 849 On the nodes in the virtual interconnection node group of the dual- 850 node interconnected ring, the same label is allocated for each 851 service LSP. This way any interconnection node in the virtual node 852 group can stitch the service LSPs between the source ring tunnel and 853 the destination ring tunnel. 855 When the service traffic passes through the interconnection node, the 856 direction of the working ring tunnels in each ring for this service 857 traffic should be the same. For example, if the working ring tunnel 858 follows the clockwise direction in Ring1, the working ring tunnel for 859 the same service traffic in Ring2 SHOULD also follow the clockwise 860 direction when the service leaves Ring1 and enters Ring2. 862 4.4.3. Ring Tunnels in Interconnected Rings 864 The same ring tunnels as described in section 4.1 are used in each 865 ring of the interconnected rings. Note that ring tunnels to the 866 virtual interconnection node group will be established by each ring 867 of the interconnected rings, i.e.: 869 o one clockwise working ring tunnel to the virtual interconnection 870 node group 872 o one anticlockwise protection ring tunnel to the virtual 873 interconnection node group 875 o one anticlockwise working ring tunnel to the virtual 876 interconnection node group 878 o one clockwise protection ring tunnel to the virtual 879 interconnection node group 881 These ring tunnels will terminated at all nodes in the virtual 882 interconnection node group. 884 For example, all the ring tunnels on Ring1 of Figure 12 are 885 established as follows: 887 o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A 889 o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B 891 o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C 893 o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D 895 o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E 897 o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F 899 o To the virtual interconnection node group (including Node F and 900 Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A 902 All the ring tunnels established in Ring2 in Figure 13 are 903 provisioned as follows: 905 o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A 907 o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F 909 o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G 911 o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H 913 o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I 915 o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J 917 o To the virtual interconnection node group(including Node F and 918 Node A): R2cW_FandA, R2aW_FandA, R2cP_FandA, R2aP_FandA 919 +---+cccccccccccc +---+ 920 | H |-------------| I |--->LSP1 921 +---+ +---+ 922 c/a a\ 923 c/a a\ 924 c/a a\ 925 +---+ +---+ 926 | G | Ring2 | J | 927 +---+ +---+ 928 c\a a/c 929 c\a a/c 930 c\a aaaaaaaaaaaaa a/c 931 +---+ccccccccccccc+---+ 932 | F |-------------| A | 933 +---+ccccccccccccc+---+ 934 c/aaaaaaaaaaaaaaaaaaa a\ 935 c/ a\ 936 c/ a\ 937 +---+ +---+ 938 | E | Ring1 | B | 939 +---+ +---+ 940 c\a a/c 941 c\a a/c 942 c\a a/c 943 +---+aaaaaaaaaaaa +---+ 944 LSP1--->| D |-------------| C | 945 +---+ccccccccccccc+---+ 947 ccccccccccc R1cW_F&A 948 aaaaaaaaaaa R1aP_F&A 949 ccccccccccc R2cW_I 950 aaaaaaaaaaa R2aP_I 951 Figure 13. Ring tunnels for the interconnected rings 953 4.4.4. Interconnected Ring Switching Procedure 955 As shown in Figure 13, for the service traffic LSP1 which enters 956 Ring1 at Node D and leaves Ring1 at Node F and continues to enter 957 Ring2 at Node F and leaves Ring2 at Node I, the protection scheme is 958 described as below. 960 In normal state, LSP1 follows R1cW_F&A in Ring1 and R2CW_I in Ring2. 961 The label used for the working ring tunnel R1cW_F&A in Ring1 is 962 popped and the label used for the working ring tunnel R2cW_I will be 963 pushed based the inner label lookup at the interconnection node F. 964 The working path that the service traffic LSP1 follows is: 965 LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. 967 In case of link failure, for example, when a failure occurs on the 968 link between Node F and Node E, Nodes F and E will detect the failure 969 and execute protection switching as described in 4.3.1.1. The path 970 that the service traffic LSP1 follows after switching change to 971 LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A->F)->R1cW_F(F) 972 ->R2cW_I(F->G->H->I)->LSP1. 974 In case of a non interconnection node failure, for example, when the 975 failure occurs at Node E in Ring1, Nodes F and D will detect the 976 failure and execute protection switching as described in 4.3.1.2. 977 The path that the service traffic LSP1 follows after switching 978 becomes: LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A->F)-> 979 R1cW_F(F)->R2cW_I(F->G->H->I). 981 In case of an interconnection node failure, for example, when the 982 failure occurs at the interconnection Node F. Nodes E and A in Ring1 983 will detect the failure, and execute protection switching as 984 described in 4.3.1.2. Nodes G and A in Ring2 will also detects the 985 failure, and execute protection switching. The path that the service 986 traffic LSP1 follows after switching is: 987 LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R1cW_A(A) 988 ->R2aP_I(A->J->I)->LSP1. 990 4.4.5. Interconnected Ring Detection Mechanism 992 As show in Figure 14, the service traffic LSP1 traverses A->B->C in 993 Ring1 and C->G->H->I in Ring2. Node C and Node D are the 994 interconnection nodes. When both the link between Node C and Node G 995 and the link between Node C and Node D fail, the ring tunnel from 996 Node C to Node I in Ring2 becomes unreachable. However, Node D is 997 still available, and LSP1 can still reach Node I. 999 +---+ *********+---+**********+---+ +---+**********+---+ 1000 LSP1->| A |----------| B |----------| C |XXXXXXXXXX| G |----------| H | 1001 +---+##########+---+##########+---+ +---+##########+---+ 1002 |# X #|* 1003 |# X #|* 1004 |# Ring1 X Ring2 #|* 1005 |# X #|* 1006 |# X #|* 1007 +---+##########+---+##########+---+######### +---+##########+---+ 1008 | F |----------| E |----------| D |----------| J |----------| I | ->LSP1 1009 +---+ +---+ +---+ +---+ +---+ 1011 *********** R1cW_C&D 1012 ########### R1aP_C&D 1013 *********** R2cW_I 1014 ########### R2aP_I 1016 Figure 14. Interconnected ring 1018 In order to achieve this, the interconnection nodes need to know the 1019 ring topology of each ring so that they can judge whether a node is 1020 reachable. This judgment is based on the knowledge of each ring 1021 topology and the fault location as described in section 3.4. The 1022 ring topology can be obtained from the NMS or topology discovery 1023 mechanisms. The fault location can be obtained by transmitting the 1024 fault information around the ring. The nodes that detect the failure 1025 will transmit the fault information in the opposite direction node by 1026 node in the ring. When the interconnection node receives the message 1027 that informs the failure, it will quickly calculate the location of 1028 the fault by the topology information that is maintained by itself 1029 and determines whether the LSPs entering the ring at itself can reach 1030 the destination. If the destination node is reachable, the LSP will 1031 leave the source ring and enter the destination ring. If the 1032 destination node is not reachable, the LSP will switch to the 1033 anticlockwise protection ring tunnel. 1035 In Figure 14, Node C determines that the ring tunnel to Node I is 1036 unreachable, the service traffic LSP1 for which the destination node 1037 on the ring tunnel is Node I should switch to the protection LSP 1038 (R1aP_C&D) and consequently the service traffic LSP1 traverses the 1039 interconnected rings at Node D. Node D will remove the ring tunnel 1040 label of Ring1 and add the ring tunnel label of Ring2. 1042 5. Ring Protection Coordination Protocol 1043 5.1. RPS Protocol 1045 The MSRP protection operation MUST be controlled with the help of the 1046 Ring Protection Switch Protocol (RPS). The RPS processes in each of 1047 the individual ring nodes that form the ring SHOULD communicate using 1048 the G-ACh channel. 1050 The RPS protocol MUST carry the ring status information and RPS 1051 requests, i.e., automatically initiated and externally initiated, 1052 between the ring nodes. 1054 Each node on the ring MUST be uniquely identified by assigning it a 1055 node ID. The node ID MUST be unique on each ring. The maximum 1056 number of nodes on the ring supported by the RPS protocol is 127. 1057 The node ID SHOULD be independent of the order in which the nodes 1058 appear on the ring. The node ID is used to identity the source and 1059 destination nodes of each RPS request. 1061 Every node obtains the ring topology either by configuration or via 1062 some topology discovery mechanism. The ring map consists of the ring 1063 topology information, and connectivity status (Intact or Severed) 1064 between the adjacent ring nodes, which is determined via the OAM 1065 message exchange between the adjacent nodes. The ring map is used by 1066 every ring node to determine the switchover behavoir of the ring 1067 tunnels. 1069 When no protection switching is active on the ring, each node MUST 1070 dispatch periodically RPS requests to the two adjacent nodes, 1071 indicating No Request (NR). When a node determines that a protection 1072 switching is required, it MUST send the appropriate RPS request in 1073 both directions. 1075 +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) 1076 -------| A |-------------| B |-------------| C |------- 1077 (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ 1079 Figure 15. RPS communication between the ring nodes in case of 1080 no failures in the ring 1082 A destination node is a node that is adjacent to a node that 1083 identified a failed span. When a node that is not the destination 1084 node receives an RPS request and it has no higher priority local 1085 request, it MUST transfer in the same direction the RPS request as 1086 received. In this way, the switching nodes can maintain direct RPS 1087 protocol communication in the ring. 1089 +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) 1090 -------| A |-------------| B |----- X -----| C |------- 1091 (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ 1093 Figure 16. RPS communication between the ring nodes in case of 1094 failure between nodes B and C 1096 Note that in the case of a bidirectional failure such as a cable cut, 1097 the two adjacent nodes detect the failure and send each other an RPS 1098 request in opposite directions. 1100 o In rings utilizing the wrapping protection. When the destination 1101 node receives the RPS request it MUST perform the switch from/to 1102 the working ring tunnels to/from the protection ring tunnels if it 1103 has no higher priority active RPS request. 1105 o In rings utilizing the steering protection. When a ring switch is 1106 required, any node MUST perform the switches if its added/dropped 1107 traffic is affected by the failure. Determination of the affected 1108 traffic SHOULD be performed by examining the RPS requests 1109 (indicating the nodes adjacent to the failure or failures) and the 1110 stored ring maps (indicating the relative position of the failure 1111 and the added traffic destined towards that failure). 1113 When the failure has cleared and the Wait-to-Restore (WTR) timer has 1114 expired, the nodes sourcing RPS requests MUST drop their respective 1115 switches (tail end) and MUST source an RPS request carrying the NR 1116 code. The node receiving from both directions such RPS request (head 1117 end) MUST drop its protection switches. 1119 A protection switch MUST be initiated by one of the criteria 1120 specified in Section 3.2. A failure of the RPS protocol or 1121 controller MUST NOT trigger a protection switch. 1123 Ring switches MUST be preempted by higher priority RPS requests. For 1124 example, consider a protection switch that is active due to a manual 1125 switch request on the given span, and another protection switch is 1126 required due to a failure on another span. Then an RPS request MUST 1127 be generated, the former protection switch MUST be dropped, and the 1128 latter protection switch established. 1130 MSRP mechanism SHOULD support multiple protection switches in the 1131 ring, resulting the ring being segmented into two or more separate 1132 segments. This may happen when several RPS requests of the same 1133 priority exist in the ring due to multiple failures or external 1134 switch commands. 1136 Proper operation of the MSRP mechanism relies on all nodes having 1137 knowledge of the state of the ring (nodes and spans) so that nodes do 1138 not preempt existing RPS request unless they have a higher-priority 1139 RPS request. In order to accommodate ring state knowledge, during a 1140 protection switch the RPS requests MUST be sent in both directions. 1142 5.1.1. Transmission and Acceptance of RPS Requests 1144 A new RPS request MUST be transmitted immediately when a change in 1145 the transmitted status occurs. 1147 The first three RPS protocol messages carrying new RPS request SHOULD 1148 be transmitted as fast as possible. For fast protection switching 1149 within 50 ms, the interval of the first three RPS protocol messages 1150 SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted 1151 with the interval of 5 seconds. 1153 5.1.2. RPS PDU Format 1155 Figure 17 depicts the format of an RPS packet that is sent on the 1156 G-ACh. The Channel Type field is set to indicate that the message is 1157 an RPS message. The ACH MUST NOT include the ACH TLV Header 1158 [RFC5586] meaning that no ACH TLVs can be included in the message. 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Dest Node ID | Src Node ID | Request | Reserved | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Figure 17. G-ACh RPS Packet Format 1169 The following fields MUST be provided: 1171 o Destination Node ID: The destination node ID MUST always be set to 1172 value of the node ID of the adjacent node. The Node ID MUST be 1173 unique on each ring. Valid destination node ID values are 1-127. 1175 o Source node ID: The source node ID MUST always be set to the ID 1176 value of the node generating the RPS request. The Node ID MUST be 1177 unique on each ring. Valid source node ID values are 1-127. 1179 o RPS request code: A code consisting of eight bits as specified 1180 below: 1182 +------------------+-----------------------------+----------+ 1183 | Bits | Condition, State | Priority | 1184 | (MSB - LSB) | or external Request | | 1185 +------------------+-----------------------------+----------+ 1186 | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | 1187 | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | 1188 | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | 1189 | 0 0 0 0 0 1 1 0 | Manual Switch (MS) | | 1190 | 0 0 0 0 0 1 0 1 | Wait-To-Restore (WTR) | | 1191 | 0 0 0 0 0 0 1 1 | Exercise (EXER) | | 1192 | 0 0 0 0 0 0 0 1 | Reverse Request (RR) | | 1193 | 0 0 0 0 0 0 0 0 | No Request (NR) | lowest | 1194 +------------------+-----------------------------+----------+ 1196 5.1.3. Ring Node RPS States 1198 Idle state: A node is in the idle state when it has no RPS request 1199 and is sourcing and receiving NR code to/from both directions. 1201 Switching state: A node not in the idle or pass-through states is in 1202 the switching state. 1204 Pass-through state: A node is in the pass-through state when its 1205 highest priority RPS request is a request not destined to it or 1206 sourced by it. The pass-through is bidirectional. 1208 5.1.3.1. Idle State 1210 A node in the idle state MUST source the NR request in both 1211 directions. 1213 A node in the idle state MUST terminate RPS requests flow in both 1214 directions. 1216 A node in the idle state MUST block the traffic flow on protection 1217 LSPs/tunnels in both directions. 1219 5.1.3.2. Switching State 1221 A node in the switching state MUST source RPS request to adjacent 1222 node with its highest RPS request code in both directions when it 1223 detects a failure or receives an external command. 1225 A node in the switching state MUST terminate RPS requests flow in 1226 both directions. 1228 As soon as it receives an RPS request from the short path, the node 1229 to which it is addressed MUST acknowledge the RPS request by replying 1230 with the RR code on the short path, and with the received RPS request 1231 code on the long path. Here the short path refers to the shorter 1232 span on the ring between the source and destination node of the RPS 1233 request, and the long path refers to the longer span on the ring 1234 between the source and destination node of the RPS request. 1236 This rule refers to the unidirectional failure detection: the RR 1237 SHOULD be issued only when the node does not detect the failure 1238 condition (i.e., the node is a head end), that is, it is not 1239 applicable when a bidirectional failure is detected, because, in this 1240 case, both nodes adjacent to the failure will send an RPS request for 1241 the failure on both paths (short and long). 1243 The following switches MUST be allowed to coexist: 1245 o LP and LP 1247 o FS and FS 1249 o SF and SF 1251 o FS and SF 1253 When multiple MS RPS requests over different spans exist at the same 1254 time, no switch SHOULD be executed and existing switches MUST be 1255 dropped. The nodes MUST signal, anyway, the MS RPS request code. 1257 Multiple EXER requests MUST be allowed to coexist in the ring. 1259 A node in a ring switching state that receives the external command 1260 LP for the affected span MUST drop its switch and MUST signal NR for 1261 the locked span if there is no other RPS request on another span. 1262 Node still SHOULD signal relevant RPS request for another span. 1264 5.1.3.3. Pass-through State 1266 When a node is in a pass-through state, it MUST transfer the received 1267 RPS Request in the same direction. 1269 When a node is in a pass-through state, it MUST enable the traffic 1270 flow on protection ring tunnels in both directions. 1272 5.1.4. RPS State Transitions 1274 All state transitions are triggered by an incoming RPS request 1275 change, a WTR expiration, an externally initiated command, or locally 1276 detected MPLS-TP section failure conditions. 1278 RPS requests due to a locally detected failure, an externally 1279 initiated command, or received RPS request shall pre-empt existing 1280 RPS requests in the prioritized order given in Section 3.1.2, unless 1281 the requests are allowed to coexist. 1283 5.1.4.1. Transitions Between Idle and Pass-through States 1285 The transition from the idle state to pass-through state MUST be 1286 triggered by a valid RPS request change, in any direction, from the 1287 NR code to any other code, as long as the new request is not destined 1288 to the node itself. Both directions move then into a pass-through 1289 state, so that, traffic entering the node through the protection Ring 1290 tunnels are transferred transparently through the node. 1292 A node MUST revert from pass-through state to the idle state when it 1293 detects NR codes incoming from both directions. Both directions 1294 revert simultaneously from the pass-through state to the idle state. 1296 5.1.4.2. Transitions Between Idle and Switching States 1298 Transition of a node from the idle state to the switching state MUST 1299 be triggered by one of the following conditions: 1301 o A valid RPS request change from the NR code to any code received 1302 on either the long or the short path and destined to this node 1304 o An externally initiated command for this node 1306 o The detection of an MPLS-TP section layer failure at this node 1308 Actions taken at a node in the idle state upon transition to 1309 switching state are: 1311 o For all protection switch requests, except EXER and LP, the node 1312 MUST execute the switch 1314 o For EXER, and LP, the node MUST signal appropriate request but not 1315 execute the switch 1317 A node MUST revert from the switching state to the idle state when it 1318 detects NR codes received from both directions. 1320 o At the tail end: When a WTR time expires or an externally 1321 initiated command is cleared at a node, the node MUST drop its 1322 switch, transit to the Idle State and signal the NR code in both 1323 directions. 1325 o At the head end: Upon reception of the NR code, from both 1326 directions, the head-end node MUST drop its switch, transition to 1327 Idle State and signal the NR code in both directions. 1329 5.1.4.3. Transitions Between Switching States 1331 When a node that is currently executing any protection switch 1332 receives a higher priority RPS request (due to a locally detected 1333 failure, an externally initiated command, or a ring protection switch 1334 request destined to it) for the same span, it MUST update the 1335 priority of the switch it is executing to the priority of the 1336 received RPS request. 1338 When a failure condition clears at a node, the node MUST enter WTR 1339 condition and remain in it for the appropriate time-out interval, 1340 unless: 1342 o A different RPS request with a higher priority than WTR is 1343 received 1345 o Another failure is detected 1347 o An externally initiated command becomes active 1349 The node MUST send out a WTR code on both the long and short paths. 1351 When a node that is executing a switch in response to incoming SF RPS 1352 request (not due to a locally detected failure) receives a WTR code 1353 (unidirectional failure case), it MUST send out RR code on the short 1354 path and the WTR on the long path. 1356 5.1.4.4. Transitions Between Switching and Pass-through States 1358 When a node that is currently executing a switch receives an RPS 1359 request for a non-adjacent span of higher priority than the switch it 1360 is executing, it MUST drop its switch immediately and enter the pass- 1361 through state. 1363 The transition of a node from pass-through to switching state MUST be 1364 triggered by: 1366 o An equal priority, a higher priority, or an allowed coexisting 1367 externally initiated command 1369 o The detection of an equal priority, a higher priority, or an 1370 allowed coexisting automatic initiated command 1372 o The receipt of an equal, a higher priority, or an allowed 1373 coexisting RPS request destined to this node 1375 5.2. RPS State Machine 1377 5.2.1. Initial States 1378 +-----------------------------------+----------------+ 1379 | State | Signaled RPS | 1380 +-----------------------------------+----------------+ 1381 | A | Idle | NR | 1382 | | Working: no switch | | 1383 | | Protection: no switch | | 1384 +-----+-----------------------------+----------------+ 1385 | B | Pass-trough | N/A | 1386 | | Working: no switch | | 1387 | | Protection: pass through | | 1388 +-----+-----------------------------+----------------+ 1389 | C | Switching - LP | LP | 1390 | | Working: no switch | | 1391 | | Protection: no switch | | 1392 +-----+-----------------------------+----------------+ 1393 | D | Idle - LW | NR | 1394 | | Working: no switch | | 1395 | | Protection: no switch | | 1396 +-----+-----------------------------+----------------+ 1397 | E | Switching - FS | FS | 1398 | | Working: switched | | 1399 | | Protection: switched | | 1400 +-----+-----------------------------+----------------+ 1401 | F | Switching - SF | SF | 1402 | | Working: switched | | 1403 | | Protection: switched | | 1404 +-----+-----------------------------+----------------+ 1405 | G | Switching - MS | MS | 1406 | | Working: switched | | 1407 | | Protection: switched | | 1408 +-----+-----------------------------+----------------+ 1409 | H | Switching - WTR | WTR | 1410 | | Working: switched | | 1411 | | Protection: switched | | 1412 +-----+-----------------------------+----------------+ 1413 | I | Switching - EXER | EXER | 1414 | | Working: no switch | | 1415 | | Protection: no switch | | 1416 +-----+-----------------------------+----------------+ 1418 5.2.2. State transitions When Local Request is Applied 1420 In the state description below 'O' means that new local request will 1421 be rejected because of exiting request. 1423 ===================================================================== 1424 Initial state New request New state 1425 ------------- ----------- --------- 1426 A (Idle) LP C (Switching - LP) 1427 LW D (Idle - LW) 1428 FS E (Switching - FS) 1429 SF F (Switching - SF) 1430 Recover from SF N/A 1431 MS G (Switching - MS) 1432 Clear N/A 1433 WTR expires N/A 1434 EXER I (Switching - EXER) 1435 ===================================================================== 1436 Initial state New request New state 1437 ------------- ----------- --------- 1438 B (Pass-trough) LP C (Switching - LP) 1439 LW B (Pass-trough) 1440 FS O - if current state is due to 1441 LP sent by another node 1442 E (Switching - FS) - otherwise 1443 SF O - if current state is due to 1444 LP sent by another node 1445 F (Switching - SF) - otherwise 1446 Recover from SF N/A 1447 MS O - if current state is due to 1448 LP, SF or FS sent by 1449 another node 1450 G (Switching - MS) - otherwise 1451 Clear N/A 1452 WTR expires N/A 1453 EXER O 1454 ===================================================================== 1455 Initial state New request New state 1456 ------------- ----------- --------- 1457 C (Switching - LP) LP N/A 1458 LW O 1459 FS O 1460 SF O 1461 Recover from SF N/A 1462 MS O 1463 Clear A (Idle) - if there is no 1464 failure in the ring 1465 F (Switching - SF) - if there 1466 is a failure at this node 1467 B (Pass-trough) - if there is 1468 a failure at another node 1469 WTR expires N/A 1470 EXER O 1471 ===================================================================== 1472 Initial state New request New state 1473 ------------- ----------- --------- 1474 D (Idle - LW) LP C (Switching - LP) 1475 LW N/A - if on the same span 1476 D (Idle - LW) - if on another 1477 span 1478 FS O - if on the same span 1479 E (Switching - FS) - if on 1480 another span 1481 SF O - if on the addressed span 1482 F (Switching - SF) - if on 1483 another span 1484 Recover from SF N/A 1485 MS O - if on the same span 1486 G (Switching - MS) - if on 1487 another span 1488 Clear A (Idle) - if there is no 1489 failure on addressed span 1490 F (Switching - SF) - if there 1491 is a failure on this span 1492 WTR expires N/A 1493 EXER O 1494 ===================================================================== 1495 Initial state New request New state 1496 ------------- ----------- --------- 1497 E (Switching - FS) LP C (Switching - LP) 1498 LW O - if on another span 1499 D (Idle - LW) - if on the same 1500 span 1501 FS N/A - if on the same span 1502 E (Switching - FS) - if on 1503 another span 1504 SF O - if on the addressed span 1505 E (Switching - FS) - if on 1506 another span 1507 Recover from SF N/A 1508 MS O 1509 Clear A (Idle) - if there is no 1510 failure in the ring 1511 F (Switching - SF) - if there 1512 is a failure at this node 1513 B (Pass-trough) - if there is 1514 a failure at another node 1515 WTR expires N/A 1516 EXER O 1517 ===================================================================== 1518 Initial state New request New state 1519 ------------- ----------- --------- 1520 F (Switching - SF) LP C (Switching - LP) 1521 LW O - if on another span 1522 D (Idle - LW) - if on the same 1523 span 1524 FS E (Switching - FS) 1525 SF N/A - if on the same span 1526 F (Switching - SF) - if on 1527 another span 1528 Recover from SF H (Switching - WTR) 1529 MS O 1530 Clear N/A 1531 WTR expires N/A 1532 EXER O 1533 ===================================================================== 1534 Initial state New request New state 1535 ------------- ----------- --------- 1536 G (Switching - MS) LP C (Switching - LP) 1537 LW O - if on another span 1538 D (Idle - LW) - if on the same 1539 span 1540 FS E (Switching - FS) 1541 SF F (Switching - SF) 1542 Recover from SF N/A 1543 MS N/A - if on the same span 1544 G (Switching - MS) - if on 1545 another span release the 1546 switches but signal MS 1547 Clear A 1548 WTR expires N/A 1549 EXER O 1550 ===================================================================== 1551 Initial state New request New state 1552 ------------- ----------- --------- 1553 H (Switching - WTR) LP C (Switching - LP) 1554 LW D (Idle - W) 1555 FS E (Switching - FS) 1556 SF F (Switching - SF) 1557 Recover from SF N/A 1558 MS G (Switching - MS) 1559 Clear A 1560 WTR expires A 1561 EXER O 1562 ===================================================================== 1563 Initial state New request New state 1564 ------------- ----------- --------- 1565 I (Switching - EXER) LP C (Switching - LP) 1566 LW D (idle - W) 1567 FS E (Switching - FS) 1568 SF F (Switching - SF) 1569 Recover from SF N/A 1570 MS G (Switching - MS) 1571 Clear A 1572 WTR expires N/A 1573 EXER N/A - if on the same span 1574 I (Switching - EXER) 1575 ===================================================================== 1577 5.2.3. State Transitions When Remote Request is Applied 1579 The priority of a remote request does not depend on the side from 1580 which the request is received. 1582 ===================================================================== 1583 Initial state New request New state 1584 ------------- ----------- --------- 1585 A (Idle) LP C (Switching - LP) 1586 FS E (Switching - FS) 1587 SF F (Switching - SF) 1588 MS G (Switching - MS) 1589 WTR N/A 1590 EXER I (Switching - EXER) 1591 RR N/A 1592 NR A (Idle) 1593 ===================================================================== 1594 Initial state New request New state 1595 ------------- ----------- --------- 1596 B (Pass-trough) LP C (Switching - LP) 1597 FS N/A - cannot happen when there 1598 is LP request in the ring 1599 E (Switching - FS) - otherwise 1600 SF N/A - cannot happen when there 1601 is LP request in the ring 1602 F (Switching - SF) - otherwise 1603 MS N/A - cannot happen when there 1604 is LP, FS or SF request 1605 in the ring 1606 G (Switching - MS) - otherwise 1607 WTR N/A - cannot happen when there 1608 is LP, FS, SF or MS 1609 request in the ring 1610 EXER N/A - cannot happen when there 1611 is LP, FS, SF, MS or WTR 1612 request in the ring 1613 I (Switching - EXER) - 1614 otherwise 1615 RR N/A 1616 NR A (Idle) - if received from 1617 both sides 1618 ===================================================================== 1619 Initial state New request New state 1620 ------------- ----------- --------- 1621 C (Switching - LP) LP C (Switching - LP) 1622 FS N/A - cannot happen when there 1623 is LP request in the ring 1624 SF N/A - cannot happen when there 1625 is LP request in the ring 1626 MS N/A - cannot happen when there 1627 is LP request in the ring 1628 WTR N/A 1629 EXER N/A - cannot happen when there 1630 is LP request in the ring 1631 RR C (Switching - LP) 1632 NR N/A 1633 ===================================================================== 1634 Initial state New request New state 1635 ------------- ----------- --------- 1636 D (Idle - LW) LP C (Switching - LP) 1637 FS E (Switching - FS) 1638 SF F (Switching - SF) 1639 MS G (Switching - MS) 1640 WTR N/A 1641 EXER I (Switching - EXER) 1642 RR N/A 1643 NR D (Idle - LW) 1644 ===================================================================== 1645 Initial state New request New state 1646 ------------- ----------- --------- 1647 E (Switching - FS) LP C (Switching - LP) 1648 FS E (Switching - FS) 1649 SF E (Switching - FS) 1650 MS N/A - cannot happen when there 1651 is FS request in the ring 1652 WTR N/A 1653 EXER N/A - cannot happen when there 1654 is FS request in the ring 1655 RR E (Switching - FS) 1656 NR N/A 1657 ===================================================================== 1658 Initial state New request New state 1659 ------------- ----------- --------- 1660 F (Switching - SF) LP C (Switching - LP) 1661 FS F (Switching - SF) 1662 SF F (Switching - SF) 1663 MS N/A - cannot happen when there 1664 is SF request in the ring 1666 WTR N/A 1667 EXER N/A - cannot happen when there 1668 is SF request in the ring 1669 RR F (Switching - SF) 1670 NR N/A 1671 ===================================================================== 1672 Initial state New request New state 1673 ------------- ----------- --------- 1674 G (Switching - MS) LP C (Switching - LP) 1675 FS E (Switching - FS) 1676 SF F (Switching - SF) 1677 MS G (Switching - MS) - release 1678 the switches but signal MS 1679 WTR N/A 1680 EXER N/A - cannot happen when there 1681 is MS request in the ring 1682 RR G (Switching - MS) 1683 NR N/A 1684 ===================================================================== 1685 Initial state New request New state 1686 ------------- ----------- --------- 1687 H (Switching - WTR) LP C (Switching - LP) 1688 FS E (Switching - FS) 1689 SF F (Switching - SF) 1690 MS G (Switching - MS) 1691 WTR H (Switching - WTR) 1692 EXER N/A - cannot happen when there 1693 is WTR request in the ring 1694 RR H (Switching - WTR) 1695 NR N/A 1696 ===================================================================== 1697 Initial state New request New state 1698 ------------- ----------- --------- 1699 I (Switching - EXER) LP C (Switching - LP) 1700 FS E (Switching - FS) 1701 SF F (Switching - SF) 1702 MS G (Switching - MS) 1703 WTR N/A 1704 EXER I (Switching - EXER) 1705 RR I (Switching - EXER) 1706 NR N/A 1707 ===================================================================== 1709 5.2.4. State Transitions When Request Addresses to Another Node is 1710 Received 1712 The priority of a remote request does not depend on the side from 1713 which the request is received. 1715 ===================================================================== 1716 Initial state New request New state 1717 ------------- ----------- --------- 1718 A (Idle) LP B (Pass-trough) 1719 FS B (Pass-trough) 1720 SF B (Pass-trough) 1721 MS B (Pass-trough) 1722 WTR B (Pass-trough) 1723 EXER B (Pass-trough) 1724 RR N/A 1725 NR N/A 1726 ===================================================================== 1727 Initial state New request New state 1728 ------------- ----------- --------- 1729 B (Pass-trough) LP B (Pass-trough) 1730 FS N/A - cannot happen when there 1731 is LP request in the ring 1732 B (Pass-trough) - otherwise 1733 SF N/A - cannot happen when there 1734 is LP request in the ring 1735 B (Pass-trough) - otherwise 1736 MS N/A - cannot happen when there 1737 is LP, FS or SF request 1738 in the ring 1739 B (Pass-trough) - otherwise 1740 WTR N/A - cannot happen when there 1741 is LP, FS, SF or MS 1742 request in the ring 1743 B (Pass-trough) - otherwise 1744 EXER N/A - cannot happen when there 1745 is LP, FS, SF, MS or WTR 1746 request in the ring 1747 B (Pass-trough) - otherwise 1748 RR N/A 1749 NR B (Pass-trough) 1750 ===================================================================== 1751 Initial state New request New state 1752 ------------- ----------- --------- 1753 C (Switching - LP) LP C (Switching - LP) 1754 FS N/A - cannot happen when there 1755 is LP request in the ring 1756 SF N/A - cannot happen when there 1757 is LP request in the ring 1758 MS N/A - cannot happen when there 1759 is LP request in the ring 1760 WTR N/A - cannot happen when there 1761 is LP in the ring 1762 EXER N/A - cannot happen when there 1763 is LP request in the ring 1764 RR N/A 1765 NR N/A 1766 ===================================================================== 1767 Initial state New request New state 1768 ------------- ----------- --------- 1769 D (Idle - LW) LP B (Pass-trough) 1770 FS B (Pass-trough) 1771 SF B (Pass-trough) 1772 MS B (Pass-trough) 1773 WTR B (Pass-trough) 1774 EXER B (Pass-trough) 1775 RR N/A 1776 NR N/A 1777 ===================================================================== 1778 Initial state New request New state 1779 ------------- ----------- --------- 1780 E (Switching - FS) LP B (Pass-trough) 1781 FS E (Switching - FS) 1782 SF E (Switching - FS) 1783 MS N/A - cannot happen when there 1784 is FS request in the ring 1785 WTR N/A - cannot happen when there 1786 is FS request in the ring 1787 EXER N/A - cannot happen when there 1788 is FS request in the ring 1789 RR N/A 1790 NR N/A 1791 ===================================================================== 1792 Initial state New request New state 1793 ------------- ----------- --------- 1794 F (Switching - SF) LP B (Pass-trough) 1795 FS F (Switching - SF) 1796 SF F (Switching - SF) 1797 MS N/A - cannot happen when there 1798 is SF request in the ring 1799 WTR N/A - cannot happen when there 1800 is SF request in the ring 1801 EXER N/A - cannot happen when there 1802 is SF request in the ring 1803 RR N/A 1804 NR N/A 1806 ===================================================================== 1807 Initial state New request New state 1808 ------------- ----------- --------- 1809 G (Switching - MS) LP B (Pass-trough) 1810 FS B (Pass-trough) 1811 SF B (Pass-trough) 1812 MS G (Switching - MS) - release 1813 the switches but signal MS 1814 WTR N/A - cannot happen when there 1815 is MS request in the ring 1816 EXER N/A - cannot happen when there 1817 is MS request in the ring 1818 RR N/A 1819 NR N/A 1820 ===================================================================== 1821 Initial state New request New state 1822 ------------- ----------- --------- 1823 H (Switching - WTR) LP B (Pass-trough) 1824 FS B (Pass-trough) 1825 SF B (Pass-trough) 1826 MS B (Pass-trough) 1827 WTR N/A 1828 EXER N/A - cannot happen when there 1829 is WTR request in the ring 1830 RR N/A 1831 NR N/A 1832 ===================================================================== 1833 Initial state New request New state 1834 I (Switching - EXER) LP B (Pass-trough) 1835 FS B (Pass-trough) 1836 SF B (Pass-trough) 1837 MS B (Pass-trough) 1838 WTR N/A 1839 EXER I (Switching - EXER) 1840 RR N/A 1841 NR N/A 1842 ===================================================================== 1844 5.3. RPS and PSC Comparison on Ring Topology 1846 This section provides comparison between RPS and PSC [RFC6378] 1847 [RFC6974] on ring topologies. This can be helpful to explain the 1848 reason of defining a new protocol for ring protection switching. 1850 The PSC protocol [RFC6378] is designed for point-to-point LSPs, on 1851 which the protection switching can only be performed on one or both 1852 of the end points of the LSP. While RPS is designed for ring 1853 tunnels, which consist of multiple ring nodes, and the failure could 1854 happen on any segment of the ring, thus RPS SHOULD be capable of 1855 identifying and handling the different failures on the ring, and 1856 coordinating the protection switching behavior of all the nodes on 1857 the ring. As specified in section 5, this is achieved with the 1858 introduction of the "Pass-Through" state for the ring nodes, and the 1859 location of the protection request is identified via the Node IDs in 1860 the RPS Request message. 1862 Taking a ring topology with N nodes as example: 1864 With the mechanism specified in RFC6974, on every ring-node, a linear 1865 protection configuration has to be provisioned with every other node 1866 in the ring, i.e. with (N-1) other nodes. This means that on every 1867 ring node there will be (N-1) instances of the PSC protocol. And in 1868 order to detect faults and to transport the PSC message, each 1869 instance shall have a MEP on the working path and a MEP on the 1870 protection path respectively. This means that every node on the ring 1871 needs to be configured with (N-1) * 2 MEPs. 1873 With the mechanism defined in this document, on every ring node there 1874 will only be a single instance of the RPS protocol. In order to 1875 detect faults and to transport the RPS message, each node only needs 1876 to have a MEP on the section to its adjacent nodes respectively. In 1877 this way, every ring-node only needs to be configured with 2 MEPs. 1879 As shown in the above example, RPS is designed for ring topologies 1880 and can achieve ring protection efficiently with minimum protection 1881 instances and OAM entities, which meets the requirements on topology 1882 specific recovery mechanisms as specified in [RFC5654]. 1884 6. IANA Considerations 1886 IANA is requested to administer the assignment of new values defined 1887 in this document and summarized in this section. 1889 6.1. G-ACh Channel Type 1891 The Channel Types for the Generic Associated Channel (GACH) are 1892 allocated from the IANA PW Associated Channel Type registry defined 1893 in [RFC4446] and updated by [RFC5586]. 1895 IANA is requested to allocate a new GACH Channel Type as follows: 1897 Value Description Reference 1898 ------ -------------------------- --------------- 1899 TBD Ring Protection Switching this document 1900 Protocol (RPS) 1902 6.2. RSP Request Codes 1904 IANA is requested to create a new sub-registry under the 1905 "Multiprotocol Label Switching (MPLS) Operations, Administration, and 1906 Management (OAM) Parameters" registry called the "MPLS RPS Request 1907 Code Registry". All code points within this registry shall be 1908 allocated according to the "Standards Action" procedure as specified 1909 in [RFC5226]. 1911 The RPS Request Field is 8 bits, the allocated values are as follows: 1913 Value Description Reference 1914 ------- --------------------------- --------------- 1915 0 No Request (NR) this document 1916 1 Reverse Request (RR) this document 1917 2 not assigned 1918 3 Exercise (EXER) this document 1919 4 not assigned 1920 5 Wait-To-Restore (WTR) this document 1921 6 Manual Switch (MS) this document 1922 7-10 not assigned 1923 11 Signal Fail (SF) this document 1924 12 not assigned 1925 13 Forced Switch (FS) this document 1926 14 not assigned 1927 15 Lockout of Protection (LP) this document 1928 16-255 not assigned 1930 7. Security Considerations 1932 The RPS protocol defined in this document is carried in the G-ACh 1933 [RFC5586], which is a generalization of the Associated Channel 1934 defined in [RFC4385]. The security considerations specified in these 1935 documents apply to the proposed RPS mechanism. 1937 8. Contributing Authors 1939 Wen Ye, Minxue Wang, Sheng Liu (China Mobile) 1941 Guanghui Sun (Huawei) 1943 9. Acknowledgements 1945 The authors would like to thank Gregory Mirsky, Yimin Shen, Eric 1946 Osborne and Spencer Jackson for their valuable comments and 1947 suggestions. 1949 10. References 1951 10.1. Normative References 1953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1954 Requirement Levels", BCP 14, RFC 2119, 1955 DOI 10.17487/RFC2119, March 1997, 1956 . 1958 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1959 Label Switching Architecture", RFC 3031, 1960 DOI 10.17487/RFC3031, January 2001, 1961 . 1963 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1964 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1965 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1966 February 2006, . 1968 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1969 Emulation (PWE3)", BCP 116, RFC 4446, 1970 DOI 10.17487/RFC4446, April 2006, 1971 . 1973 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1974 "MPLS Generic Associated Channel", RFC 5586, 1975 DOI 10.17487/RFC5586, June 2009, 1976 . 1978 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1979 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1980 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1981 September 2009, . 1983 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 1984 Administration, and Maintenance Framework for MPLS-Based 1985 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 1986 September 2011, . 1988 10.2. Informative References 1990 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1991 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1992 DOI 10.17487/RFC5226, May 2008, 1993 . 1995 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 1996 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 1997 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 1998 October 2011, . 2000 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 2001 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 2002 "Applicability of MPLS Transport Profile for Ring 2003 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 2004 . 2006 Authors' Addresses 2008 Weiqiang Cheng 2009 China Mobile 2011 Email: chengweiqiang@chinamobile.com 2013 Lei Wang 2014 China Mobile 2016 Email: wangleiyj@chinamobile.com 2018 Han Li 2019 China Mobile 2021 Email: lihan@chinamobile.com 2023 Huub van Helvoort 2024 Hai Gaoming BV 2026 Email: huubatwork@gmail.com 2028 Kai Liu 2029 Huawei Technologies 2031 Email: alex.liukai@huawei.com 2033 Jie Dong 2034 Huawei Technologies 2036 Email: jie.dong@huawei.com 2037 Jia He 2038 Huawei Technologies 2040 Email: hejia@huawei.com 2042 Fang Li 2043 China Academy of Telecommunication Research, MIIT., China 2045 Email: lifang@ritt.cn 2047 Jian Yang 2048 ZTE Corporation P.R.China 2050 Email: yang.jian90@zte.com.cn 2052 Junfang Wang 2053 Fiberhome Telecommunication Technologies Co., LTD. 2055 Email: wjf@fiberhome.com.cn