idnits 2.17.1 draft-ietf-mpls-tp-shared-ring-protection-04.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 489 has weird spacing: '...l links xxx...' == Line 600 has weird spacing: '...l links xxx...' == Line 958 has weird spacing: '...aaaaaaa a/c...' -- The document date (December 13, 2016) is 2691 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 334, 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: June 16, 2017 China Mobile 6 H. Helvoort 7 Hai Gaoming BV 8 J. Dong 9 Huawei Technologies 10 December 13, 2016 12 Shared-Ring protection (MSRP) mechanism for ring topology 13 draft-ietf-mpls-tp-shared-ring-protection-04 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 June 16, 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 the 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: All nodes in the ring topology are Ring Nodes and they 135 MUST actively participate in the ring protection. 137 Ring tunnel: A ring tunnel provides a server layer for the LSPs 138 traversing the ring. The notation used for a ring tunnel is: 139 R

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

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