idnits 2.17.1 draft-zlj-mpls-mrsvp-te-frr-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te], [RFC4090], [RFC4875]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2013) is 3893 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te' is mentioned on line 360, but not defined == Missing Reference: 'RFC-WORDS' is mentioned on line 110, but not defined == Missing Reference: 'RSVP' is mentioned on line 110, but not defined == Missing Reference: 'RSVP-TE' is mentioned on line 110, but not defined == Missing Reference: 'RFC5880' is mentioned on line 469, but not defined == Missing Reference: 'RFC5884' is mentioned on line 469, but not defined == Unused Reference: 'I-D.lzj-mpls-receiver-driven-multicast-rsvp-te' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 1041, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Katherine. Zhao 3 Internet-Draft Renwei. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: February 28, 2014 Christian. Jacquenet 6 France Telecom Orange 7 August 29, 2013 9 Fast Reroute Extensions to Receiver-Driven RSVP-TE for Multicast Tunnels 10 draft-zlj-mpls-mrsvp-te-frr-02.txt 12 Abstract 14 This document specifies fast reroute procedures to protect multicast 15 LSP tunnels built by mRSVP-TE, a receiver-driven extension to RSVP-TE 16 specified by [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te]. 17 This document is motivated by the observation that the existing FRR 18 solution specified by [RFC4090] and [RFC4875] for the sender-driven 19 RSVP-TE is no longer applicable to the receiver-driven RSVP-TE. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 13, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Link Protection and Node Protection with mRSVP-TE . . . . 5 70 2.2. Primary and Backup LSP . . . . . . . . . . . . . . . . . . 8 71 2.3. Detour Backup and Facility Backup . . . . . . . . . . . . 8 72 3. Detour Backup for mRSVP-TE . . . . . . . . . . . . . . . . . . 9 73 3.1. Link Protection in Detour Backup Mode . . . . . . . . . . 9 74 3.1.1. Detour LSP Setup Scenario for Link Protection . . . . 9 75 3.1.2. Label Allocation for Link Protection . . . . . . . . . 10 76 3.1.3. Link Failure Repair in Detour Mode . . . . . . . . . . 12 77 3.1.4. Re-convergence after Local Repair . . . . . . . . . . 12 78 3.2. Node Protection in Detour Backup Mode . . . . . . . . . . 12 79 3.2.1. Detour LSP Setup for Node Protection . . . . . . . . . 12 80 3.2.2. Label Allocation and Binding for Node Protection . . . 13 81 3.2.3. Node Failure Repair in Detour Mode . . . . . . . . . . 14 82 3.2.4. Re-Convergence after Local Repair . . . . . . . . . . 14 83 4. Facility Backup for mRSVP-TE . . . . . . . . . . . . . . . . . 15 84 4.1. Link Protection in Facility Backup Mode . . . . . . . . . 15 85 4.1.1. Backup LSP Setup for Link Protection . . . . . . . . . 15 86 4.1.2. Label Allocation for Link Protection . . . . . . . . . 16 87 4.1.3. Link Failure Repair in Facility Mode . . . . . . . . . 18 88 4.1.4. Re-Convergence after Local Repair . . . . . . . . . . 18 89 4.2. Node Protection in Facility Backup Mode . . . . . . . . . 18 90 4.2.1. Backup LSP setup in Facility Mode . . . . . . . . . . 18 91 4.2.2. Label Allocation for Node Protection . . . . . . . . . 19 92 4.2.3. Node Failure Repair and Packet Encapsulation . . . . . 22 93 4.2.4. Re-convergence after Local Repair . . . . . . . . . . 23 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 6. Manageability Considerations . . . . . . . . . . . . . . . . . 23 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 106 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 107 this document are to be interpreted as described in RFC2119 [RFC- 108 WORDS]. The reader is assumed to be familiar with the terminology in 109 [RSVP], [RSVP-TE] and [mRSVP-TE]. 111 This document uses same terminologies stated in 112 [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te], [RFC4090] and 113 [RFC4875]. In addition, some key notions and terminologies for this 114 document are explained as follows: 116 o mLSP, Multicast Label Switched Path, is either a P2MP or MP2MP LSP 117 consisting of one or more sub-LSPs. 119 o mRSVP-TE, Multicast Resource Reservation Protocol-Traffic 120 Engineering, is used to distinguish from the regular sender-driven 121 RSVP-TE. One major difference between RSVP-TE and mRSVP-TE is 122 that the tunnel setup is initiated by the data receiver instead of 123 the data sender. 125 o PLR: Point of Local Repair, an LSR that detects a local failure 126 event and redirects traffic from protected mLSP to a backup mLSP 127 tunnel which is designed to take over traffic forwarding until the 128 protected tunnel is repaired. 130 o MP: Merge Point, an LSR that merges the traffic from backup 131 tunnels with primary LSP at the level of forwarding plane. In the 132 receiver-driven RSVP-TE for approach, the MP is the LSR that 133 initiates backup mLSP setup taking PLR as the root of the backup 134 LSP. 136 o N: The node to be protected. 138 o Pn: The node(s) on the backup path for protecting node N. 140 o Root: A router where an mLSP is rooted at. Multicast contents 141 enter the root and then are distributed to leaf routers along the 142 P2MP/MP2MP LSP. 144 o FRR Domain: A set of links and LSRs that compose a protected sub- 145 LSP and backup LSP, and which is located between PLR and MP(s). 147 2. Introduction 149 Fast Reroute technology has been well accepted and deployed to 150 provide millisecond-level protection in case of node/link failures. 151 FRR employs some local repair mechanisms to meet the fast reroute 152 requirements by computing and provisioning backup tunnels in advance 153 of failure and by redirecting traffic to such backup tunnels as close 154 to the failure point as possible. 156 The fast reroute extensions to RSVP-TE are specified in [RFC4090] and 157 [RFC4875]. Such extensions work well with the sender-driven RSVP-TE, 158 but they are no longer applicable to the receiver-driven RSVP-TE for 159 multicast tunnels described in the draft 160 [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te]. 162 In the receiver-driven paradigm of mRSVP-TE, the procedure to set up 163 an LSP tunnel is inverted from that in the sender-driven RSVP-TE, and 164 thus the backup mLSP setup and failover handling mechanism will have 165 to be different from what has been specified for the sender-driven 166 RSVP-TE. From the signaling point of view, the behavior of PLR and 167 MR is inverted from the sender-driven paradigm of RSVP-TE: the setup 168 for a backup mLSP is initiated by MP with PLR being taken as the root 169 of a P2MP/MP2MP tree. The RSVP PATH message is sent from MP towards 170 PLR with the FAST_REROUT, DETOUR as well as other FRR related objects 171 conveyed in the PATH message. RSVP RESV message is sent from PLR 172 towards MP carrying FRR information such as the inner label used to 173 represent a protected mLSP tunnel, etc. 175 On the other hand, from the packet forwarding point of view, the 176 behavior of PLR and MP is similar to the sender-driven RSVP-TE. The 177 traffic switchover and redirecting are still initiated by PLR, and 178 the data traffic is merged at MP in the same way as what is specified 179 for the sender-driven RSVP-TE. 181 This document describes various FRR protection methods and behavior 182 changes for the receiver-driven mRSVP-TE, and specify fast-reroute 183 extensions to the RSVP-TE messages, mechanisms and procedures 184 specified in the mRSVP-TE draft 185 [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te]. 187 2.1. Link Protection and Node Protection with mRSVP-TE 189 FRR link protection aims to protect a direct link between two LSRs 190 (Label Switch Routers). An LSR at one end of the link is called PLR 191 (Point of Local Repair), and the other LSR located at the other end 192 of the link is called MP (Merge Point). A backup LSP whose setup is 193 originated at MP and terminated at PLR will be established to protect 194 the primary LSP crossing over the link. The LSRs over the backup 195 path are called Pn. These connected LSRs and links are called an FRR 196 domain in this document. An example of an FRR domain supporting link 197 protection is shown in Figure 1. 199 Protected 200 +---------+ Link +--------+ 201 Sender --- | R1(PLR) |------------| R2(MP) | --- Receiver 202 +---------+ +--------+ 203 * * 204 * * Backup Tunnel 205 * * 206 +---------+ 207 | R3(Pn) | 208 +---------+ 210 Figure 1: Basic FRR Link Protection 212 In an FRR domain constructed by mRSVP-TE, the MP initiates both the 213 primary and the backup LSP setup at the signaling control plane, and 214 merges the traffic from the backup LSP into the primary LSP at the 215 data forwarding plane. The PLR works with the MP to set up LSP at 216 the signaling control plane accordingly, and detects link failure and 217 initiates local repair at the data forwarding plane. In Figure 1, we 218 use hyphens (-)to denote a primary tunnel between LSRs; and asterisks 219 (*) to denote a backup tunnel. The same symbols will be applied to 220 all figures throughout the document. 222 Node protection is a technique used to protect a node N that resides 223 between PLR and MP over a primary LSP. An example of node protection 224 is shown in Figure 2. 226 Protected 227 Sender Node Receiver 228 +---------+ +---------+ +--------+ 229 ---- | R1(PLR) |-----------| R2(N) |-----------| R3(MP) | --- 230 +---------+ +---------+ +--------+ 231 * * 232 * * 233 * +---------+ +---------+ * 234 ********| R4(Pn1) |******| R5(Pn2) |******** 235 +---------+ +---------+ Backup Tunnel 237 Figure 2: Basic FRR Node Protection 239 N (R2) denotes a node being protected over a primary LSP, its 240 upstream node plays the role of PLR while the downstream node plays 241 the role of MP. Pn denotes a transit node over its backup LSP. Note 242 that there can be multiple Pn's over a backup tunnel. Pn does not 243 play a significant role for FRR but works as a regular LSR to receive 244 and transmit multicast data and signaling messages over backup LSPs. 246 Besides the basic P2P node protection, mRSVP-TE suggests P2MP and 247 MP2MP node protection as shown in Figures 3 and 4. Because the same 248 protection mechanism can be commonly used for both P2MP and MP2MP, 249 this document uses P2MP as example for the discussion, and mention 250 MP2MP only if there is a difference from P2MP. 252 There are two typical methods to protect a P2MP multicast tree, one 253 that uses a P2MP tree as a backup LSP to protect a primary mLSP (see 254 Figure 3), and the other that uses multiple P2P LSPs to protect a 255 P2MP mLSP(see Figure 4). 257 Protected 258 Sender Node Receiver 259 +-------+ +-------+ +-------+ 260 -----|R1(PLR)|--------------| R2(N) |-------|R3(MP1)|---- PE1 261 +-------+ +-------+ +-------+ 262 * \ * 263 * \ * 264 * \* 265 Backup Tunnel *\ 266 * * \ 267 * * \ 268 * +-------+ +-------+ +-------+ 269 ****|R4(Pn1)|*******|R5(Pn2)|******|R6(MP2)|---- PE2 270 +-------+ +-------+ +-------+ 272 Figure 3: P2MP Node Protection in Facility Mode 273 +---------+ +---------+ Backup Tunnel 274 ********| R4(Pn1) |******| R5(Pn2) |******** 275 * +---------+ +---------+ * 276 * +--------+ 277 Sender * Protected Node -----| R3(MP) |---- PE 278 +---------+ +---------+ | +--------+ 279 ---- | R1(PLR) |-----------| R2(N) |------| 280 +---------+ +---------+ | +--------+ 281 * -----| R3(MP) |---- PE 282 * +--------+ Receiver 283 * +---------+ +---------+ * 284 ********| R6(Pn3) |******| R7(Pn4) |******** 285 +---------+ +---------+ Backup Tunnel 287 Figure 4: Multiple P2Ps Protecting a P2MP LSP 289 2.2. Primary and Backup LSP 291 A router that detects a node/link failure must have pre-determined 292 which alternate reroute path it should use to forward traffic while 293 the failure is being fixed. The alternate backup path should be 294 established before a protected LSP is broken. Anything such as 295 backup route computation and configuration required for local repair 296 purposes should be done prior to failure occurrence so that the 297 failover time can be reduced to minimum. 299 On the control plane, the backup LSP will be set up along with its 300 primary LSP setup. The PATH/RESV refresh messages are transmitted 301 over both protected and backup LSPs before failover. However on the 302 data plane, there are two implementation options for traffic 303 forwarding. One option is that traffic is not forwarded on backup 304 LSP tunnel until a failure is detected and the local repair takes 305 place. The second option is to forward traffic on both protected and 306 backup mLSPs before failover, and the LSR at Merge Point will then 307 drop packets coming from the backup path before switchover. The 308 second option can further reduce traffic switchover time at the cost 309 of extra overhead and bandwidth sub-optimization. This document 310 leaves the flexibility for implementation to decide which option to 311 choose, but will use the first option for the discussion, i.e. we 312 assume that the traffic is forwarded on the primary LSP only before 313 switchover. 315 2.3. Detour Backup and Facility Backup 317 Due to historical reasons and implementation preferences, two 318 independent methods for doing fast reroute have been developed. One 319 backup method is called detour backup and is especially designed for 320 1:1 protection. The other one is called facility backup and is 321 especially designed for 1: N protection, where N can be equal to or 322 greater than 1. From the point of view of applications, the facility 323 backup method can support both 1:N and 1:1, but from the technical 324 point of view, these are two different methods requiring different 325 implementations with respect to their label stacks when forwarding 326 packets. 328 The detour backup creates a dedicated LSP to protect an LSP and uses 329 a single MPLS label for packet encapsulation; its implementation is 330 simpler but consumes more label resources. The facility backup 331 creates a common LSP to protect a set of LSPs that have similar 332 backup constraints. This method takes advantage of MPLS label 333 stacking and uses dual-label encapsulation, thus it can save some 334 label resources compared to the detour backup method. 336 These two solutions have co-existed as options for vendors and 337 service providers to choose. This document will specify both the 338 methods applied to mRSVP-TE. Throughout the document, the detour 339 method is used to represent 1:1 protection while the facility method 340 is used to represent 1:N protection. The term "detour LSP" is 341 especially used for 1:1 protection while "backup LSP" is used for 1: 342 N protection. Sometimes the latter can be used for both kinds of 343 protection schemes when no ambiguity arises. 345 3. Detour Backup for mRSVP-TE 347 This section specifies mechanisms and procedures for mRSVP-TE fast 348 reroute by using the detour backup method. The term "detour LSP" 349 will be used to denote the LSP in the detour mode and the 1:1 350 protection scheme. 352 3.1. Link Protection in Detour Backup Mode 354 3.1.1. Detour LSP Setup Scenario for Link Protection 356 A detour LSP setup is initiated by MP along with the setup of the 357 protected LSP (Figure 1), which is one of the major differences from 358 the procedure stated in [RFC4090] and [RFC4875]. Following the LSP 359 setup procedure specified by the draft 360 [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te], MP sends RSVP 361 PATH messages towards the sender over a primary path. For link 362 protection purpose, both the MP and PLR are directly connected by the 363 link being protected, hence the PATH message is sent from the MP to 364 the PLR directly upstream. 366 The MP is not necessarily the originator of the primary LSP, but is 367 the first LSR entering an FRR domain along the primary route. Once 368 the PATH message is sent out by the MP, the MP will check whether 369 there is a detour route available for link protection. The detour 370 route calculation can be done by running CSPF on the link state 371 database produced by IGP protocols with TE extensions. There is no 372 change required for backup route computation, and the detour LSP 373 computation will be based on this assumption. 375 If the CSPF stack returns 'no detour route found' after the detour 376 calculation, MP will not perform the detour LSP setup. If at least 377 one detour route is found by CSPF stack, MP selects the shortest 378 route and initiates the detour LSP setup. MP considers PLR as the 379 end point of the detour LSP and sends a PATH message towards PLR hop- 380 by-hop. In the example of Figure 1, the PATH message will be sent to 381 Pn (R3) and then relayed to PLR (R1). 383 Upon receipt of the PATH message, the PLR sends back a RESV message 384 towards the MP through the Pn(s). The transit Pn(s) nodes relay the 385 PATH/RESV messages without any special process required for the link 386 protection. The detour LSP setup is completed once the RESV message 387 is received and processed by the MP. 389 3.1.2. Label Allocation for Link Protection 391 Because the detour method uses a dedicated backup LSP to protect a 392 primary LSP, one-to-one binding can be made for a pair of primary and 393 backup LSPs, a single MPLS label encapsulation will be sufficient for 394 packet forwarding and local failure repair purpose. DLA (downstream 395 label allocation) can be used as the label assignment method over the 396 detour tunnel for the link protection. With mRSVP-TE, a downstream 397 label is assigned by an LSR that is sending a PATH message to its 398 upstream router, and an upstream label is assigned by an LSR that is 399 sending the RESV message to its downstream router. The label 400 allocation, however, is more complicated when the primary LSP is a 401 P2MP or MP2MP tree. A specific upstream label allocation and 402 resource preemption method is defined in this document to handle the 403 protection of P2MP and MP2MP tree structures. 405 An example of the label allocation for link protection in the detour 406 mode is provided in Figure 5. For the sake of readability, we use 407 label Lp to represent the label assigned to the primary tunnel, and 408 label Lb for the labels assigned to the backup tunnel. For example, 409 Lp2 represent a downstream label assigned for LSR R2 to receive 410 incoming data over the primary tunnel. Lb2 represents a downstream 411 label assigned for R2 to receive data over a detour LSP. 413 Lp1->Lp2,MP Lp2->Lp-pe,PE 414 Lp1->Lb3,Pn Lb2->Lp-pe,PE 416 Lp1 +---------+ Lp2 +--------+ Lp-pe 417 Sender --- | R1(PLR) |------------| R2(MP) |-------PE, Receiver 418 +---------+ Protected +--------+ 419 * Link * 420 * * Backup Tunnel 421 Lb3 * * Lb2 422 +---------+ 423 | R3(Pn) | 424 +---------+ 425 Lb3->Lb2,MP 427 Figure 5: Label Allocation for Link Protection in Detour Mode 429 In the example of Figure 5, MP assigns label Lp2 and sends it to PLR 430 via the PATH message over the link {MP-PLR} to set up the primary 431 LSP. For the detour route {MP-Pn-PLR}, MP assigns a label Lb2 and 432 sends it to Pn via the PATH message. MP binds label Lp2 with label 433 Lb2 for this pair of primary and detour LSPs. An entry 'Lp2->Lp-pe, 434 PE' will be added into MP's FIB to forward packets over the protected 435 LSP. Another entry 'Lb2-> Lp-pe, PE' will be added and used when 436 traffic is received from the detour tunnel upon switchover. 438 Pn (transit node) on the detour tunnel receives Lb2 from MP. Pn 439 assigns a downstream label Lb3 and sends it to the PLR via a PATH 440 message. Pn will add an entry 'Lb3->Lb2, MP' to its FIB for packet 441 forwarding. Note that Pn is not aware of the primary LSP, so there 442 is only one forwarding entry needed in its FIB. 444 PLR receives two PATH messages from MP and Pn respectively. Then it 445 binds label Lp2 from the primary LSP with label Lb3 from the detour 446 LSP. The detour LSP ends at PLR while the primary LSP may not end at 447 PLR if the PLR is not the root of the P2MP tree. PLR will allocate a 448 downstream label Lp1 and sends it to its upstream router, which is 449 outside of the FRR domain in this example, hence not shown in Figure 450 5. There will be two entries added into PLR's FIB: one entry 451 'Lp1->Lp2, MP' for the primary traffic forwarding, and another entry 452 'Lp1->Lb3, Pn' for the detour traffic forwarding upon failover. 454 PLR processes PATH messages from MP and sends RESV messages towards 455 MP. If the primary sub-LSP is part of a RD P2MP tree, PLR will not 456 allocate upstream labels for receiving traffic from the downstream 457 node (MP or Pn in this example) because traffic is uni-directionally 458 forwarded. If the primary sub-LSP is part of a RD MP2MP tree, PLR 459 will allocate an upstream label for receiving traffic from the 460 opposite direction, and Pn(s) do the same and allocate upstream label 461 for the detour sub-LSP accordingly. Detour LSP setup is completed 462 once MP has received and processed the RESV message originated by 463 PLR. Figures 5 shows the summary of labels allocated and FIB entries 464 created on each node in the FRR domain. 466 3.1.3. Link Failure Repair in Detour Mode 468 Link failure can be detected by, for example, BFD (Bidirectional 469 Forwarding Detection, [RFC5880],[RFC5884])along the protected LSP, 470 The failure detection algorithm is the same as what is used for the 471 sender-driven RSVP-TE. 473 Once a link failure is detected by PLR and all switchover criteria 474 are met, PLR will redirect the traffic to the detour LSP based on the 475 forwarding entry 'Lp1->Lb3, Pn'. The entry 'Lp1->Lp2, MP' for the 476 primary path will be withdrawn. 478 Pn works as a normal label switch router and forward MPLS packets to 479 MP. MP receives the packet and figures out that such packets come 480 from the detour path, so they will be forwarded to PE based on the 481 entry 'Lb2->Lp-pe, PE', in the example of Figure 5. The detour 482 traffic is therefore merged back to the primary LSP towards PE, which 483 completes the link failure repairing by detouring and merging the 484 traffic. 486 3.1.4. Re-convergence after Local Repair 488 Routers that do not belong to the FRR domain are not impacted by the 489 link failure and local repair. Traffic is transmitted over a detour 490 LSP after a link failure and local repair. Usually, the detour path 491 is not the shortest path so the network will eventually re-converge 492 and a new shortest path will be calculated by the MPLS control plane. 493 Once a new primary path is determined, the traffic is no longer 494 transmitted through the detour LSP and PLR will be notified to tear 495 down the detour LSP and clean up its internal LIB. PLR will send a 496 PathTear message to Pn and MP for tearing down the detour LSP and 497 release backup labels. Re-convergence procedure is the same as the 498 procedure used for sender-driven RSVP-TE FRR. 500 3.2. Node Protection in Detour Backup Mode 502 3.2.1. Detour LSP Setup for Node Protection 504 The detour LSP setup for the node protection is similar to the link 505 protection. Take Figure 2 as an example, where protected node N 506 resides between MP and PLR. In this case the two sub-links {MP-N} 507 and {N-PLR} are also to be protected in addition to the node N 508 protection. It is assumed that the link protection mechanism 509 described in the previous sub-section is applicable to the sub-link 510 protection in this situation. Hence this section will focus on the 511 procedure to handle node protection. A combined solution for 512 providing node protection with link protection can be derived from 513 the discussions of section 3.1 and this section. 515 For the node protection shown in Figure 2, MP(R3) sends a PATH 516 message to N for the primary LSP setup, the primary LSP in the FRR 517 domain goes through the route {MP-N-PLR}. Once the PATH message is 518 sent out to N, MP checks whether there is a detour path available for 519 node N by using CSPF computation, which would indicate N as a node to 520 be avoided on the detour path. If no detour route is found, MP skips 521 the detour LSP setup. If a detour route is found, MP initiates the 522 detour LSP setup and considers PLR as the end-point of the detour 523 LSP. MP sends a PATH message towards PLR over the detour route hop- 524 by-hop. In the example of Figure 2, the detour route is in the order 525 of {MP-Pn2-Pn1-PLR}. Similar to the link protection, PLR sends back 526 a RESV message towards MP through Pn(s). Transit node Pn(s) just 527 relay the PATH and RESV messages without any specific node protection 528 procedure. The detour LSP setup is completed once the RESV message 529 is received and processed by MP. 531 Figure 2 shows a typical example of node protection where N is not a 532 branch node; it will be more complicated when N is a branch node that 533 is part of a RD P2MP/MP2MP tree structure. The corresponding 534 mechanism is described in section 5.2.2. 536 3.2.2. Label Allocation and Binding for Node Protection 538 Similar to link protection, node protection uses the single label 539 encapsulation and downstream label allocation method in the detour 540 backup mode. An example of the label allocation for node protection 541 is provided in Figure 6. 543 Lp1->Lp2,N Lp3->Lp-pe,PE 544 Lp1->Lb4,Pn1 Lp2->Lp3,MP Lb3->Lp-pe,PE 546 Lp1 +---------+ Lp2 +---------+ Lp3 +--------+ Lp-pe 547 ---- | R1(PLR) |---------| R2(N) |--------| R3(MP) |------PE 548 +---------+ +---------+ +--------+ 549 Sender * * Receiver 550 * * 551 * Lb4 +---------+ Lb5 +---------+ Lb3 * 552 ******| R4(Pn1) |******| R5(Pn2) |****** 553 +---------+ +---------+ 554 Lb4->Lb5,Pn1 Lb5->Lb3,MP 556 Figure 6: Node Protection in Detour Mode 558 MP (R3) assigns a label Lp3 for the primary LSP and sends it to node 559 N via a PATH message over the protected route {MP-N-PLR}. N will 560 allocate a downstream label Lp2 and sends it to PLR via a PATH 561 message. MP also assigns a label Lb3 for the detour LSP and sends it 562 to Pn2 via a PATH message over the detour route {MP-Pn2-Pn1-PLR}. MP 563 binds label Lp3 with label Lb3 for this pair of primary and backup 564 LSPs. An entry 'Lp3->Lp-pe, PE' will be added to MP's FIB for packet 565 forwarding over the primary LSP. Another entry 'Lb3->Lp-pe, PE' will 566 be kept in the FIB and used when a failover takes place and traffic 567 is redirected to the detour LSP. 569 There could be multiple transit nodes Pn(s) along the detour LSP, 570 each of which will allocate a downstream label and sends it to its 571 upstream router. Eventually PLR receives the PATH message from the 572 protected node N and the transit node Pn1 in this example. PLR binds 573 primary label Lp2 with the detour label Lb4, and adds two entries 574 into its FIB: One entry 'Lp1->Lp3, N' for the traffic forwarding over 575 the primary LSP, and another entry 'Lp1->Lb4, Pn1' for the traffic 576 forwarding over the detour LSP. An example of the allocated labels 577 and FIB entries in the FRR domain are mentioned in Figure 6. 579 3.2.3. Node Failure Repair in Detour Mode 581 Once the node N failure is detected by PLR, it will redirect the 582 traffic from the primary LSP to its detour LSP based on the binding 583 and forwarding entry 'Lp1->Lb4, Pn1'. The traffic is forwarded 584 through LSR->Pn1-Pn2->MP. Eventually, MP will receive packets from 585 the detour path. Consulting its FIB forwarding entry 'Lb3->Lp-pe, 586 PE', traffic will then be forwarded to PE in the example of Figure 6, 587 so that the detoured traffic gets merged into the primary path. 589 The local repair mechanism for the node protection is the same as the 590 link protection in the detour mode except that there are two links 591 {MP-N} and {N-PLR} to be protected in conjunction with the node N 592 protection. The FRR domain must be configured so that both the link 593 and node failure detection methods are specified. For example, BFD 594 needs to be activated between MP abd N, N and PLR, and PLR and MP. 595 PLR and MP can be used for either link repair, node repair or both 596 depending on the results of BFD detection. 598 3.2.4. Re-Convergence after Local Repair 600 After a node failure takes place, the network topology will change. 601 As a consequence, the network will eventually re-converge and a new 602 best path will be computed to establish the primary LSP. PLR will be 603 notified as soon as the new primary LSP is signaled and set up. PLR 604 will send notification messages to Pn1 and MP for tearing down the 605 detour LSP and withdraw backup labels. 607 4. Facility Backup for mRSVP-TE 609 This section specifies mechanisms and procedures for mRSVP-TE fast 610 reroute by using the facility backup method. The term backup LSP 611 will be used to denote the LSP in the facility mode for 1: N 612 protection. Note that the term 'detour LSP' is no longer used in 613 this section for the Facility backup. 615 The backup LSP differs from the detour LSP in that one single backup 616 LSP is used to protect multiple primary LSPs. General speaking, two 617 labels will be used for the backup LSP with the inner label being 618 used to indicate which primary LSP is being protected. 620 4.1. Link Protection in Facility Backup Mode 622 4.1.1. Backup LSP Setup for Link Protection 624 Similar to the detour LSP setup, MP sends a RSVP PATH message towards 625 PLR over the primary route. Once the PATH message is sent out, MP 626 will execute the backup LSP procedures as per the following steps: 628 o Check whether there has been a backup LSP created to protect the 629 link between PLR and MP. If a backup LSP is found, skip the 630 further process at MP, e.g., do not send a PATH message over the 631 backup route for LSP setup. However, this does not mean that no 632 process is needed for link protection. Later on, the PLR will 633 allocate an inner label for each newly created primary LSP and 634 send it to Pn(s) and MP via RESV messages. Details for label 635 allocation and packet encapsulation are discussed in section 636 4.1.2. 638 o If there is no backup LSP available, MP initiates the backup LSP 639 setup: MP calculates a backup route by using CSPF taking PLR as 640 the endpoint of the backup LSP and sends a PATH message towards 641 PLR hop-by-hop over the backup route. In the example of Figure 1, 642 PATH messages will be sent from MP to Pn (R3) and relayed to PLR 643 (R1). PLR will then send a RESV message to MP, so as to complete 644 the backup LSP setup. Section 4.1.2 specifies the details about 645 the label allocation and binding. 647 4.1.2. Label Allocation for Link Protection 649 As a backup LSP protects one or more primary LSPs, the facility 650 protection scheme uses two labels for packet forwarding. The outer 651 label is used for regular packet forwarding hop-by-hop over the 652 backup LSP, while the inner label is used to represent a primary LSP 653 and used by MP to merge traffic forwarded over the backup LSP to its 654 corresponding primary LSP. Multiple primary LSPs will share the 655 common outer label while the inner label is unique for each protected 656 LSP. Figure 7 below shows how the two labels are assigned and used 657 for the facility backup. There are two primary LSPs to be protected 658 by a common backup LSP in this example. 660 in PLR FIB in MP FIB 661 LSP1-Entry Lp11->Lp12,MP Lp12->Lp-pe1,PE1 662 FRR:Lp12,Lp11->Lb3,Pn FRR:Lp12,Lb2->Lp-pe1,PE1 664 LSP2-Entry Lp21->Lp22,MP Lp22->Lp-pe2,PE2 665 FRR:Lp22,Lp21->Lb3,Pn FRR:Lp22,Lb2->Lp-pe2,PE2 667 LSP1-Lbl Lp11 Lp12 Lp-pe1 668 LSP2-Lbl Lp21+---------+ Lp22 +--------+ Lp-pe2 669 -------| R1(PLR) |------------| R2(MP) |-------PE1,Receiver 670 Sender +---------+ Protected +--------+-------PE2,Receiver 671 * Link * 672 * * Backup Tunnel 673 Lb3 * * Lb2 674 +---------+ 675 | R3(Pn) | 676 +---------+ 677 FRR:Lp12,Lb3->Lb2,MP 678 FRR:Lp22,Lb3->Lb2,MP 680 Figure 7: Label Allocation for Link Protection in Facility Mode 682 Assume that primary LSP1 is created first, MP assigns a downstream 683 label Lp12 for LSP1 being protected and sends the label to PLR via a 684 PATH message over route {MP-PLR}. Because the primary LSP1 is the 685 first LSP created over this route, MP also assigns a downstream label 686 Lb2 for the backup LSP and sends it to Pn via a PATH message over the 687 backup route {MP-Pn-PLR}. Pn allocates a downstream label Lb3 and 688 sends it to PLR via a PATH message. 690 Once PATH messages are received from MP and Pn respectively, PLR will 691 allocate an inner label to represent the primary LSP1 for the backup 692 LSP. The method to allocate the inner label is implementation- 693 specific. In this example, label Lp12 is used as the inner label to 694 represent primary LSP1 over the backup LSP. LSR at merge point uses 695 the inner label to locate the corresponding primary LSP. The inner 696 label is propagated from PLR to MP by a RESV message. Note that PLR 697 and MP are the only LSRs that actually see, use or process the inner 698 label, while other transit node Pns do not process the inner label. 700 The process for the second or additional primary LSPs protected by 701 the same backup LSP is different from that for the first one. MP 702 does not allocate any new downstream label for the backup LSP since 703 the backup LSP for the first primary LSP is shared between all the 704 primary LSPs protected by the same backup LSP. But the PLR is 705 required to allocate an inner label for each newly created primary 706 LSP and sends it to MP hop-by-hop via a RESV message. 708 We use Figure 7 as an example to show the packet forwarding FIB entry 709 by using the following format: 711 FRR:(inner label),(incoming outer label)->(outgoing outer label),NHOP 713 When MP allocates the downstream label Lp12 for the primary LSP1, an 714 entry 'Lp12->Lp-pe1, PE1' is added into MP's FIB. Another FRR entry 715 'FRR: Lg12, Lb2->Lp-pe1, PE1' is added when MP receives a RESV 716 message that carries an inner label Lg12 and binding information with 717 LSP1. So the MP will have two forwarding entries for each protected 718 LSP. In this example MP will maintain four entries in its FIB for 719 the two protected paths LSP1 and LSP2: 721 Lp12->Lp-pe1, PE1 723 Lp22->Lp-pe2, PE2 725 FRR: Lp12, Lb2 -> Lp-pe1, PE1 727 FRR: Lp22, Lb2 -> Lp-pe2, PE2 729 PLR creates a forwarding entry for a primary LSP whenever it receives 730 a PATH message for the setup of a new primary LSP. For each primary 731 path LSP1, once PLR receives the PATH message from the backup route, 732 PLR allocates an inner label for the primary LSP and creates an FRR 733 entry in its FIB. The PLR FIB will have these entries for the two 734 protected LSP LSP1 and LSP2: 736 Lp11 ->Lp12, MP 738 Lp21->Lp22, MP 740 FRR: Lp12, Lp11 -> Lb3, MP 741 FRR: Lp22, Lp21 -> Lb3, MP 743 Note that the transit routers Pn use the outer label for packet 744 forwarding and keep the inner label untouched. 746 4.1.3. Link Failure Repair in Facility Mode 748 Before a link failure is detected, PLR encapsulates user packets with 749 a single label Lp1 and forwards the packet to MP. MP also uses a 750 single label encapsulation and forwards the packet to PE (as per 751 Figure 7). 753 After a link failure is detected, the PLR (for example, R1 in Figure 754 7) will encapsulate traffic with two labels: the outer label Lb2 is 755 used for packet forwarding over the backup path, while the inner 756 label Lp2 is used to map traffic to the corresponding primary LSP. 757 MP will pop out outer label Lb2 if needed, swap inner label Lp12 with 758 Lp-pe1, and then forward packets to PE1, as per the example of Figure 759 7. 761 4.1.4. Re-Convergence after Local Repair 763 After a link failure occurs, the network will re-converge. PLR will 764 be notified as soon as a new best path for the primary LSP will be 765 found and activated. Then PLR will tear down the backup LSP, release 766 backup labels and clean up entries in its FIB. 768 4.2. Node Protection in Facility Backup Mode 770 4.2.1. Backup LSP setup in Facility Mode 772 Two methods for node protection in the facility protections scheme 773 have been illustrated in Figures 3 and 4. The method shown in Figure 774 3 uses a P2MP or MP2MP backup LSP to protect a branch node N; the 775 method shown in Figure 4 uses multiple LSPs to protect the node N. 776 The first method is likely to reduce traffic replication on the 777 backup LSP; the second method suffers from traffic overhead because 778 multiple backup sub-LSPs are used. Which method to use is design 779 option. In this document, we will use the method shown in Figure 3 780 to describe the node protection mechanism in the facility protection 781 scheme. 783 Specific procedures are needed for the P2MP or MP2MP tree setup and 784 label allocation. Assume that LSR PE1 joins a primary P2MP tree 785 structure in the example of Figure 3. PE1 sends a RSVP PATH message 786 to MP1 for LSP setup, this PATH message will be relayed to PLR 787 through node N being protected. MP1 calculates the backup route with 788 a constraint to avoid node N; it initiates the backup LSP setup by 789 sending a PATH message over the backup path {MP1-Pn2-Pn1-PLR}. RSVP 790 RESV messages will then be sent in return by PLR to MP1 through the 791 primary {PLR-N-MP1} and the backup {PLR-Pn1-Pn2-MP1} routes 792 respectively. 794 Later on, another LSR PE2 joins the P2MP tree by sending a PATH 795 message to MP2. MP2 will relay the PATH message to node N being 796 protected. Then N becomes a branch node and it is therefore not 797 necessary to send PATH messages to the PLR anymore. MP2 performs the 798 same procedure as MP1 did for the first branch {PE1-MP1-N}, a backup 799 route {MP2-Pn2-Pn1-PLR} will be computed by CSPF, and the node Pn2 800 now becomes a branch node that belongs to the backup P2MP tree. The 801 PATH message that used to be sent by Pn2 towards the PLR is not 802 necessary anymore. RSVP RESV messages will be sent back by the PLR 803 to MP2 through the primary route {PLR-N-MP2} and the backup route 804 {PLR-Pn1-Pn2-MP2} respectively. 806 Whenever additional primary LSP(s) are set up as far as the same node 807 N and PLR are connected, all these primary LSPs can be protected by 808 the single backup LSP. The procedure to setup the primary LSP is the 809 same as what is used for the first primary LSP setup, the key 810 technique is to allocate a unique identifier to a primary LSP and 811 bind it with the backup LSP, as per the mechanism discribed in 812 section 4.2.2. 814 4.2.2. Label Allocation for Node Protection 816 In order to achieve 1:n protection in Facility mode, a unique 817 identifier must be assigned to represent each primary LSP being 818 protected. This identifier should be advertized to all the LSRs in a 819 FRR domain and used for traffic switchover in case of node N failure. 820 There are many ways to assign and use the identifier, and this 821 document gives a sample mechanism based upon ULA (Upstream Label 822 Allocation) to assign a MPLS label and use it as the identifier of a 823 primary LSP. Figure 8 provides an example of label allocation and 824 FIB entry creation for the node protection in Facility mode. 826 Entry in PLR: Entry in N: Entry in MP1: 827 Lp1->Lpu,N Lpu->Lpu,MP1 Lpu->Lp-pe1,PE1 828 FRR:Lpu,Lp1->Lb4,Pn1 Lpu->Lpu,MP2 FRR:Lpu,Lbu->Lp-pe1 830 Lp1 +-------+ Lpu +-------+ Lpu +-------+ Lp-pe1 831 -----|R1(PLR)|--------------| R2(N) |-------|R3(MP1)|------- PE1 832 +-------+ +-------+ +-------+ 833 Sender * Protected \ * Receiver 834 * Node \ * 835 * Backup \* 836 * Tunnel *\ 837 * Lbu * \Lpu 838 * * \ 839 Lb4 * +-------+ Lb5 +-------+ Lbu +-------+ Lp-pe2 840 ****|R4(Pn1)|*******|R5(Pn2)|******|R6(MP2)|-------- PE2 841 +-------+ +-------+ +-------+ 842 Entry in Pn1 843 FRR:Lpu,Lb4->Lb5,Pn1 844 Entry in Pn2: 845 FRR:Lpu,Lb5->Lbu,MP1 846 FRR:Lpu,Lb5->Lbu,MP2 847 Entry in MP2: 848 Lpu->Lp-pe2,PE2 849 FRR:Lpu,Lbu->Lp-pe2,PE2 851 Figure 8: Label Allocation for P2MP Node Protection in Facility Mode 853 In the FRR domain of Figure 8, an identical label Lpu is assigned to 854 these sub-LSPs over the primary LSP: {PLR-N}, {N-MP1} and {N-MP2}. 855 Lpu can be allocated by the branch node N for the primary LSP and 856 used as the identifier of the primary LSP. If there are multiple 857 primary LSPs that cross the same node N and need to be protected by 858 the single backup LSP, there will be multiple Lpu labels assigned for 859 each of the primary LSPs accordingly. In order to guarantee the 860 uniqueness of Lpu in node N and MPs, the LSRs are required to have 861 ULA capability in FRR domain. In addition, an algorithm for ULA 862 assignment and negotiation among the LSRs needs to be further 863 specified by a yet-to-be-published internet draft. 865 During normal operation, PLR encapsulates packets with the label Lpu 866 and forwards them to node N over the primary LSP. The node N as a 867 branch node will replicate traffic to MP1 and MP2 using label Lpu in 868 the example of Figure 8. When a node failure is detected, PLR will 869 redirect traffic to the backup LSP, and the two labels will be used 870 for packet encapsulation over the backup LSP. The inner label is Lpu 871 and uniquely identifies a primary LSP; the outer label is allocated 872 by MP and Pn(s) using DLA (Downstream Label Allocation), which is 873 used for packet forwarding over the backup LSP by means of RSVP-TE 874 mechanism. 876 Detailed label allocation on each LSR is described below. 878 1. Label Allocation and FRR Entry on MP1 and MP2: 880 For the first primary LSP setup, MP1 assigns a downstream label Lpdla 881 for the primary LSP and sends it to the protected node N via a PATH 882 message. Node N discards Lpdla and uses ULA to assign a new label 883 Lpu that will be used as a downstream label for N to send packets to 884 MP1. 886 Node N sends the label Lpu to MP1 via a RESV message; MP1 replaces 887 its downstream assigned label Lpdla with Lpu. If Lpu has been used by 888 another LSP on the LSR, MP1 will request node N to assign another Lpu 889 by a RSVP notify message. In case of conflict, an ULA negotiation 890 procedure has to be executed (this procedure is TBD). 892 MP1 also assigns a downstream label Lbdla for the backup LSP and 893 sends it to Pn2 via a PATH message over the backup route {MP1-Pn2- 894 Pn1-PLR in Figure 8}. Pn2 is a branch node and will therefore 895 execute the same procedure as the branch node N on the primary LSP. 896 Pn2 discards label Lbdla received from the PATH message, assigns a 897 new label Lbu and sends it to MP1 via a RESV message. 899 Once a RESV message is originated by PLR and sent through the backup 900 route, MP1 will get an inner label Lpu that represents the primary 901 LSP in this example. MP1 adds a FRR entry with both inner and outer 902 label in its FIB. MP1 FIB will have two forwarding entries for the 903 LSP being protected in Facility mode: 905 Lpu->Lp-pe1, PE1 907 FRR: Lpu, Lbu->Lp-pe2, PE2 909 With the same process, MP2 will have two forwarding entries for the 910 LSP being protected: 912 Lpu->Lp-pe2, PE2 914 FRR: Lpu, Lbu->Lp-pe2, PE2 916 2. Label Allocation and FRR Entry on Pn2 and Pn1: 918 As mentioned in the last paragraph, when Pn2 (transit branch node) 919 receives PATH message from MP1 and MP2 respectively, it will allocate 920 label Lbu and sends it to each MP. Pn2 will have two forwarding 921 entries for the LSP being protected: 923 FRR: Lpu, Lb5->Lbu, MP1 925 FRR: Lpu, Lb5->Lbu, MP2 927 Pn1 is a transit node and has only one FRR entry for the LSP being 928 protected: 930 FRR: Lpu, Lb4->Lb5, Pn2 932 3. Label Allocation and FRR Entry on PLR: 934 PLR receives a PATH message from node N that carries a downstream 935 label Lpu and a PATH message from Pn1 that carries a downstream label 936 Lb5. PLR uses Lpu as an inner label for the primary LSP and sends it 937 towards MPs through Pn1 by means of RESV message. PLR will maintain 938 two entries in its FIB for a given protected LSP: 940 Lp1->Lpu, N 942 FRR: Lpu, Lp1->Lb1, Pn1 944 For every add-in primary LSP being protected by the same backup LSP, 945 PLR will assign an inner label and send it to LSRs across the backup 946 LSP so that each LSR can add the corresponding FRR entry in its FIB 947 and use this entry to forward traffic over the backup LSP. 949 4.2.3. Node Failure Repair and Packet Encapsulation 951 Once protected node N fails and the failure is detected by PLR, it 952 will initiate a switchover by redirecting traffic to the backup LSP. 953 Packet encapsulation in each LSR over the backup LSP will be done 954 based on the FRR entries of its FIB. For example (Figure 8), a 955 packet that arrives at PLR and which is supposed to be forwarded to 956 node N by using entry 'Lp1->Lpu, N', will be redirected to Pn1 based 957 on entry 'FRR: Lpu,Lp1->Lb4, Pn1'. PLR encapsulates the packet with 958 Lpu as inner label, Lb4 as outer label and forwards it to Pn1. Pn1 959 will swap outer label for packet forwarding and keep inner label 960 unchanged. 962 Once the packet reaches MP1, MP1 will pop out the outer label, swap 963 the inner label with outgoing label Lp-pe1 and forward the packet to 964 NHOP PE1 with a single label Lp-pe1, the packet de-capsulation/ 965 encapsulation is based on the 'FRR: Lpu, Lbu->Lp-pe1, PE1' entry. 966 Once traffic reaches MP1, it is then merged with the primary path. 967 The same procedure is applicable to receiver LSR MP2. 969 4.2.4. Re-convergence after Local Repair 971 Routers that do not belong to the FRR domain are not impacted by the 972 link failure and local repair procedures. However, the network will 973 eventually re-converge and a new best path to reach the root of the 974 RD P2MP tree structure will be computed by PE1 and PE2 (Figure 8). 975 PLR will be notified as soon as the new primary path is determined. 976 PLR will send notification message to Pn and MP sp that they tear 977 down the detour LSP and withdraw backup labels. There is no 978 difference between facility and detour methods in terms of re- 979 convergence process. 981 5. IANA Considerations 983 TBD. 985 6. Manageability Considerations 987 TBD. 989 7. Security Considerations 991 TBD. 993 8. Acknowledgements 995 We would like to thank Quintin Zhao, Lin Han, Emily Chen, and Robert 996 Tao for discussions and comments. 998 9. References 1000 9.1. Normative References 1002 [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te] 1003 Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven 1004 Multicast Traffic Engineered Label Switched Paths", 1005 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 (work 1006 in progress), March 2012. 1008 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1009 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1010 May 2005. 1012 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1013 "Extensions to Resource Reservation Protocol - Traffic 1014 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1015 Switched Paths (LSPs)", RFC 4875, May 2007. 1017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1021 Label Switching Architecture", RFC 3031, January 2001. 1023 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1024 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1025 Tunnels", RFC 3209, December 2001. 1027 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1028 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1029 Functional Specification", RFC 2205, September 1997. 1031 9.2. Informative References 1033 [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label 1034 Switching (MPLS) Working Group decision on MPLS signaling 1035 protocols", RFC 3468, February 2003. 1037 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1038 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1039 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1041 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 1042 Differentiated Services-aware MPLS Traffic Engineering", 1043 RFC 3564, July 2003. 1045 Authors' Addresses 1047 Katherine Zhao 1048 Huawei Technologies 1049 2330 Central Expressway 1050 Santa Clara, CA 95050 1051 USA 1053 Email: katherine.zhao@huawei.com 1054 Renwei Li 1055 Huawei Technologies 1056 2330 Central Expressway 1057 Santa Clara, CA 95050 1058 USA 1060 Email: renwei.li@huawei.com 1062 Christian Jacquenet 1063 France Telecom Orange 1064 4 rue du Clos Courtel 1065 35512 Cession Sevigne, 1066 France 1068 Email: christian.jacquenet@orange.com