idnits 2.17.00 (12 Aug 2021) /tmp/idnits11678/draft-ietf-mpls-tp-shared-ring-protection-06.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 517 has weird spacing: '...l links xxx...' == Line 633 has weird spacing: '...l links xxx...' == Line 999 has weird spacing: '...aaaaaaa a/c...' -- The document date (June 12, 2017) is 1797 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 357, 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: December 14, 2017 China Mobile 6 H. Helvoort 7 Hai Gaoming BV 8 J. Dong 9 Huawei Technologies 10 June 12, 2017 12 Shared-Ring protection (MSRP) mechanism for ring topology 13 draft-ietf-mpls-tp-shared-ring-protection-06 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 December 14, 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 . . . . . . . . . . 8 71 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 72 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 73 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 74 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 13 76 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 16 77 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 19 78 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 19 79 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 21 80 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 22 81 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 24 82 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 25 83 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 26 84 5.1. RPS and PSC Comparison on Ring Topology . . . . . . . . . 26 85 5.2. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 27 86 5.2.1. Transmission and Acceptance of RPS Requests . . . . . 29 87 5.2.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 29 88 5.2.3. Ring Node RPS States . . . . . . . . . . . . . . . . 31 89 5.2.4. RPS State Transitions . . . . . . . . . . . . . . . . 33 90 5.3. RPS State Machine . . . . . . . . . . . . . . . . . . . . 35 91 5.3.1. Switch Initiation Criteria . . . . . . . . . . . . . 35 92 5.3.2. Initial States . . . . . . . . . . . . . . . . . . . 37 93 5.3.3. State transitions When Local Request is Applied . . . 38 94 5.3.4. State Transitions When Remote Request is Applied . . 42 95 5.3.5. State Transitions When Request Addresses to Another 96 Node is Received . . . . . . . . . . . . . . . . . . 45 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 98 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 48 99 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 48 100 7. Operational Considerations . . . . . . . . . . . . . . . . . 48 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 102 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 50 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 52 106 11.2. Informative References . . . . . . . . . . . . . . . . . 52 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 109 1. Introduction 111 As described in section 2.5.6.1 of [RFC5654], several service 112 providers have expressed much interest in operating MPLS-TP in ring 113 topologies and require a high- level survivability function in these 114 topologies. In operational transport network deployment, MPLS-TP 115 networks are often constructed using ring topologies. This calls for 116 an efficient and optimized ring protection mechanism to achieve 117 simple operation and fast, sub 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 per 173 ring. The OAM of the links connected to the adjacent ring-nodes has 174 to be forwarded to only this instance in order to trigger protection. 175 For detailed information, see section 5.2. 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. For detailed 181 information, see section 5.2. 183 c. The required number of labels required for the protection paths 185 The RPS protocol uses ring tunnels and each tunnel has a set of 186 labels. The number of ring tunnel labels is related to the number of 187 ring-nodes and is independent of the number of protected LSPs. For 188 detailed information, see section 4.1.2. 190 d. The amount of control and management-plane transactions 192 Each ring-node requires only one instance of the RPS protocol per 193 ring. This means that only one maintenance operation is required per 194 ring-node. For detailed information, see section 5.2. 196 e. Minimize the signaling and routing information exchange during 197 protection 199 Information exchange during a protection switch is using the in-band 200 RPS and OAM messages. No control plane interactions are required. 201 For detailed information, see section 5.2. 203 4. Shared Ring Protection Architecture 205 4.1. Ring Tunnel 207 This document introduces a new logical layer of the ring for shared 208 ring protection in MPLS-TP networks. As shown in Figure 1, the new 209 logical layer consists of ring tunnels which provides a server layer 210 for the LSPs traversing the ring. Once a ring tunnel is established, 211 the forwarding and protection switching of the ring are all performed 212 at the ring tunnel level. A port can carry multiple ring tunnels, 213 and a ring tunnel can carry multiple LSPs. 215 +------------- 216 +-------------| 217 +-------------| | 218 ===Service1===| | | 219 ===Service2===| LSP1 | | 220 +-------------| | 221 |Ring-Tunnel1 | 222 +-------------| | 223 ===Service3===| | | 224 ===Service4===| LSP2 | | 225 +-------------| | 226 +-------------| Physical 227 +-------------| 228 +-------------| | Port 229 ===Service5===| | | 230 ===Service6===| LSP3 | | 231 +-------------| | 232 |Ring-Tunnel2 | 233 +-------------| | 234 ===Service7===| | | 235 ===Service8===| LSP4 | | 236 +-------------| | 237 +-------------| 238 +------------- 240 Figure 1. The logical layers of the ring 242 The label stack used in MPLS-TP Shared Ring Protection mechanism is 243 [Ring Tunnel Label|LSP Label|service Label](Payload) as illustrated 244 in figure 2. 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Ring tunnel Label | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | LSP Label | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Service Label | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Payload | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2. Label stack used in MPLS-TP Shared Ring Protection 257 4.1.1. Establishment of Ring Tunnel 259 The Ring tunnels are established based on the egress nodes. The 260 egress node is the node where traffic leaves the ring. LSPs which 261 have the same egress node on the ring and travels along the ring in 262 the same direction (clockwise or anticlockwise) share the same ring 263 tunnels. In other words, all the LSPs that traverse the ring in the 264 same direction and exit from the same node share the same working 265 ring tunnel and protection ring tunnel. For each egress node, four 266 ring tunnels are established: 268 o one clockwise working ring tunnel, which is protected by the 269 anticlockwise protection ring tunnel 271 o one anticlockwise protection ring tunnel 273 o one anticlockwise working ring tunnel, which is protected by the 274 clockwise protection ring tunnel 276 o one clockwise protection ring tunnel 278 The structure of the protection tunnels is determined by the selected 279 protection mechanism. This will be detailed in subsequent sections. 281 As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, 282 Node A and Node B respectively, and all leave the ring at Node D. To 283 protect these LSPs that traverse the ring, a clockwise working ring 284 tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise protection 285 ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also, an 286 anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and 287 its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D 288 are established. For simplicity Figure 3 only shows RcW_D and RaP_D. 289 A similar provisioning should be applied for any other node on the 290 ring. In summary, for each node in Figure 3 when acting as egress 291 node, the ring tunnels are created as follows: 293 o To Node A: RcW_A, RaW_A, RcP_A, RaP_A 295 o To Node B: RcW_B, RaW_B, RcP_B, RaP_B 297 o To Node C: RcW_C, RaW_C, RcP_C, RaP_C 299 o To Node D: RcW_D, RaW_D, RcP_D, RaP_D 301 o To Node E: RcW_E, RaW_E, RcP_E, RaP_E 303 o To Node F: RcW_F, RaW_F, RcP_F, RaP_F 304 +---+#############+---+ 305 | F |-------------| A | +-- LSP2 306 +---+*************+---+ 307 #/* *\# 308 #/* *\# 309 #/* *\# 310 +---+ +---+ 311 LSP1-+ | E | | B |+-- LSP3 312 +---+ +---+ 313 #\ */# 314 #\ */# 315 #\ */# 316 +---+*************+---+ 317 LSP1 +--| D |-------------| C | 318 LSP2 +---+#############+---+ 319 LSP3 321 ---- physical links 322 **** RcW_D 323 #### RaP_D 325 Figure 3. Ring tunnels in MSRP 327 Through these working and protection ring tunnels, LSPs which enter 328 the ring from any node can reach any egress nodes on the ring, and 329 are protected from failures on the ring. 331 4.1.2. Label Assignment and Distribution 333 The ring tunnel labels are downstream-assigned labels as defined in 334 [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can 335 be either configured statically, provisioned by a controller, or 336 distributed dynamically via a control protocol. For an LSP which 337 traverses the ring tunnel, the ingress ring node and the egress ring 338 node are considered adjacent at the LSP layer, and LSP label needs to 339 be allocated at these two ring nodes. The control plane for label 340 distribution is outside the scope of this document. 342 4.1.3. Forwarding Operation 344 When an MPLS-TP transport path, i.e. an LSP, enters the ring, the 345 ingress node on the ring pushes the working ring tunnel label which 346 is used to reach the specific egress node and sends the traffic to 347 the next hop. The transit nodes on the working ring tunnel swap the 348 ring tunnel labels and forward the packets to the next hop. When the 349 packet arrives at the egress node, the egress node pops the ring 350 tunnel label and forwards the packets based on the inner LSP label 351 and service label. Figure 4 shows the label operation in the MPLS-TP 352 shared ring protection mechanism. Assume that LSP1 enters the ring 353 at Node A and exits from Node D, and the following label operations 354 are executed. 356 1. Ingress node: Packets of LSP1 arrive at Node A with a label stack 357 [LSP1] and are supposed to be forwarded in the clockwise 358 direction of the ring. The label of the clockwise working ring 359 tunnel RcW_D will be pushed at Node A, the label stack for the 360 forwarded packet at Node A is changed to [RcW_D(B)|LSP1]. 362 2. Transit nodes: In this case, Node B and Node C forward the 363 packets by swapping the working ring tunnel labels. For example, 364 the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node 365 B. 367 3. Egress node: When the packet arrives at Node D (i.e. the egress 368 node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and 369 subsequently deals with the inner labels of LSP1. 371 +---+#####[RaP_D(F)]######+---+ 372 | F |---------------------| A | +-- LSP1 373 +---+*****[RcW_D(A)]******+---+ 374 #/* *\# 375 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)] 376 #/* *\# 377 +---+ +---+ 378 | E | | B | 379 +---+ +---+ 380 #\ */# 381 [RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)] 382 #\ */# 383 +---+*****[RcW_D(D)]****+---+ 384 LSP1 +-- | D |-------------------| C | 385 +---+#####[RaP_D(C)]####+---+ 387 -----physical links ****** RcW_D ###### RaP_D 389 Figure 4. Label operation of MSRP 391 4.2. Failure Detection 393 The MPLS-TP section layer OAM is used to monitor the connectivity 394 between each two adjacent nodes on the ring using the mechanisms 395 defined in [RFC6371]. Protection switching is triggered by the 396 failure detected on the ring by the OAM mechanisms. 398 Two ports of a link form a Maintenance Entity Group (MEG), and an MEG 399 end point (MEP) function is installed in each ring port. CC OAM 400 packets are periodically exchanged between each pair of MEPs to 401 monitor the link health. Three consecutive lost CC packets MUST be 402 interpreted as a link failure. 404 A node failure is regarded as the failure of two links attached to 405 that node. The two nodes adjacent to the failed node detect the 406 failure in the links that are connected to the failed node. 408 4.3. Ring Protection 410 This section specifies the ring protection mechanisms in detail. In 411 general, the description uses the clockwise working ring tunnel and 412 the corresponding anti-clockwise protection ring tunnel as an 413 example, but the mechanism is applicable in the same way to the anti- 414 clockwise working and clockwise protection ring tunnels. 416 In a ring network, each working ring tunnel is associated with a 417 protection ring tunnel in the opposite direction, and every node MUST 418 obtain the ring topology either by configuration or via a topology 419 discovery mechanism. The ring topology and the connectivity (Intact 420 or Severed) between two adjacent ring nodes form the ring map. Each 421 ring node maintains the ring map and uses it to perform ring 422 protection switching. 424 Taking the topology in Figure 4 as an example, LSP1 enters the ring 425 at Node A and leaves the ring at Node D. In normal state, LSP1 is 426 carried by the clockwise working ring tunnel (RcW_D) through the path 427 A->B->C->D. The label operation is: 429 [LSP1](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) 430 -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload). 432 Then at node D the packet will be forwarded based on the label stack 433 of LSP1. 435 Three typical ring protection mechanisms are described in this 436 section: wrapping, short wrapping and steering. All nodes on the 437 same ring MUST use the same protection mechanism. If the RPS 438 protocol in any node detects RPS message with a protection switching 439 mode that was not provisioned in that node a failure of protocol will 440 be reported, and the protection mechanism will not be activated. 442 Wrapping ring protection: the node which detects a failure or accepts 443 a switch request switches the traffic impacted by the failure or the 444 switch request to the opposite direction (away from the failure). In 445 this way, the impacted traffic is switched to the protection ring 446 tunnel by the switching node upstream of the failure, then travels 447 around the ring to the switching node downstream of the failure 448 through the protection ring tunnel, where it is switched back onto 449 the working ring tunnel to reach the egress node. 451 Short wrapping ring protection provides some optimization to wrapping 452 protection, in which the impacted traffic is only switched once to 453 the protection ring tunnel by the switching node upstream to the 454 failure. At the egress node, the traffic leave the ring from the 455 protection ring tunnel. This can reduce the traffic detour of 456 wrapping protection. 458 Steering ring protection implies that the node that detects a failure 459 sends a request along the ring to the other node adjacent to the 460 failure, and all nodes in the ring process this information. For the 461 impacted traffic, the ingress node (which adds traffic to the ring) 462 performs switching of the traffic from working to the protection ring 463 tunnel, and the egress node will drop the traffic received from the 464 protection ring tunnel. 466 The following sections describe these protection mechanisms in 467 detail. 469 4.3.1. Wrapping 471 With the wrapping mechanism, the protection ring tunnel is a closed 472 ring identified by the egress node. As shown in Figure 4, the RaP_D 473 is the anticlockwise protection ring tunnel for the clockwise working 474 ring tunnel RcW_D. As specified in the following sections, the 475 closed ring protection tunnel can protect both link failures and node 476 failures. Wrapping can be applicable for the protection the p2mp 477 LSPs on the ring, the details of which is outside the scope of this 478 document. 480 4.3.1.1. Wrapping for Link Failure 482 When a link failure between Node B and Node C occurs, if it is a bi- 483 directional failure, both Node B and Node C can detect the failure 484 via the OAM mechanism; if it is an uni-directional failure, one of 485 the two nodes would detect the failure via the OAM mechanism. In 486 both cases the node at the other side of the detected failure will be 487 determined by the ring-map and informed using the Ring Protection 488 Switch Protocol (RPS) which is specified in section 5. Then Node B 489 switches the clockwise working ring tunnel (RcW_D) to the 490 anticlockwise protection ring tunnel (RaP_D) and Node C switches 491 anticlockwise protection ring tunnel(RaP_D) back to the clockwise 492 working ring tunnel (RcW_D). The payload which enters the ring at 493 Node A and leaves the ring at Node D follows the path 494 A->B->A->F->E->D->C->D. The label operation is: 496 [LSP1](Payload) -> [RcW_D(B)|LSP1](Node A) -> [RaP_D(A)|LSP1](Node B) 497 -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] (Node F) -> 498 [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> 499 [RcW_D(D)|LSP1](Node C) -> [LSP1](Payload). 501 +---+#####[RaP_D(F)]######+---+ 502 | F |---------------------| A | +-- LSP1 503 +---+*****[RcW_D(A)]******+---+ 504 #/* *\# 505 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 506 #/* *\# 507 +---+ +---+ 508 | E | | B | 509 +---+ +---+ 510 #\ *x# 511 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 512 #\ *x# 513 +---+*****[RcW_D(D)]****+---+ 514 LSP1 +-- | D |-------------------| C | 515 +---+#####[RaP_D(C)]####+---+ 517 -----physical links xxxx Failure Link 518 ****** RcW_D ###### RaP_D 520 Figure 5.Wrapping for link failure 522 4.3.1.2. Wrapping for Node Failure 524 As shown in Figure 6, when Node B fails, Node A detects the failure 525 between A and B and switches the clockwise work ring tunnel (RcW_D) 526 to the anticlockwise protection ring tunnel (RaP_D), Node C detects 527 the failure between C and B and switches the anticlockwise protection 528 ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). 529 The node at the other side of the failed node will be determined by 530 the ring-map and informed using the Ring Protection Switch Protocol 531 (RPS) specified in section 5. 533 The payload which enters the ring at Node A and exits at Node D 534 follows the path A->F->E->D->C->D. The label operation is: 536 [LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 537 [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] 538 (NodeC) -> [LSP1](Payload). 540 In one special case where node D fails, all the ring tunnels with 541 node D as egress will become unusable. The ingress node will update 542 its ring map according to received RPS messages and determine that 543 the egress node is not reachable thus it will not send traffic to 544 either the working or the protection tunnel. However, before the 545 failure location information is propagated to all the ring nodes, the 546 wrapping protection mechanism may cause temporary traffic loop: node 547 C detects the failure and switches the traffic from the clockwise 548 work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel 549 (RaP_D), node E also detects the failure and would switch the traffic 550 from anticlockwise protection ring tunnel (RaP_D) back to the 551 clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate 552 the temporary loop problem is: the TTL of the ring tunnel label is 553 set to 2*N by the ingress ring node of the traffic, where N is the 554 number of nodes on the ring. 556 +---+#####[RaP_D(F)]######+---+ 557 | F |---------------------| A | +-- LSP1 558 +---+*****[RcW_D(A)]******+---+ 559 #/* *\# 560 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 561 #/* *\# 562 +---+ xxxxx 563 | E | x B x 564 +---+ xxxxx 565 #\ */# 566 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 567 #\ */# 568 +---+*****[RcW_D(D)]****+---+ 569 LSP1 +-- | D |-------------------| C | 570 +---+#####[RaP_D(C)]####+---+ 572 -----physical links xxxxxx Failure Node 573 *****RcW_D ###### RaP_D 575 Figure 6. Wrapping for node failure 577 4.3.2. Short Wrapping 579 With the wrapping protection scheme, protection switching is executed 580 at both nodes adjacent to the failure, consequently the traffic will 581 be wrapped twice. This mechanism will cause additional latency and 582 bandwidth consumption when traffic is switched to the protection 583 path. 585 With short wrapping protection, protection switching is executed only 586 at the node upstream to the failure, and the packet leaves the ring 587 in the protection ring tunnel at the egress node. This scheme can 588 reduce the additional latency and bandwidth consumption when traffic 589 is switched to the protection path. However the two directions of a 590 protected bidirectional LSP are no longer co-routed under the 591 protection switching conditions. 593 In the traditional wrapping solution, the protection ring tunnel is 594 configured as a closed ring, while in the short wrapping solution, 595 the protection ring tunnel is configured as ended at the egress node, 596 which is similar to the working ring tunnel. Short wrapping is easy 597 to implement in shared ring protection because both the working and 598 protection ring tunnels are terminated on the egress nodes. Figure 7 599 shows the clockwise working ring tunnel and the anticlockwise 600 protection ring tunnel with node D as the egress node. 602 4.3.2.1. Short Wrapping for Link Failure 604 As shown in Figure 7, in normal state, LSP1 is carried by the 605 clockwise working ring tunnel (RcW_D) through the path A->B->C->D. 606 When a link failure between Node B and Node C occurs, Node B switches 607 the working ring tunnel RcW_D to the protection ring tunnel RaP_D in 608 the opposite direction. The difference with wrapping occurs in the 609 protection ring tunnel at the egress node. In short wrapping 610 protection, Rap_D ends in Node D and then traffic will be forwarded 611 based on the LSP labels. Thus with the short wrapping mechanism, 612 LSP1 will follow the path A->B->A->F->E->D when a link failure 613 between Node B and Node C happens. The protection switch at node D 614 is based on the information from its ring map and the information 615 received via the RPS protocol. 617 +---+#####[RaP_D(F)]######+---+ 618 | F |---------------------| A | +-- LSP1 619 +---+*****[RcW_D(A)]******+---+ 620 #/* *\# 621 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 622 #/* *\# 623 +---+ +---+ 624 | E | | B | 625 +---+ +---+ 626 #\ *x# 627 [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) 628 #\ *x# 629 +---+*****[RcW_D(D)]****+---+ 630 LSP1 +-- | D |-------------------| C | 631 +---+ +---+ 633 ----- physical links xxxxx Failure Link 634 ****** RcW_D ###### RaP_D 636 Figure 7. Short wrapping for link failure 638 4.3.2.2. Short Wrapping for Node Failure 640 For the node failure which happens on a non-egress node, the short 641 wrapping protection switching is similar to the link failure case as 642 described in the previous section. This section specifies the 643 scenario of an egress node failure. 645 As shown in Figure 8, LSP1 enters the ring on node A, and leaves the 646 ring on node D. In normal state, LSP1 is carried by the clockwise 647 working ring tunnel (RcW_D) through the path A->B->C->D. When node D 648 fails, traffic of LSP1 cannot be protected by any ring tunnels which 649 use node D as the egress node. The ingress node will update its ring 650 map according to received RPS messages and determine that the egress 651 node is not reachable thus it will not send traffic to either the 652 working or the protection tunnel. However, before the failure 653 location information is propagated to all the ring nodes using the 654 RPS protocol, node C switches all the traffic on the working ring 655 tunnel RcW_D to the protection ring tunnel RaP_D in the opposite 656 direction based on the information in the ring map. When the traffic 657 arrives at node E which also detects the failure of node D, the 658 protection ring tunnel RaP_D cannot be used to forward traffic to 659 node D. Since with short wrapping mechanism, protection switching 660 can only be performed once from the working ring tunnel to the 661 protection ring tunnel, thus node E MUST NOT switch the traffic which 662 is already carried on the protection ring tunnel back to the working 663 ring tunnel in the opposite direction. Instead, node E will discard 664 the traffic received on RaP_D locally. This can avoid the temporary 665 traffic loop when the failure happens on the egress node of the ring 666 tunnel. This also illustrates one of the benefits of having separate 667 working and protection ring tunnels in each ring direction. 669 +---+#####[RaP_D(F)]######+---+ 670 | F |---------------------| A | +-- LSP1 671 +---+*****[RcW_D(A)]******+---+ 672 #/* *\# 673 [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) 674 #/* *\# 675 +---+ +---+ 676 | E | | B | 677 +---+ +---+ 678 #\ */# 679 [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) 680 #\ */# 681 xxxxx*****[RcW_D(D)]****+---+ 682 LSP1 +-- x D x-------------------| C | 683 xxxxx +---+ 685 -----physical links xxxxxx Failure Node 686 *****RcW_D ###### RaP_D 688 Figure 8. Short Wrapping for egress node failure 690 4.3.3. Steering 692 With the steering protection mechanism, the ingress node (which adds 693 traffic to the ring) perform switching from the working to the 694 protection ring tunnel, and at the egress node the traffic leaves the 695 ring from the protection ring tunnel. 697 When a failure occurs in the ring, the node which detects the failure 698 with OAM mechanism sends the failure information in the opposite 699 direction of the failure hop by hop along the ring using an RPS 700 request message and the ring-map information. When a ring node 701 receives the RPS message which identifies a failure, it can determine 702 the location of the fault by using the topology information of the 703 ring map and updates the ring map accordingly, then it can determine 704 whether the LSPs entering the ring locally need to switchover or not. 705 For LSPs that need to switchover, it will switch the LSPs from the 706 working ring tunnels to their corresponding protection ring tunnels. 708 4.3.3.1. Steering for Link Failure 709 Ring map of F +--LSPl 710 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ 711 |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| 712 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ 713 |I|I|I|S|I|I| |I|I|S|I|I|I| 714 +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ 715 [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] 716 #/* [RcW_D(F)] *\# 717 +-+-+-+-+-+-+-+ #/* *\# 718 |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 719 +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ 720 |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| 721 +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 722 #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| 723 [RaP_D(D)] #\* */# +-+-+-+-+-+-+ 724 #\* */# [RaP_D(B)] 725 +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ 726 |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| 727 +-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ 728 |I|I|I|I|I|S| LSP2 |S|I|I|I|I|I| 729 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 731 ----- physical links ***** RcW_D ##### RaP_D 732 I: Intact S: Severed 733 Figure 9. Steering operation and protection switching 735 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 736 enters the ring from Node B, and both of them have the same 737 destination node D. 739 In normal state, LSP1 is carried by the clockwise working ring tunnel 740 (RcW_D) through the path A->B->C->D, the label operation is: 741 [LSP1](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) 742 -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload) . 744 LSP2 is carried by the clockwise working ring tunnel (RcW_D) through 745 the path B->C->D, the label operation is: [LSP2](Payload) -> 746 [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload) . 748 If the link between nodes C and D fails, according to the fault 749 detection and distribution mechanisms, Node D will find out that 750 there is a failure in the link between C and D, and it will update 751 the link state of its ring topology, changing the link between C and 752 D from normal to fault. In the direction that is opposite to the 753 failure position, Node D will send the state report message to Node 754 E, informing Node E of the fault between C and D, and E will update 755 the link state of its ring topology accordingly, changing the link 756 between C and D from normal to fault. In this way, the state report 757 message is sent hop by hop in the clockwise direction. Similar to 758 Node D, Node C will send the failure information in the anti- 759 clockwise direction. 761 When Node A receives the failure report message and updates the link 762 state of its ring map, it is aware that there is a fault on the 763 clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the 764 ring locally and is carried by this ring tunnel, thus Node A will 765 decide to switch the LSP1 onto the anticlockwise protection ring 766 tunnel to node D (RaP_D). After the switchover, LSP1 will follow the 767 path A->F->E->D, the label operation is: [LSP1](Payload) -> 768 [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> 769 [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload). 771 The same procedure also applies to the operation of LSP2. When Node 772 B updates the link state of its ring topology, and finds out that the 773 working ring tunnel RcW_D has failed, it will switch the LSP2 to the 774 anticlockwise protection tunnel RaP_D. After the switchover, LSP2 775 goes through the path B->A->F->E->D, and the label operation is: 776 [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) 777 -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> 778 [LSP2](Payload). 780 Assume the link between nodes A and B breaks down, as shown in 781 Figure 10. Similar to the above failure case, Node B will detect a 782 fault in the link between A and B, and it will update its ring map, 783 changing the link state between A and B from normal to fault. The 784 state report message is sent hop by hop in the clockwise direction, 785 notifying every node that there is a fault between node A and B, and 786 every node updates the link state of its ring topology. As a result, 787 Node A will detect a fault in the working ring tunnel to node D, and 788 switch LSP1 to the protection ring tunnel, while Node B determine 789 that the working ring tunnel for LSP2 still works fine, and will not 790 perform the switchover. 792 /-- LSPl 793 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ 794 |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| 795 +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ 796 |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| 797 +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ 798 [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] 799 #/* x +-- LSP2 800 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 801 |E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B| 802 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ 803 |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| 804 +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ 805 [RaP_D(D)] #\* */# [RaP_D(B)] 806 +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ 807 |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| 808 +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ 809 |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| 810 +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ 812 ----- physical links ***** RcW_D ##### RaP_D 814 Figure 10. Steering operation and protection switching (2) 816 4.3.3.2. Steering for Node Failure 818 For a node failure which happens on a non-egress node, steering 819 protection switching is similar to the link failure case as described 820 in the previous section. 822 If the failure occurs at the egress node of the LSP, the ingress node 823 will update its ring map according to the received RPS messages, it 824 will also determine that the egress node is not reachable after the 825 failure, thus it will not send traffic to either the working or the 826 protection tunnel, and a traffic loop can be avoided. 828 4.4. Interconnected Ring Protection 830 4.4.1. Interconnected Ring Topology 832 Interconnected ring topology is widely used in MPLS-TP networks. For 833 a given ring, the interconnection node acts as the egress node for 834 that ring, meaning that all LSPs using the interconnection node as an 835 egress from one specific ring to another will use the same group of 836 ring tunnels within the ring. This document will discuss two typical 837 interconnected ring topologies: 839 1. Single-node interconnected rings 840 In single-node interconnected rings, the connection between 841 the two rings is through a single node. Because the 842 interconnection node is in fact a single point of failure, 843 this topology should be avoided in real transport networks. 845 Figure 11 shows the topology of single-node interconnected 846 rings. Node C is the interconnection node between Ring1 and 847 Ring2. 849 +---+ +---+ +---+ +---+ 850 | A |------| B |----- -----| G |------| H | 851 +---+ +---+ \ / +---+ +---+ 852 | \ / | 853 | \ +---+ / | 854 | Ring1 | C | Ring2 | 855 | / +---+ \ | 856 | / \ | 857 +---+ +---+ / \ +---+ +---+ 858 | F |------| E |----- -----| J |------| I | 859 +---+ +---+ +---+ +---+ 861 Figure 11. Single-node interconnected rings 863 2. Dual-node interconnected rings 865 In dual-node interconnected rings, the connection between the 866 two rings is through two nodes. The two interconnection nodes 867 belong to both interconnected rings. This topology can 868 recover from one interconnection node failure. 870 Figure 12 shows the topology of dual-node interconnected 871 rings. Nodes C and Node D are the interconnection nodes 872 between Ring1 and Ring2. 874 +---+ +---+ +---+ +---+ +---+ 875 | A |------| B |------| C |------| G |------| H | 876 +---+ +---+ +---+ +---+ +---+ 877 | | | | 878 | | | | 879 | Ring1 | | Ring2 | 880 | | | | 881 | | | | 882 +---+ +---+ +---+ +---+ +---+ 883 | F |------| E |------| D |------| J |------| I | 884 +---+ +---+ +---+ +---+ +---+ 886 Figure 12. Dual-node interconnected rings 888 4.4.2. Interconnected Ring Protection Mechanisms 890 Interconnected rings can be treated as two independent rings. Ring 891 protection switching (RPS) protocol operates on each ring 892 independently. A failure that happens in one ring only triggers 893 protection switching in the ring itself and does not affect the other 894 ring, unless the failure is on the interconnection node. In this 895 way, protection switching on each ring is the same as the mechanisms 896 described in section 4.3. 898 The service LSPs that traverse the interconnected rings use the ring 899 tunnels in each ring, within a given ring, the tunnel is selected 900 using normal ring selection procedures. The traversing LSPs are 901 stitched on the interconnection node. On the interconnection node, 902 the ring tunnel label of the source ring is popped, then LSP label is 903 swapped, after that the ring tunnel label of the destination ring is 904 pushed. 906 In the dual-node interconnected ring scenario, the two 907 interconnection nodes can be managed as a virtual node group. In 908 addition to the ring tunnels to each physical ring node, Each ring 909 SHOULD assign the working and protection ring tunnels to the virtual 910 interconnection node group. In addition, on both nodes in the 911 virtual interconnection node group, the same LSP label is assigned 912 for each traversed LSP. This way, any interconnection node in the 913 virtual node group can terminate the working or protection ring 914 tunnels targeted to the virtual node group, and stitch the service 915 LSP from the source ring tunnel to the destination ring tunnel. 917 When the service LSP passes through the interconnected rings, the 918 direction of the working ring tunnels used on both rings SHOULD be 919 the same. In dual-node interconnected rings, this ensures that in 920 normal state the traffic passes only one of the two interconnection 921 nodes, and does not pass the link between the two interconnection 922 nodes. The traffic will then only be switched to the protection path 923 if the interconnection node which is in working path fails. For 924 example, if the service LSP uses the clockwise working ring tunnel on 925 Ring1, when the service LSP leaves Ring1 and enters Ring2, the 926 working ring tunnel used on Ring2 should also follow the clockwise 927 direction. 929 4.4.3. Ring Tunnels in Interconnected Rings 931 The same ring tunnels as described in section 4.1 are used in each 932 ring of the interconnected rings. In addition, ring tunnels to the 933 virtual interconnection node group are established on each ring of 934 the interconnected rings, i.e.: 936 o one clockwise working ring tunnel to the virtual interconnection 937 node group 939 o one anticlockwise protection ring tunnel to the virtual 940 interconnection node group 942 o one anticlockwise working ring tunnel to the virtual 943 interconnection node group 945 o one clockwise protection ring tunnel to the virtual 946 interconnection node group 948 The ring tunnels to the virtual interconnection node group are shared 949 by all LSPs that need to be forwarded to other rings. These ring 950 tunnels can terminate at any node in the virtual interconnection node 951 group. 953 For example, all the ring tunnels on Ring1 in Figure 13 are 954 provisioned as follows: 956 o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A 958 o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B 960 o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C 962 o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D 964 o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E 966 o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F 968 o To the virtual interconnection node group (including Node F and 969 Node A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A 971 All the ring tunnels on Ring2 in Figure 13 are provisioned as 972 follows: 974 o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A 976 o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F 978 o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G 980 o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H 982 o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I 984 o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J 986 o To the virtual interconnection node group (including Node F and 987 Node A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A 988 +---+cccccccccccc +---+ 989 | H |-------------| I |--->LSP1 990 +---+ +---+ 991 c/a a\ 992 c/a a\ 993 c/a a\ 994 +---+ +---+ 995 | G | Ring2 | J | 996 +---+ +---+ 997 c\a a/c 998 c\a a/c 999 c\a aaaaaaaaaaaaa a/c 1000 +---+ccccccccccccc+---+ 1001 | F |-------------| A | 1002 +---+ccccccccccccc+---+ 1003 c/aaaaaaaaaaaaaaaaaaa a\ 1004 c/ a\ 1005 c/ a\ 1006 +---+ +---+ 1007 | E | Ring1 | B | 1008 +---+ +---+ 1009 c\a a/c 1010 c\a a/c 1011 c\a a/c 1012 +---+aaaaaaaaaaaa +---+ 1013 LSP1--->| D |-------------| C | 1014 +---+ccccccccccccc+---+ 1016 ccccccccccc R1cW_F&A 1017 aaaaaaaaaaa R1aP_F&A 1018 ccccccccccc R2cW_I 1019 aaaaaaaaaaa R2aP_I 1020 Figure 13. Ring tunnels for the interconnected rings 1022 4.4.4. Interconnected Ring Switching Procedure 1024 As shown in Figure 13, for the service LSP1 which enters Ring1 at 1025 Node D and leaves Ring1 at Node F and continues to enter Ring2 at 1026 Node F and leaves Ring2 at Node I, the short wrapping protection 1027 scheme is described as below. 1029 In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. 1030 At the interconnection node F, the label used for the working ring 1031 tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the 1032 label used for the working ring tunnel R2cW_I in Ring2 will be pushed 1033 based the inner LSP label lookup. The working path that the service 1034 LSP1 follows is: LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1. 1036 In case of link failure, for example, when a failure occurs on the 1037 link between Node F and Node E, Node E will detect the failure and 1038 execute protection switching as described in 4.3.2. The path that 1039 the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- 1040 >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 1042 In case of a non-interconnection node failure, for example, when the 1043 failure occurs at Node E in Ring1, Node D will detect the failure and 1044 execute protection switching as described in 4.3.2. The path that 1045 the service LSP1 follows after switching becomes: 1046 LSP1->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. 1048 In case of an interconnection node failure, for example, when the 1049 failure occurs at the interconnection Node F, Node E in Ring1 will 1050 detect the failure, and execute protection switching as described in 1051 4.3.2. Node A in Ring2 will also detect the failure, and execute 1052 protection switching as described in 4.3.2. The path that the 1053 service traffic LSP1 follows after switching is: 1054 LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1. 1056 4.4.5. Interconnected Ring Detection Mechanism 1058 As shown in Figure 13, in normal state the service traffic LSP1 1059 traverses D->E->F in Ring1 and F->G->H->I in Ring2. Node A and F are 1060 the interconnection nodes. When both the link between Node F and 1061 Node G and the link between Node F and Node A fail, the ring tunnel 1062 from Node F to Node I in Ring2 becomes unreachable. However, the 1063 other interconnection node A is still available, and LSP1 can still 1064 reach Node I via node A. 1066 In order to achieve this, the interconnection nodes need to know the 1067 ring topology of each ring so that they can judge whether a node is 1068 reachable. This judgment is based on the knowledge of ring map and 1069 the fault location. The ring map can be obtained from the NMS or 1070 topology discovery mechanisms. The fault location can be obtained by 1071 transmitting the fault information around the ring. The nodes that 1072 detect the failure will transmit the fault information in the 1073 opposite direction hop by hop using the RPS protocol message. When 1074 the interconnection node receives the message that informs the 1075 failure, it will calculate the location of the fault according to the 1076 topology information that is maintained by itself and determines 1077 whether the LSPs entering the ring at itself can reach the 1078 destination. If the destination node is reachable, the LSP will 1079 leave the source ring and enter the destination ring. If the 1080 destination node is not reachable, the LSP will switch to the 1081 anticlockwise protection ring tunnel. 1083 In Figure 13, Node F determines that the ring tunnel to Node I is 1084 unreachable, the service LSP1 for which the destination node on the 1085 ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A) 1086 and consequently the service traffic LSP1 traverses the 1087 interconnected rings at Node A. Node A will pop the ring tunnel 1088 label of Ring1 and push the ring tunnel label of Ring2 and send the 1089 traffic to Node I via ring tunnel (R2aW_I). 1091 5. Ring Protection Coordination Protocol 1093 5.1. RPS and PSC Comparison on Ring Topology 1095 This section provides comparison between RPS and PSC [RFC6378] 1096 [RFC6974] on ring topologies. This can be helpful to explain the 1097 reason of defining a new protocol for ring protection switching. 1099 The PSC protocol [RFC6378] is designed for point-to-point LSPs, on 1100 which the protection switching can only be performed on one or both 1101 of the end points of the LSP. The RPS protocol is designed for ring 1102 tunnels, which consist of multiple ring nodes, and the failure could 1103 happen on any segment of the ring, thus RPS is capable of identifying 1104 and handling the different failures on the ring, and coordinating the 1105 protection switching behavior of all the nodes on the ring. As will 1106 be specified in the following sections, this is achieved with the 1107 introduction of the "Pass-Through" state for the ring nodes, and the 1108 location of the protection request is identified via the Node IDs in 1109 the RPS Request message. 1111 Taking a ring topology with N nodes as example: 1113 With the mechanism specified in [RFC6974], on every ring node, a 1114 linear protection configuration has to be provisioned with every 1115 other node in the ring, i.e. with (N-1) other nodes. This means that 1116 on every ring node there will be (N-1) instances of the PSC protocol. 1117 And in order to detect faults and to transport the PSC message, each 1118 instance shall have a MEP on the working path and a MEP on the 1119 protection path respectively. This means that every node on the ring 1120 needs to be configured with (N-1) * 2 MEPs. 1122 With the mechanism defined in this document, on every ring node there 1123 will only be a single instance of the RPS protocol. In order to 1124 detect faults and to transport the RPS message, each node only needs 1125 to have a MEP on the section to its adjacent nodes respectively. In 1126 this way, every ring node only needs to be configured with 2 MEPs. 1128 As shown in the above example, RPS is designed for ring topologies 1129 and can achieve ring protection efficiently with minimum protection 1130 instances and OAM entities, which meets the requirements on topology 1131 specific recovery mechanisms as specified in [RFC5654]. 1133 5.2. RPS Protocol 1135 The Ring Protection Switch (RPS) Protocol defined in this section is 1136 used to coordinate the protection switching action of all the ring 1137 nodes in the same ring. 1139 The protection operation of the ring tunnels is controlled with the 1140 help of the RPS protocol. The RPS processes in each of the 1141 individual ring nodes that form the ring MUST communicate using the 1142 G-ACh channel. The RPS protocol is applicable to all the three ring 1143 protection modes. This section takes the short-wrapping mechanism 1144 described in section 4.3.2 as an example. 1146 The RPS protocol is used to distribute the ring status information 1147 and RPS requests to all the ring nodes. Changes in the ring status 1148 information and RPS requests can be initiated automatically based on 1149 link status or caused by external commands. 1151 Each node on the ring is uniquely identified by assigning it a node 1152 ID. The node ID MUST be unique on each ring. The maximum number of 1153 nodes on the ring supported by the RPS protocol is 127. The node ID 1154 SHOULD be independent of the order in which the nodes appear on the 1155 ring. The node ID is used to identity the source and destination 1156 nodes of each RPS request. 1158 Every node obtains the ring topology either by configuration or via 1159 some topology discovery mechanism. The ring map consists of the ring 1160 topology information, and connectivity status (Intact or Severed) 1161 between the adjacent ring nodes, which is determined via the OAM 1162 message exchanged between the adjacent nodes. The ring map is used 1163 by every ring node to determine the switchover behavior of the ring 1164 tunnels. 1166 As shown in Figure 14, when no protection switching is active on the 1167 ring, each node MUST send RPS requests with No Request (NR) to its 1168 two adjacent nodes periodically. The transmission interval of RPS 1169 requests is specified in section 5.2.1. 1171 +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) 1172 -------| A |-------------| B |-------------| C |------- 1173 (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ 1175 Figure 14. RPS communication between the ring nodes in case of 1176 no failure in the ring 1178 As shown in Figure 15, When a node detects a failure and determines 1179 that protection switching is required, it MUST send the appropriate 1180 RPS request in both directions to the destination node. The 1181 destination node is the other node that is adjacent to the identified 1182 failure. When a node that is not the destination node receives an 1183 RPS request and it has no higher priority local request, it MUST 1184 transfer in the same direction the RPS request as received. In this 1185 way, the switching nodes can maintain RPS protocol communication in 1186 the ring. The RPS request MUST be terminated by the destination node 1187 of the message. If an RPS request with the node itself set as the 1188 source node is received, this message MUST be dropped and not be 1189 forwarded to next node. 1191 +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) 1192 -------| A |-------------| B |----- X -----| C |------- 1193 (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ 1195 Figure 15. RPS communication between the ring nodes in case of 1196 failure between nodes B and C 1198 Note that in the case of a bidirectional failure such as a cable cut, 1199 the two adjacent nodes detect the failure and send each other an RPS 1200 request in opposite directions. 1202 o In rings utilizing the wrapping protection, each node detects the 1203 failure or receives the RPS request as the destination node MUST 1204 perform the switch from/to the working ring tunnels to/from the 1205 protection ring tunnels if it has no higher priority active RPS 1206 request. 1208 o In rings utilizing the short wrapping protection, each node 1209 detects the failure or receives the RPS request as the destination 1210 node MUST perform the switch only from the working ring tunnels to 1211 the protection ring tunnels. 1213 o In rings utilizing the steering protection. When a ring switch is 1214 required, any node MUST perform the switches if its added/dropped 1215 traffic is affected by the failure. Determination of the affected 1216 traffic MUST be performed by examining the RPS requests 1217 (indicating the nodes adjacent to the failure or failures) and the 1218 stored ring map (indicating the relative position of the failure 1219 and the added traffic destined towards that failure). 1221 When the failure has cleared and the Wait-to-Restore (WTR) timer has 1222 expired, the nodes which generate the RPS requests MUST drop their 1223 respective switches and MUST generate an RPS request carrying the NR 1224 code. The node receiving from both directions such an RPS request 1225 MUST drop its protection switches. 1227 A protection switch MUST be initiated by one of the criteria 1228 specified in Section 5.3. A failure of the RPS protocol or 1229 controller MUST NOT trigger a protection switch. 1231 Ring switches MUST be preempted by higher priority RPS requests. For 1232 example, consider a protection switch that is active due to a manual 1233 switch request on the given link, and another protection switch is 1234 required due to a failure on another link. Then an RPS request MUST 1235 be generated, the former protection switch MUST be dropped, and the 1236 latter protection switch established. 1238 The shared ring protection mechanism supports multiple protection 1239 switches in the ring, resulting in the ring being segmented into two 1240 or more separate segments. This may happen when several RPS requests 1241 of the same priority exist in the ring due to multiple failures or 1242 external switch commands. 1244 Proper operation of the MSRP mechanism relies on all nodes using 1245 their ring map to determine the state of the ring (nodes and links). 1246 In order to accommodate ring state knowledge, during a protection 1247 switch the RPS requests MUST be sent in both directions. 1249 5.2.1. Transmission and Acceptance of RPS Requests 1251 A new RPS request MUST be transmitted immediately when a change in 1252 the transmitted status occurs. 1254 The first three RPS protocol messages carrying new RPS request MUST 1255 be transmitted as fast as possible. For fast protection switching 1256 within 50 ms, the interval of the first three RPS protocol messages 1257 SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted 1258 with the interval of 5 seconds. A ring node which is not the 1259 destination of the received RPS message MUST forward it to the next 1260 node along the ring immediately. 1262 5.2.2. RPS PDU Format 1264 Figure 16 depicts the format of an RPS packet that is sent on the 1265 G-ACh. The Channel Type field is set to indicate that the message is 1266 an RPS message. 1268 0 1 2 3 1269 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 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 |0 0 0 1|Version| Reserved | RPS Channel Type (TBD) | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Dest Node ID | Src Node ID | Request | M | Reserved | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 16. G-ACh RPS Packet Format 1277 The following fields MUST be provided: 1279 o Destination Node ID: The destination node ID MUST always be set to 1280 value of the node ID of the adjacent node. The Node ID MUST be 1281 unique on each ring. Valid destination node ID values are 1-127. 1283 o Source Node ID: The source node ID MUST always be set to the ID 1284 value of the node generating the RPS request. The Node ID MUST be 1285 unique on each ring. Valid source node ID values are 1-127. 1287 o Protection Switching Mode (M): This 2-bit field indicates the 1288 protection switching mode used by the sending node of the RPS 1289 message. This can be used to check that the ring nodes on the 1290 same ring use the same protection switching mechanism. The 1291 defined values of the M field are listed as below: 1293 +------------------+-----------------------------+ 1294 | Bits (MSB-LSB) | Protecton Switching Mode | 1295 +------------------+-----------------------------+ 1296 | 0 0 | Reserved | 1297 | 0 1 | Wrapping | 1298 | 1 0 | Short Wrapping | 1299 | 1 1 | Steering | 1300 +------------------+-----------------------------+ 1302 o RPS request code: A code consisting of eight bits as specified 1303 below: 1305 +------------------+-----------------------------+----------+ 1306 | Bits | Condition, State | Priority | 1307 | (MSB - LSB) | or external Request | | 1308 +------------------+-----------------------------+----------+ 1309 | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | 1310 | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | 1311 | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | 1312 | 0 0 0 0 0 1 1 0 | Manual Switch (MS) | | 1313 | 0 0 0 0 0 1 0 1 | Wait-To-Restore (WTR) | | 1314 | 0 0 0 0 0 0 1 1 | Exercise (EXER) | | 1315 | 0 0 0 0 0 0 0 1 | Reverse Request (RR) | | 1316 | 0 0 0 0 0 0 0 0 | No Request (NR) | lowest | 1317 +------------------+-----------------------------+----------+ 1319 5.2.3. Ring Node RPS States 1321 Idle state: A node is in the idle state when it has no RPS request 1322 and is sending and receiving NR code to/from both directions. 1324 Switching state: A node not in the idle or pass-through states is in 1325 the switching state. 1327 Pass-through state: A node is in the pass-through state when its 1328 highest priority RPS request is a request not destined to it or 1329 generated by it. The pass-through is bidirectional. 1331 5.2.3.1. Idle State 1333 A node in the idle state MUST generate the NR request in both 1334 directions. 1336 A node in the idle state MUST terminate RPS requests flow in both 1337 directions. 1339 A node in the idle state MUST block the traffic flow on protection 1340 ring tunnels in both directions. 1342 5.2.3.2. Switching State 1344 A node in the switching state MUST generate RPS request to its 1345 adjacent node with its highest RPS request code in both directions 1346 when it detects a failure or receives an external command. 1348 In bidirectional failure condition, both of the nodes adjacent to the 1349 failure detect the failure and send the RPS request in both 1350 directions with the destination set to each other, while each node 1351 can only receive the RPS request via the long path, the message sent 1352 via the short path will get lost due to the bidirectional failure. 1354 Here the short path refers to the shorter path on the ring between 1355 the source and destination node of the RPS request, and the long path 1356 refers to the longer path on the ring between the source and 1357 destination node of the RPS request. Upon receipt of the RPS request 1358 on the long path, the destination node of the RPS request MUST send 1359 RPS request with its highest request code periodically along the long 1360 path to the other node adjacent to the failure. 1362 In unidirectional failure condition, the node which detects the 1363 failure MUST send the RPS request in both directions with the 1364 destination node set to the other node adjacent to the failure. The 1365 destination node of the RPS request cannot detect the failure itself 1366 but will receive RPS request from both the short path and the long 1367 path. The destination node MUST acknowledge the received RPS request 1368 by replying an RPS request with the RR code on the short path, and an 1369 RPS request with the received RPS request code on the long path. 1370 Accordingly, when the node which detects the failure receives RPS 1371 request with RR code on the short path, then the RPS request received 1372 from the same node along the long path SHOULD be ignored. 1374 A node in the switching state MUST terminate the received RPS 1375 requests in both directions and not forward it further along the 1376 ring. 1378 The following switches as defined in section 5.3.1 MUST be allowed to 1379 coexist: 1381 o LP and LP 1383 o FS and FS 1385 o SF and SF 1387 o FS and SF 1389 When multiple MS RPS requests exist at the same time addressing 1390 different links and there is no higher priority request on the ring, 1391 no switch SHOULD be executed and existing switches MUST be dropped. 1392 The nodes MUST still signal RPS request with the MS code. 1394 Multiple EXER requests MUST be allowed to coexist in the ring. 1396 A node in a ring switching state that receives the external command 1397 LP for the affected link MUST drop its switch and MUST signal NR for 1398 the locked link if there is no other RPS request on another link. 1399 The node still SHOULD signal relevant RPS request for another link. 1401 5.2.3.3. Pass-through State 1403 When a node is in a pass-through state, it MUST transfer the received 1404 RPS Request unchanged in the same direction. 1406 When a node is in a pass-through state, it MUST enable the traffic 1407 flow on protection ring tunnels in both directions. 1409 5.2.4. RPS State Transitions 1411 All state transitions are triggered by an incoming RPS request 1412 change, a WTR expiration, an externally initiated command, or locally 1413 detected MPLS-TP section failure conditions. 1415 RPS requests due to a locally detected failure, an externally 1416 initiated command, or received RPS request shall preempt existing RPS 1417 requests in the prioritized order given in Section 5.2.2, unless the 1418 requests are allowed to coexist. 1420 5.2.4.1. Transitions Between Idle and Pass-through States 1422 The transition from the idle state to pass-through state MUST be 1423 triggered by a valid RPS request change, in any direction, from the 1424 NR code to any other code, as long as the new request is not destined 1425 to the node itself. Both directions move then into a pass-through 1426 state, so that, traffic entering the node through the protection ring 1427 tunnels are transferred transparently through the node. 1429 A node MUST revert from pass-through state to the idle state when RPS 1430 request with NR code is received in both directions. Then both 1431 directions revert simultaneously from the pass-through state to the 1432 idle state. 1434 5.2.4.2. Transitions Between Idle and Switching States 1436 Transition of a node from the Idle state to the Switching state MUST 1437 be triggered by one of the following conditions: 1439 o A valid RPS request change from the NR code to any code received 1440 on either the long or the short path and is destined to this node 1442 o An externally initiated command for this node 1444 o The detection of an MPLS-TP section layer failure at this node 1446 Actions taken at a node in the Idle state upon transition to the 1447 switching state are: 1449 o For all protection switch requests, except EXER and LP, the node 1450 MUST execute the switch 1452 o For EXER, and LP, the node MUST signal appropriate request but not 1453 execute the switch 1455 In one of the following conditions, transition from the Switching 1456 state to the Idle state MUST be triggered: 1458 o On node which triggers the protection switching, when the WTR time 1459 expires or an externally initiated command is cleared, the node 1460 MUST transit from Switching state to Idle State and signal the NR 1461 code using RPS message in both directions. 1463 o On node which enters the switching state due to the received RPS 1464 request: Upon reception of the NR code from both directions, the 1465 head-end node MUST drop its switch, transition to Idle State and 1466 signal the NR code in both directions. 1468 5.2.4.3. Transitions Between Switching States 1470 When a node that is currently executing any protection switch 1471 receives a higher priority RPS request (due to a locally detected 1472 failure, an externally initiated command, or a ring protection switch 1473 request destined to it) for the same link, it MUST update the 1474 priority of the switch it is executing to the priority of the 1475 received RPS request. 1477 When a failure condition clears at a node, the node MUST enter WTR 1478 condition and remain in it for the appropriate time-out interval, 1479 unless: 1481 o A different RPS request with a higher priority than WTR is 1482 received 1484 o Another failure is detected 1486 o An externally initiated command becomes active 1488 The node MUST send out a WTR code on both the long and short paths. 1490 When a node that is executing a switch in response to incoming SF RPS 1491 request (not due to a locally detected failure) receives a WTR code 1492 (unidirectional failure case), it MUST send out RR code on the short 1493 path and the WTR on the long path. 1495 5.2.4.4. Transitions Between Switching and Pass-through States 1497 When a node that is currently executing a switch receives an RPS 1498 request for a non-adjacent link of higher priority than the switch it 1499 is executing, it MUST drop its switch immediately and enter the pass- 1500 through state. 1502 The transition of a node from pass-through to switching state MUST be 1503 triggered by: 1505 o An equal priority, a higher priority, or an allowed coexisting 1506 externally initiated command 1508 o The detection of an equal priority, a higher priority, or an 1509 allowed coexisting automatic initiated command 1511 o The receipt of an equal, a higher priority, or an allowed 1512 coexisting RPS request destined to this node 1514 5.3. RPS State Machine 1516 5.3.1. Switch Initiation Criteria 1518 5.3.1.1. Administrative Commands 1520 Administrative commands can be initiated by the network operator 1521 through the Network Management System (NMS). The operator command 1522 may be transmitted to the appropriate node via the MPLS-TP RPS 1523 message. 1525 The following commands can be transferred by the RPS message: 1527 o Lockout of Protection (LP): This command prevents any protection 1528 activity and prevents using ring switches anywhere in the ring. 1529 If any ring switches exist in the ring, this command causes the 1530 switches to drop. 1532 o Forced Switch to protection (FS): This command performs the ring 1533 switch of normal traffic from the working entity to the protection 1534 entity for the link between the node at which the command is 1535 initiated and the adjacent node to which the command is directed. 1536 This switch occurs regardless of the state of the MPLS-TP section 1537 for the requested link, unless a higher priority switch request 1538 exists. 1540 o Manual Switch to protection (MS): This command performs the ring 1541 switch of the normal traffic from the working entity to the 1542 protection entity for the link between the node at which the 1543 command is initiated and the adjacent node to which the command is 1544 directed. This occurs if the MPLS-TP section for the requested 1545 link is not satisfying an equal or higher priority switch request. 1547 o Exercise - Ring (EXER): This command exercises ring protection 1548 switching on the addressed link without completing the actual 1549 switch. The command is issued and the responses (RR) are checked, 1550 but no normal traffic is affected. 1552 The following commands are not transferred by the RPS message: 1554 o Clear: This command clears the administrative command and Wait-To- 1555 Restore timer (WTR) at the node to which the command was 1556 addressed. The node to node signaling after the removal of the 1557 externally initiated commands is performed using the no-request 1558 code (NR). 1560 o Lockout of Working (LW): This command prevents the normal traffic 1561 transported over the addressed link from being switched to the 1562 protection entity by disabling the node's capability of requesting 1563 switch for this link in case of failure. If any normal traffic is 1564 already switched on the protection entity, the switch is dropped. 1565 If no other switch requests are active on the ring, the no-request 1566 code (NR) is transmitted. This command has no impact on any other 1567 link. If the node receives the switch request from the adjacent 1568 node from any side it will perform the requested switch. If the 1569 node receives the switch request addressed to the other node, it 1570 will enter the pass-through state. 1572 5.3.1.2. Automatically Initiated Commands 1574 Automatically initiated commands can be initiated based on MPLS-TP 1575 section layer OAM indication and the received switch requests. 1577 The node can initiate the following switch requests automatically: 1579 o Signal Fail (SF): This command is issued when the MPLS-TP section 1580 layer OAM detects signal failure condition. 1582 o Wait-To-Restore (WTR): This command is issued when MPLS-TP section 1583 detects that the SF condition has cleared. It is used to maintain 1584 the state during the WTR period unless it is preempted by a higher 1585 priority switch request. The WTR time may be configured by the 1586 operator in 1 minute steps between 0 and 12 minutes; the default 1587 value is 5 minutes. 1589 o Reverse Request (RR): This command is transmitted to the source 1590 node of the received RPS message over the short path as an 1591 acknowledgment for receiving the switch request. 1593 5.3.2. Initial States 1595 This section describes the possible states of a ring node, the 1596 corresponding action of the working and protection ring tunnels on 1597 the node, and the RPS request which should be generated in that 1598 state. 1600 +-----------------------------------+----------------+ 1601 | State | Signaled RPS | 1602 +-----------------------------------+----------------+ 1603 | A | Idle | NR | 1604 | | Working: no switch | | 1605 | | Protection: no switch | | 1606 +-----+-----------------------------+----------------+ 1607 | B | Pass-through | N/A | 1608 | | Working: no switch | | 1609 | | Protection: pass through | | 1610 +-----+-----------------------------+----------------+ 1611 | C | Switching - LP | LP | 1612 | | Working: no switch | | 1613 | | Protection: no switch | | 1614 +-----+-----------------------------+----------------+ 1615 | D | Idle - LW | NR | 1616 | | Working: no switch | | 1617 | | Protection: no switch | | 1618 +-----+-----------------------------+----------------+ 1619 | E | Switching - FS | FS | 1620 | | Working: switched | | 1621 | | Protection: switched | | 1622 +-----+-----------------------------+----------------+ 1623 | F | Switching - SF | SF | 1624 | | Working: switched | | 1625 | | Protection: switched | | 1626 +-----+-----------------------------+----------------+ 1627 | G | Switching - MS | MS | 1628 | | Working: switched | | 1629 | | Protection: switched | | 1630 +-----+-----------------------------+----------------+ 1631 | H | Switching - WTR | WTR | 1632 | | Working: switched | | 1633 | | Protection: switched | | 1634 +-----+-----------------------------+----------------+ 1635 | I | Switching - EXER | EXER | 1636 | | Working: no switch | | 1637 | | Protection: no switch | | 1638 +-----+-----------------------------+----------------+ 1640 5.3.3. State transitions When Local Request is Applied 1642 In the state description below 'O' means that new local request will 1643 be rejected because of exiting request. 1645 ===================================================================== 1646 Initial state New request New state 1647 ------------- ----------- --------- 1648 A (Idle) LP C (Switching - LP) 1649 LW D (Idle - LW) 1650 FS E (Switching - FS) 1651 SF F (Switching - SF) 1652 Recover from SF N/A 1653 MS G (Switching - MS) 1654 Clear N/A 1655 WTR expires N/A 1656 EXER I (Switching - EXER) 1657 ===================================================================== 1658 Initial state New request New state 1659 ------------- ----------- --------- 1660 B (Pass-through) LP C (Switching - LP) 1661 LW B (Pass-through) 1662 FS O - if current state is due to 1663 LP sent by another node 1664 E (Switching - FS) - otherwise 1665 SF O - if current state is due to 1666 LP sent by another node 1667 F (Switching - SF) - otherwise 1668 Recover from SF N/A 1669 MS O - if current state is due to 1670 LP, SF or FS sent by 1671 another node 1672 G (Switching - MS) - otherwise 1673 Clear N/A 1674 WTR expires N/A 1675 EXER O 1676 ===================================================================== 1677 Initial state New request New state 1678 ------------- ----------- --------- 1679 C (Switching - LP) LP N/A 1680 LW O 1681 FS O 1682 SF O 1683 Recover from SF N/A 1684 MS O 1685 Clear A (Idle) - if there is no 1686 failure in the ring 1687 F (Switching - SF) - if there 1688 is a failure at this node 1689 B (Pass-through) - if there is 1690 a failure at another node 1691 WTR expires N/A 1692 EXER O 1693 ===================================================================== 1694 Initial state New request New state 1695 ------------- ----------- --------- 1696 D (Idle - LW) LP C (Switching - LP) 1697 LW N/A - if on the same link 1698 D (Idle - LW) - if on another 1699 link 1700 FS O - if on the same link 1701 E (Switching - FS) - if on 1702 another link 1703 SF O - if on the addressed link 1704 F (Switching - SF) - if on 1705 another link 1706 Recover from SF N/A 1707 MS O - if on the same link 1708 G (Switching - MS) - if on 1709 another link 1710 Clear A (Idle) - if there is no 1711 failure on addressed link 1712 F (Switching - SF) - if there 1713 is a failure on this link 1714 WTR expires N/A 1715 EXER O 1716 ===================================================================== 1717 Initial state New request New state 1718 ------------- ----------- --------- 1719 E (Switching - FS) LP C (Switching - LP) 1720 LW O - if on another link 1721 D (Idle - LW) - if on the same 1722 link 1723 FS N/A - if on the same link 1724 E (Switching - FS) - if on 1725 another link 1726 SF O - if on the addressed link 1727 E (Switching - FS) - if on 1728 another link 1729 Recover from SF N/A 1730 MS O 1731 Clear A (Idle) - if there is no 1732 failure in the ring 1733 F (Switching - SF) - if there 1734 is a failure at this node 1735 B (Pass-through) - if there is 1736 a failure at another node 1737 WTR expires N/A 1738 EXER O 1739 ===================================================================== 1740 Initial state New request New state 1741 ------------- ----------- --------- 1742 F (Switching - SF) LP C (Switching - LP) 1743 LW O - if on another link 1744 D (Idle - LW) - if on the same 1745 link 1746 FS E (Switching - FS) 1747 SF N/A - if on the same link 1748 F (Switching - SF) - if on 1749 another link 1750 Recover from SF H (Switching - WTR) 1751 MS O 1752 Clear N/A 1753 WTR expires N/A 1754 EXER O 1755 ===================================================================== 1756 Initial state New request New state 1757 ------------- ----------- --------- 1758 G (Switching - MS) LP C (Switching - LP) 1759 LW O - if on another link 1760 D (Idle - LW) - if on the same 1761 link 1762 FS E (Switching - FS) 1763 SF F (Switching - SF) 1764 Recover from SF N/A 1765 MS N/A - if on the same link 1766 G (Switching - MS) - if on 1767 another link release the 1768 switches but signal MS 1769 Clear A 1770 WTR expires N/A 1771 EXER O 1772 ===================================================================== 1773 Initial state New request New state 1774 ------------- ----------- --------- 1775 H (Switching - WTR) LP C (Switching - LP) 1776 LW D (Idle - W) 1777 FS E (Switching - FS) 1778 SF F (Switching - SF) 1779 Recover from SF N/A 1780 MS G (Switching - MS) 1781 Clear A 1782 WTR expires A 1783 EXER O 1784 ===================================================================== 1785 Initial state New request New state 1786 ------------- ----------- --------- 1787 I (Switching - EXER) LP C (Switching - LP) 1788 LW D (idle - W) 1789 FS E (Switching - FS) 1790 SF F (Switching - SF) 1791 Recover from SF N/A 1792 MS G (Switching - MS) 1793 Clear A 1794 WTR expires N/A 1795 EXER N/A - if on the same link 1796 I (Switching - EXER) 1797 ===================================================================== 1799 5.3.4. State Transitions When Remote Request is Applied 1801 The priority of a remote request does not depend on the side from 1802 which the request is received. 1804 ===================================================================== 1805 Initial state New request New state 1806 ------------- ----------- --------- 1807 A (Idle) LP C (Switching - LP) 1808 FS E (Switching - FS) 1809 SF F (Switching - SF) 1810 MS G (Switching - MS) 1811 WTR N/A 1812 EXER I (Switching - EXER) 1813 RR N/A 1814 NR A (Idle) 1815 ===================================================================== 1816 Initial state New request New state 1817 ------------- ----------- --------- 1818 B (Pass-through) LP C (Switching - LP) 1819 FS N/A - cannot happen when there 1820 is LP request in the ring 1821 E (Switching - FS) - otherwise 1822 SF N/A - cannot happen when there 1823 is LP request in the ring 1824 F (Switching - SF) - otherwise 1825 MS N/A - cannot happen when there 1826 is LP, FS or SF request 1827 in the ring 1828 G (Switching - MS) - otherwise 1829 WTR N/A - cannot happen when there 1830 is LP, FS, SF or MS 1831 request in the ring 1832 EXER N/A - cannot happen when there 1833 is LP, FS, SF, MS or WTR 1834 request in the ring 1835 I (Switching - EXER) - 1836 otherwise 1837 RR N/A 1838 NR A (Idle) - if received from 1839 both sides 1840 ===================================================================== 1841 Initial state New request New state 1842 ------------- ----------- --------- 1843 C (Switching - LP) LP C (Switching - LP) 1844 FS N/A - cannot happen when there 1845 is LP request in the ring 1846 SF N/A - cannot happen when there 1847 is LP request in the ring 1848 MS N/A - cannot happen when there 1849 is LP request in the ring 1850 WTR N/A 1851 EXER N/A - cannot happen when there 1852 is LP request in the ring 1853 RR C (Switching - LP) 1854 NR N/A 1855 ===================================================================== 1856 Initial state New request New state 1857 ------------- ----------- --------- 1858 D (Idle - LW) LP C (Switching - LP) 1859 FS E (Switching - FS) 1860 SF F (Switching - SF) 1861 MS G (Switching - MS) 1862 WTR N/A 1863 EXER I (Switching - EXER) 1864 RR N/A 1865 NR D (Idle - LW) 1866 ===================================================================== 1867 Initial state New request New state 1868 ------------- ----------- --------- 1869 E (Switching - FS) LP C (Switching - LP) 1870 FS E (Switching - FS) 1871 SF E (Switching - FS) 1872 MS N/A - cannot happen when there 1873 is FS request in the ring 1874 WTR N/A 1875 EXER N/A - cannot happen when there 1876 is FS request in the ring 1877 RR E (Switching - FS) 1878 NR N/A 1879 ===================================================================== 1880 Initial state New request New state 1881 ------------- ----------- --------- 1882 F (Switching - SF) LP C (Switching - LP) 1883 FS F (Switching - SF) 1884 SF F (Switching - SF) 1885 MS N/A - cannot happen when there 1886 is SF request in the ring 1888 WTR N/A 1889 EXER N/A - cannot happen when there 1890 is SF request in the ring 1891 RR F (Switching - SF) 1892 NR N/A 1893 ===================================================================== 1894 Initial state New request New state 1895 ------------- ----------- --------- 1896 G (Switching - MS) LP C (Switching - LP) 1897 FS E (Switching - FS) 1898 SF F (Switching - SF) 1899 MS G (Switching - MS) - release 1900 the switches but signal MS 1901 WTR N/A 1902 EXER N/A - cannot happen when there 1903 is MS request in the ring 1904 RR G (Switching - MS) 1905 NR N/A 1906 ===================================================================== 1907 Initial state New request New state 1908 ------------- ----------- --------- 1909 H (Switching - WTR) LP C (Switching - LP) 1910 FS E (Switching - FS) 1911 SF F (Switching - SF) 1912 MS G (Switching - MS) 1913 WTR H (Switching - WTR) 1914 EXER N/A - cannot happen when there 1915 is WTR request in the ring 1916 RR H (Switching - WTR) 1917 NR N/A 1918 ===================================================================== 1919 Initial state New request New state 1920 ------------- ----------- --------- 1921 I (Switching - EXER) LP C (Switching - LP) 1922 FS E (Switching - FS) 1923 SF F (Switching - SF) 1924 MS G (Switching - MS) 1925 WTR N/A 1926 EXER I (Switching - EXER) 1927 RR I (Switching - EXER) 1928 NR N/A 1929 ===================================================================== 1931 5.3.5. State Transitions When Request Addresses to Another Node is 1932 Received 1934 The priority of a remote request does not depend on the side from 1935 which the request is received. 1937 ===================================================================== 1938 Initial state New request New state 1939 ------------- ----------- --------- 1940 A (Idle) LP B (Pass-through) 1941 FS B (Pass-through) 1942 SF B (Pass-through) 1943 MS B (Pass-through) 1944 WTR B (Pass-through) 1945 EXER B (Pass-through) 1946 RR N/A 1947 NR N/A 1948 ===================================================================== 1949 Initial state New request New state 1950 ------------- ----------- --------- 1951 B (Pass-through) LP B (Pass-through) 1952 FS N/A - cannot happen when there 1953 is LP request in the ring 1954 B (Pass-through) - otherwise 1955 SF N/A - cannot happen when there 1956 is LP request in the ring 1957 B (Pass-through) - otherwise 1958 MS N/A - cannot happen when there 1959 is LP, FS or SF request 1960 in the ring 1961 B (Pass-through) - otherwise 1962 WTR N/A - cannot happen when there 1963 is LP, FS, SF or MS 1964 request in the ring 1965 B (Pass-through) - otherwise 1966 EXER N/A - cannot happen when there 1967 is LP, FS, SF, MS or WTR 1968 request in the ring 1969 B (Pass-through) - otherwise 1970 RR N/A 1971 NR N/A 1972 ===================================================================== 1973 Initial state New request New state 1974 ------------- ----------- --------- 1975 C (Switching - LP) LP C (Switching - LP) 1976 FS N/A - cannot happen when there 1977 is LP request in the ring 1978 SF N/A - cannot happen when there 1979 is LP request in the ring 1980 MS N/A - cannot happen when there 1981 is LP request in the ring 1982 WTR N/A - cannot happen when there 1983 is LP in the ring 1984 EXER N/A - cannot happen when there 1985 is LP request in the ring 1986 RR N/A 1987 NR N/A 1988 ===================================================================== 1989 Initial state New request New state 1990 ------------- ----------- --------- 1991 D (Idle - LW) LP B (Pass-through) 1992 FS B (Pass-through) 1993 SF B (Pass-through) 1994 MS B (Pass-through) 1995 WTR B (Pass-through) 1996 EXER B (Pass-through) 1997 RR N/A 1998 NR N/A 1999 ===================================================================== 2000 Initial state New request New state 2001 ------------- ----------- --------- 2002 E (Switching - FS) LP B (Pass-through) 2003 FS E (Switching - FS) 2004 SF E (Switching - FS) 2005 MS N/A - cannot happen when there 2006 is FS request in the ring 2007 WTR N/A - cannot happen when there 2008 is FS request in the ring 2009 EXER N/A - cannot happen when there 2010 is FS request in the ring 2011 RR N/A 2012 NR N/A 2013 ===================================================================== 2014 Initial state New request New state 2015 ------------- ----------- --------- 2016 F (Switching - SF) LP B (Pass-through) 2017 FS F (Switching - SF) 2018 SF F (Switching - SF) 2019 MS N/A - cannot happen when there 2020 is SF request in the ring 2021 WTR N/A - cannot happen when there 2022 is SF request in the ring 2023 EXER N/A - cannot happen when there 2024 is SF request in the ring 2025 RR N/A 2026 NR N/A 2028 ===================================================================== 2029 Initial state New request New state 2030 ------------- ----------- --------- 2031 G (Switching - MS) LP B (Pass-through) 2032 FS B (Pass-through) 2033 SF B (Pass-through) 2034 MS G (Switching - MS) - release 2035 the switches but signal MS 2036 WTR N/A - cannot happen when there 2037 is MS request in the ring 2038 EXER N/A - cannot happen when there 2039 is MS request in the ring 2040 RR N/A 2041 NR N/A 2042 ===================================================================== 2043 Initial state New request New state 2044 ------------- ----------- --------- 2045 H (Switching - WTR) LP B (Pass-through) 2046 FS B (Pass-through) 2047 SF B (Pass-through) 2048 MS B (Pass-through) 2049 WTR N/A 2050 EXER N/A - cannot happen when there 2051 is WTR request in the ring 2052 RR N/A 2053 NR N/A 2054 ===================================================================== 2055 Initial state New request New state 2056 I (Switching - EXER) LP B (Pass-through) 2057 FS B (Pass-through) 2058 SF B (Pass-through) 2059 MS B (Pass-through) 2060 WTR N/A 2061 EXER I (Switching - EXER) 2062 RR N/A 2063 NR N/A 2064 ===================================================================== 2066 6. IANA Considerations 2068 IANA is requested to administer the assignment of new values defined 2069 in this document and listed in the sections below. 2071 6.1. G-ACh Channel Type 2073 The Channel Types for the Generic Associated channel (GACh) are 2074 allocated from the IANA PW Associated Channel Type registry defined 2075 in [RFC4446] and updated by [RFC5586]. 2077 IANA is requested to allocate a new GACh Channel Type as follows: 2079 Value| Description | Reference 2080 ------+---------------------------+-------------- 2081 TBD | Ring Protection Switching |this document 2082 | Protocol (RPS) | 2083 ------+---------------------------+-------------- 2085 6.2. RPS Request Codes 2087 IANA is requested to create a new sub-registry under the 2088 "Multiprotocol Label Switching (MPLS) Operations, Administration, and 2089 Management (OAM) Parameters" registry called the "MPLS RPS Request 2090 Code Registry". All code points within this registry shall be 2091 allocated according to the "Specification Required" procedure as 2092 specified in [RFC5226]. 2094 The RPS Request Field is 8 bits, the allocated values are as follows: 2096 Value Description Reference 2097 ------- --------------------------- --------------- 2098 0 No Request (NR) this document 2099 1 Reverse Request (RR) this document 2100 2 unassigned 2101 3 Exercise (EXER) this document 2102 4 unassigned 2103 5 Wait-To-Restore (WTR) this document 2104 6 Manual Switch (MS) this document 2105 7-10 unassigned 2106 11 Signal Fail (SF) this document 2107 12 unassigned 2108 13 Forced Switch (FS) this document 2109 14 unassigned 2110 15 Lockout of Protection (LP) this document 2111 16-254 unassigned 2112 255 Reserved 2114 7. Operational Considerations 2116 This document describes three protection modes of the RPS protocol. 2117 Operators could choose the appropriate protection mode according to 2118 their network and service requirement. 2120 Wrapping mode provides a ring protection mechanism in which the 2121 protected traffic will reach every node of the ring, and is 2122 applicable to protect both the point-to-point LSPs and LSPs which 2123 needs to be dropped in several ring nodes, i.e. the point-to- 2124 multipoint applications. When protection is in active, the protected 2125 traffic is switched (wrapped) to/from the protection ring tunnel at 2126 both sides of the defective link/node. Due to the wrapping the 2127 additional propagation delay and bandwidth consumption of the 2128 protection tunnel are considerable. For bidirectional LSP, the 2129 protected traffic in both directions is co-routed. 2131 Short wrapping mode provides a ring protection mechanism which can be 2132 used to protect only point-to-point LSPs. When protection is in 2133 active, the protected traffic wrapped to the protection ring tunnel 2134 at the defective link/node and leaves the ring when the protection 2135 ring tunnel reach the egress node. Compared with wrapping mode, 2136 short wrapping can reduce the propagation latency and bandwidth 2137 consumption of the protection tunnel. However the two directions of 2138 a protected bidirectional LSP are not totally co-routed. 2140 Steering mode provides a ring protection mechanism that can be used 2141 to protect only point-to-point LSPs. When protection is in 2142 active,the protected traffic is switched to the protection ring 2143 tunnel at the ingress node and leaves the ring when the protection 2144 ring tunnel reach the egress node. Steering mode has the least 2145 propagation delay and bandwidth consumption of the three modes, and 2146 the two directions of a protected bidirectional LSP can be kept co- 2147 routed. 2149 Note that only one protection mode can be provisioned in the whole 2150 ring for all protected traffic. 2152 8. Security Considerations 2154 MPLS-TP is a subset of MPLS and so builds upon many of the aspects of 2155 the security model of MPLS. Please refer to [RFC5920] for generic 2156 MPLS security issues and methods for securing traffic privacy and 2157 integrity. 2159 The RPS message defined in this document is used for protection 2160 coordination on the ring, if it is injected or modified by an 2161 attacker, the ring nodes might not agree on the protection action, 2162 and the improper protection switching action may cause temporary 2163 break to services traversing the ring. It is important that the RPS 2164 message is used within a trusted MPLS-TP network domain as described 2165 in [RFC6941]. 2167 The RPS message is carried in the G-ACh [RFC5586], so it is dependent 2168 on the security of the G-ACh itself. The G-ACh is a generalization 2169 of the Associated Channel defined in [RFC4385]. Thus, this document 2170 relies on the security mechanisms provided for the Associated Channel 2171 as described in those two documents. 2173 As described in the security considerations of [RFC6378], the G-ACh 2174 is essentially connection oriented so injection or modification of 2175 control messages requires the subversion of a transit node. Such 2176 subversion is generally considered hard in connection oriented MPLS 2177 networks and impossible to protect against at the protocol level. 2178 Management level techniques are more appropriate. The procedures and 2179 protocol extensions defined in this document do not affect the 2180 security model of MPLS-TP linear protection as defined in [RFC6378]. 2182 9. Contributing Authors 2183 Kai Liu 2184 Huawei Technologies 2185 Email: alex.liukai@huawei.com 2187 Jia He 2188 Huawei Technologies 2189 Email: hejia@huawei.com 2191 Fang Li 2192 China Academy of Telecommunication Research MIIT., China 2193 Email: lifang@catr.cn 2195 Jian Yang 2196 ZTE Corporation P.R.China 2197 Email: yang.jian90@zte.com.cn 2199 Junfang Wang 2200 Fiberhome Telecommunication Technologies Co., LTD. 2201 Email: wjf@fiberhome.com.cn 2203 Wen Ye 2204 China Mobile 2205 Email: yewen@chinamobile.com 2207 Minxue Wang 2208 China Mobile 2209 Email: wangminxue@chinamobile.com 2211 Sheng Liu 2212 China Mobile 2213 Email: liusheng@chinamobile.com 2215 Guanghui Sun 2216 Huawei Technologies 2217 Email: sunguanghui@huawei.com 2219 10. Acknowledgements 2221 The authors would like to thank Gregory Mirsky, Yimin Shen, Eric 2222 Osborne, Spencer Jackson and Eric Gray for their valuable comments 2223 and suggestions. 2225 11. References 2226 11.1. Normative References 2228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2229 Requirement Levels", BCP 14, RFC 2119, 2230 DOI 10.17487/RFC2119, March 1997, 2231 . 2233 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2234 Label Switching Architecture", RFC 3031, 2235 DOI 10.17487/RFC3031, January 2001, 2236 . 2238 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 2239 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 2240 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 2241 February 2006, . 2243 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 2244 Emulation (PWE3)", BCP 116, RFC 4446, 2245 DOI 10.17487/RFC4446, April 2006, 2246 . 2248 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 2249 "MPLS Generic Associated Channel", RFC 5586, 2250 DOI 10.17487/RFC5586, June 2009, 2251 . 2253 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 2254 Sprecher, N., and S. Ueno, "Requirements of an MPLS 2255 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 2256 September 2009, . 2258 11.2. Informative References 2260 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2261 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2262 DOI 10.17487/RFC5226, May 2008, 2263 . 2265 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 2266 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 2267 . 2269 [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, 2270 Administration, and Maintenance Framework for MPLS-Based 2271 Transport Networks", RFC 6371, DOI 10.17487/RFC6371, 2272 September 2011, . 2274 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 2275 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 2276 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 2277 October 2011, . 2279 [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., 2280 and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) 2281 Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2282 2013, . 2284 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 2285 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 2286 "Applicability of MPLS Transport Profile for Ring 2287 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 2288 . 2290 Authors' Addresses 2292 Weiqiang Cheng 2293 China Mobile 2295 Email: chengweiqiang@chinamobile.com 2297 Lei Wang 2298 China Mobile 2300 Email: wangleiyj@chinamobile.com 2302 Han Li 2303 China Mobile 2305 Email: lihan@chinamobile.com 2307 Huub van Helvoort 2308 Hai Gaoming BV 2310 Email: huubatwork@gmail.com 2312 Jie Dong 2313 Huawei Technologies 2315 Email: jie.dong@huawei.com