idnits 2.17.1 draft-zhao-mpls-mldp-protections-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (July 15, 2013) is 3939 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: 'RFC5286' is mentioned on line 164, but not defined == Unused Reference: 'RFC3031' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC6348' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'I-D.wijnands-mpls-mldp-node-protection' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'I-D.enyedi-rtgwg-mrt-frr-algorithm' is defined on line 798, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 6348 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-ldp-multi-topology-08 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-03 == Outdated reference: A later version (-04) exists of draft-enyedi-rtgwg-mrt-frr-algorithm-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Quintin Zhao 3 Internet-Draft Tao Chou 4 Intended status: Standards Track Huawei Technology 5 Expires: January 16, 2014 Boris Zhang 6 Telus Communications 7 Emily Chen 8 July 15, 2013 10 P2MP Based mLDP Node Protection Mechanisms for mLDP LSP 11 draft-zhao-mpls-mldp-protections-05.txt 13 Abstract 15 This document specifies the procedures and protocol extensions for 16 the protection of mLDP nodes within Multi-Protocol Label Switching 17 (MPLS) networks using P2MP backup LSPs. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 16, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 5 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Example of mLDP Node Protection . . . . . . . . . . . . . . . 6 71 6. Signaling Procedures for P2MP Based Node Protection . . . . . 7 72 6.1. The Computation of the Backup Path . . . . . . . . . . . . 8 73 6.2. The Procedures for MP, PTN, STN and PLR . . . . . . . . . 8 74 6.2.1. MP's Procedures . . . . . . . . . . . . . . . . . . . 8 75 6.2.2. PTN's Procedures . . . . . . . . . . . . . . . . . . . 9 76 6.2.3. STN's Procedures . . . . . . . . . . . . . . . . . . . 9 77 6.2.4. PLR's Procedures . . . . . . . . . . . . . . . . . . . 10 78 6.3. PLR's Switching Over Considerations . . . . . . . . . . . 10 79 6.4. The Procedures after the Reconvergence . . . . . . . . . . 11 80 6.5. Considerations for MP2MP LSP Node Protection . . . . . . . 11 81 6.5.1. MP's Procedure . . . . . . . . . . . . . . . . . . . . 12 82 6.5.2. PLR's Procedure . . . . . . . . . . . . . . . . . . . 13 83 6.5.3. Switch over Procedure . . . . . . . . . . . . . . . . 13 84 7. Protocol Extensions for mLDP Based Node Protection . . . . . . 13 85 7.1. mLDP Based MP Protection Capability Parameter TLV . . . . 13 86 7.2. mLDP Based MP Node Protection Status Elements . . . . . . 14 87 7.3. mLDP Backup FEC Element Encoding . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 To meet user demand, operators and service providers continue to 99 deploy multicast applications using the Multicast Label Distribution 100 Protocol (Multicast LDP - mLDP) across MPLS networks. For real-time 101 applications, such as stock trading, on-line games, and multimedia 102 teleconference, traditional node protection mechanisms, such as 103 relying on IGP re-convergence to build the new Label Switched Path 104 (LSP), fail to achieve a protection switching time less than that 105 which is required to minimize the interruption of applications. 107 Instead of relying on IGP re-convergence to build the new LSP for 108 failure protection, pre-computing and establishing a backup path 109 before the failure delivers a better solution, allowing a more rapid 110 switch over to the backup path when the protected node fails . 112 Providing a pre-computed backup path requires solutions to two 113 complex problems: 115 o how to compute a completely disjoint backup path for each node in 116 a multicast tree, and 118 o how to signal and setup the computed backup path. 120 For a primary Point-to-Multipoint (P2MP) Label Switched Path (LSP) 121 created by LDP, there are several methods that could be chosen for 122 creating a backup path: 124 o The use of an RSVP-TE (Resource Reservation Protocol - RSVP - 125 Traffic Engineering) point-to-point (P2P) tunnel as a logical out- 126 going interface, which consequently utilizes the mature high- 127 availability technology of RSVP-TE. 129 o The use of an alternative LDP P2P LSP as a packet encapsulation, 130 which avoids the complex configuration of P2P RSVP-TE. 132 o Creating a P2MP backup LSP using a loop-free alternative route 133 provided by the IGP. 135 o Using multi-topology technology, wherein the backup topology can 136 be either statically configured or dynamically computed and 137 signaled using IP/LDP Fast-Reroute mechanisms 138 [I-D.ietf-rtgwg-mrt-frr-architecture]. 140 When the backup path is available, there are two methods for packet 141 forwarding and protection switch over: 143 Method 1 The traffic sender transmits the stream on both the primary 144 and backup path always. Once the local traffic receiver 145 detects a failure, the switch over will be relatively fast. 146 However, the disadvantage of this method is that it 147 consumes bandwidth because duplicate traffic will be sent 148 on the primary and backup paths. 150 Method 2 The traffic sender transmits only on the primary path 151 before the failure. Traffic is only forwarded to the MP 152 through the backup path when failure is detected. Although 153 bandwidth resource usage is minimized, cooperation is 154 required to provide adequate switching times and to 155 minimize higher-layer and application impact. 157 Ideally, if the switching time performance can be equal to or better 158 than that of Method 1, it is reasonable to choose Method 2 to avoid 159 bandwidth wastage. This consideration has been taken into account in 160 making the recommendations in this document. 162 Note that for the computation and configuration of the primary 163 topology, the algorithm used could be the Loop-free Alternate (LFA) 164 based [RFC5286], Maximally Redundant Tree (MRT) based 165 [I-D.ietf-rtgwg-mrt-frr-architecture] , or based on any other 166 algorithms or methods available including static and offline tools; 167 any such method can be used in conjunction with the mechanisms 168 described in this document , which is limited to determining the 169 nodes that should be spanned by the backup paths for the protection 170 of a node in the primary multicast tree. In addition, the mechanism 171 for detecting the node failure that will result in switchover to the 172 backup pathis also outside the scope of this document. 174 Compared to a P2P LSP based solution, this P2MP LSP based solution 175 not only uses mLDP mechanisms for both the primary path and backup 176 paths, but also avoids unnecessary packet duplication where multiple 177 P2P backup paths for the same node pass through.common nodes. 179 The remainder of this document specifies the signaling procedures and 180 protocol extensions for the P2MP LSP based mLDP node protection 181 solution which was briefly introduced above. 183 2. Terminology 185 This document uses terminology discussed in [RFC6388] and 186 [I-D.ietf-mpls-ldp-multi-topology]. Additional key terms and 187 terminology are listed here: 189 o Point of Local Repair (PLR): The node upon which traffic is 190 redirected onto the preset backup path. 192 o Merge Point(MP):The node(s) where the primary path and the backup 193 path rejoin and merge. Since the backup path is a multicast tree 194 there will generally be more than one merge point. 196 o Primary Transit Node (PTN): The node between the PLR and MP on the 197 primary path. 199 o Secondary Transit Node (STN): A node on the backup path between 200 the PLR and MP. There might be more than one STN on the backup 201 path between the PLR and MP nodes. 203 2.1. Requirement Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 3. Requirements 211 A number of requirements have been identified that will allow the 212 optimal set of mechanisms to be developed. These are: 214 o Computation of a possible disjoint (link and node) backup path 215 within the multicast tree. In the case that there is no backup 216 path available, there will be no backup path setup using the 217 solution described in this draft will not be applicable. 219 o Minimize the PLR's switch over time from the primary path to the 220 backup path when failure happens; 222 o Minimization of operation and maintenance cost; 224 o The solution should work without other protocol extensions other 225 than the protocol extensions specified in this draft. 227 o The solution should work for all network topologies deployed in 228 the users' network as long as there is a alternative backup path 229 available. 231 4. Scope 233 This document specifies the signaling procedures and protocol 234 extensions for the P2MP LSP based mLDP transit node protection 235 solution. 237 The method used for detecting the node failure is out the scope of 238 this document. 240 Protection of the leaf and root nodes of the multicast tree is also 241 out of scope of this document. 243 The protection mechanism for the case of multiple failures happening 244 at the same time is out of scope of this document. 246 In the case that there is no backup path computed from the backup 247 path computation algorithms, then there will be no backup path setup 248 to protect the transit node failures. 250 5. Example of mLDP Node Protection 252 By using the procedures introduced in section 5 plus the available 253 backup path computation algorithms, MP can initiate the building of 254 the backup mLDP LSP starting from the PLR, avoiding the PTN and 255 reaching the MPs. In the case of a large number of MPs, the solution 256 introduced in this draft can avoid unnecessary packet duplication 257 between PLR and the merge points. If a backup multicast tree is 258 built rather than individual LSPs from the PLR to each MP then common 259 transit points on the backup tree that would otherwise have multiple 260 unicast LSPs passing through them will be saved some bandwidth on 261 their incoming links. 263 | 264 V 265 +------------+ Point of Local Repair/ 266 | R1 | Switch over Point 267 +------------+ (Upstream LSR) 268 / \ 269 10/ \20 (cost) 270 / \ 271 V V 272 Primary +----------+ +-----------+ Secondary 273 Transit Node | R2 | | R3 |Transit Node 274 (PTN) +----------+ +-----------+ (STN) 275 | \ / | 276 10| 10\ /20 |20 277 | \ / | 278 | \ | 279 | / \ | 280 V V V V 281 +-----------+ +-----------+ Merge Point 282 | R4 | | R5 | (Downstream LSR) 283 +-----------+ +-----------+ 284 | | 285 V V 287 Figure 1: mLDP Local Protection using mLDP LSP Example 289 In Figure 1, R2 is on the preferential signalling/data path from R4/5 290 to R1, and the secondary signalling/data path from R4/R5 to R1 is 291 through R3. In this case , the mLDP LSP will be established 292 according to the IGP preferential path as R1--R2--R4/R5. As an 293 example, this figure takes R2 as the PTN though the PTN can be any 294 Transit Node of the mLDP LSP. (We assume that all the nodes in 295 Figure 1 support this mLDP based node protection method.) 297 In this scenario, if R2 is protected by two P2P LSPs as R1--R3--R4 298 and R1--R3--R5 , the traffic will be duplicated on the link between 299 R1 and R3 when the primary traffic is switched into the secondary 300 path, and R3 will receive two copies of the multicast packages. But, 301 if R2 is protected by a mLDP LSP instead, R3 will only receive one 302 copy of the stream, and thus there will be no packet duplication on 303 the link between R1 and R3 when the failure happens. 305 6. Signaling Procedures for P2MP Based Node Protection 307 This section introduces the signaling procedures of P2MP LSP's node 308 protection using P2MP-based backup LSP for a Protected Node N. 310 6.1. The Computation of the Backup Path 312 Obviously, the backup path can not go through the protected node N. 313 This section discusses how to choose the backup upstream LSR to avoid 314 N. 316 Firstly, find the candidate upstream LSRs as below: 318 o MPs should preferentially choose the upstream LSRs on the shortest 319 path as candidates, except node N. If no other upstream LSRs are 320 on the shortest path, MPs should choose the next-hop on N's detour 321 path as a candidate. The detour path can be an IGP-FRR path or 322 other topology-based disjoint paths. The IGP-FRR path can be 323 provided by LFA, U-Turn [[anchor9: EBD: Needs references.]], etc. 324 The disjoint path can be provided by MT, MRT, etc. Choosing the 325 candidates is a local decision and can be determined by 326 configuration. 328 o The STN node MUST be chosen from the IGP next-hops on the shortest 329 path toward the PLR within the topology specified in the FRR mLDP 330 FEC element by the MT-ID (Multi-Topology Identifier) [[anchor10: 331 EBD: Multi-Topology IDs need some explanation - it appears here 332 without any introduction and I (for one) have no idea why there 333 might be several and what they might cover.]] field. The 334 candidate upstream LSRs MUST NOT include the PTN. 336 Thus, each node can choose one upstream node from the candidate 337 upstream LSRs as its backup upstream LSR via the algorithm described 338 in Section 2.4.1.1 of [RFC6388]. 340 6.2. The Procedures for MP, PTN, STN and PLR 342 The procedures for P2MP Based Node Protection described in this 343 document assumes the PLR is capable of node failure detection. In 344 procedures described here covers the scenario where there is only one 345 PTN between the PLR and MP. The cases where there are more than one 346 PTNs between PLR and MP is out scope of this document. 348 We assume all the involved nodes have advertised their corresponding 349 protection capabilities. And the following section specifies the 350 signaling procedures of P2MP Based Node Protection. 352 6.2.1. MP's Procedures 354 Each non-Ingress LSR determines its own upstream LSR and sends out a 355 label mapping message, in accordance with the procedures documented 356 in [RFC6388] without any additional extension. And its upstream LSR 357 will propagate a new label mapping message to its upstream LSR. In 358 such cases, the non-Ingress LSR is the MP node (as R4, R5 in 359 Figure 1), MP's upstream LSR is the protected node (as R2 in Figure 360 1), and the protected node's upstream node is PLR (as R1 in 361 Figure 1). 363 When one MP (as R4/R5 nodes in Figure 1) receives the Notification 364 from the PTN after the MP has sent the label mapping message to the 365 PTN, based on the PLR and PTN info, the MP individually determines 366 its secondary path toward the PLR according to the IGP routes. The 367 algorithms for choosing/computing the backup path can be LFA, MRT or 368 others. After the backup upstream LSR is chosen, MP will send out a 369 Label mapping message with the new FRR FEC (see section 7.3 for 370 details), which includes the mLDP backup tree's key and the MT-ID if the backup path is not in 372 the default topology. Note that the label assigned for the primary 373 path and the secondary path MUST be different to avoid having the MP 374 feed primary traffic to its secondary path's downstream LSRs. In 375 addition, the original-mLDP-FEC of the backup tree key is encoded in 376 a special opaque value as introduced in section 7.3 378 6.2.2. PTN's Procedures 380 After the Protected Node (as R2 in Figure 1 ) determines its upstream 381 LSR (as R1 in Figure 1), it will send the information (PLR's 382 identify, mLDP FEC) via Notification messages to all its downstream 383 nodes(MPs) immediately. If other LSRs become its downstream nodes 384 later, it will send such announcements to its new MP(s). 386 6.2.3. STN's Procedures 388 When one node receives such aforementioned label mapping messages 389 which inlcudes the mLDP FRR type of FECs, if it is not the PLR, it 390 can consider itself a STN and will choose its backup upstream node 391 toward PLR on the corresponding topology's shortest IGP path. To 392 avoid the backup LSP going through the PTN, additional path selection 393 rule(s) should be applied. A simple method is for the transit nodes 394 to not choose the specified PTN as its upstream LSR for the backup 395 LSP. Other methods, such as the not-via policy, are under study and 396 will be added in the future. To make the primary and backup 397 topologies rooted from PLR satisfy the 'maximum disjointed' 398 requirement, they can either be configured through static 399 configurations or be signaled dynamically through other mechanisms 400 such as MRT. 402 When a STN on the backup mLSP fails before the backup LSP is put into 403 use, this will trigger a recalculation of the backup LSP(s). 405 6.2.4. PLR's Procedures 407 When PLR(R1) receives the FRR label mapping message, it can identify 408 that it is the PLR by the mLDP backup FEC elements. Thus, it will 409 decode the special opaque value (which contains the primary mLDP FEC 410 element, introduced in section 7.3) and generate the backup 411 forwarding entry for the specific LSP, which is identified by the 412 root address and opaque value in the special opaque value. It will 413 also bind the backup forwarding state to the specific primary entry, 414 which is indicated by the Protected Node address in the message. 415 Note that there might be more than one backup forwarding entry for a 416 specific protected node. 418 When failure is detected by PLR, it will switch the traffic to the 419 backup paths. MP will also locally choose which traffic to receive 420 and merge this traffic back to the primary LSP. The switch over 421 manner on PLR is specified in detail in the later section of this 422 document. 424 6.3. PLR's Switching Over Considerations 426 This section provides two modes for Switch over when failure occurs 427 using the Protection Method 2 described in section 1 where there is 428 only one copy of the traffic sent out from the PLR both before the 429 PTN fails and after the PTN fails. 431 Depending on the capability of the MP node, MP node can set Node 432 Failure (detection required) Flag in two modes. 434 Mode 1: The MP sets the Node Failure Required Flag (in the P2MP 435 Based MP Node Protection Status Element) as 'Y'. This 436 means that the MP requires the PLR to have the capability 437 of detecting the PTN's failure. In this case, if the PLR 438 doesn't have the node failure detection capability, then 439 the backup path will not be setup and no protection is 440 setup for the PTN. If the PLR has the capability of 441 detecting the PTN's failure, the backup path can be setup 442 correctly and only after PLR detects that PTN's failure, 443 there will be backup traffic forwarded through the backup 444 path to the MP(s). 446 Mode 2: The MP sets the Node Failure Required Flag, in the P2MP 447 Based MP Node Protection Status Element, set as 'N'. This 448 means that the MP has the capability of dropping duplicated 449 multicast packages and doesn't require the PLR to have the 450 capability of detecting the PTN's failure. In this case, 451 PLR switches the traffic to the backup path once it detects 452 the link failure between PLR and PTN no matter it is caused 453 by the PTN's failure or not. In the case that it is a link 454 failure case, and the link protection is also deployed, 455 then the MP will receive two copies of the traffic, one 456 copy from the normal link protection path, and one copy 457 from the node protection path through STN. MP must take 458 the responsibility to drop one of the two duplicate 459 traffics when link fails between PLR and PTN. 461 6.4. The Procedures after the Reconvergence 463 When Merge Point(s) see the next hop to Root changed, it/they will 464 advertise the new mapping message(s), and the traffic will re- 465 converge to the new primary path. MP will then withdraw the backup 466 label after the re-convergence. STN will delete the specified backup 467 LSP just as in the procedure of deleting normal P2MP LSP. And the 468 entire backup P2MP LSP will be deleted when the node MP leaves the 469 backup P2MP LSP. 471 6.5. Considerations for MP2MP LSP Node Protection 473 When a MP2MP LSP node needs to be protected, it can be treated with 474 the same P2MP LSP node protection procedures for each forwarding 475 direction. 477 | 478 V 479 +------------+ Point of Local Repair/ 480 | R1 | Switch over Point 481 +------------+ (Upstream LSR for Downstream flow) 482 / \ 483 10/ \20 (cost) 484 / \ 485 V V 486 Primary +----------+ +-----------+ Secondary 487 Transit Node | R2 | | R3 |Transit Node 488 (PTN) +----------+ +-----------+ (STN) 489 | \ / | 490 10| 10\ /20 |20 491 | \ / | 492 | \ | 493 | / \ | 494 V V V V 495 +-----------+ +-----------+ Merge Point 496 | R4 | | R5 | (Downstream LSR 497 +-----------+ +-----------+ for Downstream flow) 498 | | 499 V V 501 Figure 2: MP2MP Example (R1 is the PLR) 503 ^ 504 | 505 +------------+ Merge Point 506 | R1 | (the downstream LSR for the upstream flow) 507 +------------+ 508 ^ ^ 509 10/ \20 (cost) 510 / \ 511 Primary +----------+ +-----------+ Secondary 512 Transit Node | R2 | | R3 |Transit Node 513 (PTN) +----------+ +-----------+ (STN) 514 ^ ^ ^ ^ 515 | \ / | 516 10| 10\ /20 |20 517 | \ / | 518 | \ | 519 | / \ | 520 +-----------+ +-----------+ 521 PLR for | R4 | | R5 | 522 the upstream flow +-----------+ +-----------+ 523 ^ ^ 524 | | 526 Figure 3: MP2MP Example (R4 is the PLR) 528 For each direction of MP2MP traffic flows (downstream in Figure 2 or 529 upstream in Figure 3, the MP, PLR and MP nodes use the P2MP node 530 protection procedures with the following additional considerations: 532 6.5.1. MP's Procedure 534 MP sends a backup label mapping message containing MP2MP downstream 535 FRR FEC elements. When PLR receives a backup label mapping message 536 with a MP2MP downstream flag, it sends the backup label mapping 537 message with mp2mp upstream FRR FEC elements to Pn and then finally 538 to MPs. This procedure just follows the normal MP2MP LSP procedure. 540 For the forwarding entries, MP node binds its primary MP2MP 541 downstream NHLFE entry to backup MP2MP downstream ILM entry and binds 542 its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM 543 entry. 545 For the forwarding entries, MP node binds its primary MP2MP 546 downstream NHLFE entry to backup MP2MP downstream ILM entry and binds 547 its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM 548 entry. 550 6.5.2. PLR's Procedure 552 PLR node binds its backup MP2MP downstream NHLFE entry to primary 553 MP2MP downstream ILM entry, also binds its primary MP2MP upstream 554 NHLFE entry to backup MP2MP upstream ILM entry. 556 6.5.3. Switch over Procedure 558 When the protected node fails, both the affected downstream and 559 upstream nodes function as PLR and switch the downstream flow and 560 upstream flow to their respective backup paths. 562 7. Protocol Extensions for mLDP Based Node Protection 564 Numerical fields in the formats defined in this section are encoded 565 as unsigned integers in network octet and bit order. 567 7.1. mLDP Based MP Protection Capability Parameter TLV 569 A new Capability Parameter TLV is defined as mLDP Based MP Protection 570 Capability for node protection. The format is illustrated as the 571 following: 573 0 1 2 3 574 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |1|0| mLDP Based MP Prot.(IANA) | Length (= 2) | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |S| Reserved | 579 +-+-+-+-+-+-+-+-+ 581 Figure 4: mLDP Based MP Protection Capability 583 mLDP Based MP Prot.: TBA1 (to be assigned by IANA) 585 S: As specified in [RFC5561] 587 This is an unidirectional capability announcement. 589 An LSR, which supports the mLDP based protection procedures, should 590 advertise mLDP Based MP Protection Capability TLV to its LDP 591 speakers. Without receiving this capability announcement, an LSR 592 MUST NOT send any messages including the mLDP Based MP Node 593 Protection Status Element and mLDP Backup FEC Element to its peer. 595 7.2. mLDP Based MP Node Protection Status Elements 597 A new type of LDP MP Status Value Element is introduced for notifying 598 upstream LSR information. It is encoded as follows: 600 0 1 2 3 601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |mLDP FRR Type | Length | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 ~ PLR Node Address ~ 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 5: FRR LDP MP Status Value Element 610 mLDP FRR Type: Type TBA2 (to be assigned by IANA) 612 Length: If the Address Family is IPv4, the Length MUST be 613 5; 614 if the Address Family is IPv6, the Length MUST be 615 17. 617 PLR Node Address: The host address of the PLR Node. 619 7.3. mLDP Backup FEC Element Encoding 621 A new type of mLDP backup FEC Element is introduced, it is used for 622 notifying upstream LSR information. It is encoded as follows: 624 0 1 2 3 625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 |mLDP FEC T-FRR | Address Family | Address Length| 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 ~ PLR Node Address ~ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |N| Status code | FEC-Type | MT-ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Protected Node Address | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Opaque Length | Opaque Value ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 637 ~ ~ 638 | | 639 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 6: mLDP Backup FEC Element 645 mLDP FEC Type-FRR: Type TBA3 (to be assigned by IANA) 647 Address Length: If the Address Family is IPv4, the Address 648 Length MUST be 9; 649 if the Address Family is IPv6, the Address 650 Length MUST be 33. 652 PLR Node Address: The host address of the PLR Node. 654 Protected Node Address: The host address of the Protected Node. 656 Status code: 1 = Primary path for traffic forwarding 657 2 = Secondary path for traffic forwarding 659 FEC-Type: 6 = P2MP FEC type 660 7 = MP2MP-up FEC type 661 8 = MP2MP-down FEC type 663 MT-ID: Multi-Topology ID. Unsigned 16 bit integer. 665 Opaque Length: The length of the opaque value, in octets. 667 Opaque Value: One or more MP opaque value elements, which 668 is the same definition in [RFC6388]. For the 669 FRR mLDP FEC element, the Opaque Value MUST 670 be encoded as the Recursive Opaque Value, 671 which is defined in [RFC6512]. The value 672 fields of the Recursive Opaque Value contain 673 the original primary path's mLDP FEC element. 675 The encoding for the Recursive Opaque Value, as defined in [RFC6512], 676 is shown in Figure 7. 678 0 1 2 3 679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type = 7 | Length | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 683 ~ ~ 684 | P2MP or MP2MP FEC Element | 685 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Figure 7: Recursive Opaque Value 691 The Opaque Value is encoded by the MP node and decoded by PLR. Any 692 other nodes on the path MUST NOT interpret the opaque value. 694 8. IANA Considerations 696 The document introduces following new protocol elements that require 697 IANA consideration and assignments: 699 o Code Points for "MP Protection Capability" TLV from the "LDP TLV 700 Type Name Space" registry within the LDP Parameters 702 Registry: 703 Range/Value Description 704 -------------- ------------------------------ 705 TBA1 MP Protection Capability (defined in section 7.1) 707 Figure 8: New Code Points for MP Protection Capability Extensions 709 o Code Points for mLDP Based MP Node Protection Status Elements from 710 the "LDP TLV Type Name Space" registry within the LDP Parameters 711 Registry: 712 Range/Value Description 713 -------------- ------------------------------ 714 TBA2 Based MP Node Protection Status (defined in section 7.2) 716 Figure 9: Based MP Node Protectiin on Status 718 o Code Points for mLDP FRR Type FEC from the the LDP registry 719 "Forwarding Equivalence Class (FEC) Type Name Space". within the 720 LDP Parameters 722 Registry: 723 Range/Value Description 724 -------------- ------------------------------ 725 TBA3 mLDP FRR Type FEC (defined in section 7.3) 727 Figure 10: mLDP FRR Type FEC 729 9. Security Considerations 731 The same security considerations apply as for the base LDP 732 specification, as described in [RFC5036]. The protocol extensions 733 specified in this document do not provide any authorization mechanism 734 for controlling the set of LSRs that may attempt to join a mLDP 735 protection session. If such authorization is desirable, additional 736 mechanisms outside the scope of this document are needed. 738 Note that authorization policies should be implemented and/or 739 configured at all the nodes involved. 741 10. Acknowledgements 743 We would like to thank Nicolai Leymann and Daniel King for their 744 valuable suggestions to this draft. We also would like to thank 745 Robin Li, Lujun Wan, Kenji fujihira, Martin Vigoureux, Yaacov 746 Weingarten, Eric Osborne and Elwyn Davis for their detailed comments 747 and suggestions to the draft. 749 11. References 750 11.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 756 Label Switching Architecture", RFC 3031, January 2001. 758 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 759 Specification", RFC 5036, October 2007. 761 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 762 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 764 [RFC6348] Le Roux, JL. and T. Morin, "Requirements for Point-to- 765 Multipoint Extensions to the Label Distribution Protocol", 766 RFC 6348, September 2011. 768 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 769 "Label Distribution Protocol Extensions for Point-to- 770 Multipoint and Multipoint-to-Multipoint Label Switched 771 Paths", RFC 6388, November 2011. 773 [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, 774 "Using Multipoint LDP When the Backbone Has No Route to 775 the Root", RFC 6512, February 2012. 777 11.2. Informative References 779 [I-D.ietf-mpls-ldp-multi-topology] 780 Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP 781 Extensions for Multi Topology Routing", 782 draft-ietf-mpls-ldp-multi-topology-08 (work in progress), 783 May 2013. 785 [I-D.wijnands-mpls-mldp-node-protection] 786 Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, 787 A., and Q. Zhao, "mLDP Node Protection", 788 draft-wijnands-mpls-mldp-node-protection-04 (work in 789 progress), June 2013. 791 [I-D.ietf-rtgwg-mrt-frr-architecture] 792 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 793 J., Konstantynowicz, M., and R. White, "An Architecture 794 for IP/LDP Fast-Reroute Using Maximally Redundant Trees", 795 draft-ietf-rtgwg-mrt-frr-architecture-03 (work in 796 progress), July 2013. 798 [I-D.enyedi-rtgwg-mrt-frr-algorithm] 799 Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, 800 "Algorithms for computing Maximally Redundant Trees for 801 IP/LDP Fast- Reroute", 802 draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in 803 progress), October 2012. 805 Authors' Addresses 807 Quintin Zhao 808 Huawei Technology 809 125 Nagog Technology Park 810 Acton, MA 01719 811 US 813 Email: quintin.zhao@huawei.com 815 Tao Chou 816 Huawei Technology 817 156 Beiqing Rd 818 Haidian District, Beijing 100095 819 China 821 Email: tao.chou@huawei.com 823 Boris Zhang 824 Telus Communications 825 200 Consilium Pl Floor 15 826 Toronto, ON M1H 3J3 827 Canada 829 Phone: 830 Email: Boris.Zhang@telus.com 832 Emily Chen 833 2717 Seville Blvd, Apt 1205 834 Clearwater, FL 33764 835 US 837 Email: emily.chen220@gmail.com