idnits 2.17.1 draft-weingarten-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 757 has weird spacing: '...segment bac...' == Line 764 has weird spacing: '...segment back...' -- The document date (September 1, 2011) is 4619 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 234, but not defined == Missing Reference: 'L1' is mentioned on line 449, but not defined -- Looks like a reference, but probably isn't: '99' on line 1005 -- Looks like a reference, but probably isn't: '199' on line 976 -- Looks like a reference, but probably isn't: '299' on line 976 -- Looks like a reference, but probably isn't: '399' on line 976 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-linear-protection-02 Summary: 0 errors (**), 0 flaws (~~), 7 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 Nokia Siemens Networks 4 Intended status: Informational S. Bryant 5 Expires: March 4, 2012 Cisco 6 N. Sprecher 7 Nokia Siemens Networks 8 D. Ceccarelli 9 D. Caviglia 10 F. Fondelli 11 Ericsson 12 M. Corsi 13 Altran 14 B. Wu 15 X. Dai 16 ZTE Corporation 17 September 1, 2011 19 Applicability of MPLS-TP Linear Protection for Ring Topologies 20 draft-weingarten-mpls-tp-ring-protection-06.txt 22 Abstract 24 This document presents an applicability statement to address the 25 requirements for protection of ring topologies for Multi-Protocol 26 Label Switching Transport Profile (MPLS-TP) Label Switched Paths 27 (LSP) on multiple layers. The MPLS-TP Requirements document 28 specifies specific criteria for justification of dedicated protection 29 mechanism for particular topologies, including optimizing the number 30 of OAM entities needed, minimizing the number of labels for 31 protection paths, minimizing the number of recovery elements in the 32 network, and minimizing the number of control and management 33 transactions necessary. The document proposes a methodology for ring 34 protection based on existing MPLS-TP survivability mechanisms, 35 specifically those defined in MPLS-TP Linear Protection, without the 36 need for specification of new constructs or protocols. 38 This document is a product of a joint Internet Engineering Task Force 39 (IETF) / International Telecommunications Union Telecommunications 40 Standardization Sector (ITU-T) effort to include an MPLS Transport 41 Profile within the IETF MPLS and PWE3 architectures to support the 42 capabilities and functionalities of a packet transport network as 43 defined by the ITU-T. 45 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on March 4, 2012. 62 Copyright Notice 64 Copyright (c) 2011 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 81 1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5 82 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 83 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 84 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 2.3. P2P ring protection using SPME . . . . . . . . . . . . . . 10 87 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 88 2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12 89 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13 90 2.3.4. Wrapping for link and node protection . . . . . . . . 14 91 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15 92 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15 93 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15 94 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17 95 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19 96 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19 97 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20 98 3.2.2. Walkthrough using context labels . . . . . . . . . . . 21 99 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23 100 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 104 9. Informative References . . . . . . . . . . . . . . . . . . . . 25 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 107 1. Introduction 109 Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being 110 standardized as part of a joint effort between the Internet 111 Engineering Task Force (IETF) and the International Telecommunication 112 Union Standardization (ITU-T). These specifications are based on the 113 requirements that were generated from this joint effort. 115 The requirements for MPLS-TP [TPReqs] indicates a requirement to 116 support a network that may include sub-networks that constitute a 117 MPLS-TP ring as defined in the requirements. The requirements 118 document does not identify any protection requirements specific to a 119 ring topology. However, the requirements state that specific 120 protection mechanisms aimed at ring topologies may be developed if 121 these allow the network to optimize: 123 o Number of OAM entities needed to trigger the protection 125 o Number of elements of recovery needed 127 o Number of labels required 129 o Number of control and management plane transactions during a 130 recovery operation 132 o Impact of signaling and routing information exchanged, in presence 133 of control plane 135 This document will propose a set of basic mechanisms that could be 136 used for the protection of the data flows that traverse a MPLS-TP 137 ring. The mechanism is based on existing MPLS and MPLS-TP protection 138 mechanisms. We show that this mechanism provides the ability to 139 protect all of the basic conditions within a reasonable time frame 140 and does optimize the criteria set out in [TPReqs] as summarized 141 above. 143 A related topic in [TPReqs] addresses the required support for 144 interconnected rings. This topic involves various scenarios that 145 require further study and will be addressed in a separate document, 146 based on the principles outlined in this document. 148 1.1. Problem statement 150 Ring topologies, as defined in [TPReqs], are used in transport 151 networks due to their ability to easily support both p2p and p2mp 152 transport paths. When designing a protection mechanism for a ring 153 topology, there is a need to address both - 154 1. A point-to-point transport path that enters a MPLS-TP capable 155 ring at one node, the ingress node, and exits the ring at a 156 single egress node possibly continuing beyond the ring. 158 2. Where the ring is being used as a branching point for a point-to- 159 multipoint transport path, i.e. the transport path enters the 160 MPLS-TP capable ring at the ingress node and exits through a 161 number of egress nodes, possibly continuing beyond the ring. 163 In either of these two situations, there is a need to address the 164 following different cases - 166 1. One of the ring links causes a fault condition. This could be 167 either a unidirectional or bidirectional fault, and should be 168 detected by the neighboring nodes. 170 2. One of the ring nodes causes a fault condition. This condition 171 is invariably a bidirectional fault (although in rare cases of 172 misconfiguration this could be detected as a unidirectional 173 fault) and should be detected by the two neighboring ring nodes. 175 3. An operator command is issued to a specific ring node. A 176 description of the different operator commands is found in 177 Section 4.12 of [RFC4427]. Examples of these commands include 178 Manual Switch, Forced Switch, or Clear operations. 180 The protection domain addressed in this document is limited to the 181 traffic that is traversing the ring. Traffic on the transport path 182 prior to the ring ingress node or beyond the egress nodes may be 183 protected by some other mechanism. 185 1.2. Terminology and Notation 187 The terminology used in this document is based on the terminology 188 defined in the MPLS-TP framework documents: 190 o MPLS-TP Framework[TPFwk] 192 o MPLS-TP OAM Framework[OAMFwk] 194 o MPLS-TP Survivability Framework[SurvivFwk] 196 The MPLS-TP Framework document [TPFwk] defines a Sub-Path Maintenance 197 Entity (SPME) construct that can be defined between any two LSRs of a 198 MPLS-TP LSP. This SPME may be configured as a co-routed 199 bidirectional path. The SPME is defined to allow management and 200 monitoring of any segment of a transport path. This concept will be 201 used extensively throughout the document to support protection of the 202 traffic that traverses a MPLS-TP ring. 204 In addition, we describe the use of the label stack in connection 205 with the redirecting of data packets by the protection mechanism. 206 The following syntax will be used to describe the contents of the 207 label stack: 209 1. The label stack will be enclosed in square brackets ("[]") 211 2. Each level in the stack will be separated by the '|' character. 212 It should be noted that the label stack may contain additional 213 levels however, we only present the levels that are germane to 214 the protection mechanism. 216 3. When applicable, the S-bit (signifying that a given label is the 217 bottom of the label stack) will be denoted by the string '+S' 218 within the label. If a label is not shown with '+S' that label 219 may or may not be the bottom label in the stack. '+S' is only 220 shown when it is important to illustrate that a given label is 221 definitely the last one in the label stack. 223 4. The label of the LSP at the ingress point to the ring will be 224 denoted by the string "LI" and the label of the LSP that is 225 expected at the egress point from the ring will be denoted by the 226 string "LE" 228 5. The label for a SPME will be denoted by Px(y) where x and y are 229 LSR identifiers and the intention is to the label for LSR-x to 230 transmit to LSR-y over the SPME. 232 For example - 234 o the label stack [LI] denotes the label stack received at the 235 ingress node of the ring. This may have additional labels after 236 LI, e.g. a PW label however, this is irrelevant to the discussion 237 of the protection scenario. 239 o [PB(G)|LE] denotes a stack whose top-label is the SPME label for 240 LSR-B to transmit the data packet to LSR-G, the second label is 241 the label that would be used by the egress LSR to continue the 242 packet on the original LSP. 244 o If "LE" were the bottom label in the stack, then the label stack 245 would be shown as [PB(G)|LE+S]. 247 1.3. Contributing Authors 249 Akira Sakurai (NEC), Rolf Winter (NEC) 251 2. P2P Ring Protection 253 Classically there are two protection architecture mechanisms for ring 254 topologies, based on SDH specifications [G.841], that have been 255 proposed in various forums to perform recovery of a topological ring 256 network - "wrapping" and "steering". The following sub-sections will 257 examine these two mechanisms. 259 2.1. Wrapping 261 Wrapping is defined as a local protection architecture. This 262 mechanism is local to the LSRs that are neighbors to the detected 263 fault. When a fault is detected (either a link or node failure), the 264 neighboring LSR can identify that the fault would prevent forwarding 265 of the data along the data path. Therefore, in order to continue the 266 data along the path, there is need to "wrap" all data traffic around 267 the ring, on an alternate data path, until arriving at the LSR that 268 is on the opposite side of the fault. When this LSR also detects 269 that there is a fault condition on the LSP, it can identify that the 270 data traffic that is arriving on the alternate (protecting) data path 271 is intended for the "broken" LSP. Therefore, again taking a local 272 decision, can wrap the data back onto the normal working path until 273 the egress from the ring segment. Wrapping behavior is similar to 274 MPLS-TE FRR as defined in [RFC4090] using either bypass or detour 275 tunnels. It would be possible to wrap each LSP arounf the failed 276 links via a detour tunnel using a different label for each LSP or to 277 wrap all the LSPs using a bypass tunnel and a single label. 279 ___ ######## ___ ######## ___ 280 ======>/LSR\********/LSR\***XX***/LSR\ 281 \_B_/@@@@@@@@\_A_/ \_F_/ 282 *@ #* 283 *@ #* 284 *@ #* 285 _*@ ___ #*_ 286 /LSR\********/LSR\********/LSR\======> 287 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 289 ===> connected LSP *** physical link 290 ### working path @@@ wrapped data path 292 Figure 1: Wrapping protection for p2p path 294 In this figure we have a ring with a LSP that enters the ring at 295 LSR-B and exits at LSR-E. The normal working path follows through 296 B-A-F-E. If a fault is detected on the link A<-->F, then the 297 wrapping mechanism decides that LSR-A would wrap the traffic around 298 the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on 299 the far side of the failed link). LSR-F would then wrap the data 300 packets back onto the working path F-->E to the egress node. In this 301 protection scheme, the traffic will follow the path - 302 B-A-B-C-D-E-F-E. 304 This protection scheme is simple in the sense that there is no need 305 for coordination between the different LSR in the ring - only the 306 LSRs that detect the fault must wrap the traffic, either onto the 307 wrapped data path (at the near-end) or back to the working path (at 308 the far-end). Coordination would only be needed to maintain co- 309 routed bidirectional traffic even in cases of a unidirectional fault 310 condition. 312 The following considerations should be taken into account when 313 considering use of wrapping protection: 315 o Detection of loss-of-continuity or mis-connectivity, should be 316 performed at the link level and/or per LSR when using node-level 317 protection. Configuration of the protection being performed (i.e. 318 link protection or node protection) needs to be performed 319 a-priori, since the configuration of the proper protection path is 320 dependent upon this decision. 322 o There is a need to define a data-path that traverses the alternate 323 path around the ring to connect between the two neighbors of the 324 detected fault. If protecting both the links and the nodes of a 325 LSP, then, for a ring with N nodes, there is a need for O(2N) 326 alternate paths. 328 o When wrapping, the data is transmitted over some of the links 329 twice, once in each direction. For example, in the figure above 330 the traffic is transmitted both B-->A and then A-->B, later it is 331 transmitted E-->F and F-->E. This means that there is additional 332 bandwidth needed for this protection. 334 o If a double-fault situation occurs in the ring, then wrapping will 335 not be able to deliver any packets except between the ingress and 336 the first fault location. This is based on the need for wrapping 337 to connect between the neighbors of the fault location, and this 338 is not possible in the segmented ring. 340 o The resource allocation for the alternate-paths could be 341 problematic, since most of these alternate paths will not be used 342 simultaneously. One possibility could be to allocate '0' 343 resources and depend on the NMS to allocate the proper resources 344 around the ring. 346 o Wrapping also involves greater latency in delivering the packets, 347 as a result of traversing the entire ring. This could be very 348 restrictive for large rings. 350 2.2. Steering 352 The second common scheme for ring protection, steering, takes 353 advantage of the ring topology by defining two paths from the ingress 354 point (to the ring) to the egress point going in opposite directions 355 around the ring. This is illustrated in Figure 2, where if we assume 356 that the traffic needs to enter the ring from node B and exit through 357 node F, we could define a primary path through nodes B-A-F, and an 358 alternate path through the nodes B-C-D-E-F. In steering the 359 switching is always performed by the ingress node (node B in 360 Figure 2). If a fault condition is detected anywhere on the working 361 path (B-A-F), then the traffic would be redirected by B to the 362 alternate path (i.e. B-C-D-E-F). 364 This mechanism bears similarities to linear 1:1 protection 365 [SurvivFwk]. The two paths around the ring act as the working and 366 protection paths. There is need to communicate to the ingress node 367 the need to switch over to the protection path and there is a need to 368 coordinate the switchover between the two end-points of the protected 369 domain. 371 The following considerations must be taken into account regarding the 372 steering architecture: 374 o Steering relies on a failure detection method that is able to 375 notify the ingress node of the fault condition. This may involve 376 different OAM functionality described in [OAMFwk], e.g. Remote 377 Defect Indication, Alarm reporting. 379 o The process of notifying the ingress node adds to the latency of 380 the protection switching process, after the detection of the fault 381 condition. 383 o While there is no need for double bandwidth for the data path, 384 there is the necessity for the ring to maintain enough capacity 385 for all of the data in both directions around the ring. 387 2.3. P2P ring protection using SPME 389 The SPME concept was introduced by [TPFwk] to support management and 390 monitoring an arbitrary segment of a transport. However, an SPME is 391 essentially a valid LSP that may be used to aggregate all LSP traffic 392 that traverses the sub-path delineated by the SPME. An SPME may be 393 monitored using the OAM mechanisms as described in the MPLS-TP OAM 394 Framework document [OAMFwk]. 396 When defining a MPLS-TP ring as a protection domain, there is a need 397 to design a protection mechanism that protects all the LSPs that 398 cross the MPLS-TP ring. For this purpose, we associate a (working) 399 SPME with the segment of the transport path that traverses the ring. 400 In addition, we configure an alternate (protecting) SPME that 401 traverses the ring in the opposite direction around the ring. The 402 exact selection of the SPMEs is dependent on the type of transport 403 path and protection that is being implemented and will be detailed in 404 the following sub-sections. 406 Based on this architectural configuration for ring protection, it is 407 possible to limit the number of alternate paths needed to protect the 408 data traversing the ring. In addition, since we will perform all of 409 the OAM functionality on the SPME configured for the traffic, we can 410 minimize the number of OAM sessions needed to monitor the data 411 traffic of the ring - rather than monitoring each individual LSP. 413 The following figure shows a MPLS-TP ring that is part of a larger 414 MPLS-TP network. The ring could be used as a network segment that 415 may be traversed by numerous LSPs. In particular, the figure shows 416 that for all LSPs that connect to the ring at LSR-B and exit the ring 417 from LSR-F, we configure two SPME through the ring (the first SPME 418 traverses along B-A-F, and the second SPME traverses B-C-D-E-F). 420 ___ ___ ___ 421 ======>/LSR\********/LSR\********/LSR\======> 422 \_B_/########\_A_/########\_F_/ 423 *@ @* 424 *@ @* 425 *@ @* 426 _*@ ___ @*_ 427 /LSR\********/LSR\********/LSR\ 428 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 430 ===> connected LSP *** physical link 431 ### primary SPME @@@ secondary SPME 433 Figure 2: A MPLS-TP ring 435 In all of the following subsections, we use 1:1 linear protection 436 [SurvivFwk] [LinProtect] to perform protection switching and 437 coordination when a signal fault is detected. The actual 438 configuration of the SPMEs used may change dependent upon the choice 439 of methodology and this will be detailed in the following sections. 440 However, in all of these configurations the mechanism will be to 441 transmit the data traffic on the primary SPME, while applying OAM 442 functionality over both the primary and the secondary SPME to detect 443 signal fault conditions on either path. If a signal fault is 444 detected on the primary SPME, then the mechanism described in 445 [LinProtect] shall be used to coordinate a switch-over of data 446 traffic to the secondary SPME. 448 Assuming that the SPME is implemented as an hierarchical LSP, packets 449 that arrive at LSR-B with a label stack [L1] will have the SPME label 450 pushed at LSR-B (i.e. the packet will arrive at LSR-A with a label 451 stack of [PA(F)|L1], arrive at LSR-F with [PF(F)|L1]). The SPME 452 label will be popped by LSR-F and the LSP label will be treated 453 appropriately at LSR-F and forwarded along the LSP. This scenario is 454 true for all LSP that are aggregated by this primary SPME. 456 2.3.1. Path SPME for Steering 458 A p2p SPME that traverses part of a ring has two Maintenance Entity 459 Group End Points (MEPs), each one acts as the ingress and egress in 460 one direction of the bidirectional SPME. Since the SPME is 461 traversing a ring we can take advantage of another characteristic of 462 a ring - there is always an alternative path between the two MEPs, 463 i.e. traversing the ring in the opposite direction. This alternative 464 SPME can be defined as the protection path for the working path that 465 is configured as part of the LSP and defined as a SPME. 467 For each pair of SPMEs that are defined in this way, it is possible 468 to verify the connectivity and continuity by applying the MPLS-TP OAM 469 functionality to both the working and protection SPME. If a 470 discontinuity or mis-connectivity is detected then the MEPs will 471 become aware of this condition, and could perform a protection switch 472 of all LSPs to the alternate, protection SPME. 474 This protection mechanism is identical to application of 1:1 linear 475 protection[SurvivFwk] [LinProtect] to the pair of SPMEs. Under 476 normal conditions, all LSP data traffic will be transmitted on the 477 working SPME. If the linear protection is triggered, by either the 478 OAM indication, an other fault indication trigger, or an operator 479 command, then the MEPs will select the protection SPME to transmit 480 all LSP data packets. 482 The protection SPME will continue to transmit the data packets until 483 the stable recovery of the fault condition. Upon recovery, the 484 ingress LSR could switch traffic back to the working SPME, if the 485 protection domain is configured for revertive behavior. 487 The control of the protection switching, especially for cases of 488 operator commands, would be covered by the protocol defined in 489 [LinProtect]. 491 2.3.2. Wrapping with segment based SPME 493 It is possible to use the SPME mechanism to perform segment-based 494 protection. For each link in the ring, we define two SPME - the 495 first is a SPME between the two LSRs that are connected by the link, 496 and the second SPME between these same two LSRs but traversing the 497 entire ring (except the link that connects the LSRs). In Figure 3 we 498 show the primary SPME that connects LSR-A & LSR-F over a segment 499 connection, and the secondary SPME that connects these same LSRs by 500 traversing the ring in the opposite direction. 502 ___ ___ ___ 503 /LSR\********/LSR\********/LSR\ 504 \_B_/@@@@@@@@\_A_/########\_F_/ 505 *@ *@ 506 *@ *@ 507 *@ *@ 508 _*@ ___ _*@ 509 /LSR\********/LSR\********/LSR\ 510 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 512 *** physical link 513 ### primary SPME @@@ secondary SPME 515 Figure 3: Segment SPMEs 517 By applying OAM monitoring of these two SPME (at each LSR), it is 518 possible to affect a wrapping protection mechanism for the LSP 519 traffic that traverses the ring. The LSR on either side of the 520 segment would identify that there is a fault condition on the link 521 and redirect all LSP traffic to the secondary SPME. The traffic 522 would traverse the ring until arriving at the neighboring (relative 523 to the segment) LSR. At this point, the LSP traffic would be 524 redirected onto the original LSP, quite likely over the neighboring 525 SPME. 527 Following the progression of the label stack through this switching 528 operation: 530 1. The data packet arrives at LSR-A with label stack [LI+S] (i.e. 531 top label from the LSP and bottom-of-stack indicator) 533 2. In the normal case (no switching), LSR-A forwards the packet with 534 label stack [PA1(F)|LE+S] (i.e. swap the label for the LSP, to be 535 acceptable to the SPME egress, and push the label for the primary 536 SPME from LSR-A to LSR-F). 538 3. When switching is in-effect, LSR-A forwards the packet with label 539 stack [PA2(F)|LE+S] (i.e. LSR-A pushed the label for the 540 secondary SPME from LSR-A to LSR-F, after swapping the label of 541 the lower level LSP). 543 4. When the packet arrives at LSR-F, it will pop the SPME label, 544 process the LSP label, and forward the packet to the next point, 545 possibly pushing a SPME label if the next segment is likewise 546 protected. 548 2.3.3. Wrapping node protection 550 Implementation of protection at the node level would be similar to 551 the mechanism described in the previous sub-section. The difference 552 would be in the SPMEs that are used. For node protection, the 553 primary SPME would be configured between the two LSR that are 554 connected to the node that is being protected (see SPME between LSR-A 555 and LSR-E through LSR-F in Figure 4), and the secondary SPME would be 556 configured between these same nodes, going around the ring (see 557 secondary SPME in Figure 4). 559 ___ ___ ___ 560 /LSR\********/LSR\********/LSR\ 561 \_B_/@@@@@@@@\_A_/########\_F_/ 562 *@ *# 563 *@ *# 564 *@ *# 565 _*@ ___ _*# 566 /LSR\********/LSR\********/LSR\ 567 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 569 *** physical link 570 ### primary SPME @@@ secondary SPME 572 Figure 4: Node-protection SPMEs 574 The protection mechanism would work similarly - based on 1:1 linear 575 protection [SurvivFwk], triggered by OAM functions on both SPMEs, and 576 wrapping the data packets onto the secondary SPME at the ingress MEP 577 (e.g. LSR-A in the figure) of the SPME and back onto the 578 continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) 579 of the SPME. 581 2.3.4. Wrapping for link and node protection 583 In the different types of wrapping presented in sections 2.3.2 and 584 2.3.3, there is a limitation that the protection mechanism must a 585 priori decide whether it is protecting for link or node failure. In 586 addition, the neighboring LSR, that detects the fault, cannot readily 587 differentiate between a link failure or a node failure. 589 It is possible to combine the link protection mechanism presented in 590 section 2.3.2 with the protection mechanism of section 2.3.3 to give 591 more complete coverage. For each segment, we configure both a 592 secondary link protection SPME as well as two secondary node 593 protection SPME, i.e. one for each direction of the bidirectional 594 segment SPME (see Figure 5). When a protection switch is triggered, 595 the ingress LSR of the segment will examine the packet ring 596 destination. Only if this destination is for the LSR connected to 597 the "secondary link" SPME, then the packets will be wrapped onto this 598 secondary SPME. For all other cases, the data packets will be 599 wrapped onto the "secondary node" SPME. In all cases the egress LSR 600 for the secondary SPME will wrap the data traffic back onto the 601 working LSP/SPME. 603 ___ ++++++++ ___ ___ 604 /LSR\********/LSR\********/LSR\ 605 \_B_/@@@@@@@@\_A_/########\_F_/ 606 $+*@ +*$ 607 $+*@ +*$ 608 $+*@ +*$ 609 $+*@ ++++++++ ___ ++++++++ +*$ 610 /LSR\********/LSR\********/LSR\ 611 \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ 612 $$$$$$$$ $$$$$$$$ 614 *** physical link 615 ### primary SPME @@@ secondary node#1 SPME 616 $$$ secondary node#2 SPME +++ secondary segment SPME 618 Figure 5: Segment & Node protection SPMEs 620 2.4. Analysis of p2p protection 622 Analyzing the mechanisms described in the above subsections we can 623 point to the following observations (based on a ring with N nodes): 625 o Number of SPME that need to be configured - for path SPME (sec 626 2.3.1) = O(2N^2) [two SPME from each ingress LSR to each other 627 node in the ring], for segment SPME (sec 2.3.4) = O(4N) [four SPME 628 for each link in the ring] 630 o Number of OAM sessions at each node - for path SPME = O(2N), for 631 segment SPME = 4 633 o Bandwidth requirements - for path SPME: single bandwidth at each 634 link, for segment SPME: double bandwidth at links that are between 635 ingress and wrapping node and between second wrapping node and 636 egress. 638 o Special considerations - for path SPME: latency of OAM detection 639 of fault condition by ingress MEP [using Alarm-reporting could 640 optimize over using CC-V only], for segment SPME: need to examine 641 data packet ring destination before selecting bypass SPME. 643 3. P2MP protection 645 [TPReqs] requires that ring protection must provide protection for 646 unidirectional point-to-multipoint paths through the ring. Ring 647 topologies provide a ready platform for supporting such data paths. 648 A p2mp LSP in an MPLS-TP ring would be characterized by a single 649 ingress LSR and multiple egress LSRs. The following sub-sections 650 will present methods to address the protection of the ring-based 651 sections of these LSP. 653 3.1. Wrapping for p2mp LSP 655 When protecting a p2mp ring data path using the wrapping 656 architecture, the basic operation is similar to the description 657 given, as the traffic has been wrapped back onto the normal working 658 path on the far-side of the detected fault and will continue to be 659 transported to all of the egress points. 661 It is possible to optimize the performance of the wrapping mechanism 662 when applied to p2mp LSPs by exploiting the topology of ring 663 networks. 665 This improved mechanism, which we call Ring Optimized Multicast 666 Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. 668 There is one difference - rather than configuring the protection LSP 669 between the end nodes of a failed link (link protection) or between 670 the upstream and downstream node of a failed node (node protection), 671 the improved mechanism configures a protection p2mp LSP from the 672 upstream (with respect to the failure) node and all egress nodes (for 673 the particular LSP) downstream from the failure. 675 Referring to Figure 6, it is possible to identify the protected 676 (working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup 677 (protection) LSP. This protection LSP will be used to wrap the data 678 back around the ring to protect against a failure on link B-C. This 679 protection LSP is also a p2mp LSP that is configured with egress 680 points (at nodes F, D, & C) complimentary to the broken working data 681 path. 683 | 684 | 685 V Ingress 686 ___ _V_ ___ 687 /LSR\ /LSR\**************/LSR\ 688 <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/ 689 @ * * 690 @ * * 691 @ * XXXX Failure 692 @ * * 693 @_* ___ __* 694 /LSR\*************/LSR\**************/LSR\ 695 \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/ 696 @ @ 697 @ @ 698 V V 700 *** working LSP @@@ protection LSP 702 Figure 6: P2MP ROM Wrapping 704 Using this mechanism, there is a need to configure a particular 705 protection LSP for each node on the working LSP. In the table below, 706 "X's Backup" is the backup path activated by node X as a consequence 707 of a failure affecting node Y (downstream node with respect to X) or 708 link X-Y, and square brackets, in the path,indicate egress nodes. 710 Protected LSP: A->B->[C]->[D]->E->[F] 712 ---- LINK/NODE PROTECTION---- 714 A's Backup: A->[F]->E->[D]->[C] 715 B's Backup: B->A->[F]->E->[D]->[C] 716 C's Backup: C->B->A->[F]->E->[D] 717 D's Backup: D->C->B->A->[F] 718 E's Backup: E->D->C->B->A->[F] 720 It should be noted that ROM-Wrapping is an LSP based protection 721 mechanism, as opposed to the SPME based protection mechanisms that 722 are presented in other sections of this draft. While this may seem 723 to be limited in scope, the mechanism may be very efficient for many 724 applications that are based on p2mp distribution schemes. While ROM- 725 Wrapping can be applied to any network topology, it is particularly 726 efficient for interconnected ring topologies. 728 3.1.1. Comparison of Wrapping and ROM-Wrapping 730 It is possible to compare the Wrapping and the ROM-Wrapping 731 mechanisms in different aspects, and show some improvements offered 732 by ROM-Wrapping. 734 When configuring the protection LSP for Wrapping it is necessary to 735 configure for a specific failure: link protection or node protection. 736 If the protection method is configured to protect node failures but 737 the actual failure affects a link, this could result in failing to 738 deliver traffic to the node, when it should be possible to. 740 ROM-Wrapping however does not have this limitation, because there is 741 no distinction between node and link protection. Whether link B-C or 742 node C fails, in either case the rerouting will attempt to reach C. 743 If the failure is on the link, the traffic will be delivered to C, 744 while if the failure is at node C, the traffic will be rerouted 745 correctly until node D, and will be blocked at this point. However, 746 all egress nodes up-to the failure will be able to deliver the 747 traffic properly. 749 A second aspect is the number of hops needed to properly deliver the 750 traffic. Referring to the example shown in Figure 6, where a failure 751 is detected on link B-C, the following table lists the set of nodes 752 traversed by the data in the protection: 754 Basic Wrapping: 756 A-B B-A-F-E-D-C [C]-[D]-E-[F] 757 "Upstream" segment backup path "Downstream" segment 758 with respect to the with respect to the 759 failure failure 761 ROM Wrapping: 763 A-B B-A-[F]-E-[D]-[C] .. 764 "Upstream" segment backup path 765 with respect to the 766 failure 768 Comparing the two lists of nodes, it is possible to see that in this 769 particular case the number of hops crossed using the simple Wrapping 770 is significantly higher than the number of hops crossed by the 771 traffic when ROM-Wrapping is used. Generally, the number of hops for 772 basic Wrapping is always higher or at least equal compared to ROM- 773 Wrapping. This implies a certain waste of bandwidth on all links 774 that are crossed in both directions. 776 Considering the ring network previously seen, it is possible to do 777 some bandwidth utilization considerations. The protected LSP is set 778 up from A to F clockwise and an M Mbps bandwidth is reserved along 779 the path. All the protection LSPs are pre-provisioned 780 counterclockwise, each of them may also have reserved bandwidth M. 781 These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP] 782 style. 784 The bandwidth reserved counterclockwise is not used when the 785 protected LSP is properly working and could, in theory, be used for 786 extra traffic [RFC4427]. However, it should be noted that [TPReqs] 787 does not require support of such extra traffic. 789 The two recovery mechanism require different protection bandwidths. 790 In the case of Wrapping, the bandwidth used is M in both directions 791 of many of the links. While in case of ROM-Wrapping, only the links 792 from the ingress node to the node performing the actual wrapping 793 utilize M bandwidth in both directions, while all other links utilize 794 M bandwidth only in the counterclockwise direction. 796 Consider the case of a failure detected on link B-C as shown in 797 Figure 6. The following table lists the bandwidth utilization on 798 each link (in units equal to M), for each recovery mechanism and for 799 each direction (CW=clockwise, CCW=counterclockwise). 801 +----------+----------+--------------+ 802 | | Wrapping | ROM-Wrapping | 803 +----------+----------+--------------+ 804 | Link A-B | CW+CCW | CW+CCW | 805 | Link A-F | CCW | CCW | 806 | Link F-E | CW+CCW | CCW | 807 | Link E-D | CW+CCW | CCW | 808 | Link D-C | CW+CCW | CCW | 809 +----------+----------+--------------+ 811 3.1.2. Multiple Failures Comparison 813 A further comparison between Wrapping and ROM-Wrapping can be done 814 with respect to their ability to react to multiple failures. The 815 wrapping recovery mechanism does not have the ability to recover from 816 multiple failures on a ring network, while ROM-Wrapping is able to 817 recover, from some multiple failures. 819 Consider, for example, a double link failure affecting links B-C and 820 C-D shown in Figure 6. The Wrapping mechanism is not able to recover 821 from the failure because B, upon detecting the failure, has no 822 alternative paths to reach C. The whole P2MP traffic is lost. The 823 ROM-Wrapping mechanism is able to partially recover from the failure, 824 because the backup P2MP LSP to node F and node D is correctly set up 825 and continues delivering traffic. 827 3.2. Steering for p2mp paths 829 When protecting p2mp traffic that uses a MPLS-TP ring as its 830 branching point, i.e. it enters the ring at a head-end node and exits 831 the ring at multiple nodes, we can employ a steering mechanism based 832 on 1+1 linear protection [SurvivFwk]. We can configure two p2mp 833 unidirectional SPME from each node on the ring that traverse the ring 834 in both directions. These SPME will be configured with an egress at 835 each ring node. In order to be able to properly direct the LSP 836 traffic to the proper egress point for that particular LSP, we need 837 to employ context labeling as defined in [RFC5331]. The method for 838 using these labels is expanded in section 3.2.1. 840 For every LSP that enters the ring at a given node the traffic will 841 be sent through one of these SPME (the working SPME). In case there 842 is a failure condition, the traffic is transmitted on both SPME, each 843 with its own context label and the context-specific label for the 844 particular LSP. In this way, all egress nodes are able to receive 845 the data traffic. While each node detects that there is connectivity 846 from the ingress point, it continues to select the data that is 847 coming from the working SPME. If a particular node stops receiving 848 the connectivity messages from the working SPME, it identifies that 849 it must switch its selector to read the data packets from the 850 protection SPME. 852 ^ ^ ^ 853 _|_ _|_ _|_ 854 ----->/LSR\********/LSR\********/LSR\ 855 \_A_/========\_B_/========\_C_/ 856 +* <+++++++++*|| 857 +* +*|| 858 +* +*|| 859 +* +*|| 860 +*_ ++++++++ ___ +++++++++*|| 861 /LSR\********/LSR\********/LSR\ 862 \_F_/<=======\_E_/========\_D_/ 863 | | | 864 V V V 866 ---> connected LSP *** physical link 867 === working SPME +++ protection SPME 869 Figure 7: P2MP SPMEs 871 3.2.1. Context labels 873 Figure 7 shows the two unidirectional p2mp SPME that are configured 874 from LSR-A with egress points at all of the nodes on the ring. The 875 clockwise SPME (i.e. A-B-C-D-E-F) is configured as the working SPME, 876 that will aggregate all traffic for p2mp LSPs that enter the ring at 877 LSR-A and must be sent out of the ring at any subset of the ring 878 nodes. The counter-clockwise SPME (i.e. A-F-E-D-C-B) is configured 879 as the protection SPME. 881 [RFC5331] defines the concept of context labels. A context- 882 identifying label defines a context label space that is used to 883 interpret the context-specific labels (found directly below the 884 context- identifying label) for a specific tunnel. The SPME label is 885 a context- identifying label. This means that at each hop the node 886 that receives the SPME label uses it to point not directly to a 887 forwarding table, but to a LIB. As a node receives an SPME label it 888 examines it, discovers that it is a context label, pops off the SPME 889 label, and looks up the next label down in the stack in the LIB 890 indicated by the context label. 892 The label below this context-identifying label should be used by the 893 forwarding function of the node to decide the actions taken for this 894 packet. In MPLS-TP ring protection there are two context LIBs. One 895 is the context LIB for the working SPME and the other is the context 896 LIB for the P-SPME. All context LIBs have a behavior defined for the 897 e2e LSP label but the behavior at each node may be different in the 898 context of each SPME. 900 For example, using the ring that is shown in Figure 7, if the working 901 SPME is configured to have a context-identifying label of CW at each 902 node on the ring and the protection SPME is configured to have a 903 context-identifying label of CP at each node. For the specific LSP 904 we will designate the context-specific label used on the working SPME 905 as WL(x-y) to be the label used as node-x to forward the packet to 906 node-y. Similarly, for the context-specific labels on the protection 907 SPME would be designated PL(x-y). An explicit example of label 908 values appears in the next sub-section. 910 If we apply the 1+1 linear protection scheme outlined above for an 911 p2mp LSP that enters the ring at LSR-A and has egress points from the 912 ring at LSR-C and LSR-E using the two SPME shown in Figure 7 then a 913 packet that arrives at LSR-A with a label stack [LI+S] will be 914 forwarded on the working SPME with a label stack [CW | WL(A-B)]. The 915 packet should then be forwarded to LSR-C arriving with a label [CW | 916 WL(B-C)], where WL(B-C) should instruct the forwarding function to 917 egress the packet with [LE(C)] and forward a copy to LSR-D with label 918 stack [CW | WL(C-D)]. 920 If a fault condition is detected, then some of the nodes will cease 921 to receive the packets from the clockwise (working) SPME. These LSR 922 should then begin to switch their selector bridge to accept the data 923 packets from the protection SPME. At the ingress point the packet 924 will be transmitted on both the working SPME and the protection SPME. 925 Continuing the example, if there is a failure on the link between 926 LSR-C and LSR-D then LSR-A will transmit one copy of the data to 927 LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP 928 | PL(A-F)]. The packet will arrive at LSR-C from the working SPME 929 and egress from the ring. LSR-E will receive the packet from the 930 protection SPME with stack [CP | PL(F-E)] and the context-sensitive 931 label PL(F-E) will instruct the forwarding function to send a copy 932 out of the ring with label LE(E) and a second copy to LSR-D with 933 stack [CP | PL(E-D)]. In this way each of the egress points receive 934 the packet from the SPME that is available at that point. 936 This architecture has the added advantages that there is no need for 937 the ingress node to identify the existence of the mis-connectivity, 938 and there is no need for a return path from the egress points to the 939 ingress. 941 3.2.2. Walkthrough using context labels 943 In order to better demonstrate the use of the context labels we 944 present a walkthrough of an example application of the p2mp 945 protection presented in this section. Referring to Figure 8, there 946 is a p2mp LSP that traverses the ring, entering the ring at LSR-B and 947 branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond 948 LSR-H. For purposes of protection two p2mp unidirectional SPME are 949 configured on the ring starting from LSR-B. One of the SPME, the 950 working SPME, is configured with egress points at each of the LSR - 951 C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is 952 configured with egress points at each of the LSR - A, K, J, H, G, F, 953 E, D, C. 955 ^ ^ ^ ^ ^ 956 _|_ xxxxxxxxx_|_ xxxxxxxxxX|_xxxxxxxxxX|_ xxxxxxxx_|_ 957 xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ 958 \_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/ 959 *+ <+++++++++ +++++++ ++++++++*||x 960 *+ +*||x 961 *+ +*||x 962 *+ +*||x 963 _*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x 964 /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ 965 \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/ 966 | | | |Xxxxxxxxxx | 967 V V V V V 969 xxx p2mp LSP (X LSP egress) *** physical link 970 === working SPME +++ protection SPME 972 Figure 8: P2MP SPMEs 974 For this example we suppose that the LSP traffic enters the ring at 975 LSR-B with the label stack [99], leaves the ring at LSR-D with stack 976 [199], at LSR-E with stack [299], and LSR-H with stack [399]. 978 While it is possible for the context-identifying label for the SPME 979 be configured as a different value at each LSR, for the sake of this 980 example we will suppose a configuration of 200 as the context- 981 identifying label for the working SPME at each of the LSR in the 982 ring, and 400 as the context-identifying label for the protection 983 SPME at each LSR. 985 For the specific connected LSP we configure the following context- 986 specific labels for each context: 988 +------+-----------------------------+------------------------------+ 989 | node | W-context(200) | P-context(400) | 990 +------+-----------------------------+------------------------------+ 991 | A | 65 {drop packet} | 165 {fwrd w/[400|190]} | 992 | C | 90 {fwrd w/[200|80]} | 190 {drop packet} | 993 | D | 80 {fwrd w/[200|75] + | 180 {egress w/[199]} | 994 | | egress w/[199]} | | 995 | E | 75 {fwrd w/[200|65] + | 175 {fwrd w/[400|180] + | 996 | | egress w/[299]} | egress w/[299]} | 997 | F | 65 {fwrd w/[200|55]} | 165 {fwrd w/[400|175]} | 998 | G | 55 {fwrd w/[200|45]} | 155 {fwrd w/[400|165]} | 999 | H | 45 {egress w/[399]} | 145 {fwrd w/[400|155] + | 1000 | | | egress w/[399]} | 1001 | J | 65 {drop packet} | 165 {fwrd w/[400|145]} | 1002 | K | 65 {drop packet} | 190 {fwrd w/[400|165]} | 1003 +------+-----------------------------+------------------------------+ 1005 When a packet arrives on the LSP to LSR-B with stack [99], the 1006 forwarding function determines that it is necessary to forward the 1007 packet to both the working SPME with stack [200|90] and the 1008 protection SPME with stack [400|165]. Each LSR on the SPME will 1009 identify the top label, i.e. 200 or 400, to be the context- 1010 identifying label and use the next label in the stack to select the 1011 forwarding action from the specific context table. 1013 Therefore, at LSR-C the packet on the working SPME will arrive with 1014 stack [200|90] and the 200 will point to the table in the middle 1015 column above. After popping the 200 the next label, i.e. 90, will 1016 select the forwarding action "fwrd w/[200|80]" and the packet will be 1017 forwarded to LSR-D with stack [200|80]. In this manner, the packet 1018 will be forwarded along both SPME according to the configured 1019 behavior in the context tables. However, the egress points at LSR D, 1020 E, & H, will all be configured with a selector bridge to only use the 1021 input from the working SPME. If any of these egress points identify 1022 that there is a connection fault on the working SPME, then the 1023 selector bridge will cause the LSR to read the input from the 1024 protection SPME. 1026 4. Coordination protocol 1028 The Survivability Framework [SurvivFwk] indicates that there is a 1029 need to coordinate protection switching between the end-points of a 1030 protected bidirectional domain. The coordination is necessary for 1031 particular cases, in order to maintain the co-routed nature of the 1032 bidirectional transport path. The particular cases where this 1033 becomes necessary include cases of unidirectional fault detection and 1034 use of operator commands. 1036 By using the same mechanisms defined in [LinProtect], for linear 1037 protection, to apply for ring protection we are able to gain a 1038 consistent solution for this coordination between the end-points of 1039 the protection domain. The Protection State Coordination Protocol 1040 that is specified in [LinProtect] provides coverage for all the 1041 coordination cases, including support for operator commands, e.g. 1042 Forced-Switch. 1044 5. Conclusions and Recommendations 1046 Ring topologies are prevelant in traditional transport networks and 1047 will continue to be used for various reasons. Protection for 1048 transport paths that traverse a ring within a MPLS network can be 1049 provided by applying an appropriate instance of linear protection, as 1050 defined in [SurvivFwk]. This document has shown that for each of the 1051 traditional ring protection architectures there is an application of 1052 linear protection that provides efficient coverage, based on the use 1053 of the Sub-Path Maintenance Entity (SPME), defined in [TPFwk] and 1054 [OAMFwk]. For example, 1056 o p2p Steering - Configuration of two SPME, from ring ingress to 1057 ring egress, and 1:1 linear protection 1059 o p2p Wrapping for link protection - Configuration of two SPME, one 1060 for the protected link and the second using the long route between 1061 the two neighboring nodes, and 1:1 linear protection. 1063 o p2p Wrapping for node protection - Configuration of two SPME, one 1064 between the two neighbors of the protected node and the second 1065 between these two nodes on the long route, and 1:1 linear 1066 protection. 1068 o p2mp Wrapping - it is possible to optimize the performance of the 1069 wrapping by configuring the proper protection path to egress the 1070 data at the proper branching nodes. 1072 o p2mp Steering - by combining 1+1 linear protection and 1073 configuration of the SPME based on context-sensitive labeling of 1074 the protection path. 1076 It has been shown that this set of protection architecture and 1077 mechanisms are optimized based on the criteria defined in [TPReqs] 1078 for justification of designing a specific protection mechanism for a 1079 ring topology. This thereby aleviates the necessity to create a new 1080 mechanism or protocol to support the protection of ring topologies. 1082 By basing the simple p2p ring protection on basic 1:1 linear 1083 protection there is a very efficient way of implementing Steering 1084 protection for the sections of a transport path that traverses the 1085 ring. Steering should be the preferred mechanism for ring protection 1086 since it reduces the extra bandwidth required when traffic doubles 1087 through wrapped protection, and the ability to protect both against 1088 link and node failures without complicating the fault detection or 1089 the need to configure multiple protection paths. While this is true, 1090 the possiblity remains to support either mechanism while depending 1091 upon the OAM functionality [outlined in [OAMFwk] and specified in 1092 various documents] and the coordination protocol specified for linear 1093 protection in [LinProtect]. 1095 6. IANA Considerations 1097 This document makes no request of IANA. 1099 Note to RFC Editor: this section may be removed on publication as an 1100 RFC. 1102 7. Security Considerations 1104 To be added in future version. 1106 8. Acknowledgements 1108 The authors would like to thank all members of the teams (the Joint 1109 Working Team, the MPLS Interoperability Design Team in IETF and the 1110 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 1111 specification of MPLS Transport Profile. 1113 9. Informative References 1115 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1116 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1117 May 2005. 1119 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1120 Label Assignment and Context-Specific Label Space", 1121 RFC 5331, Aug 2008. 1123 [TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 1124 "Requirements for the Transport Profile of MPLS", 1125 RFC 5654, April 2009. 1127 [TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP 1128 Framework", ID draft-ietf-mpls-tp-framework-12, May 2010. 1130 [OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM 1131 Framework", ID draft-ietf-mpls-tp-oam-framework-06, 1132 May 2010. 1134 [SurvivFwk] 1135 Sprecher, N. and A. Farrel, "MPLS-TP Survivability 1136 Framework", ID draft-ietf-mpls-tp-survive-fwk-06, 1137 June 2010. 1139 [LinProtect] 1140 Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., 1141 and Y. Weingarten, "MPLS-TP Linear Protection", 1142 ID draft-ietf-mpls-tp-linear-protection-02, October 2009. 1144 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 1145 Jamin, "Resource ReSerVation Protocol (RSVP) - Functional 1146 Specifications", RFC 2205, September 1997. 1148 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1149 Restoration) Terminology for GMPLS", RFC 4427, March 2006. 1151 [G.841] ITU, "Types and characteristics of SDH network protection 1152 architectures", ITU-T G.841, October 1998. 1154 Authors' Addresses 1156 Yaacov Weingarten 1157 Nokia Siemens Networks 1158 3 Hanagar St. Neve Ne'eman B 1159 Hod Hasharon, 45241 1160 Israel 1162 Phone: +972-9-775 1827 1163 Email: yaacov.weingarten@nsn.com 1164 Stewart Bryant 1165 Cisco 1166 United Kingdom 1168 Email: stbryant@cisco.com 1170 Nurit Sprecher 1171 Nokia Siemens Networks 1172 3 Hanagar St. Neve Ne'eman B 1173 Hod Hasharon, 45241 1174 Israel 1176 Email: nurit.sprecher@nsn.com 1178 Danielle Ceccarelli 1179 Ericsson 1180 Via A. Negrone 1/A 1181 Genova, Sestri Ponente 1182 Italy 1184 Email: daniele.ceccarelli@ericsson.com 1186 Diego Caviglia 1187 Ericsson 1188 Via A. Negrone 1/A 1189 Genova, Sestri Ponente 1190 Italy 1192 Email: diego.caviglia@ericsson.com 1194 Francesco Fondelli 1195 Ericsson 1196 Via A. Negrone 1/A 1197 Genova, Sestri Ponente 1198 Italy 1200 Email: francesco.fondelli@ericsson.com 1201 Marco Corsi 1202 Altran 1203 Via A. Negrone 1/A 1204 Genova, Sestri Ponente 1205 Italy 1207 Email: marco.corsi@altran.it 1209 Bo Wu 1210 ZTE Corporation 1211 4F,RD Building 2,Zijinghua Road 1212 Nanjing, Yuhuatai District 1213 P.R.China 1215 Email: wu.bo@zte.com.cn 1217 Xuehui Dai 1218 ZTE Corporation 1219 4F,RD Building 2,Zijinghua Road 1220 Nanjing, Yuhuatai District 1221 P.R.China 1223 Email: dai.xuehui@zte.com.cn