idnits 2.17.1 draft-ietf-mpls-tp-shared-ring-protection-03.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 488 has weird spacing: '...l links xxx...' == Line 598 has weird spacing: '...l links xxx...' == Line 956 has weird spacing: '...aaaaaaa a/c...' -- The document date (September 29, 2016) is 2765 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 335, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 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 2, 2017 China Mobile 6 H. Helvoort 7 Hai Gaoming BV 8 J. Dong 9 Huawei Technologies 10 September 29, 2016 12 Shared-Ring protection (MSRP) mechanism for ring topology 13 draft-ietf-mpls-tp-shared-ring-protection-03 15 Abstract 17 This document describes requirements, architecture and solutions for 18 MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- 19 to-point (P2P) services. The MSRP mechanism is described to meet the 20 ring protection requirements as described in RFC 5654. This document 21 defines the Ring Protection Switch (RPS) Protocol that is used to 22 coordinate the protection behavior of the nodes on MPLS ring. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 2, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 66 3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 4 67 4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 68 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 70 4.1.2. Label Assignment and Distribution . . . . . . . . . . 7 71 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 7 72 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 8 73 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 9 74 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10 75 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12 76 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14 77 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17 78 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17 79 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 19 80 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19 81 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21 82 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22 83 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23 84 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 23 85 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 25 86 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 25 87 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 88 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 89 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 90 5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31 91 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 32 92 5.2.3. State transitions When Local Request is Applied . . . 33 93 5.2.4. State Transitions When Remote Request is Applied . . 37 94 5.2.5. State Transitions When Request Addresses to Another 95 Node is Received . . . . . . . . . . . . . . . . . . 40 96 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 42 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 98 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 43 99 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 44 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 101 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 105 10.2. Informative References . . . . . . . . . . . . . . . . . 46 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 108 1. Introduction 110 As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1, 111 Ring Protection, several service providers have expressed much 112 interest in operating MPLS-TP in ring topologies and require a high- 113 level survivability function in these topologies. In operational 114 transport network deployment, MPLS-TP networks are often constructed 115 using ring topologies. This calls for an efficient and optimized 116 ring protection mechanism to achieve simple operation and fast, sub 117 50 ms, recovery performance. 119 This document specifies an MPLS-TP Shared-Ring Protection mechanisms 120 that meets the criteria for ring protection and the ring protection 121 requirements described in section 2.5.6.1 of [RFC5654]. 123 The basic concept and architecture of Shared-Ring protection 124 mechanism are specified in this document. This document describes 125 the solutions for point-to-point transport paths. While the basic 126 concept may also apply to point-to-multipoint transport paths, the 127 solution for point-to-multipoint transport paths is out of the scope 128 of this document. 130 2. Terminology and Notation 132 Terminology: 134 Ring Node: A ring node is a node in the ring topology that actively 135 participates in the ring protection. 137 Ring tunnel: A ring tunnel provides a server layer for the LSPs 138 traverse the ring. The notation for ring tunnel is: xxxx R

_ 139 where = c (clockwise) or a (anticlockwise),

= W (working) or 140 P (protecting), and the node name. 142 Ring map: A ring map is present in each ring-node. The ring-map 143 contains the ring topology information, i.e. the nodes in the ring, 144 the adjacency of the ring-nodes and the status of the links between 145 ring-nodes (Intact or Severed) and for each protected LSP at which 146 node it enters and leaves the ring. The ring map is used by every 147 ring node to determine the switchover behavior of the ring tunnels. 149 Notation: 151 The following syntax will be used to describe the contents of the 152 label stack: 154 1. The label stack will be enclosed in square brackets ("[]"). 156 2. Each level in the stack will be separated by the '|' character. 157 It should be noted that the label stack may contain additional 158 layers. However, we only present the layers that are related to the 159 protection mechanism. 161 3. If the Label is assigned by Node X, the Node Name is enclosed in 162 bracket ("()") 164 3. MPLS-TP Ring Protection Criteria and Requirements 166 The generic requirements for MPLS-TP protection are specified in 167 [RFC5654]. The requirements specific for ring protection are 168 specified in section 2.5.6.1 of [RFC5654]. This section describes 169 how the criteria for ring protection are met: 171 a. The number of OAM entities needed to trigger protection 173 Each ring-node requires only one instance of the RPS protocol. The 174 OAM of the links connected to the adjacent ring-nodes has to be 175 forwarded to only this instance in order to trigger protection. 177 b. The number of elements of recovery in the ring 179 Each ring-node requires only one instance of the RPS protocol and is 180 independent of the number of LSPs that are protected. 182 c. The required number of labels required for the protection paths 184 The RPS protocol uses ring tunnels and each tunnel has a set of 185 labels. The number of ring tunnel labels is related to the number of 186 ring-nodes and is independent of the number of protected LSPs. 188 d. The amount of control and management-plane transactions 189 Each ring-node requires only one instance of the RPS protocol this 190 means that only one maintenance operation is required per ring-node. 192 e. Minimize the signaling and routing information exchange during 193 protection 195 Information exchange during a protection switch is using the in-band 196 RPS and OAM messages. No control plane interactions are required. 198 4. Shared Ring Protection Architecture 200 4.1. Ring Tunnel 202 This document introduces a new logical layer of the ring for shared 203 ring protection in MPLS-TP networks. As shown in Figure 1, the new 204 logical layer consists of ring tunnels which provides a server layer 205 for the LSPs traverse the ring. Once a ring tunnel is established, 206 the forwarding and protection switching of the ring are all performed 207 at the ring tunnel level. A port can carry multiple ring tunnels, 208 and a ring tunnel can carry multiple LSPs. 210 +------------- 211 +-------------| 212 +-------------| | 213 =====PW1======| | | 214 | | Ring | Physical 215 =====PW2======| LSP | Tunnel | Port 216 | | | 217 =====PW3======| | | 218 +-------------| | 219 +-------------| 220 +------------- 221 Figure 1. The logical layers of the ring 223 The label stack used in MPLS-TP Shared Ring Protection mechanism is 224 [Ring Tunnel Label|LSP Label|PW Label](Payload) as illustrated in 225 figure 2. 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Ring tunnel Label | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | LSP Label | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | PW Label | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Payload | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 2. Label stack used in MPLS-TP Shared Ring Protection 238 4.1.1. Establishment of Ring Tunnel 240 The Ring tunnels are established based on the egress nodes. The 241 egress node is the node where traffic leaves the ring. LSPs which 242 have the same egress node on the ring and travels along the ring in 243 the same direction (clockwise or anticlockwise) share the same ring 244 tunnels. In other words, all the LSPs that traverse the ring in the 245 same direction and exit from the same node share the same working 246 ring tunnel and protection ring tunnel. For each egress node, four 247 ring tunnels are established: 249 o one clockwise working ring tunnel, which is protected by the 250 anticlockwise protection ring tunnel 252 o one anticlockwise protection ring tunnel 254 o one anticlockwise working ring tunnel, which is protected by the 255 clockwise protection ring tunnel 257 o one clockwise protection ring tunnel 259 The structure of the protection tunnels are determined by the 260 selected protection mechanism. This will be detailed in subsequent 261 sections. 263 As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, 264 Node A and Node B respectively, and all leave the ring at Node D. To 265 protect these LSPs that traverse the ring, a clockwise working ring 266 tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection 267 ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an 268 anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and 269 its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D 270 are established. For simplicity Figure 3 only shows RcW_D and RaP_D. 271 A similar provisioning should be applied for any other node on the 272 ring. In summary, for each node in Figure 3 when acting as egress 273 node, the ring tunnels are created as follows: 275 o To Node A: RcW_A, RaW_A, RcP_A, RaP_A 277 o To Node B: RcW_B, RaW_B, RcP_B, RaP_B 279 o To Node C: RcW_C, RaW_C, RcP_C, RaP_C 281 o To Node D: RcW_D, RaW_D, RcP_D, RaP_D 283 o To Node E: RcW_E, RaW_E, RcP_E, RaP_E 285 o To Node F: RcW_F, RaW_F, RcP_F, RaP_F 286 +---+#############+---+ 287 | F |-------------| A | +-- LSP2 288 +---+*************+---+ 289 #/* *\# 290 #/* *\# 291 #/* *\# 292 +---+ +---+ 293 LSP1-+ | E | | B |+-- LSP3 294 +---+ +---+ 295 #\ */# 296 #\ */# 297 #\ */# 298 +---+*************+---+ 299 LSP1 +--| D |-------------| C | 300 LSP2 +---+#############+---+ 301 LSP3 303 ---- physical links 304 **** RcW_D 305 #### RaP_D 307 Figure 3. Ring tunnels in MSRP 309 Through these working and protection ring tunnels, LSPs which enter 310 the ring from any node can reach any egress nodes on the ring, and 311 are protected from failures on the ring. 313 4.1.2. Label Assignment and Distribution 315 The ring tunnel labels are downstream-assigned labels as defined in 316 [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can 317 be either configured statically, provisioned by a controller, or 318 distributed dynamically via a control protocol. 320 4.1.3. Forwarding Operation 322 When an MPLS-TP transport path, such as an LSP, enters the ring, the 323 ingress node on the ring pushes the working ring tunnel label which 324 is used to reach the specific egress node and sends the traffic to 325 the next hop. The transit nodes on the working ring tunnel swap the 326 ring tunnel labels and forward the packets to the next hop. When the 327 packet arrives at the egress node, the egress node pops the ring 328 tunnel label and forwards the packets based on the inner LSP label 329 and PW label. Figure 4 shows the label operation in the MPLS-TP 330 shared ring protection mechanism. Assume that LSP1 enters the ring 331 at Node A and exits from Node D, and the following label operations 332 are executed. 334 1. Ingress node: Packets of LSP1 arrive at Node A with a label stack 335 [LSP1] and is supposed to be forwarded in the clockwise direction 336 of the ring. The clockwise working ring tunnel label RcW_D will 337 be pushed at Node A, the label stack for the forwarded packet at 338 Node A is changed to [RcW_D(B)|LSP1]. 340 2. Transit nodes: In this case, Node B and Node C forward the 341 packets by swapping the working ring tunnel labels. For example, 342 the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node 343 B. 345 3. Egress node: When the packet arrives at Node D (i.e. the egress 346 node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and 347 subsequently deals with the inner labels of LSP1. 349 +---+#####[RaP_D(F)]######+---+ 350 | F |---------------------| A | +-- LSP1 351 +---+*****[RcW_D(A)]******+---+ 352 #/* *\# 353 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)] 354 #/* *\# 355 +---+ +---+ 356 | E | | B | 357 +---+ +---+ 358 #\ */# 359 [RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)] 360 #\ */# 361 +---+*****[RcW_D(D)]****+---+ 362 LSP1 +-- | D |-------------------| C | 363 +---+#####[RaP_D(C)]####+---+ 365 -----physical links ****** RcW_D ###### RaP_D 367 Figure 4. Label operation of MSRP 369 4.2. Failure Detection 371 The MPLS-TP section layer OAM is used to monitor the connectivity 372 between each two adjacent nodes on the ring using the mechanisms 373 defined in [RFC6371]. Protection switching is triggered by the 374 failure detected on the ring by the OAM mechanisms. 376 Two ports of a link form a Maintenance Entity Group (MEG), and an MEG 377 end point (MEP) function is installed in each ring port. CC OAM 378 packets are periodically exchanged between each pair of MEPs to 379 monitor the link health. Three consecutive lost CC packets will be 380 interpreted as a link failure. 382 A node failure is regarded as the failure of two links attached to 383 that node. The two nodes adjacent to the failed node detect the 384 failure in the links that are connected to the failed node. 386 4.3. Ring Protection 388 This section specifies the ring protection mechanisms in detail. In 389 general, the description uses the clockwise working ring tunnel and 390 the corresponding anti-clockwise protection ring tunnel as an 391 example, but the mechanism is applicable in the same way to the anti- 392 clockwise working and clockwise protection ring tunnels. 394 In a ring network, each working ring tunnel is associated with a 395 protection ring tunnel in the opposite direction, and every node MUST 396 obtain the ring topology either by configuration or via a topology 397 discovery mechanism. The ring topology and the connectivity (Intact 398 or Severed) between two adjacent ring nodes form the ring map. Each 399 ring node maintains the ring map and use it to perform ring 400 protection. 402 Taking the topology in Figure 4 as an example, LSP1 enters the ring 403 at Node A and leaves the ring at Node D. In normal state, LSP1 is 404 carried by the clockwise working ring tunnel (RcW_D) through the path 405 A->B->C->D. The label operation is: 407 [LSP1](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) 408 -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload). Then at node D the 409 packet will be forwarded based on the label stack of LSP1. 411 Three typical ring protection mechanisms are described in this 412 section: wrapping, short wrapping and steering. All nodes on the 413 same ring MUST use the same protection mechanism. 415 Wrapping ring protection: the node which detects a failure or accepts 416 a switch request switches the traffic impacted by the failure or the 417 switch request to the opposite direction (away from the failure). In 418 this way, the impacted traffic is switched to the protection ring 419 tunnel by the switching node upstream of the failure, then travels 420 around the ring to the switching node downstream of the failure 421 through the protection ring tunnel, where it is switched back onto 422 the working ring tunnel to reach the egress node. 424 Short wrapping ring protection provides some optimization to wrapping 425 protection, in which the impacted traffic is only switched once to 426 the protection ring tunnel by the switching node upstream to the 427 failure. At the egress node, the traffic leave the ring from the 428 protection ring tunnel. This can reduce the traffic detour of 429 wrapping protection. 431 Steering ring protection implies that the node that detects a failure 432 sends a request along the ring to the other node adjacent to the 433 failure, and all nodes in the ring process this information. For the 434 impaced traffic, the ingress node (which adds traffic to the ring) 435 perform switching of the traffic from working to the protection ring 436 tunnel, and the egress node will drop the traffic received from the 437 protection ring tunnel. 439 The following sections describes these protection mechanisms in 440 detail. 442 4.3.1. Wrapping 444 With the wrapping mechanism, the protection ring tunnel is a closed 445 ring identified by the egress node. As shown in Figure 4, the RaP_D 446 is the anticlockwise protection ring tunnel for the clockwise working 447 ring tunnel RcW_D. As specified in the following sections, the 448 closed ring protection tunnel can protect both link failures and node 449 failures. 451 4.3.1.1. Wrapping for Link Failure 453 When a link failure between Node B and Node C occurs, if it is a bi- 454 directional failure, both Node B and Node C can detect the failure 455 via the OAM mechanism; if it is a uni-directional failure, one of the 456 two nodes would detect the failure via the OAM mechanism. In both 457 cases the node at the other side of the detected failure will be 458 determined by the ring-map and informed using the Ring Protection 459 Switch Protocol (RPS) which is specified in section 5. Then Node B 460 switches the clockwise working ring tunnel (RcW_D) to the 461 anticlockwise protection ring tunnel (RaP_D) and Node C switches 462 anticlockwise protection ring tunnel(RaP_D) back to the clockwise 463 working ring tunnel (RcW_D). The data traffic which enters the ring 464 at Node A and leaves the ring at Node D follows the path 465 A->B->A->F->E->D->C->D. The label operation is: 467 [LSP1](Payload) -> [RcW_D(B)|LSP1](Node A) -> [RaP_D(A)|LSP1](Node B) 468 -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] (Node F) -> 469 [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> 470 [RcW_D(D)|LSP1](Node C) -> [LSP1](Payload). 472 +---+#####[RaP_D(F)]######+---+ 473 | F |---------------------| A | +-- LSP1 474 +---+*****[RcW_D(A)]******+---+ 475 #/* *\# 476 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 477 #/* *\# 478 +---+ +---+ 479 | E | | B | 480 +---+ +---+ 481 #\ *x# 482 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 483 #\ *x# 484 +---+*****[RcW_D(D)]****+---+ 485 LSP1 +-- | D |-------------------| C | 486 +---+#####[RaP_D(C)]####+---+ 488 -----physical links xxxx Failure Link 489 ****** RcW_D ###### RaP_D 491 Figure 5.Wrapping for link failure 493 4.3.1.2. Wrapping for Node Failure 495 As shown in Figure 6, when Node B fails, Node A detects the failure 496 between A and B and switches the clockwise work ring tunnel (RcW_D) 497 to the anticlockwise protection ring tunnel (RaP_D), Node C detects 498 the failure between C and B and switches the anticlockwise protection 499 ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). 500 The node at the other side of the failed node will be determined by 501 the ring-map and informed using the Ring Protection Switch Protocol 502 (RPS) specified in section 5. 504 The data traffic which enters the ring at Node A and exits at Node D 505 follows the path A->F->E->D->C->D. The label operation is: 507 [LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 508 [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] 509 (NodeC) -> [LSP1](Payload). 511 In one special case where node D fails, all the ring tunnels with 512 node D as egress will become unusable. However, before the failure 513 location information is propagated to all the ring nodes, the 514 wrapping protection mechanism may cause temporary traffic loop: node 515 C detects the failure and switches the traffic from the clockwise 516 work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel 517 (RaP_D), node E also detects the failure and would switch the traffic 518 from anticlockwise protection ring tunnel (RaP_D) back to the 519 clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate 520 the temporary loop problem is: the TTL of the ring tunnel label is 521 set to 2*N by the ingress ring node of the traffic, where N is the 522 number of nodes on the ring. 524 +---+#####[RaP_D(F)]######+---+ 525 | F |---------------------| A | +-- LSP1 526 +---+*****[RcW_D(A)]******+---+ 527 #/* *\# 528 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 529 #/* *\# 530 +---+ xxxxx 531 | E | x B x 532 +---+ xxxxx 533 #\ */# 534 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 535 #\ */# 536 +---+*****[RcW_D(D)]****+---+ 537 LSP1 +-- | D |-------------------| C | 538 +---+#####[RaP_D(C)]####+---+ 540 -----physical links xxxxxx Failure Node 541 *****RcW_D ###### RaP_D 543 Figure 6. Wrapping for node failure 545 4.3.2. Short Wrapping 547 With the wrapping protection scheme, protection switching is executed 548 at both nodes adjacent to the failure, consequently the traffic will 549 be wrapped twice. This mechanism will cause additional latency and 550 bandwidth consumption when traffic is switched to the protection 551 path. 553 With short wrapping protection, data traffic switching is executed 554 only at the node upstream to the failure, and data traffic leaves the 555 ring in the protection ring tunnel at the egress node. This scheme 556 can reduce the additional latency and bandwidth consumption when 557 traffic is switched to the protection path. 559 In the wrapping solution, in normal state the protection ring tunnel 560 is a closed ring, while in the short wrapping solution, the 561 protection ring tunnel is ended at the egress node, which is similar 562 to the working ring tunnel. Short wrapping is easy to implement in 563 shared ring protection because both the working and protection ring 564 tunnels are terminated on the egress nodes. Figure 7 shows the 565 clockwise working ring tunnel and the anticlockwise protection ring 566 tunnel with node D as the egress node. 568 4.3.2.1. Short Wrapping for Link Failure 570 As shown in Figure 7, in normal state, LSP1 is carried by the 571 clockwise working ring tunnel (RcW_D) through the path A->B->C->D. 572 When a link failure between Node B and Node C occurs, Node B switches 573 the working ring tunnel RcW_D to the protection ring tunnel RaP_D in 574 the opposite direction. The difference with wrapping occurs in the 575 protection ring tunnel at egress node. In short wrapping protection, 576 Rap_D ends in Node D and then traffic will be forwarded based on the 577 LSP labels. Thus with short wrapping mechanism, LSP1 will follow the 578 path A->B->A->F->E->D when link failure between Node B and Node C 579 happens. The protection switch at node D is based on the information 580 from its ring map and the information received via the RPS protocol. 582 +---+#####[RaP_D(F)]######+---+ 583 | F |---------------------| A | +-- LSP1 584 +---+*****[RcW_D(A)]******+---+ 585 #/* *\# 586 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 587 #/* *\# 588 +---+ +---+ 589 | E | | B | 590 +---+ +---+ 591 #\ *x# 592 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 593 #\ *x# 594 +---+*****[RcW_D(D)]****+---+ 595 LSP1 +-- | D |-------------------| C | 596 +---+ +---+ 598 ----- physical links xxxxx Failure Link 599 ****** RcW_D ###### RaP_D 601 Figure 7. Short wrapping for link failure 603 4.3.2.2. Short Wrapping for Node Failure 605 For the node failure which happens on a non-egress node, short 606 wrapping protection switching is similar to the link failure case as 607 described in the previous section. This section specifies the 608 scenario of egress node failure. 610 As shown in Figure 8, LSP1 enters the ring on node A, and leaves the 611 ring on node D. In normal state, LSP1 is carried by the clockwise 612 working ring tunnel (RcW_D) through the path A->B->C->D. When node D 613 fails, traffic of LSP1 cannot be protected by any ring tunnels which 614 use node D as the egress node. However, before the failure location 615 information is propagated to all the ring nodes using the RPS 616 protocol, node C switches all the traffic on the working ring tunnel 617 RcW_D to the protection ring tunnel RaP_D in the opposite direction 618 based on the information in the ring map. When the traffic arrives 619 at node E which also detects the failure of node D, the protection 620 ring tunnel RaP_D cannot be used to forward traffic to node D. Since 621 with short wrapping mechanism, protection switching can only be 622 performed once from the working ring tunnel to the protection ring 623 tunnel, thus node E MUST NOT switch the traffic which is already 624 carried on the protection ring tunnel back to the working ring tunnel 625 in the opposite direction. Instead, node E will discard the traffic 626 received on RaP_D locally. This can avoid the temporary traffic loop 627 when the failure happens on the egress node of the ring tunnel. This 628 also illustrates one of the benefits of having separate working and 629 protection ring tunnels in each ring direction. 631 +---+#####[RaP_D(F)]######+---+ 632 | F |---------------------| A | +-- LSP1 633 +---+*****[RcW_D(A)]******+---+ 634 #/* *\# 635 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 636 #/* *\# 637 +---+ +---+ 638 | E | | B | 639 +---+ +---+ 640 #\ */# 641 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 642 #\ */# 643 xxxxx*****[RcW_D(D)]****+---+ 644 LSP1 +-- x D x-------------------| C | 645 xxxxx +---+ 647 -----physical links xxxxxx Failure Node 648 *****RcW_D ###### RaP_D 650 Figure 8. Short Wrapping for egress node failure 652 4.3.3. Steering 654 With steering protection mechanism, the ingress node (which adds 655 traffic to the ring) perform switching from working to the protection 656 ring tunnel, and at the egress node the traffic leaves the ring from 657 the protection ring tunnel. 659 When a failure occurs in the ring, the node which detects the failure 660 via OAM mechanism sends the failure information in the opposite 661 direction of the failure hop by hop along the ring using RPS request 662 message and the ring-map information. When a ring node receives the 663 RPS message which identifies a failure, it can determine the location 664 of the fault by using the topology information of the ring map and 665 update the ring map accordingly, then it can determine whether the 666 LSPs entering the ring locally need to switchover or not. For LSPs 667 that need to switchover, it will switch the LSPs from the working 668 ring tunnels to its corresponding protection ring tunnels. The 669 transfer of the failure information by the RPS protocol will increase 670 the protection switch time. 672 4.3.3.1. Steering for Link Failure 674 Ring map of F +--LSPl 675 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ 676 |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| 677 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ 678 |I|I|I|S|I|I| |I|I|S|I|I|I| 679 +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ 680 [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] 681 #/* [RcW_D(F)] *\# 682 +-+-+-+-+-+-+-+ #/* *\# 683 |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 684 +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ 685 |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| 686 +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 687 #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| 688 [RaP_D(D)] #\* */# +-+-+-+-+-+-+ 689 #\* */# [RaP_D(B)] 690 +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ 691 |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| 692 +-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ 693 |I|I|I|I|I|S| LSP2 |S|I|I|I|I|I| 694 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 696 ----- physical links ***** RcW_D ##### RaP_D 697 I: Intact S: Severed 698 Figure 9. Steering operation and protection switching 700 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 701 enters the ring from Node B, and both of them have the same 702 destination node D. 704 In normal state, LSP1 is carried by the clockwise working ring tunnel 705 (RcW_D) through the path A->B->C->D, the label operation is: 706 [LSP1](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) 707 -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload) . 709 LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught 710 the path B->C->D, the label operation is: [LSP2](Payload) -> 711 [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload) . 713 If the link between nodes C and D fails, according to the fault 714 detection and distribution mechanisms, Node D will find out that 715 there is a failure in the link between C and D, and it will update 716 the link state of its ring topology, changing the link between C and 717 D from normal to fault. In the direction that opposite to the 718 failure position, Node D will send the state report message to Node 719 E, informing Node E of the fault between C and D, and E will update 720 the link state of its ring topology accordingly, changing the link 721 between C and D from normal to fault. In this way, the state report 722 message is sent hop by hop in the clockwise direction. Similar to 723 Node D, Node C will send the failure information in the anti- 724 clockwise direction. 726 When Node A receives the failure report message and updates the link 727 state of its ring map, it is aware that there is a fault on the 728 clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the 729 ring locally and is carried by this ring tunnel, thus Node A will 730 decide to switch the LSP1 onto the anticlockwise protection ring 731 tunnel to node D (RaP_D). After the switchover, LSP1 will follow the 732 path A->F->E->D, the label operation is: [LSP1](Payload) -> 733 [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 734 [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload). 736 The same procedure also applies to the operation of LSP2. When Node 737 B updates the link state of its ring topology, and finds out that the 738 working ring tunnel RcW_D has failed, it will switch the LSP2 to the 739 anticlockwise protection tunnel RaP_D. After the switchover, LSP2 740 goes through the path B->A->F->E->D, and the label operation is: 741 [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) 742 -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> 743 [LSP2](Payload). 745 Assume the link between nodes A and B breaks down, as shown in 746 Figure 10. Similar to the above failure case, Node B will detect a 747 fault in the link between A and B, and it will update its ring map, 748 changing the link state between A and B from normal to fault. The 749 state report message is sent hop by hop in the clockwise direction, 750 notifying every node that there is a fault between node A and B, and 751 every node updates the link state of its ring topology. As a result, 752 Node A will detect a fault in the working ring tunnel to node D, and 753 switch LSP1 to the protection ring tunnel, while Node B determine 754 that the working ring tunnel for LSP2 still works fine, and will not 755 perform the switchover. 757 /-- LSPl 758 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ 759 |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| 760 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ 761 |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| 762 +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ 763 [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] 764 #/* x +-- LSP2 765 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 766 |E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B| 767 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 768 |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| 769 +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ 770 [RaP_D(D)] #\* */# [RaP_D(B)] 771 +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 772 |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| 773 +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ 774 |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| 775 +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ 777 ----- physical links ***** RcW_D ##### RaP_D 779 Figure 10. Steering operation and protection switching (2) 781 4.3.3.2. Steering for Node Failure 783 For node failure which happens on a non-egress node, steering 784 protection switching is similar to the link failure case as described 785 in the previous section. 787 If the failure occurs at the egress node of the LSP, since the 788 ingress node can update its ring map according to the received RPS 789 messages, it will determine that the egress node is not reachable 790 after the failure, thus it will not send traffic to either the 791 working or protection tunnel, and traffic loop can be avoided. 793 4.4. Interconnected Ring Protection 795 4.4.1. Interconnected Ring Topology 797 Interconnected ring topology is widely used in MPLS-TP networks. 798 This document will discuss two typical interconnected ring 799 topologies: 801 1. Single-node interconnected rings 803 In single-node interconnected rings, the connection between 804 the two rings is through a single node. Because the 805 interconnection node is in fact a single point of failure, 806 this topology should be avoided in real transport networks. 807 Figure 11 shows the topology of single-node interconnected 808 rings. Node C is the interconnection node between Ring1 and 809 Ring2. 811 2. Dual-node interconnected rings 813 In dual-node interconnected rings, the connection between the 814 two rings is through two nodes. The two interconnection nodes 815 belong to both interconnected rings. This topology can 816 recover from one interconnection node failure. 818 Figure 11 shows the topology of single-node interconnected rings. 819 Node C is the interconnection node between Ring1 and Ring2. 821 +---+ +---+ +---+ +---+ 822 | A |------| B |----- -----| G |------| H | 823 +---+ +---+ \ / +---+ +---+ 824 | \ / | 825 | \ +---+ / | 826 | Ring1 | C | Ring2 | 827 | / +---+ \ | 828 | / \ | 829 +---+ +---+ / \ +---+ +---+ 830 | F |------| E |----- -----| J |------| I | 831 +---+ +---+ +---+ +---+ 833 Figure 11. Single-node interconnected rings 835 Figure 12 shows the topology of dual-node interconnected rings. 836 Nodes C and Node D are the interconnection nodes between Ring1 and 837 Ring2. 839 +---+ +---+ +---+ +---+ +---+ 840 | A |------| B |------| C |------| G |------| H | 841 +---+ +---+ +---+ +---+ +---+ 842 | | | | 843 | | | | 844 | Ring1 | | Ring2 | 845 | | | | 846 | | | | 847 +---+ +---+ +---+ +---+ +---+ 848 | F |------| E |------| D |------| J |------| I | 849 +---+ +---+ +---+ +---+ +---+ 851 Figure 12. Dual-node interconnected rings 853 4.4.2. Interconnected Ring Protection Mechanisms 855 Interconnected rings can be treated as two independent rings. Ring 856 protection switching (RPS) protocol operates on each ring 857 independently. A failure that happens in one ring only triggers 858 protection switching in the ring itself and does not affect the other 859 ring, unless the failure is on the interconnection node. In this 860 way, protection switching on each ring is the same as the mechanisms 861 described in section 4.3. 863 The service LSPs that traverse the interconnected rings use separate 864 ring tunnels on each ring, and the LSPs on different rings are 865 stitched by the interconnection node. On the interconnection node, 866 the ring tunnel label of the source ring is popped, then LSP label is 867 swapped, after that the ring tunnel label of the destination ring is 868 pushed. 870 In the dual-node interconnected ring scenario, the two 871 interconnection nodes can be managed as a virtual node group. In 872 addition to the ring tunnels to each physical ring node, Each ring 873 SHOULD assign the working and protection ring tunnels to the virtual 874 interconnection node group. In addition, on both nodes in the 875 virtual interconnection node group, the same LSP label is assigned 876 for each traversed LSP. This way, any interconnection node in the 877 virtual node group can terminate the working or protection ring 878 tunnels targeted to the virtual node group, and stitch the service 879 LSP from the source ring tunnel to the destination ring tunnel. 881 When the service LSP passes through the interconnected rings, the 882 direction of the working ring tunnels used on both rings SHOULD be 883 the same. For example, if the service LSP uses the clockwise working 884 ring tunnel on Ring1, when the service LSP leaves Ring1 and enters 885 Ring2, the working ring tunnel used on Ring2 SHOULD also follow the 886 clockwise direction. 888 4.4.3. Ring Tunnels in Interconnected Rings 890 The same ring tunnels as described in section 4.1 are used in each 891 ring of the interconnected rings. In addition, ring tunnels to the 892 virtual interconnection node group are established on each ring of 893 the interconnected rings, i.e.: 895 o one clockwise working ring tunnel to the virtual interconnection 896 node group 898 o one anticlockwise protection ring tunnel to the virtual 899 interconnection node group 901 o one anticlockwise working ring tunnel to the virtual 902 interconnection node group 904 o one clockwise protection ring tunnel to the virtual 905 interconnection node group 907 These ring tunnels will terminated at any node in the virtual 908 interconnection node group. 910 For example, all the ring tunnels on Ring1 in Figure 13 are 911 provisioned as follows: 913 o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A 915 o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B 917 o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C 919 o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D 921 o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E 923 o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F 925 o To the virtual interconnection node group (including Node F and 926 Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A 928 All the ring tunnels on Ring2 in Figure 13 are provisioned as 929 follows: 931 o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A 933 o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F 935 o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G 937 o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H 939 o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I 941 o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J 943 o To the virtual interconnection node group (including Node F and 944 Node A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A 945 +---+cccccccccccc +---+ 946 | H |-------------| I |--->LSP1 947 +---+ +---+ 948 c/a a\ 949 c/a a\ 950 c/a a\ 951 +---+ +---+ 952 | G | Ring2 | J | 953 +---+ +---+ 954 c\a a/c 955 c\a a/c 956 c\a aaaaaaaaaaaaa a/c 957 +---+ccccccccccccc+---+ 958 | F |-------------| A | 959 +---+ccccccccccccc+---+ 960 c/aaaaaaaaaaaaaaaaaaa a\ 961 c/ a\ 962 c/ a\ 963 +---+ +---+ 964 | E | Ring1 | B | 965 +---+ +---+ 966 c\a a/c 967 c\a a/c 968 c\a a/c 969 +---+aaaaaaaaaaaa +---+ 970 LSP1--->| D |-------------| C | 971 +---+ccccccccccccc+---+ 973 ccccccccccc R1cW_F&A 974 aaaaaaaaaaa R1aP_F&A 975 ccccccccccc R2cW_I 976 aaaaaaaaaaa R2aP_I 977 Figure 13. Ring tunnels for the interconnected rings 979 4.4.4. Interconnected Ring Switching Procedure 981 As shown in Figure 13, for the service LSP1 which enters Ring1 at 982 Node D and leaves Ring1 at Node F and continues to enter Ring2 at 983 Node F and leaves Ring2 at Node I, the short wrapping protection 984 scheme is described as below. 986 In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. 987 At the interconnection node F, the label used for the working ring 988 tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the 989 label used for the working ring tunnel R2cW_I in Ring2 will be pushed 990 based the inner LSP label lookup. The working path that the service 991 LSP1 follows is: LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. 993 In case of link failure, for example, when a failure occurs on the 994 link between Node F and Node E, Node E will detect the failure and 995 execute protection switching as described in 4.3.2. The path that 996 the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- 997 >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 999 In case of a non-interconnection node failure, for example, when the 1000 failure occurs at Node E in Ring1, Node D will detect the failure and 1001 execute protection switching as described in 4.3.2. The path that 1002 the service LSP1 follows after switching becomes: 1003 LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 1005 In case of an interconnection node failure, for example, when the 1006 failure occurs at the interconnection Node F. Node E in Ring1 will 1007 detect the failure, and execute protection switching as described in 1008 4.3.2. Node A in Ring2 will also detect the failure, and execute 1009 protection switching as described in 4.3.2. The path that the 1010 service traffic LSP1 follows after switching is: 1011 LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1. 1013 4.4.5. Interconnected Ring Detection Mechanism 1015 As show in Figure 13, in normal state the service traffic LSP1 1016 traverses D->E->F in Ring1 and F->G->H->I in Ring2. Node A and F are 1017 the interconnection nodes. When both the link between Node F and 1018 Node G and the link between Node F and Node A fail, the ring tunnel 1019 from Node F to Node I in Ring2 becomes unreachable. However, the 1020 other interconnection node A is still available, and LSP1 can still 1021 reach Node I via node A. 1023 In order to achieve this, the interconnection nodes need to know the 1024 ring topology of each ring so that they can judge whether a node is 1025 reachable. This judgment is based on the knowledge of ring map and 1026 the fault location as described in section 3.4. The ring map can be 1027 obtained from the NMS or topology discovery mechanisms. The fault 1028 location can be obtained by transmitting the fault information around 1029 the ring. The nodes that detect the failure will transmit the fault 1030 information in the opposite direction hop by hop using the RPS 1031 protocol message. When the interconnection node receives the message 1032 that informs the failure, it will quickly calculate the location of 1033 the fault according to the topology information that is maintained by 1034 itself and determines whether the LSPs entering the ring at itself 1035 can reach the destination. If the destination node is reachable, the 1036 LSP will leave the source ring and enter the destination ring. If 1037 the destination node is not reachable, the LSP will switch to the 1038 anticlockwise protection ring tunnel. 1040 In Figure 13, Node F determines that the ring tunnel to Node I is 1041 unreachable, the service LSP1 for which the destination node on the 1042 ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A) 1043 and consequently the service traffic LSP1 traverses the 1044 interconnected rings at Node A. Node A will pop the ring tunnel 1045 label of Ring1 and push the ring tunnel label of Ring2 and send the 1046 traffic to Node I via ring tunnel (R2aW_I). 1048 5. Ring Protection Coordination Protocol 1050 5.1. RPS Protocol 1052 The MSRP protection operation MUST be controlled with the help of the 1053 Ring Protection Switch protocol (RPS). The RPS processes in each of 1054 the individual ring nodes that form the ring MUST communicate using 1055 the G-ACh channel. The described RPS protocol uses the short- 1056 wrapping mechanism described in section 4.3.2 as an example. 1058 All nodes in the same ring MUST use the same protection mechanism, 1059 Wrapping, steering or short-wrapping. 1061 The RPS protocol MUST carry the ring status information and RPS 1062 requests, either automatically initiated or externally initiated, 1063 between the ring nodes. 1065 Each node on the ring MUST be uniquely identified by assigning it a 1066 node ID. The node ID MUST be unique on each ring. The maximum 1067 number of nodes on the ring supported by the RPS protocol is 127. 1068 The node ID SHOULD be independent of the order in which the nodes 1069 appear on the ring. The node ID is used to identity the source and 1070 destination nodes of each RPS request. 1072 Every node obtains the ring topology either by configuration or via 1073 some topology discovery mechanism. The ring map consists of the ring 1074 topology information, and connectivity status (Intact or Severed) 1075 between the adjacent ring nodes, which is determined via the OAM 1076 message exchanged between the adjacent nodes. The ring map is used 1077 by every ring node to determine the switchover behavior of the ring 1078 tunnels. 1080 When no protection switching is active on the ring, each node MUST 1081 dispatch periodically RPS requests to the two adjacent nodes, 1082 indicating No Request (NR). When a node determines that a protection 1083 switching is required, it MUST send the appropriate RPS request in 1084 both directions. 1086 +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) 1087 -------| A |-------------| B |-------------| C |------- 1088 (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ 1090 Figure 14. RPS communication between the ring nodes in case of 1091 no failure in the ring 1093 A destination node is a node that is adjacent to a node that 1094 identified a failed span. When a node that is not the destination 1095 node receives an RPS request and it has no higher priority local 1096 request, it MUST transfer in the same direction the RPS request as 1097 received. In this way, the switching nodes can maintain direct RPS 1098 protocol communication in the ring. 1100 +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) 1101 -------| A |-------------| B |----- X -----| C |------- 1102 (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ 1104 Figure 15. RPS communication between the ring nodes in case of 1105 failure between nodes B and C 1107 Note that in the case of a bidirectional failure such as a cable cut, 1108 the two adjacent nodes detect the failure and send each other an RPS 1109 request in opposite directions. 1111 o In rings utilizing the wrapping protection, each node detects the 1112 failure or receives the RPS request as the destination node MUST 1113 perform the switch from/to the working ring tunnels to/from the 1114 protection ring tunnels if it has no higher priority active RPS 1115 request. 1117 o In rings utilizing the short wrapping protection, each node 1118 detects the failure or receives the RPS request as the destination 1119 node MUST perform the switch only from the working ring tunnels to 1120 the protection ring tunnels. 1122 o In rings utilizing the steering protection. When a ring switch is 1123 required, any node MUST perform the switches if its added/dropped 1124 traffic is affected by the failure. Determination of the affected 1125 traffic SHOULD be performed by examining the RPS requests 1126 (indicating the nodes adjacent to the failure or failures) and the 1127 stored ring map (indicating the relative position of the failure 1128 and the added traffic destined towards that failure). 1130 When the failure has cleared and the Wait-to-Restore (WTR) timer has 1131 expired, the nodes sourcing RPS requests MUST drop their respective 1132 switches (tail end) and MUST source an RPS request carrying the NR 1133 code. The node receiving from both directions such RPS request (head 1134 end) MUST drop its protection switches. 1136 A protection switch MUST be initiated by one of the criteria 1137 specified in Section 5.2. A failure of the RPS protocol or 1138 controller MUST NOT trigger a protection switch. 1140 Ring switches MUST be preempted by higher priority RPS requests. For 1141 example, consider a protection switch that is active due to a manual 1142 switch request on the given span, and another protection switch is 1143 required due to a failure on another span. Then an RPS request MUST 1144 be generated, the former protection switch MUST be dropped, and the 1145 latter protection switch established. 1147 MSRP mechanism SHOULD support multiple protection switches in the 1148 ring, resulting the ring being segmented into two or more separate 1149 segments. This may happen when several RPS requests of the same 1150 priority exist in the ring due to multiple failures or external 1151 switch commands. 1153 Proper operation of the MSRP mechanism relies on all nodes having 1154 knowledge of the state of the ring (nodes and spans) so that nodes do 1155 not preempt existing RPS request unless they have a higher-priority 1156 RPS request. In order to accommodate ring state knowledge, during a 1157 protection switch the RPS requests MUST be sent in both directions. 1159 5.1.1. Transmission and Acceptance of RPS Requests 1161 A new RPS request MUST be transmitted immediately when a change in 1162 the transmitted status occurs. 1164 The first three RPS protocol messages carrying new RPS request SHOULD 1165 be transmitted as fast as possible. For fast protection switching 1166 within 50 ms, the interval of the first three RPS protocol messages 1167 SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted 1168 with the interval of 5 seconds. A ring node which is not the 1169 destination of the received RPS message MUST forward it to the next 1170 node along the ring immediately. 1172 5.1.2. RPS PDU Format 1174 Figure 17 depicts the format of an RPS packet that is sent on the 1175 G-ACh. The Channel Type field is set to indicate that the message is 1176 an RPS message. The ACH MUST NOT include the ACH TLV Header 1177 [RFC5586] meaning that no ACH TLVs can be included in the message. 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Dest Node ID | Src Node ID | Request | M | Reserved | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 Figure 16. G-ACh RPS Packet Format 1188 The following fields MUST be provided: 1190 o Destination Node ID: The destination node ID MUST always be set to 1191 value of the node ID of the adjacent node. The Node ID MUST be 1192 unique on each ring. Valid destination node ID values are 1-127. 1194 o Source Node ID: The source node ID MUST always be set to the ID 1195 value of the node generating the RPS request. The Node ID MUST be 1196 unique on each ring. Valid source node ID values are 1-127. 1198 o Protection Switching Mode (M): This 2-bit field indicates the 1199 protection swithcing mode used by the sending node of the RPS 1200 message. This can be used to check that the ring nodes on the 1201 same ring use the same protecion switching mechanism. The defined 1202 values of the M field are listed as below: 1204 +------------------+-----------------------------+ 1205 | Bits (MSB-LSB) | Protecton Switching Mode | 1206 +------------------+-----------------------------+ 1207 | 0 0 | Wrapping | 1208 | 0 1 | Short Wrapping | 1209 | 1 0 | Steering | 1210 | 1 1 | Reserved | 1211 +------------------+-----------------------------+ 1213 o RPS request code: A code consisting of eight bits as specified 1214 below: 1216 +------------------+-----------------------------+----------+ 1217 | Bits | Condition, State | Priority | 1218 | (MSB - LSB) | or external Request | | 1219 +------------------+-----------------------------+----------+ 1220 | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | 1221 | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | 1222 | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | 1223 | 0 0 0 0 0 1 1 0 | Manual Switch (MS) | | 1224 | 0 0 0 0 0 1 0 1 | Wait-To-Restore (WTR) | | 1225 | 0 0 0 0 0 0 1 1 | Exercise (EXER) | | 1226 | 0 0 0 0 0 0 0 1 | Reverse Request (RR) | | 1227 | 0 0 0 0 0 0 0 0 | No Request (NR) | lowest | 1228 +------------------+-----------------------------+----------+ 1230 5.1.3. Ring Node RPS States 1232 Idle state: A node is in the idle state when it has no RPS request 1233 and is sourcing and receiving NR code to/from both directions. 1235 Switching state: A node not in the idle or pass-through states is in 1236 the switching state. 1238 Pass-through state: A node is in the pass-through state when its 1239 highest priority RPS request is a request not destined to it or 1240 sourced by it. The pass-through is bidirectional. 1242 5.1.3.1. Idle State 1244 A node in the idle state MUST source the NR request in both 1245 directions. 1247 A node in the idle state MUST terminate RPS requests flow in both 1248 directions. 1250 A node in the idle state MUST block the traffic flow on protection 1251 ring tunnels in both directions. 1253 5.1.3.2. Switching State 1255 A node in the switching state MUST source RPS request to adjacent 1256 node with its highest RPS request code in both directions when it 1257 detects a failure or receives an external command. 1259 A node in the switching state MUST terminate RPS requests flow in 1260 both directions. 1262 As soon as it receives an RPS request from the short path, the node 1263 to which it is addressed MUST acknowledge the RPS request by replying 1264 with the RR code on the short path, and with the received RPS request 1265 code on the long path. Accordingly, if RR code is received from the 1266 short path, then the RPS request sent by the same node over the long 1267 path SHOULD be ignored. Here the short path refers to the shorter 1268 span on the ring between the source and destination node of the RPS 1269 request, and the long path refers to the longer span on the ring 1270 between the source and destination node of the RPS request. 1272 This rule refers to the unidirectional failure detection: the RR 1273 SHOULD be issued only when the node does not detect the failure 1274 condition (i.e., the node is a head end), that is, it is not 1275 applicable when a bidirectional failure is detected, because, in this 1276 case, both nodes adjacent to the failure will send an RPS request for 1277 the failure on both paths (short and long). 1279 The following switches MUST be allowed to coexist: 1281 o LP and LP 1283 o FS and FS 1285 o SF and SF 1287 o FS and SF 1289 When multiple MS RPS requests over different spans exist at the same 1290 time, no switch SHOULD be executed and existing switches MUST be 1291 dropped. The nodes MUST signal, anyway, the MS RPS request code. 1293 Multiple EXER requests MUST be allowed to coexist in the ring. 1295 A node in a ring switching state that receives the external command 1296 LP for the affected span MUST drop its switch and MUST signal NR for 1297 the locked span if there is no other RPS request on another span. 1298 Node still SHOULD signal relevant RPS request for another span. 1300 5.1.3.3. Pass-through State 1302 When a node is in a pass-through state, it MUST transfer the received 1303 RPS Request in the same direction. 1305 When a node is in a pass-through state, it MUST enable the traffic 1306 flow on protection ring tunnels in both directions. 1308 5.1.4. RPS State Transitions 1310 All state transitions are triggered by an incoming RPS request 1311 change, a WTR expiration, an externally initiated command, or locally 1312 detected MPLS-TP section failure conditions. 1314 RPS requests due to a locally detected failure, an externally 1315 initiated command, or received RPS request shall preempt existing RPS 1316 requests in the prioritized order given in Section 5.1.2, unless the 1317 requests are allowed to coexist. 1319 5.1.4.1. Transitions Between Idle and Pass-through States 1321 The transition from the idle state to pass-through state MUST be 1322 triggered by a valid RPS request change, in any direction, from the 1323 NR code to any other code, as long as the new request is not destined 1324 to the node itself. Both directions move then into a pass-through 1325 state, so that, traffic entering the node through the protection Ring 1326 tunnels are transferred transparently through the node. 1328 A node MUST revert from pass-through state to the idle state when it 1329 detects NR codes incoming from both directions. Both directions 1330 revert simultaneously from the pass-through state to the idle state. 1332 5.1.4.2. Transitions Between Idle and Switching States 1334 Transition of a node from the idle state to the switching state MUST 1335 be triggered by one of the following conditions: 1337 o A valid RPS request change from the NR code to any code received 1338 on either the long or the short path and destined to this node 1340 o An externally initiated command for this node 1342 o The detection of an MPLS-TP section layer failure at this node 1344 Actions taken at a node in the idle state upon transition to 1345 switching state are: 1347 o For all protection switch requests, except EXER and LP, the node 1348 MUST execute the switch 1350 o For EXER, and LP, the node MUST signal appropriate request but not 1351 execute the switch 1353 A node MUST revert from the switching state to the idle state when it 1354 detects NR codes received from both directions. 1356 o At the tail end: When a WTR time expires or an externally 1357 initiated command is cleared at a node, the node MUST drop its 1358 switch, transit to the Idle State and signal the NR code in both 1359 directions. 1361 o At the head end: Upon reception of the NR code, from both 1362 directions, the head-end node MUST drop its switch, transition to 1363 Idle State and signal the NR code in both directions. 1365 5.1.4.3. Transitions Between Switching States 1367 When a node that is currently executing any protection switch 1368 receives a higher priority RPS request (due to a locally detected 1369 failure, an externally initiated command, or a ring protection switch 1370 request destined to it) for the same span, it MUST update the 1371 priority of the switch it is executing to the priority of the 1372 received RPS request. 1374 When a failure condition clears at a node, the node MUST enter WTR 1375 condition and remain in it for the appropriate time-out interval, 1376 unless: 1378 o A different RPS request with a higher priority than WTR is 1379 received 1381 o Another failure is detected 1383 o An externally initiated command becomes active 1385 The node MUST send out a WTR code on both the long and short paths. 1387 When a node that is executing a switch in response to incoming SF RPS 1388 request (not due to a locally detected failure) receives a WTR code 1389 (unidirectional failure case), it MUST send out RR code on the short 1390 path and the WTR on the long path. 1392 5.1.4.4. Transitions Between Switching and Pass-through States 1394 When a node that is currently executing a switch receives an RPS 1395 request for a non-adjacent span of higher priority than the switch it 1396 is executing, it MUST drop its switch immediately and enter the pass- 1397 through state. 1399 The transition of a node from pass-through to switching state MUST be 1400 triggered by: 1402 o An equal priority, a higher priority, or an allowed coexisting 1403 externally initiated command 1405 o The detection of an equal priority, a higher priority, or an 1406 allowed coexisting automatic initiated command 1408 o The receipt of an equal, a higher priority, or an allowed 1409 coexisting RPS request destined to this node 1411 5.2. RPS State Machine 1413 5.2.1. Switch Initiation Criteria 1415 5.2.1.1. Administrative Commands 1417 Administrative commands can be initiated by the network operator 1418 through the Network Management System (NMS). The operator command 1419 may be transmitted to the appropriate node via the MPLS-TP RPS 1420 message. 1422 The following commands can be transferred by the RPS message: 1424 o Lockout of Protection (LP): This command prevents any protection 1425 activity and prevents using ring switches anywhere in the ring. 1426 If any ring switches exist in the ring, this command causes the 1427 switches to drop. 1429 o Forced Switch to protection (FS): This command performs the ring 1430 switch of normal traffic from the working entity to the protection 1431 entity for the span between the node at which the command is 1432 initiated and the adjacent node to which the command is directed. 1433 This switch occurs regardless of the state of the MPLS-TP section 1434 for the requested span, unless a higher priority switch request 1435 exists. 1437 o Manual Switch to protection (MS): This command performs the ring 1438 switch of the normal traffic from the working entity to the 1439 protection entity for the span between the node at which the 1440 command is initiated and the adjacent node to which the command is 1441 directed. This occurs if the MPLS-TP section for the requested 1442 span is not satisfying an equal or higher priority switch request. 1444 o Exercise - Ring (EXER): This command exercises ring protection 1445 switching on the addressed span without completing the actual 1446 switch. The command is issued and the responses (RR) are checked, 1447 but no normal traffic is affected. 1449 The following commands are not transferred by the RPS message: 1451 o Clear: This command clears the administrative command and Wait-To- 1452 Restore timer (WTR) at the node to which the command was 1453 addressed. The node-to-node signaling after the removal of the 1454 externally initiated commands is performed using the no-request 1455 code (NR). 1457 o Lockout of Working: This command prevents the normal traffic 1458 transported over the addressed span from being switched to the 1459 protection entity by disabling the node's capability of requesting 1460 switch for this span in case of failure. If any normal traffic is 1461 already switched on the protection entity, the switch is dropped. 1462 If no other switch requests are active on the ring, the no-request 1463 code (NR) is transmitted. This command has no impact on any other 1464 span. If the node receives the switch request from the adjacent 1465 node from any side it will perform the requested switch. If the 1466 node receives the switch request addressed to the other node, it 1467 will enter the pass-through state. 1469 5.2.1.2. Automatically Initiated Commands 1471 Automatically initiated commands can be initiated based on MPLS-TP 1472 section layer OAM indication and the received switch requests. 1474 The node can initiate the following switch requests automatically: 1476 o Signal Fail (SF): This command is issued when the MPLS-TP section 1477 layer OAM detects signal failure condition. 1479 o Wait-To-Restore (WTR): This command is issued when MPLS-TP section 1480 detects that the SF condition has cleared. It is used to maintain 1481 the state during the WTR period unless it is preempted by a higher 1482 priority switch request. The WTR time may be configured by the 1483 operator in 1 minute steps between 0 and 12 minutes; the default 1484 value is 5 minutes. 1486 o Reverse Request (RR): This command is transmitted to the source 1487 node of the received RPS message over the short path as an 1488 acknowledgment for receiving the switch request. 1490 5.2.2. Initial States 1491 +-----------------------------------+----------------+ 1492 | State | Signaled RPS | 1493 +-----------------------------------+----------------+ 1494 | A | Idle | NR | 1495 | | Working: no switch | | 1496 | | Protection: no switch | | 1497 +-----+-----------------------------+----------------+ 1498 | B | Pass-through | N/A | 1499 | | Working: no switch | | 1500 | | Protection: pass through | | 1501 +-----+-----------------------------+----------------+ 1502 | C | Switching - LP | LP | 1503 | | Working: no switch | | 1504 | | Protection: no switch | | 1505 +-----+-----------------------------+----------------+ 1506 | D | Idle - LW | NR | 1507 | | Working: no switch | | 1508 | | Protection: no switch | | 1509 +-----+-----------------------------+----------------+ 1510 | E | Switching - FS | FS | 1511 | | Working: switched | | 1512 | | Protection: switched | | 1513 +-----+-----------------------------+----------------+ 1514 | F | Switching - SF | SF | 1515 | | Working: switched | | 1516 | | Protection: switched | | 1517 +-----+-----------------------------+----------------+ 1518 | G | Switching - MS | MS | 1519 | | Working: switched | | 1520 | | Protection: switched | | 1521 +-----+-----------------------------+----------------+ 1522 | H | Switching - WTR | WTR | 1523 | | Working: switched | | 1524 | | Protection: switched | | 1525 +-----+-----------------------------+----------------+ 1526 | I | Switching - EXER | EXER | 1527 | | Working: no switch | | 1528 | | Protection: no switch | | 1529 +-----+-----------------------------+----------------+ 1531 5.2.3. State transitions When Local Request is Applied 1533 In the state description below 'O' means that new local request will 1534 be rejected because of exiting request. 1536 ===================================================================== 1537 Initial state New request New state 1538 ------------- ----------- --------- 1539 A (Idle) LP C (Switching - LP) 1540 LW D (Idle - LW) 1541 FS E (Switching - FS) 1542 SF F (Switching - SF) 1543 Recover from SF N/A 1544 MS G (Switching - MS) 1545 Clear N/A 1546 WTR expires N/A 1547 EXER I (Switching - EXER) 1548 ===================================================================== 1549 Initial state New request New state 1550 ------------- ----------- --------- 1551 B (Pass-through) LP C (Switching - LP) 1552 LW B (Pass-through) 1553 FS O - if current state is due to 1554 LP sent by another node 1555 E (Switching - FS) - otherwise 1556 SF O - if current state is due to 1557 LP sent by another node 1558 F (Switching - SF) - otherwise 1559 Recover from SF N/A 1560 MS O - if current state is due to 1561 LP, SF or FS sent by 1562 another node 1563 G (Switching - MS) - otherwise 1564 Clear N/A 1565 WTR expires N/A 1566 EXER O 1567 ===================================================================== 1568 Initial state New request New state 1569 ------------- ----------- --------- 1570 C (Switching - LP) LP N/A 1571 LW O 1572 FS O 1573 SF O 1574 Recover from SF N/A 1575 MS O 1576 Clear A (Idle) - if there is no 1577 failure in the ring 1578 F (Switching - SF) - if there 1579 is a failure at this node 1580 B (Pass-through) - if there is 1581 a failure at another node 1582 WTR expires N/A 1583 EXER O 1584 ===================================================================== 1585 Initial state New request New state 1586 ------------- ----------- --------- 1587 D (Idle - LW) LP C (Switching - LP) 1588 LW N/A - if on the same span 1589 D (Idle - LW) - if on another 1590 span 1591 FS O - if on the same span 1592 E (Switching - FS) - if on 1593 another span 1594 SF O - if on the addressed span 1595 F (Switching - SF) - if on 1596 another span 1597 Recover from SF N/A 1598 MS O - if on the same span 1599 G (Switching - MS) - if on 1600 another span 1601 Clear A (Idle) - if there is no 1602 failure on addressed span 1603 F (Switching - SF) - if there 1604 is a failure on this span 1605 WTR expires N/A 1606 EXER O 1607 ===================================================================== 1608 Initial state New request New state 1609 ------------- ----------- --------- 1610 E (Switching - FS) LP C (Switching - LP) 1611 LW O - if on another span 1612 D (Idle - LW) - if on the same 1613 span 1614 FS N/A - if on the same span 1615 E (Switching - FS) - if on 1616 another span 1617 SF O - if on the addressed span 1618 E (Switching - FS) - if on 1619 another span 1620 Recover from SF N/A 1621 MS O 1622 Clear A (Idle) - if there is no 1623 failure in the ring 1624 F (Switching - SF) - if there 1625 is a failure at this node 1626 B (Pass-through) - if there is 1627 a failure at another node 1628 WTR expires N/A 1629 EXER O 1630 ===================================================================== 1631 Initial state New request New state 1632 ------------- ----------- --------- 1633 F (Switching - SF) LP C (Switching - LP) 1634 LW O - if on another span 1635 D (Idle - LW) - if on the same 1636 span 1637 FS E (Switching - FS) 1638 SF N/A - if on the same span 1639 F (Switching - SF) - if on 1640 another span 1641 Recover from SF H (Switching - WTR) 1642 MS O 1643 Clear N/A 1644 WTR expires N/A 1645 EXER O 1646 ===================================================================== 1647 Initial state New request New state 1648 ------------- ----------- --------- 1649 G (Switching - MS) LP C (Switching - LP) 1650 LW O - if on another span 1651 D (Idle - LW) - if on the same 1652 span 1653 FS E (Switching - FS) 1654 SF F (Switching - SF) 1655 Recover from SF N/A 1656 MS N/A - if on the same span 1657 G (Switching - MS) - if on 1658 another span release the 1659 switches but signal MS 1660 Clear A 1661 WTR expires N/A 1662 EXER O 1663 ===================================================================== 1664 Initial state New request New state 1665 ------------- ----------- --------- 1666 H (Switching - WTR) LP C (Switching - LP) 1667 LW D (Idle - W) 1668 FS E (Switching - FS) 1669 SF F (Switching - SF) 1670 Recover from SF N/A 1671 MS G (Switching - MS) 1672 Clear A 1673 WTR expires A 1674 EXER O 1675 ===================================================================== 1676 Initial state New request New state 1677 ------------- ----------- --------- 1678 I (Switching - EXER) LP C (Switching - LP) 1679 LW D (idle - W) 1680 FS E (Switching - FS) 1681 SF F (Switching - SF) 1682 Recover from SF N/A 1683 MS G (Switching - MS) 1684 Clear A 1685 WTR expires N/A 1686 EXER N/A - if on the same span 1687 I (Switching - EXER) 1688 ===================================================================== 1690 5.2.4. State Transitions When Remote Request is Applied 1692 The priority of a remote request does not depend on the side from 1693 which the request is received. 1695 ===================================================================== 1696 Initial state New request New state 1697 ------------- ----------- --------- 1698 A (Idle) LP C (Switching - LP) 1699 FS E (Switching - FS) 1700 SF F (Switching - SF) 1701 MS G (Switching - MS) 1702 WTR N/A 1703 EXER I (Switching - EXER) 1704 RR N/A 1705 NR A (Idle) 1706 ===================================================================== 1707 Initial state New request New state 1708 ------------- ----------- --------- 1709 B (Pass-through) LP C (Switching - LP) 1710 FS N/A - cannot happen when there 1711 is LP request in the ring 1712 E (Switching - FS) - otherwise 1713 SF N/A - cannot happen when there 1714 is LP request in the ring 1715 F (Switching - SF) - otherwise 1716 MS N/A - cannot happen when there 1717 is LP, FS or SF request 1718 in the ring 1719 G (Switching - MS) - otherwise 1720 WTR N/A - cannot happen when there 1721 is LP, FS, SF or MS 1722 request in the ring 1723 EXER N/A - cannot happen when there 1724 is LP, FS, SF, MS or WTR 1725 request in the ring 1726 I (Switching - EXER) - 1727 otherwise 1728 RR N/A 1729 NR A (Idle) - if received from 1730 both sides 1731 ===================================================================== 1732 Initial state New request New state 1733 ------------- ----------- --------- 1734 C (Switching - LP) LP C (Switching - LP) 1735 FS N/A - cannot happen when there 1736 is LP request in the ring 1737 SF N/A - cannot happen when there 1738 is LP request in the ring 1739 MS N/A - cannot happen when there 1740 is LP request in the ring 1741 WTR N/A 1742 EXER N/A - cannot happen when there 1743 is LP request in the ring 1744 RR C (Switching - LP) 1745 NR N/A 1746 ===================================================================== 1747 Initial state New request New state 1748 ------------- ----------- --------- 1749 D (Idle - LW) LP C (Switching - LP) 1750 FS E (Switching - FS) 1751 SF F (Switching - SF) 1752 MS G (Switching - MS) 1753 WTR N/A 1754 EXER I (Switching - EXER) 1755 RR N/A 1756 NR D (Idle - LW) 1757 ===================================================================== 1758 Initial state New request New state 1759 ------------- ----------- --------- 1760 E (Switching - FS) LP C (Switching - LP) 1761 FS E (Switching - FS) 1762 SF E (Switching - FS) 1763 MS N/A - cannot happen when there 1764 is FS request in the ring 1765 WTR N/A 1766 EXER N/A - cannot happen when there 1767 is FS request in the ring 1768 RR E (Switching - FS) 1769 NR N/A 1770 ===================================================================== 1771 Initial state New request New state 1772 ------------- ----------- --------- 1773 F (Switching - SF) LP C (Switching - LP) 1774 FS F (Switching - SF) 1775 SF F (Switching - SF) 1776 MS N/A - cannot happen when there 1777 is SF request in the ring 1779 WTR N/A 1780 EXER N/A - cannot happen when there 1781 is SF request in the ring 1782 RR F (Switching - SF) 1783 NR N/A 1784 ===================================================================== 1785 Initial state New request New state 1786 ------------- ----------- --------- 1787 G (Switching - MS) LP C (Switching - LP) 1788 FS E (Switching - FS) 1789 SF F (Switching - SF) 1790 MS G (Switching - MS) - release 1791 the switches but signal MS 1792 WTR N/A 1793 EXER N/A - cannot happen when there 1794 is MS request in the ring 1795 RR G (Switching - MS) 1796 NR N/A 1797 ===================================================================== 1798 Initial state New request New state 1799 ------------- ----------- --------- 1800 H (Switching - WTR) LP C (Switching - LP) 1801 FS E (Switching - FS) 1802 SF F (Switching - SF) 1803 MS G (Switching - MS) 1804 WTR H (Switching - WTR) 1805 EXER N/A - cannot happen when there 1806 is WTR request in the ring 1807 RR H (Switching - WTR) 1808 NR N/A 1809 ===================================================================== 1810 Initial state New request New state 1811 ------------- ----------- --------- 1812 I (Switching - EXER) LP C (Switching - LP) 1813 FS E (Switching - FS) 1814 SF F (Switching - SF) 1815 MS G (Switching - MS) 1816 WTR N/A 1817 EXER I (Switching - EXER) 1818 RR I (Switching - EXER) 1819 NR N/A 1820 ===================================================================== 1822 5.2.5. State Transitions When Request Addresses to Another Node is 1823 Received 1825 The priority of a remote request does not depend on the side from 1826 which the request is received. 1828 ===================================================================== 1829 Initial state New request New state 1830 ------------- ----------- --------- 1831 A (Idle) LP B (Pass-through) 1832 FS B (Pass-through) 1833 SF B (Pass-through) 1834 MS B (Pass-through) 1835 WTR B (Pass-through) 1836 EXER B (Pass-through) 1837 RR N/A 1838 NR N/A 1839 ===================================================================== 1840 Initial state New request New state 1841 ------------- ----------- --------- 1842 B (Pass-through) LP B (Pass-through) 1843 FS N/A - cannot happen when there 1844 is LP request in the ring 1845 B (Pass-through) - otherwise 1846 SF N/A - cannot happen when there 1847 is LP request in the ring 1848 B (Pass-through) - otherwise 1849 MS N/A - cannot happen when there 1850 is LP, FS or SF request 1851 in the ring 1852 B (Pass-through) - otherwise 1853 WTR N/A - cannot happen when there 1854 is LP, FS, SF or MS 1855 request in the ring 1856 B (Pass-through) - otherwise 1857 EXER N/A - cannot happen when there 1858 is LP, FS, SF, MS or WTR 1859 request in the ring 1860 B (Pass-through) - otherwise 1861 RR N/A 1862 NR N/A 1863 ===================================================================== 1864 Initial state New request New state 1865 ------------- ----------- --------- 1866 C (Switching - LP) LP C (Switching - LP) 1867 FS N/A - cannot happen when there 1868 is LP request in the ring 1869 SF N/A - cannot happen when there 1870 is LP request in the ring 1871 MS N/A - cannot happen when there 1872 is LP request in the ring 1873 WTR N/A - cannot happen when there 1874 is LP in the ring 1875 EXER N/A - cannot happen when there 1876 is LP request in the ring 1877 RR N/A 1878 NR N/A 1879 ===================================================================== 1880 Initial state New request New state 1881 ------------- ----------- --------- 1882 D (Idle - LW) LP B (Pass-through) 1883 FS B (Pass-through) 1884 SF B (Pass-through) 1885 MS B (Pass-through) 1886 WTR B (Pass-through) 1887 EXER B (Pass-through) 1888 RR N/A 1889 NR N/A 1890 ===================================================================== 1891 Initial state New request New state 1892 ------------- ----------- --------- 1893 E (Switching - FS) LP B (Pass-through) 1894 FS E (Switching - FS) 1895 SF E (Switching - FS) 1896 MS N/A - cannot happen when there 1897 is FS request in the ring 1898 WTR N/A - cannot happen when there 1899 is FS request in the ring 1900 EXER N/A - cannot happen when there 1901 is FS request in the ring 1902 RR N/A 1903 NR N/A 1904 ===================================================================== 1905 Initial state New request New state 1906 ------------- ----------- --------- 1907 F (Switching - SF) LP B (Pass-through) 1908 FS F (Switching - SF) 1909 SF F (Switching - SF) 1910 MS N/A - cannot happen when there 1911 is SF request in the ring 1912 WTR N/A - cannot happen when there 1913 is SF request in the ring 1914 EXER N/A - cannot happen when there 1915 is SF request in the ring 1916 RR N/A 1917 NR N/A 1919 ===================================================================== 1920 Initial state New request New state 1921 ------------- ----------- --------- 1922 G (Switching - MS) LP B (Pass-through) 1923 FS B (Pass-through) 1924 SF B (Pass-through) 1925 MS G (Switching - MS) - release 1926 the switches but signal MS 1927 WTR N/A - cannot happen when there 1928 is MS request in the ring 1929 EXER N/A - cannot happen when there 1930 is MS request in the ring 1931 RR N/A 1932 NR N/A 1933 ===================================================================== 1934 Initial state New request New state 1935 ------------- ----------- --------- 1936 H (Switching - WTR) LP B (Pass-through) 1937 FS B (Pass-through) 1938 SF B (Pass-through) 1939 MS B (Pass-through) 1940 WTR N/A 1941 EXER N/A - cannot happen when there 1942 is WTR request in the ring 1943 RR N/A 1944 NR N/A 1945 ===================================================================== 1946 Initial state New request New state 1947 I (Switching - EXER) LP B (Pass-through) 1948 FS B (Pass-through) 1949 SF B (Pass-through) 1950 MS B (Pass-through) 1951 WTR N/A 1952 EXER I (Switching - EXER) 1953 RR N/A 1954 NR N/A 1955 ===================================================================== 1957 5.3. RPS and PSC Comparison on Ring Topology 1959 This section provides comparison between RPS and PSC [RFC6378] 1960 [RFC6974] on ring topologies. This can be helpful to explain the 1961 reason of defining a new protocol for ring protection switching. 1963 The PSC protocol [RFC6378] is designed for point-to-point LSPs, on 1964 which the protection switching can only be performed on one or both 1965 of the end points of the LSP. While RPS is designed for ring 1966 tunnels, which consist of multiple ring nodes, and the failure could 1967 happen on any segment of the ring, thus RPS SHOULD be capable of 1968 identifying and handling the different failures on the ring, and 1969 coordinating the protection switching behavior of all the nodes on 1970 the ring. As specified in section 5, this is achieved with the 1971 introduction of the "Pass-Through" state for the ring nodes, and the 1972 location of the protection request is identified via the Node IDs in 1973 the RPS Request message. 1975 Taking a ring topology with N nodes as example: 1977 With the mechanism specified in [RFC6974], on every ring-node, a 1978 linear protection configuration has to be provisioned with every 1979 other node in the ring, i.e. with (N-1) other nodes. This means that 1980 on every ring node there will be (N-1) instances of the PSC protocol. 1981 And in order to detect faults and to transport the PSC message, each 1982 instance shall have a MEP on the working path and a MEP on the 1983 protection path respectively. This means that every node on the ring 1984 needs to be configured with (N-1) * 2 MEPs. 1986 With the mechanism defined in this document, on every ring node there 1987 will only be a single instance of the RPS protocol. In order to 1988 detect faults and to transport the RPS message, each node only needs 1989 to have a MEP on the section to its adjacent nodes respectively. In 1990 this way, every ring-node only needs to be configured with 2 MEPs. 1992 As shown in the above example, RPS is designed for ring topologies 1993 and can achieve ring protection efficiently with minimum protection 1994 instances and OAM entities, which meets the requirements on topology 1995 specific recovery mechanisms as specified in [RFC5654]. 1997 6. IANA Considerations 1999 IANA is requested to administer the assignment of new values defined 2000 in this document and listed in the sections below. 2002 6.1. G-ACh Channel Type 2004 The Channel Types for the Generic Associated channel (GACh) are 2005 allocated from the IANA PW Associated Channel Type registry defined 2006 in [RFC4446] and updated by [RFC5586]. 2008 IANA is requested to allocate a new GACH Channel Type as follows: 2010 Value| Description | Reference 2011 ------+---------------------------+-------------- 2012 TBD | Ring Protection Switching |this document 2013 | Protocol (RPS) | 2014 ------+---------------------------+-------------- 2016 6.2. RPS Request Codes 2018 IANA is requested to create a new sub-registry under the 2019 "Multiprotocol Label Switching (MPLS) Operations, Administration, and 2020 Management (OAM) Parameters" registry called the "MPLS RPS Request 2021 Code Registry". All code points within this registry shall be 2022 allocated according to the "Standards Action" procedure as specified 2023 in [RFC5226]. 2025 The RPS Request Field is 8 bits, the allocated values are as follows: 2027 Value Description Reference 2028 ------- --------------------------- --------------- 2029 0 No Request (NR) this document 2030 1 Reverse Request (RR) this document 2031 2 unassigned 2032 3 Exercise (EXER) this document 2033 4 unassigned 2034 5 Wait-To-Restore (WTR) this document 2035 6 Manual Switch (MS) this document 2036 7-10 unassigned 2037 11 Signal Fail (SF) this document 2038 12 unassigned 2039 13 Forced Switch (FS) this document 2040 14 unassigned 2041 15 Lockout of Protection (LP) this document 2042 16-254 unassigned 2043 255 Reserved 2045 7. Security Considerations 2047 The RPS protocol defined in this document is carried in the G-ACh 2048 [RFC5586], which is a generalization of the Associated Channel 2049 defined in [RFC4385]. The security considerations specified in these 2050 documents apply to the proposed RPS mechanism. 2052 8. Contributing Authors 2053 Kai Liu 2054 Huawei Technologies 2055 Email: alex.liukai@huawei.com 2057 Jia He 2058 Huawei Technologies 2059 Email: hejia@huawei.com 2061 Fang Li 2062 China Academy of Telecommunication Research MIIT., China 2063 Email: lifang@catr.cn 2065 Jian Yang 2066 ZTE Corporation P.R.China 2067 Email: yang.jian90@zte.com.cn 2069 Junfang Wang 2070 Fiberhome Telecommunication Technologies Co., LTD. 2071 Email: wjf@fiberhome.com.cn 2073 Wen Ye 2074 China Mobile 2075 Email: yewen@chinamobile.com 2077 Minxue Wang 2078 China Mobile 2079 Email: wangminxue@chinamobile.com 2081 Sheng Liu 2082 China Mobile 2083 Email: liusheng@chinamobile.com 2085 Guanghui Sun 2086 Huawei Technologies 2087 Email: sunguanghui@huawei.com 2089 9. Acknowledgements 2091 The authors would like to thank Gregory Mirsky, Yimin Shen, Eric 2092 Osborne, Spencer Jackson and Eric Gray for their valuable comments 2093 and suggestions. 2095 10. References 2096 10.1. Normative References 2098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2099 Requirement Levels", BCP 14, RFC 2119, 2100 DOI 10.17487/RFC2119, March 1997, 2101 . 2103 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2104 Label Switching Architecture", RFC 3031, 2105 DOI 10.17487/RFC3031, January 2001, 2106 . 2108 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 2109 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 2110 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 2111 February 2006, . 2113 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 2114 Emulation (PWE3)", BCP 116, RFC 4446, 2115 DOI 10.17487/RFC4446, April 2006, 2116 . 2118 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 2119 "MPLS Generic Associated Channel", RFC 5586, 2120 DOI 10.17487/RFC5586, June 2009, 2121 . 2123 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 2124 Sprecher, N., and S. Ueno, "Requirements of an MPLS 2125 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 2126 September 2009, . 2128 10.2. Informative References 2130 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2131 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2132 DOI 10.17487/RFC5226, May 2008, 2133 . 2135 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2136 Administration, and Maintenance Framework for MPLS-Based 2137 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2138 September 2011, . 2140 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 2141 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 2142 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 2143 October 2011, . 2145 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 2146 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 2147 "Applicability of MPLS Transport Profile for Ring 2148 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 2149 . 2151 Authors' Addresses 2153 Weiqiang Cheng 2154 China Mobile 2156 Email: chengweiqiang@chinamobile.com 2158 Lei Wang 2159 China Mobile 2161 Email: wangleiyj@chinamobile.com 2163 Han Li 2164 China Mobile 2166 Email: lihan@chinamobile.com 2168 Huub van Helvoort 2169 Hai Gaoming BV 2171 Email: huubatwork@gmail.com 2173 Jie Dong 2174 Huawei Technologies 2176 Email: jie.dong@huawei.com