idnits 2.17.1 draft-ietf-mpls-tp-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 860 has weird spacing: '...segment bac...' == Line 867 has weird spacing: '...segment back...' -- The document date (April 29, 2013) is 4009 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LI' is mentioned on line 483, but not defined -- Looks like a reference, but probably isn't: '99' on line 1116 -- Looks like a reference, but probably isn't: '199' on line 1087 -- Looks like a reference, but probably isn't: '299' on line 1087 -- Looks like a reference, but probably isn't: '399' on line 1087 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Weingarten 3 Internet-Draft 4 Intended status: Informational S. Bryant 5 Expires: October 31, 2013 Cisco 6 D. Ceccarelli 7 D. Caviglia 8 F. Fondelli 9 Ericsson 10 M. Corsi 11 Altran 12 B. Wu 13 X. Dai 14 ZTE Corporation 15 April 29, 2013 17 Applicability of MPLS-TP Linear Protection for Ring Topologies 18 draft-ietf-mpls-tp-ring-protection-06.txt 20 Abstract 22 This document presents an applicability of existing MPLS protection 23 mechanisms, both local and end-to-end, to Multi-Protocol Label 24 Switching Transport Profile (MPLS-TP) in ring topologies. This 25 document does not propose any new mechanisms or protocols. 26 Protection on rings offers a number of opportunities for optimization 27 as the protection choices are starkly limited (all traffic traveling 28 one way around a ring can only be switched to travel the other way on 29 the ring), but also suffers from some complications caused by the 30 limitations of the topology. 32 Requirements for MPLS-TP protection especially for protection in ring 33 topologies are discussed in "Requirements of an MPLS Transport 34 Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) 35 Survivability Framework" (RFC 6372). This document shows how MPLS-TP 36 linear protection as defined in RFC 6378 can be applied to single 37 ring topologies, discusses how most of the requirements are met, and 38 describes scenarios in which the function provided by applying linear 39 protection in a ring topology falls short of some of the 40 requirements. 42 This document is a product of a joint Internet Engineering Task Force 43 (IETF) / International Telecommunications Union Telecommunications 44 Standardization Sector (ITU-T) effort to include an MPLS Transport 45 Profile within the IETF MPLS and PWE3 architectures to support the 46 capabilities and functionalities of a packet transport network as 47 defined by the ITU-T. 49 Status of this Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on October 31, 2013. 66 Copyright Notice 68 Copyright (c) 2013 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 85 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 86 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6 87 1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 88 2. Point-to-point (P2P) Ring Protection . . . . . . . . . . . . . 7 89 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 2.3. SPME for P2P protection of a ring topology . . . . . . . . 10 92 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 93 2.3.2. Wrapping link protection with segment based SPME . . . 13 94 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14 95 2.3.4. Wrapping for link and node protection . . . . . . . . 15 96 2.4. Analysis of P2P protection . . . . . . . . . . . . . . . . 16 97 2.4.1. Recommendations for protection of P2P paths 98 traversing a ring . . . . . . . . . . . . . . . . . . 17 99 3. Point-to-multipoint protection . . . . . . . . . . . . . . . . 17 100 3.1. Wrapping for P2MP LSP . . . . . . . . . . . . . . . . . . 17 101 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19 102 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 21 103 3.2. Steering for P2MP paths . . . . . . . . . . . . . . . . . 21 104 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 22 105 3.2.2. Walkthrough using context labels . . . . . . . . . . . 24 106 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 25 107 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 113 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 116 1. Introduction 118 Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been 119 standardized as part of a joint effort between the Internet 120 Engineering Task Force (IETF) and the International Telecommunication 121 Union Standardization (ITU-T). These specifications are based on the 122 requirements that were generated from this joint effort. 124 The MPLS-TP requirement document [RFC5654] includes a requirement to 125 support a network that may include sub-networks that constitute an 126 MPLS-TP ring as defined in the document. However, the document does 127 not identify any protection requirements specific to a ring topology. 128 However, the requirements state that specific protection mechanisms 129 applying to ring topologies may be developed if these allow the 130 network to minimize: 132 o Number of OAM entities needed to trigger the protection 134 o Number of elements of recovery needed 136 o Number of labels required 138 o Number of control and management plane transactions during a 139 maintenance operation 141 o Impact of signaling and routing information exchanged during 142 protection, in the presence of a control plane 144 This document describes how applying a set of basic MPLS-TP linear 145 protection mechanisms defined in [RFC6378] can be used to provide 146 protection of the data flows that traverse an MPLS-TP ring. These 147 mechanisms provide data flow protection due to any switching trigger 148 within a reasonable time frame and optimize the criteria set out in 149 [RFC5654], as summarized above. This document does not define any 150 new protocol mechanisms or procedures. 152 A related topic in [RFC5654] addresses the required support for 153 interconnected rings. This topic involves various scenarios that 154 require further study and will be addressed in a separate document, 155 based on the principles outlined in this document. 157 1.1. Problem statement 159 Ring topologies, as defined in [RFC5654], are used in transport 160 networks. When designing a protection mechanism for a single ring 161 topology, there is a need to address both - 162 1. A point-to-point transport path that either originates at or 163 enters an MPLS-TP capable ring at one node, the ingress node, and 164 exits the ring at a single egress node possibly continuing beyond 165 the ring. 167 2. Where the ring is being used as a branching point for a point-to- 168 multipoint transport path, i.e. the transport path originates at 169 or enters the MPLS-TP capable ring at the ingress node and exits 170 through a number of egress nodes, possibly continuing beyond the 171 ring. 173 In either of these two situations, there is a need to address the 174 following different cases - 176 1. One of the ring links causes a fault condition. This could be 177 either a unidirectional or bidirectional fault, and should be 178 detected by the neighboring nodes. 180 2. One of the ring nodes causes a fault condition. This condition 181 is invariably a bidirectional fault (although in rare cases of 182 misconfiguration this could be detected as a unidirectional 183 fault) and should be detected by the two neighboring ring nodes. 185 3. An operator command changes the operational state of a node or a 186 link, or specifically triggers a protection action is issued to a 187 specific ring node. A description of the different operator 188 commands is found in Section 4.13 of [RFC4427]. Examples of 189 these commands include Manual Switch, Forced Switch, or Clear 190 operations. 192 The protection domain addressed in this document is limited to the 193 traffic that traverses on the ring. Protection triggers on the 194 transport path prior to the ring ingress node or beyond the egress 195 nodes may be protected by some other mechanism. 197 1.2. Scope of the document 199 This document addresses the requirements that appear in Section 200 2.5.6.1 of [RFC5654] on Ring Protection based on the application of 201 the linear protection as defined in [RFC6378]. Requirement R93 202 regarding the support of interconnected rings and protection of 203 faults in the interconnection nodes and links is for further study. 205 In addition, requirement R105 requiring the support of lockout of 206 specific nodes or spans is only supported to the degree that it is 207 supported by the linear protection mechanism. 209 1.3. Terminology and Notation 211 The terminology used in this document is based on the terminology 212 defined in the MPLS-TP framework documents: 214 o MPLS-TP Framework[RFC5921] 216 o MPLS-TP OAM Framework[RFC6371] 218 o MPLS-TP Survivability Framework[RFC6372] 220 The MPLS-TP Framework document [RFC5921] defines a Sub-Path 221 Maintenance Entity (SPME) construct that can be defined between any 222 two Label Switching Routers (LSR) of an MPLS-TP Label Switched Path 223 (LSP). This SPME may be configured as a co-routed bidirectional 224 path. The SPME is defined to allow management and monitoring of any 225 segment of a transport path. This concept will be used extensively 226 throughout the document to support protection of the traffic that 227 traverses an MPLS-TP ring. 229 In addition, we describe the use of the label stack in connection 230 with the redirecting of data packets by the protection mechanism. 231 The following syntax will be used to describe the contents of the 232 label stack: 234 1. The label stack will be enclosed in square brackets ("[]") 236 2. Each level in the stack will be separated by the '|' character. 237 It should be noted that the label stack may contain additional 238 levels however, we only present the levels that are germane to 239 the protection mechanism. 241 3. When applicable, the S-bit (signifying that a given label is the 242 bottom of the label stack) will be denoted by the string '+S' 243 within the label. If a label is not shown with '+S' that label 244 may or may not be the bottom label in the stack. '+S' is only 245 shown when it is important to illustrate that a given label is 246 definitely the last one in the label stack. 248 4. The label of the LSP at the ingress point to the ring will be 249 denoted by the string "LI" and the label of the LSP that is 250 expected at the egress point from the ring will be denoted by the 251 string "LE", and "LSE" will denote the label expected at the exit 252 LSR of a SPME (if it is different from the egress point from the 253 ring, for example as described in Section 2.3). 255 5. The label for a SPME will be denoted by Pxi(y) where x and y are 256 LSR identifiers and the intention is to the label for LSR-x to 257 transmit to LSR-y over the SPME whose index is i. 259 For example - 261 o the label stack [LI] denotes the label stack received at the 262 ingress node of the ring. This may have additional labels after 263 LI, e.g. a PW label however, this is irrelevant to the discussion 264 of the protection scenario. 266 o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label 267 for LSR-B to transmit the data packet to LSR-G, the second label 268 is the label that would be used by the egress LSR to continue the 269 packet on the original LSP. 271 o If "LE" were the bottom label in the stack, then the label stack 272 would be shown as [PB1(G)|LE+S]. 274 1.4. Contributing Authors 276 The authors would like to acknowledge the following individuals that 277 contributed their insights and advice to this work: 279 Nurit Sprecher (NSN) 281 Akira Sakurai (NEC) 283 Rolf Winter (NEC) 285 Eric Osborne (Cisco) 287 2. Point-to-point (P2P) Ring Protection 289 There are two protection architecture mechanisms, that have 290 historically been applied to ring topologies, based on SDH 291 specifications [G.841], and have been proposed in various forums to 292 perform recovery of a topological ring network - "Wrapping" and 293 "Steering". The following sub-sections examine these two mechanisms, 294 as applied to an MPLS transport network. 296 2.1. Wrapping 298 Wrapping is defined as a local protection architecture. This 299 mechanism is local to the nodes that are neighbors to the detected 300 fault. When a fault is detected (either a link or node failure), the 301 neighboring node can identify that the fault would prevent forwarding 302 of the data along the data path. Therefore, in order to continue the 303 data along the path, there is need to "wrap" all data traffic around 304 the ring, on an alternate data path, until arriving at the node that 305 is on the opposite side of the fault. When this far-side node also 306 detects that there is a fault condition on the working path, it can 307 identify that the data traffic that is arriving on the alternate 308 (protecting) data path is intended for the "broken" data path. 309 Therefore, again taking a local decision, can wrap the data back onto 310 the normal working path until the egress from the ring segment. 312 Wrapping behavior is similar to MPLS-TE FRR as defined in [RFC4090] 313 using either bypass or detour tunnels. Applying this methodology to 314 MPLS, it is possible to wrap the traffic of each LSP around the 315 failed links via a detour tunnel using a different label for each LSP 316 or to wrap all LSPs using a bypass tunnel and a single label. 318 ___ ######## ___ ######## ___ 319 ======>/LSR\********/LSR\***XX***/LSR\ 320 \_B_/@@@@@@@@\_A_/ \_F_/ 321 *@ #*@ 322 *@ #*@ 323 *@ #*@ 324 _*@ ___ #*@ 325 /LSR\********/LSR\********/LSR\======> 326 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 328 ===> connected LSP *** physical link 329 ### working path @@@ wrapped data path 331 Figure 1: Wrapping protection for P2P path 333 Consider the LSP that is shown in Figure 1 that enters the ring of 334 LSRs at LSR-B and exits at LSR-E. The normal working path LSP 335 follows through LSRs B-A-F-E. If a fault is detected on the link 336 A<->F, then the wrapping mechanism decides that LSR-A would wrap the 337 traffic around the ring, on a wrapped data path A-B-C-D-E-F, to 338 arrive at LSR-F (on the far side of the failed link). LSR-F would 339 then wrap the data packets back onto the working path F->E to the 340 egress node. In this protection scheme, the traffic will follow the 341 path - B-A-B-C-D-E-F-E. 343 This protection scheme is simple in the sense that there is no need 344 for coordination between the different LSR in the ring - only the 345 LSRs that detect the fault must wrap the traffic, either onto the 346 wrapped data path (at the near-end) or back to the working path (at 347 the far-end). However, coordination of the switchover to the 348 protection path would be needed to maintain the traffic on a co- 349 routed bidirectional LSP even in cases of a unidirectional fault 350 condition. 352 The following considerations should be taken into account when 353 considering use of wrapping protection: 355 o Detection of loss-of-continuity or mis-connectivity should be 356 performed at the link level and/or per LSR when using node-level 357 protection. Configuration of the protection being performed (i.e. 358 link protection or node protection) needs to be performed 359 a-priori, since the configuration of the proper protection path is 360 dependent upon this decision. 362 o There is a need to define a data-path that traverses the alternate 363 path around the ring to connect between the two neighbors of the 364 detected fault. If protecting both the links and the nodes of a 365 LSP, then, for a ring with N nodes, there is a need for O(2N) 366 alternate paths. 368 o When wrapping, the data is transmitted over some of the links 369 twice, once in each direction. For example, in the figure above 370 the traffic is transmitted both B->A and then A->B, later it is 371 transmitted E->F and F->E. This means that there is additional 372 bandwidth needed for this protection. 374 o If a double-fault situation occurs in the ring, then wrapping will 375 not be able to deliver any packets except between the ingress and 376 the first fault location encountered on the working path. This is 377 based on the need for wrapping to connect between the neighbors of 378 the fault location, and this is not possible in the segmented 379 ring. 381 o The resource pre-allocation for all of the alternate-paths could 382 be problematic [causing massive over subscription of the available 383 resources]. However, since most of these alternate paths will not 384 be used simultaneously, there is the possibility of allocating '0' 385 resources and depend on the NMS to allocate the proper resources 386 around the ring, based on actual traffic usage. 388 o Wrapping also involves a small increase in traffic latency in 389 delivering the packets, as a result of traversing the entire ring, 390 during protection. 392 2.2. Steering 394 The second common scheme for ring protection, steering, takes 395 advantage of the ring topology by defining two paths from the ingress 396 point (to the ring) to the egress point going in opposite directions 397 around the ring. This is illustrated in Figure 2, where if we assume 398 that the traffic needs to enter the ring from node B and exit through 399 node F, we could define a primary path through nodes B-A-F, and an 400 alternate path through the nodes B-C-D-E-F. In steering the 401 switching is always performed by the ingress node (node B in 402 Figure 2). If a fault condition is detected anywhere on the working 403 path (B-A-F), then the traffic would be redirected by B to the 404 alternate path (i.e. B-C-D-E-F). 406 ___ ___ ___ 407 ======>/LSR\********/LSR\********/LSR\======> 408 \_B_/########\_A_/########\_F_/ 409 *@ @* 410 *@ @* 411 *@ @* 412 _*@ ___ @*_ 413 /LSR\********/LSR\********/LSR\ 414 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 416 ===> connected LSP *** physical link 417 ### working path @@@ protection path 419 Figure 2: Steering protection in an MPLS-TP ring 421 This mechanism bears similarities to linear 1:1 protection [RFC6372]. 422 The two paths around the ring act as the working and protection 423 paths. There is need to communicate to the ingress node the need to 424 switch over to the protection path and there is a need to coordinate 425 the switchover between the two end-points of the protected domain. 427 The following considerations must be taken into account regarding the 428 steering architecture: 430 o Steering relies on a failure detection method that is able to 431 notify the ingress node of the fault condition. This may involve 432 different OAM functionality described in [RFC6371], e.g. Remote 433 Defect Indication, Alarm reporting. 435 o The process of notifying the ingress node adds to the latency of 436 the protection switching process, after the detection of the fault 437 condition. 439 o While there is no need for double bandwidth for the data path, 440 there is the necessity for the ring to maintain enough capacity 441 for all of the data in both directions around the ring. 443 2.3. SPME for P2P protection of a ring topology 445 The SPME concept was introduced by [RFC5921] to support management 446 and monitoring an arbitrary segment of a transport. However, an SPME 447 is essentially a valid LSP that may be used to aggregate all LSP 448 traffic that traverses the sub-path delineated by the SPME. An SPME 449 may be monitored using the OAM mechanisms as described in the MPLS-TP 450 OAM Framework document [RFC6371]. 452 When defining an MPLS-TP ring as a protection domain, there is a need 453 to design a protection mechanism that protects all the LSPs that 454 cross the MPLS-TP ring. For this purpose, we associate a (working) 455 SPME with the segment of the transport path that traverses the ring. 456 In addition, we configure an alternate (protecting) SPME that 457 traverses the ring in the opposite direction around the ring. The 458 exact selection of the SPMEs is dependent on the type of transport 459 path and protection that is being implemented and will be detailed in 460 the following sub-sections. 462 Based on this architectural configuration for protection of ring 463 topologies, it is possible to limit the number of alternate paths 464 needed to protect the data traversing the ring. In addition, since 465 we will perform all of the OAM functionality on the SPME configured 466 for the traffic, we can minimize the number of OAM sessions needed to 467 monitor the data traffic of the ring - rather than monitoring each 468 individual LSP. 470 In all of the following subsections, we use 1:1 linear protection 471 [RFC6372] [RFC6378] to perform protection switching and coordination 472 when a signal fault is detected. The actual configuration of the 473 SPMEs used may change dependent upon the choice of methodology and 474 this will be detailed in the following sections. However, in all of 475 these configurations the mechanism will be to transmit the data 476 traffic on the primary SPME, while applying OAM functionality over 477 both the primary and the secondary SPME to detect signal fault 478 conditions on either path. If a signal fault is detected on the 479 primary SPME, then the mechanism described in [RFC6378] shall be used 480 to coordinate a switch-over of data traffic to the secondary SPME. 482 Assuming that the SPME is implemented as an hierarchical LSP, packets 483 that arrive at LSR-B with a label stack [LI] will have the SPME label 484 pushed at LSR-B and the LSP label will be swapped for the label that 485 is expected by the egress LSR (i.e. the packet will arrive at LSR-A 486 with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]). 487 The SPME label will be popped by LSR-F and the LSP label will be 488 treated appropriately at LSR-F and forwarded along the LSP, outside 489 the ring. This scenario is true for all LSP that are aggregated by 490 this primary SPME. 492 2.3.1. Path SPME for Steering 494 A P2P SPME that traverses part of a ring has two Maintenance Entity 495 Group End Points (MEPs), each one acts as the ingress and egress in 496 one direction of the bidirectional SPME. Since the SPME is 497 traversing a ring we can take advantage of another characteristic of 498 a ring - there is always an alternative path between the two MEPs, 499 i.e. traversing the ring in the opposite direction. This alternative 500 SPME can be defined as the protection path for the working path that 501 is configured as part of the LSP and defined as a SPME. 503 For each pair of SPMEs that are defined in this way, it is possible 504 to verify the connectivity and continuity by applying the MPLS-TP OAM 505 functionality to both the working and protection SPME. If a 506 discontinuity or mis-connectivity is detected then the MEPs will 507 become aware of this condition, and could perform a protection switch 508 of all LSPs to the alternate, protection SPME. 510 The following figure shows an MPLS-TP ring that is part of a larger 511 MPLS-TP network. The ring could be used as a network segment that 512 may be traversed by numerous LSPs. In particular, the figure shows 513 that for all LSPs that connect to the ring at LSR-B and exit the ring 514 from LSR-F, we configure two SPME through the ring (the first SPME 515 traverses along B-A-F, and the second SPME traverses B-C-D-E-F). 517 ___ ___ ___ 518 ======>/LSR\********/LSR\********/LSR\======> 519 \_B_/########\_A_/########\_F_/ 520 *@ @* 521 *@ @* 522 *@ @* 523 _*@ ___ @*_ 524 /LSR\********/LSR\********/LSR\ 525 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 527 ===> connected LSP *** physical link 528 ### primary SPME @@@ secondary SPME 530 Figure 3: An MPLS-TP ring 532 This protection mechanism is identical to application of 1:1 linear 533 protection[RFC6372] [RFC6378] to the pair of SPMEs. Under normal 534 conditions, all LSP data traffic will be transmitted on the working 535 SPME. If the linear protection is triggered, by either the OAM 536 indication, an other fault indication trigger, or an operator 537 command, then the MEPs will select the protection SPME to transmit 538 all LSP data packets. 540 The protection SPME will continue to transmit the data packets until 541 the stable recovery of the fault condition. Upon recovery, i.e. the 542 fault condition has cleared and the network is stabilized, the 543 ingress LSR could switch traffic back to the working SPME, if the 544 protection domain is configured for revertive behavior. 546 The control of the protection switching, especially for cases of 547 operator commands, would be covered by the protocol defined in 548 [RFC6378]. 550 2.3.2. Wrapping link protection with segment based SPME 552 It is possible to use the SPME mechanism to perform segment-based 553 protection. For each link in the ring, we define two SPME - the 554 first is a SPME between the two LSRs that are connected by the link, 555 and the second SPME between these same two LSRs but traversing the 556 entire ring (except the link that connects the LSRs). In Figure 4 we 557 show the primary SPME that connects LSR-A & LSR-F over a segment 558 connection, and the secondary SPME that connects these same LSRs by 559 traversing the ring in the opposite direction. 561 ___ ___ ___ 562 /LSR\********/LSR\********/LSR\ 563 \_B_/@@@@@@@@\_A_/########\_F_/ 564 *@ *@ 565 *@ *@ 566 *@ *@ 567 _*@ ___ _*@ 568 /LSR\********/LSR\********/LSR\ 569 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 571 *** physical link 572 ### primary SPME @@@ secondary SPME 574 Figure 4: Segment SPMEs 576 By applying OAM monitoring of these two SPME (at each LSR), it is 577 possible to affect a wrapping protection mechanism for the LSP 578 traffic that traverses the ring. The LSR on either side of the 579 segment would identify that there is a fault condition on the link 580 and redirect all LSP traffic to the secondary SPME. The traffic 581 would traverse the ring until arriving at the neighboring (relative 582 to the segment) LSR. At this point, the LSP traffic would be 583 redirected onto the original LSP, quite likely over the neighboring 584 SPME. 586 Following the progression of the label stack through this switching 587 operation (for a LSP that enters the ring at LSR B and exits the ring 588 at LSR E): 590 1. The data packet arrives at LSR-A with label stack [L1+S] (i.e. 591 top label from the LSP and bottom-of-stack indicator) 593 2. In the normal case (no protection switching), LSR-A forwards the 594 packet with label stack [PA1(F)|LSE+S] (i.e. swap the label for 595 the LSP, to be acceptable to the SPME egress, and push the label 596 for the primary SPME from LSR-A to LSR-F). 598 3. When protection switching is in-effect, LSR-A forwards the packet 599 with label stack [PA2(B)|LSE+S] (i.e. LSR-A pushed the label for 600 the secondary SPME from LSR-A to LSR-F, after swapping the label 601 of the lower level LSP). This will be transmitted along the 602 secondary SPME until LSR-E forwards it to LSR-F with label stack 603 [PE2(F)|LSE+S]. 605 4. When the packet arrives at LSR-F, it will pop the SPME label, 606 process the LSP label, and forward the packet to the next point, 607 possibly pushing a SPME label if the next segment is likewise 608 protected. 610 2.3.3. Wrapping node protection 612 Implementation of protection at the node level would be similar to 613 the mechanism described in the previous sub-section. The difference 614 would be in the SPMEs that are used. For node protection, the 615 primary SPME would be configured between the two LSR that are 616 connected to the node that is being protected (see SPME between LSR-A 617 and LSR-E through LSR-F in Figure 5), and the secondary SPME would be 618 configured between these same nodes, going around the ring (see 619 secondary SPME in Figure 5). 621 ___ ___ ___ 622 /LSR\********/LSR\********/LSR\ 623 \_B_/@@@@@@@@\_A_/########\_F_/ 624 *@ *# 625 *@ *# 626 *@ *# 627 _*@ ___ _*# 628 /LSR\********/LSR\********/LSR\ 629 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 631 *** physical link 632 ### primary SPME @@@ secondary SPME 634 Figure 5: Node-protection SPMEs 636 The protection mechanism would work similarly - based on 1:1 linear 637 protection [RFC6372], triggered by OAM functions on both SPMEs, and 638 wrapping the data packets onto the secondary SPME at the ingress MEP 639 (e.g. LSR-A in the figure) of the SPME and back onto the 640 continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) 641 of the SPME. 643 2.3.4. Wrapping for link and node protection 645 In the different types of wrapping presented in Section 2.3.2 and 646 Section 2.3.3, there is a limitation that the protection mechanism 647 must a priori decide whether it is protecting for link or node 648 failure. In addition, the neighboring LSR, that detects the fault, 649 cannot readily differentiate between a link failure or a node 650 failure. 652 It would be possible to configure extra SPME to protect both for link 653 and node failures, arriving at a configuration of the ring that is 654 shown in Figure 6. Here there are three protection SPME configured: 656 o Secondary node#1 would be used to divert traffic as a result of an 657 indication that LSR-F is not available, it redirects traffic to be 658 transmitted between LSR-A and LSR-E. 660 o Secondary node#2 would be used to divert traffic as a result of an 661 indication that LSR-A is not available, it redirects traffic to be 662 transmitted between LSR-F and LSR-B. 664 o Secondary segment would be used to divert traffic as a result of 665 an indication that the segment between LSR-A and LSR-F is not 666 available, it redirects traffic to be transmitted between LSR-A 667 and LSR-F on the long circuit of the ring. 669 Choosing the SPME to use for the wrapping would, however, then 670 involve considerable effort and could result in the protected traffic 671 not sharing the same protection path in both directions. 673 ___ ++++++++ ___ ___ 674 /LSR\********/LSR\********/LSR\ 675 \_B_/@@@@@@@@\_A_/########\_F_/ 676 $+*@ +*$ 677 $+*@ +*$ 678 $+*@ +*$ 679 $+*@ ++++++++ ___ ++++++++ +*$ 680 /LSR\********/LSR\********/LSR\ 681 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 682 $$$$$$$$ $$$$$$$$ 684 *** physical link 685 ### primary SPME @@@ secondary node#1 SPME 686 $$$ secondary node#2 SPME +++ secondary segment SPME 688 Figure 6: Segment & Node protection SPMEs 690 2.4. Analysis of P2P protection 692 Analyzing the mechanisms described in the above subsections we can 693 point to the following observations (based on a ring with N nodes, 694 assumed to be not more than 16): 696 o Number of SPME that need to be configured - for steering SPME 697 protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress 698 LSR to each other node in the ring], for wrapping based on SPME 699 either as described in Section 2.3.2 and Section 2.3.3 = O(2N) 700 [however, the operator must decide a priori on whether to protect 701 for link failures or node failures at each point] 703 o Number of OAM sessions at each node - for steering = O(2N), for 704 SPME wrapping = 3 706 o Bandwidth requirements - for SPME-based steering: single bandwidth 707 at each link, for wrapping: double bandwidth at links that are 708 between ingress and wrapping node and between second wrapping node 709 and egress. 711 o Special considerations - for SPME based steering: latency of OAM 712 detection of fault condition by ingress MEP [using Alarm-reporting 713 could optimize over using CC-V only], for SPME wrapping: at each 714 node must decide a priori whether protecting for link or node 715 failures. To protect for both node and link failures would 716 increase the complexity of deciding which protection path to use, 717 as well as, violating the co-routedness of the protected traffic. 719 Based on this analysis, using steering as described in Section 2.3.1 720 would be the recommended protection mechanism due to its simplicity. 722 It should be pointed out that the number of SPME involved in this 723 protection could be reduced by eliminating SPME between pairs of LSR 724 that are not used as an ingress and egress pair. 726 2.4.1. Recommendations for protection of P2P paths traversing a ring 728 Based on the analysis presented, while applying linear protection to 729 effect Wrapping protection to a ring topology is possible as 730 demonstrated, this does have certain limitations in addressing some 731 of the required behavior. The limitations include: 733 o Need to a-priori configure the protection for link or node 734 protection 736 o Increased number of SPME that need to be defined 738 o Difficulty in addressing cases of multiple failures in the ring 740 Application of linear protection, based on the use of SPME within the 741 ring, to implement a Steering methodology to protect a ring topology 742 is rather straight forward, overcomes the limitations listed above, 743 and scales very well. For this and other reasons listed previously, 744 the authors recommend the use of Steering to provide protection of a 745 ring topology when using the mechanisms described in this document 746 for protection of P2P paths that traverse the ring. 748 3. Point-to-multipoint protection 750 [RFC5654] requires that ring protection must provide protection for 751 unidirectional point-to-multipoint paths through the ring. Ring 752 topologies provide a ready platform for supporting such data paths. 753 A Point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be 754 characterized by a single ingress LSR and multiple egress LSRs. The 755 following sub-sections will present methods to address the protection 756 of the ring-based sections of these LSP. 758 3.1. Wrapping for P2MP LSP 760 When protecting a P2MP ring data path using the wrapping 761 architecture, the basic operation is similar to the description 762 given, as the traffic has been wrapped back onto the normal working 763 path on the far-side of the detected fault and will continue to be 764 transported to all of the egress points. 766 It is possible to optimize the performance of the wrapping mechanism 767 when applied to P2MP LSPs by exploiting the topology of ring 768 networks. 770 This improved mechanism, which we call Ring Optimized Multipoint 771 Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. 772 However, ROM-Wrapping configures protection P2MP LSP, relative to 773 each node that is considered a failure risk, from the upstream node 774 and all egress nodes (for the particular LSP) downstream from the 775 failure risk. 777 Referring to Figure 7, it is possible to identify the protected 778 (working) LSP (A-B-{C}-{D}-E-{F}) and one possible backup 779 (protection) LSP (note:the egress nodes are indicated by the curly 780 braces). This protection LSP will be used to wrap the data back 781 around the ring to protect against a failure on link B-C. This 782 protection LSP is also a P2MP LSP that is configured with egress 783 points (at nodes F, D, & C) complementary to the broken working data 784 path. 786 | 787 | 788 V Ingress 789 ___ _V_ ___ 790 /LSR\ /LSR\**************/LSR\ 791 <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/ 792 @ * * 793 @ * * 794 @ * XXXX Failure 795 @ * * 796 @_* ___ __* 797 /LSR\*************/LSR\**************/LSR\ 798 \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/ 799 @ @ 800 @ @ 801 V V 803 *** working LSP @@@ protection LSP 805 Figure 7: P2MP ROM Wrapping 807 Using this mechanism, there is a need to configure a particular 808 protection LSP for each node on the working LSP. In the table below, 809 "X's Backup" is the backup path activated by node X as a consequence 810 of a failure affecting node Y (downstream node with respect to X) or 811 link X-Y, and square brackets, in the path,indicate egress nodes. 813 Protected LSP: A->B->{C}->{D}->E->{F} 815 -- LINK/NODE PROTECTION -- 817 A's Backup: A->{F}->E->{D}->{C} 818 B's Backup: B->A->{F}->E->{D}->{C} 819 C's Backup: C->B->A->{F}->E->{D} 820 D's Backup: D->C->B->A->{F} 821 E's Backup: E->D->C->B->A->{F} 823 It should be noted that ROM-Wrapping is an LSP based protection 824 mechanism, as opposed to the SPME based protection mechanisms that 825 are presented in other sections of this draft. While this may seem 826 to be limited in scope, the mechanism may be very efficient for many 827 applications that are based on P2MP distribution schemes. While ROM- 828 Wrapping can be applied to any network topology, it is particularly 829 efficient for interconnected ring topologies. 831 3.1.1. Comparison of Wrapping and ROM-Wrapping 833 It is possible to compare the Wrapping and the ROM-Wrapping 834 mechanisms in different aspects, and show some improvements offered 835 by ROM-Wrapping. 837 When configuring the protection LSP for Wrapping it is necessary to 838 configure for a specific failure: link protection or node protection. 839 If the protection method is configured to protect node failures but 840 the actual failure affects a link, this could result in failing to 841 deliver traffic to the node, when it should be possible to. 843 ROM-Wrapping however does not have this limitation, because there is 844 no distinction between node and link protection. Whether link B-C or 845 node C fails, in either case the rerouting will attempt to reach C. 846 If the failure is on the link, the traffic will be delivered to C, 847 while if the failure is at node C, the traffic will be rerouted 848 correctly until node D, and will be blocked at this point. However, 849 all egress nodes up-to the failure will be able to deliver the 850 traffic properly. 852 A second aspect is the number of hops needed to properly deliver the 853 traffic. Referring to the example shown in Figure 7, where a failure 854 is detected on link B-C, the following table lists the set of nodes 855 traversed by the data in the protection: 857 Basic Wrapping: 859 A-B B-A-F-E-D-C {C}-{D}-E-{F} 860 "Upstream" segment backup path "Downstream" segment 861 with respect to the with respect to the 862 failure failure 864 ROM Wrapping: 866 A-B B-A-{F}-E-{D}-{C} .. 867 "Upstream" segment backup path 868 with respect to the 869 failure 871 Comparing the two lists of nodes, it is possible to see that in this 872 particular case the number of hops crossed using the simple Wrapping 873 is significantly higher than the number of hops crossed by the 874 traffic when ROM-Wrapping is used. Generally, the number of hops for 875 basic Wrapping is always higher or at least equal compared to ROM- 876 Wrapping. This implies a certain waste of bandwidth on all links 877 that are crossed in both directions. 879 Considering the ring network previously seen, it is possible to do 880 some bandwidth utilization considerations. The protected LSP is set 881 up from A to F clockwise and an M Mbps bandwidth is reserved along 882 the path. All the protection LSPs are pre-provisioned 883 counterclockwise, each of them may also have reserved bandwidth M. 884 These LSPs share the same bandwidth in a SE (Shared Explicit) 885 [RFC2205] style. 887 The bandwidth reserved counterclockwise is not used when the 888 protected LSP is properly working and could, in theory, be used for 889 extra traffic [RFC4427]. However, it should be noted that [RFC5654] 890 does not require support of such extra traffic. 892 The two recovery mechanism require different protection bandwidths. 893 In the case of Wrapping, the bandwidth used is M in both directions 894 of many of the links. While in case of ROM-Wrapping, only the links 895 from the ingress node to the node performing the actual wrapping 896 utilize M bandwidth in both directions, while all other links utilize 897 M bandwidth only in the counterclockwise direction. 899 Consider the case of a failure detected on link B-C as shown in 900 Figure 7. The following table lists the bandwidth utilization on 901 each link (in units equal to M), for each recovery mechanism and for 902 each direction (CW=clockwise, CCW=counterclockwise). 904 +----------+----------+--------------+ 905 | | Wrapping | ROM-Wrapping | 906 +----------+----------+--------------+ 907 | Link A-B | CW+CCW | CW+CCW | 908 | Link A-F | CCW | CCW | 909 | Link F-E | CW+CCW | CCW | 910 | Link E-D | CW+CCW | CCW | 911 | Link D-C | CW+CCW | CCW | 912 +----------+----------+--------------+ 914 3.1.2. Multiple Failures Comparison 916 A further comparison between Wrapping and ROM-Wrapping can be done 917 with respect to their ability to react to multiple failures. The 918 wrapping recovery mechanism does not have the ability to recover from 919 multiple failures on a ring network, while ROM-Wrapping is able to 920 recover, from some multiple failures. 922 Consider, for example, a double link failure affecting links B-C and 923 C-D shown in Figure 7. The Wrapping mechanism is not able to recover 924 from the failure because B, upon detecting the failure, has no 925 alternative paths to reach C. The whole P2MP traffic is lost. The 926 ROM-Wrapping mechanism is able to partially recover from the failure, 927 because the backup P2MP LSP to node F and node D is correctly set up 928 and continues delivering traffic. 930 3.2. Steering for P2MP paths 932 When protecting P2MP traffic that uses an MPLS-TP ring as its 933 branching point, i.e. it enters the ring at a head-end node and exits 934 the ring at multiple nodes, we can employ a steering mechanism based 935 on 1+1 linear protection [RFC6372]. We can configure two P2MP 936 unidirectional SPME from each node on the ring that traverse the ring 937 in both directions. These SPME will be configured with an egress at 938 each ring node. In order to be able to properly direct the LSP 939 traffic to the proper egress point for that particular LSP, we need 940 to employ context labeling as defined in [RFC5331]. The method for 941 using these labels is expanded upon in section 3.2.1. 943 For every LSP that enters the ring at a given node the traffic will 944 be sent through both of these SPME, each with its own context label 945 and the context-specific label for the particular LSP. The egress 946 nodes should select the traffic that is arriving on the working SPME. 947 When a failure condition is identified, the egress nodes should 948 select the traffic from whichever of the two SPME whose traffic 949 arrives at that node, i.e. since one of the two (presumably the 950 working SPME) will be blocked by the failure. In this way, all 951 egress nodes are able to receive the data traffic. While each node 952 detects that there is connectivity from the ingress point, it 953 continues to select the data that is coming from the working SPME. 954 If a particular node stops receiving the connectivity messages from 955 the working SPME, it identifies that it must select to read the data 956 packets from the protection SPME. 958 3.2.1. Context labels 960 Figure 8 shows the two unidirectional P2MP SPME that are configured 961 from LSR-A with egress points at all of the nodes on the ring. The 962 clockwise SPME (i.e. A-B-C-D-E-F) is configured as the working SPME, 963 that will aggregate all traffic for P2MP LSPs that enter the ring at 964 LSR-A and must be sent out of the ring at any subset of the ring 965 nodes. The counter-clockwise SPME (i.e. A-F-E-D-C-B) is configured 966 as the protection SPME. 968 ^ ^ ^ 969 _|_ _|_ _|_ 970 ----->/LSR\********/LSR\********/LSR\ 971 \_A_/========\_B_/========\_C_/ 972 +* <+++++++++*|| 973 +* +*|| 974 +* +*|| 975 +* +*|| 976 +*_ ++++++++ ___ +++++++++*|| 977 /LSR\********/LSR\********/LSR\ 978 \_F_/<=======\_E_/========\_D_/ 979 | | | 980 V V V 982 ---> connected LSP *** physical link 983 === working SPME +++ protection SPME 985 Figure 8: P2MP SPMEs 987 [RFC5331] defines the concept of context labels. A context- 988 identifying label defines a context label space that is used to 989 interpret the context-specific labels (found directly below the 990 context- identifying label) for a specific tunnel. The SPME label is 991 a context- identifying label. This means that at each hop the node 992 that receives the SPME label uses it to point not directly to a 993 forwarding table, but to a Label Information Base (LIB). As a node 994 receives an SPME label it examines it, discovers that it is a context 995 label, pops off the SPME label, and looks up the next label down in 996 the stack in the LIB indicated by the context label. 998 The label below this context-identifying label should be used by the 999 forwarding function of the node to decide the actions taken for this 1000 packet. In MPLS-TP protection of ring topologies there are two 1001 context LIBs. One is the context LIB for the working SPME and the 1002 other is the context LIB for the P-SPME. All context LIBs have a 1003 behavior defined for the end-to-end LSP label but the behavior at 1004 each node may be different in the context of each SPME. 1006 For example, using the ring that is shown in Figure 8, if the working 1007 SPME is configured to have a context-identifying label of CW at each 1008 node on the ring and the protection SPME is configured to have a 1009 context-identifying label of CP at each node. For the specific LSP 1010 we will designate the context-specific label used on the working SPME 1011 as WL(x-y) to be the label used as node-x to forward the packet to 1012 node-y. Similarly, for the context-specific labels on the protection 1013 SPME would be designated PL(x-y). An explicit example of label 1014 values appears in the next sub-section. 1016 Applying 1+1 linear protection, as outlined above, for a P2MP LSP 1017 that enters the ring at LSR-A and has egress points from the ring at 1018 LSR-C and LSR-E using the two SPME shown in Figure 8 then a packet 1019 that arrives at LSR-A with a label stack [LI+S] will be forwarded on 1020 the working SPME with a label stack [CW | WL(A-B)]. The packet 1021 should then be forwarded to LSR-C arriving with a label [CW | 1022 WL(B-C)], where WL(B-C) should instruct the forwarding function to 1023 egress the packet with [LE(C)] and forward a copy to LSR-D with label 1024 stack [CW | WL(C-D)]. 1026 If a fault condition is detected, for example on the link C-D, then 1027 the nodes that are beyond the fault point, in this example nodes 1028 LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from 1029 the clockwise (working) SPME. These LSR should then begin to switch 1030 their "selector bridge" and accept the data packets from the 1031 protection (counter-clockwise) SPME. At the ingress point, LSR-A, 1032 all data packets will have been transmitted on both the working SPME 1033 and the protection SPME. Continuing the example, LSR-A will transmit 1034 one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy 1035 to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C 1036 from the working SPME and egress from the ring. LSR-E will receive 1037 the packet from the protection SPME with stack [CP | PL(F-E)] and the 1038 context-sensitive label PL(F-E) will instruct the forwarding function 1039 to send a copy out of the ring with label LE(E) and a second copy to 1040 LSR-D with stack [CP | PL(E-D)]. In this way each of the egress 1041 points receives the packet from the SPME that is available at that 1042 point. 1044 This architecture has the added advantages that there is no need for 1045 the ingress node to identify the existence of the mis-connectivity, 1046 and there is no need for a return path from the egress points to the 1047 ingress. 1049 3.2.2. Walkthrough using context labels 1051 In order to better demonstrate the use of the context labels we 1052 present a walkthrough of an example application of the P2MP 1053 protection presented in this section. Referring to Figure 9, there 1054 is a P2MP LSP that traverses the ring, entering the ring at LSR-B and 1055 branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond 1056 LSR-H. For purposes of protection two P2MP unidirectional SPME are 1057 configured on the ring starting from LSR-B. One of the SPME, the 1058 working SPME, is configured with egress points at each of the LSR - 1059 C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is 1060 configured with egress points at each of the LSR - A, K, J, H, G, F, 1061 E, D, C. 1063 ^ ^ ^ ^ 1064 ^ ^ ^ ^ 1065 ___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_ 1066 xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ 1067 \_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/ 1068 *+ <+++++++++ +++++++ ++++++++*||x 1069 *+ +*||x 1070 *+ +*||x 1071 *+ +*||x 1072 _*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x 1073 /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ 1074 \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/ 1075 + + + +Xxxxxxxxxx + 1076 v v v v v 1077 v v v v v 1079 xxx P2MP LSP (X LSP egress) *** physical link 1080 === working SPME +++ protection SPME 1081 +>> protection SPME egress 1083 Figure 9: P2MP SPMEs 1085 For this example we suppose that the LSP traffic enters the ring at 1086 LSR-B with the label stack [99], leaves the ring at LSR-D with stack 1087 [199], at LSR-E with stack [299], and LSR-H with stack [399]. 1089 While it is possible for the context-identifying label for the SPME 1090 be configured as a different value at each LSR, for the sake of this 1091 example we will suppose a configuration of 200 as the context- 1092 identifying label for the working SPME at each of the LSR in the 1093 ring, and 400 as the context-identifying label for the protection 1094 SPME at each LSR. 1096 For the specific connected LSP we configure the following context- 1097 specific labels for each context: 1099 +------+-----------------------------+------------------------------+ 1100 | node | W-context(200) | P-context(400) | 1101 +------+-----------------------------+------------------------------+ 1102 | A | 65 {drop packet} | 165 {fwrd w/[400|190]} | 1103 | C | 90 {fwrd w/[200|80]} | 190 {drop packet} | 1104 | D | 80 {fwrd w/[200|75] + | 180 {egress w/[199]} | 1105 | | egress w/[199]} | | 1106 | E | 75 {fwrd w/[200|65] + | 175 {fwrd w/[400|180] + | 1107 | | egress w/[299]} | egress w/[299]} | 1108 | F | 65 {fwrd w/[200|55]} | 165 {fwrd w/[400|175]} | 1109 | G | 55 {fwrd w/[200|45]} | 155 {fwrd w/[400|165]} | 1110 | H | 45 {egress w/[399]} | 145 {fwrd w/[400|155] + | 1111 | | | egress w/[399]} | 1112 | J | 65 {drop packet} | 165 {fwrd w/[400|145]} | 1113 | K | 65 {drop packet} | 190 {fwrd w/[400|165]} | 1114 +------+-----------------------------+------------------------------+ 1116 When a packet arrives on the LSP to LSR-B with stack [99], the 1117 forwarding function determines that it is necessary to forward the 1118 packet to both the working SPME with stack [200|90] and the 1119 protection SPME with stack [400|165]. Each LSR on the SPME will 1120 identify the top label, i.e. 200 or 400, to be the context- 1121 identifying label and use the next label in the stack to select the 1122 forwarding action from the specific context table. 1124 Therefore, at LSR-C the packet on the working SPME will arrive with 1125 stack [200|90] and the 200 will point to the table in the middle 1126 column above. After popping the 200 the next label, i.e. 90, will 1127 select the forwarding action "fwrd w/[200|80]" and the packet will be 1128 forwarded to LSR-D with stack [200|80]. In this manner, the packet 1129 will be forwarded along both SPME according to the configured 1130 behavior in the context tables. However, the egress points at LSR D, 1131 E, & H, will all be configured with a selector bridge to only use the 1132 input from the working SPME. If any of these egress points identify 1133 that there is a connection fault on the working SPME, then the 1134 selector bridge will cause the LSR to read the input from the 1135 protection SPME. 1137 4. Coordination protocol 1139 The Survivability Framework [RFC6372] indicates that there is a need 1140 to coordinate protection switching between the end-points of a 1141 protected bidirectional domain. The coordination is necessary for 1142 particular cases, in order to maintain the co-routed nature of the 1143 bidirectional transport path. The particular cases where this 1144 becomes necessary include cases of unidirectional fault detection and 1145 use of operator commands. 1147 By using the same mechanisms defined in [RFC6378], for linear 1148 protection, to apply for protection of a single ring topology we are 1149 able to gain a consistent solution for this coordination between the 1150 end-points of the protection domain. The Protection State 1151 Coordination Protocol that is specified in [RFC6378] provides 1152 coverage for all the coordination cases, including support for 1153 operator commands, e.g. Forced-Switch. 1155 5. Conclusions and Recommendations 1157 Ring topologies are prevalent in traditional transport networks and 1158 will continue to be used for various reasons. Protection for 1159 transport paths that traverse a ring within an MPLS network can be 1160 provided by applying an appropriate instance of linear protection, as 1161 defined in [RFC6372]. This document has shown that for each of the 1162 traditional ring protection architectures there is an application of 1163 linear protection that provides efficient coverage, based on the use 1164 of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and 1165 [RFC6371]. For example, 1167 o P2P Steering - Configuration of two SPME, from ring ingress to 1168 ring egress, and 1:1 linear protection 1170 o P2P Wrapping for link protection - Configuration of two SPME, one 1171 for the protected link and the second using the long route between 1172 the two neighboring nodes, and 1:1 linear protection. 1174 o P2P Wrapping for node protection - Configuration of two SPME, one 1175 between the two neighbors of the protected node and the second 1176 between these two nodes on the long route, and 1:1 linear 1177 protection. 1179 o P2MP Wrapping - it is possible to optimize the performance of the 1180 wrapping by configuring the proper protection path to egress the 1181 data at the proper branching nodes. 1183 o P2MP Steering - by combining 1+1 linear protection and 1184 configuration of the SPME based on context-sensitive labeling of 1185 the protection path. 1187 It has been shown that this set of protection architecture and 1188 mechanisms are optimized based on the criteria defined in [RFC5654] 1189 for justification of designing a specific protection mechanism for a 1190 ring topology. 1192 Protection of traffic over a ring topology based on the Steering 1193 architecture using basic 1:1 linear protection is a very efficient 1194 implementation for sections of a P2P transport path that traverses a 1195 ring. Steering should be the preferred mechanism for P2P protection 1196 in a ring topology since it reduces the extra bandwidth required when 1197 traffic doubles through wrapped protection, and the ability to 1198 protect both against link and node failures without complicating the 1199 fault detection or the need to configure multiple protection paths. 1200 While this is true, the possiblity remains to support either 1201 mechanism while depending upon the OAM functionality [outlined in 1202 [RFC6371] and specified in various documents] and the coordination 1203 protocol specified for linear protection in [RFC6378]. 1205 6. IANA Considerations 1207 This document makes no request of IANA. 1209 Note to RFC Editor: this section may be removed on publication as an 1210 RFC. 1212 7. Security Considerations 1214 This document does not add any security risks to the network. Any 1215 security considerations are defined in [RFC6378] and their 1216 applicability to the information contained in this document follow 1217 naturally from the applicability of the mechanism defined in that 1218 document. 1220 8. Acknowledgements 1222 The authors would like to acknowledge the strong contributions from 1223 all the people commenting on this draft and making suggestions for 1224 improvements. 1226 9. References 1228 9.1. Normative References 1230 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1231 A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378, 1232 October 2011. 1234 9.2. Informative References 1236 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1237 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1238 May 2005. 1240 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1241 Label Assignment and Context-Specific Label Space", 1242 RFC 5331, Aug 2008. 1244 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1245 and S. Ueno, "Requirements for the Transport Profile of 1246 MPLS", RFC 5654, Sept 2009. 1248 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1249 Berger, "MPLS-TP Framework", RFC 5921, July 2010. 1251 [RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371, 1252 Sept 2011. 1254 [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability 1255 Framework", RFC 6372, Sept 2011. 1257 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 1258 Jamin, "Resource ReSerVation Protocol (RSVP) - Functional 1259 Specifications", RFC 2205, September 1997. 1261 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1262 Restoration) Terminology for GMPLS", RFC 4427, March 2006. 1264 [G.841] ITU, "Types and characteristics of SDH network protection 1265 architectures", ITU-T G.841, October 1998. 1267 Authors' Addresses 1269 Yaacov Weingarten 1270 34 Hagefen St. 1271 Karnei Shomron, 4485500 1272 Israel 1274 Phone: 1275 Email: wyaacov@gmail.com 1276 Stewart Bryant 1277 Cisco 1278 United Kingdom 1280 Email: stbryant@cisco.com 1282 Danielle Ceccarelli 1283 Ericsson 1284 Via A. Negrone 1/A 1285 Genova, Sestri Ponente 1286 Italy 1288 Email: daniele.ceccarelli@ericsson.com 1290 Diego Caviglia 1291 Ericsson 1292 Via A. Negrone 1/A 1293 Genova, Sestri Ponente 1294 Italy 1296 Email: diego.caviglia@ericsson.com 1298 Francesco Fondelli 1299 Ericsson 1300 Via A. Negrone 1/A 1301 Genova, Sestri Ponente 1302 Italy 1304 Email: francesco.fondelli@ericsson.com 1306 Marco Corsi 1307 Altran 1308 Via A. Negrone 1/A 1309 Genova, Sestri Ponente 1310 Italy 1312 Email: corsi.marco@gmail.com 1313 Bo Wu 1314 ZTE Corporation 1315 4F,RD Building 2,Zijinghua Road 1316 Nanjing, Yuhuatai District 1317 P.R.China 1319 Email: wu.bo@zte.com.cn 1321 Xuehui Dai 1322 ZTE Corporation 1323 4F,RD Building 2,Zijinghua Road 1324 Nanjing, Yuhuatai District 1325 P.R.China 1327 Email: dai.xuehui@zte.com.cn