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