idnits 2.17.1 draft-kini-mpls-frr-ldp-03.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISO10589' is mentioned on line 110, but not defined ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-ipfrr-notvia-addresses-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kini, Ed. 3 Internet-Draft S. Narayanan 4 Intended status: Informational Ericsson 5 Expires: January 17, 2013 S. Litkowski 6 Orange 7 July 16, 2012 9 Fast Re-route using extensions to LDP 10 draft-kini-mpls-frr-ldp-03 12 Abstract 14 Label Distribution Protocol (LDP) is widely deployed to signal Label 15 Switched Paths (LSPs) due to its simple operational model. Since LDP 16 establishes LSPs along IGP routed paths, its failure recovery is 17 gated by the interior gateway protocol's (IGP's) re-convergence. 18 Though some mechanisms exist to do Fast Re-route (FRR) of LDP LSPs, 19 they suffer from significant complexity or lack of full coverage or 20 both. This document describes a method to perform FRR of LDP LSPs 21 that retains the simple operational model of LDP. The goal is to 22 provide 100% coverage for all failure scenarios including Shared Risk 23 Link Group (SRLG) failure with recovery characteristics similar to 24 the methods in Resource Reservation Protocol - Traffic Engineering 25 FRR (RSVP-TE-FRR). 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 17, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. LDP local repair technique . . . . . . . . . . . . . . . . . . 4 67 6. Protocol procedures and extensions . . . . . . . . . . . . . . 9 68 6.1. Failure Entity TLV . . . . . . . . . . . . . . . . . . . . 10 69 6.1.1. IP address . . . . . . . . . . . . . . . . . . . . . . 11 70 6.1.2. SRLG . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.2. Backup Path Vector TLV . . . . . . . . . . . . . . . . . . 11 72 6.3. Capability Advertisement TLVs . . . . . . . . . . . . . . 13 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Label Distribution Protocol (LDP) [RFC5036] is a widely deployed 84 signaling protocol in MPLS networks due to its simple operational 85 model. It signals LSPs along interior gateway protocol (IGP) routed 86 paths. In case of a failure in the network, the recovery of traffic 87 on LDP LSPs is gated by reconvergence of IGPs. IGPs have relatively 88 slower convergence due to link-state database flooding, route re- 89 computation, route-download etc. An alternative is to use IP Fast 90 Re-route (IPFRR) techniques to provide FRR for LDP LSPs. This 91 includes techniques such as LFA [RFC5286] that provides an alternate 92 path that can also be used by LDP LSPs. However LFA does not provide 93 full coverage. Other IPFRR methods such as NOT-VIA 94 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] involve significant 95 complexity. Another approach to protect LDP LSPs is to transport 96 them over RSVP-TE LSPs that are protected using RSVP-TE-FRR 97 [RFC4090]. This can indirectly protect LDP LSPs. However this has 98 the complexity of deploying an additional protocol RSVP-TE [RFC3209] 99 and also the network planning to setup the RSVP-TE LSPs that are 100 required to adequately protect the network. 102 In this document we describe a local-repair mechanism that can 103 provide fast-reroute for LDP LSPs. This mechanism retains the 104 simplicity of LDPs operational model and does not require deployment 105 of additional signaling protocols. It also provides full coverage in 106 all failure scenarios, including shared risk link group (SRLG) 107 failures. The mechanism in this document is henceforth referred to 108 as FRR-LDP. It aims to provide traffic recovery times similar to 109 that provided by RSVP-TE-FRR [RFC4090]. This mechanism works for a 110 link-state IGP such as OSPF [RFC2328] or IS-IS[ISO10589]. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Scope 120 This draft is applicable only when per platform label spaces are 121 used. Per interface label spaces are out of scope. 123 3. Terminology 124 SPT: Shortest Path Tree 126 PLR: Point of Local Repair. The head-end LSR of a backup-SP LSP. 128 Backup-SP LSP (BSP LSP): An LDP LSP that provides a backup for a 129 specific failure on the shortest path LDP LSP. The failed entity 130 may be a link, a node or a SRLG. This LSP originates from the 131 PLR. 133 Backup-SP Merge Point (BSP-MP): The LSR where the Backup-SP LSP is 134 label switched to a label allocated for the shortest path LDP LSP. 135 It need not be downstream of the failed entity. 137 Exclude-SPT: The shortest path tree from a PLR to a destination, 138 when a particular failure point (link, node, SRLG) is excluded 139 from the topology. 141 4. Notation 143 We use the notation L:X-A to denote the label that LSR A allocates 144 for FEC X for the shortest path LSP to X. We also use the notation 145 Lb:X-A to denote the BSP-LSP label allocated by LSR A for FEC X. The 146 label actions that are setup by LSR A for such a label are explained 147 in detail later in the document. 149 5. LDP local repair technique 151 In a shortest path routed network, unicast traffic to a destination 152 flows along a multi-point to point (MP2P) tree/graph towards that 153 destination. When a failure occurs in such a network, traffic from 154 nodes that are upstream from the failed entity on the MP2P tree gets 155 affected. However, traffic along the tree that is not upstream of 156 the failed entity does not get affected. This is true even when the 157 destination is multi-homed and/or the failed entity consists of 158 several components e.g. SRLG failure. 160 A PLR protects against a failure detected on its link by re-routing 161 LSPs having that link as a nexthop, along pre-computed and pre- 162 programmed backup paths. The failed entity may be just the link or 163 could be the entire adjacent LSR or even an SRLG with several 164 components. The backup path for a protected LSP must go from the PLR 165 to a LSR (a.k.a Merge Point - MP) that is not upstream of the failed 166 entity in the MP2P tree for that shortest-path protected LSP's 167 destination. Note that the backup path may have to avoid multiple 168 components of the failure e.g., to protect against SRLG failures it 169 must avoid all the components of the SRLG. If there exists a 170 shortest path LDP LSP that is along a backup path for a LSP, i.e. a 171 shortest-path LDP LSP from the PLR to a LSR that is not upstream of 172 the failure, then it should be used for protection. Such a shortest 173 path LSP is called a Backup Shortest Path LSP (BSP-LSP) and the 174 egress of that LSP which is also the MP is referred to as a backup 175 shortest path merge point (BSP-MP). The PLR must learn the label 176 allocated by the BSP-MP for the protected LSP's destination. The 177 protocol mechanism for to setup the BSP-LSP and for the PLR to learn 178 the label allocated by the BSP-MP for the protected LSP are described 179 in detail later. 181 To protect against a failure the PLR first swaps the incoming label 182 of the protected shortest-path LDP LSP with the one allocated by the 183 BSP-MP for the destination corresponding to the protected shortest- 184 path LDP LSP. It then tunnels the MPLS frame over the BSP-LSP. All 185 these actions are pre-computed, so that at the time of failure the 186 PLR has to perform a small change of the label forwarding actions to 187 protect the traffic. This helps to recover the traffic in sub 188 50msec. 190 A simple example is illustrated below in Figure 1. LSR P protects a 191 LSP to Z against failure of link P-S by using the shortest-path LSP 192 from P to M i.e. the LSP P-Q-M. LSR P would trigger a protection 193 switch action when link P-S fails that would swap label L:Z-P with 194 L:Z-M, and then tunnel the packet through the shortest-path LSP from 195 P to M by pushing the label L:M-Q and uses nexthop of the shortest- 196 path LSP from P to M i.e. link P-Q. It should be noted that the 197 shortest-path LSP from PLR to BSP-MP i.e., from P to M or P-Q-M that 198 was used as a BSP-LSP would continue to be on the same path even 199 after a failure that it is protecting from. It should also be noted 200 that a BSP-LSP can protect multiple LSPs as long as the BSP-MP is not 201 upstream of the failure entity in the MP2P trees of all the protected 202 LSPs. 204 +---+ +---+ +---+ 205 | Q |-------| M |-------| R | 206 +---+ +---+ +---+ 207 | | 208 | | 209 +---+ +---+ +---+ +---+ 210 | A |-----| P |---------X---------| S |------| Z | 211 +---+ +---+ +---+ +---+ 213 L:M-Q 214 L:Z-P L:Z-M L:Z-M L:Z-R L:Z-S 215 A------>P------>Q------>M------>R------>S------>Z 216 Figure 1: Backup Shortest Path LSP 218 A shortest path LDP LSP may not exist from the PLR to an LSR that is 219 upstream of the failure entity on the MP2P tree. A simple example is 220 illustrated in Figure 2. In such a case the backup path LSP would 221 have non shortest-path forwarding links in it. The backup LSP must 222 take the path P-Q-M that is not a shortest-path LSP from P to M 223 (which is P-S-R-M). However the shortest-path LSP cannot be used 224 since it goes through the failure entity that needs to be protected 225 against i.e. link P-S. The backup path LSP P-Q-M would need label 226 forwarding onto links that are not along the shortest-path LSP from 227 PLR to BSP-MP. In this case LSR Q would have to allocate an 228 additional label to forward the traffic on the backup path i.e. to 229 LSR M. So LSR Q allocates a label Lb:Q-M that has an action of pop 230 when Penultimate Hop Popping (PHP) is the mode of operation and 231 forward along the link Q-M. The protocol mechanisms to signal label 232 Lb:Q-M from Q to P are described later in this document. 234 +---+ +---+ +---+ 235 | Q |-------| M |-------| R | 236 +---+ +---+ +---+ 237 | | 238 | | 239 +---+ +---+ +---+ +---+ 240 | A |-----| P |---------X---------| S |-----| Z | 241 +---+ +---+ +---+ +---+ 243 Link Q-M is a high cost link. 245 Lb:M-Q 246 L:Z-P L:Z-M L:Z-M L:Z-R L:Z-S 247 A------>P------>Q------>M------>R------>S------>Z 249 Figure 2: Backup Shortest Path LSP with non shortest-path forwarding 251 By selecting the backup path as the shortest path in the topology 252 with the failure entity removed, the traffic churn after the failure 253 can be minimized. We continue to denote the backup path LSP as BSP- 254 LSP and note that the shortest-path is in the topology with the 255 failure entity removed. If any segment of this path can use existing 256 LDP shortest path LSPs, it would reduce the additional forwarding 257 state needed for the backup LSP. Hence it is recommended that the 258 shortest path LSPs be used as segments in the BSP-LSP wherever 259 possible and keep the non shortest-path links along the BSP-LSP to 260 the minimum. In that case only those LSRs along the backup LSP that 261 routes the backup LSP to a non shortest path link need to allocate 262 additional labels to create the backup LSP. 264 An example in Figure 3 illustrates how a shortest-path LSP used as a 265 segment in a BSP-LSP reduces forwarding state in intermediate LSRs. 266 LSR P protects the LSP to Z from failure of the link P-S. The BSP- 267 LSP is P-T-Q-M and consists of a shortest-path LSP P-T-Q. Only Q 268 allocates an additional label to forward the packet along the link 269 Q-M. This label has to be advertised to P. LSR T does not have any 270 additional state for the BSP-LSP. For the protected LSP going to Z, 271 P installs an action to swap the label L:Z-P to L:Z-M and push the 272 label Lb:M-Q in order to tunnel the packet to the BSP-MP i.e. M. LSR 273 P additionally pushes the label L:Q-T with a nexthop of link P-T to 274 follow the shortest-path LSP from P to Q. These actions are triggered 275 on detecting failure of link P-S. 277 +---+ +---+ +---+ 278 | Q |-------| M |-------| R | 279 +---+ +---+ +---+ 280 | | 281 +---+ | 282 | T | | 283 +---+ | 284 | | 285 +---+ +---+ +---+ +---+ 286 | A |-----| P |---------X---------| S |-----| Z | 287 +---+ +---+ +---+ +---+ 289 Link Q-M is a high cost link. 291 L:Q-T 292 Lb:M-Q Lb:M-Q 293 L:Z-P L:Z-M L:Z-M L:Z-M L:Z-R L:Z-S 294 A------>P------>T------>Q------>M------>R------>S---->Z 296 Figure 3: Backup Shortest Path LSP with non shortest-path forwarding 297 and a shortest-path LSP segment 299 A slightly more complex topology in Figure 4 illustrates how a 300 combination of shortest path LSPs and non shortest-path links are 301 combined to create a BSP-LSP. PLR P protects against failure of node 302 X by creating a backup LSP P-T-Q-S-R-M. The shortest path LSP Q-S-R 303 can be used as a segment of the BSP-LSP. Since LSRs R and T need to 304 forward the packet on a non shortest-path LSP nexthop, they allocate 305 additional labels to create the BSP-LSP. Other LSRs along the BSP- 306 LSP such as S do not have any additional state for the BSP-LSP. 308 +---+ +---+ +---+ 309 | Q |---------------| S |---------------| R | 310 +---+ +---+ +---+ 311 | \ | / | 312 | \ | / | 313 | \ | / | 314 +---+ - +---+ +---+ +---+ - | 315 | T | | Y | | U | | V | | 316 +---+ +---+ +---+ +---+ | 317 | \ | / | 318 | \ | / | 319 | \ | / | 320 +---+ +---+ - +---+- +---+ +---+ 321 | A |-----| P |---------------| X |---------------| M |------| Z | 322 +---+ +---+ +---+ +---+ +---+ 324 Link R-M and T-Q are high cost links. 326 L:R-S 327 Lb:M-T Lb:M-Q Lb:M-R Lb:M-R 328 L:Z-P L:Z-M L:Z-M L:Z-M L:Z-M L:Z-M 329 A------>P------>T------>Q------>S------>R------>M----->Z 331 Figure 4: Backup Shortest Path LSP with non shortest-path forwarding 332 and a shortest-path LSP segment 334 There will be a maximum of two additional labels stacked on the 335 packet as it goes along the BSP-LSP. An advantage of using the 336 shortest-path (in the post failure topology) as the backup path is 337 that existing shortest path algorithms can be re-used by simply 338 computing it on topologies with the failure entity removed. Since 339 FRR-LDP is a local repair mechanism, an LSR computes BSP-LSPs only 340 for failures of its immediate nexthops i.e. links/nodes/SRLGs. 342 It should be noted that the BSP-LSP becomes a single hop LSP when a 343 Loop Free Alternate (LFA) is present. In such cases the LFA could be 344 used and the mechanisms in this draft can be applied only for those 345 cases where an LFA is not available. FRR-LDP can be viewed as an 346 extension to LFA with the additional benefit that it provides full 347 failure coverage against link/node/SRLG failures. 349 Additional label advertisements are needed for FRR-LDP to function as 350 described above. Firstly the PLR needs the label that the BSP-MP has 351 allocated for the FEC corresponding to the protected LSP. Secondly, 352 labels should be allocated and advertised for the BSP-LSP when an LSR 353 has to route the BSP-LSP along a non shortest-path nexthop. The 354 latter is of course not applicable if the BSP-LSP is itself a 355 shortest-path LSP, in which case LDP would signal it with existing 356 procedures. 358 To signal the label of the FEC of the protected LSP from the BSP-MP 359 to the PLR, a targeted LDP session should be used. Note that the PLR 360 is not interested in all label mappings from a BSP-MP. It is 361 interested only in those mappings for which it will tunnel packets to 362 that BSP-MP on a local failure. The PLR should use the Downstream on 363 Demand (DoD) mode to request from the BSP-MP, the specific label 364 mappings that it is interested in. 366 As explained earlier the BSP-LSP is a LSP that goes from the PLR to 367 the BSP-MP and is the shortest-path from PLR to the BSP-MP in the 368 topology where a failed entity is removed. That failed entity is 369 local to the PLR, though it may have additional components that are 370 non-local to the PLR in case of a SRLG failure. To signal labels for 371 such a LSP using LDP procedures, the label mappings are defined for a 372 combination of the FEC and the failed-entity. The failed entity is 373 identified by a new TLV called "Failure Entity TLV", defined in 374 Section 6.1. It is modeled as a simplified version of the 375 EXCLUDE_ROUTE object XRO [RFC4874]. The presence of the "Failure 376 Entity TLV" indicates that the LDP message is for a BSP-LSP. To 377 identify the path that the BSP-LSP should take, a new TLV called the 378 "Backup Path Vector TLV" is defined in Section 6.2. This TLV is 379 modeled as a simplified version of the Explicit Route Object (ERO) in 380 RSVP-TE [RFC3209]. The PLR uses this TLV to route the LSP along a 381 path that is not the shortest-path to the BSP-MP in the current 382 topology but will be the shortest-path in the topology with the 383 failure entity removed. The PLR uses the Label Request message with 384 the FEC of an address of the BSP-MP, the "Failure Entity TLV" and the 385 "Backup Path Vector TLV" to request a label from the downstream LSR. 386 Further details of how the "Backup Path Vector TLV" is processed is 387 described in Section 6.2. 389 6. Protocol procedures and extensions 391 To create the BSP-LSP the PLR can compute the path for the BSP-LSP. 393 If a shortest-path LSP can be used as a BSP-LSP then no extra 394 protocol procedures are required to setup the BSP-LSP. The PLR just 395 needs to get the label corresponding to the FEC of the protected LSP 396 from the BSP-MP. This can be done by setting up a targeted LDP 397 session from PLR to the BSP-MP. This can be a session that is setup 398 dynamically rather than being statically configured. Its setup is 399 initiated by the PLR after the backup path computation that 400 determines which LSRs becomes BSP-MPs for its local failures. The 401 labels should be advertised from BSP-MP to the PLR in a DoD mode. 403 If the path calculated for the BSP-LSP is not along a shortest path 404 from the PLR to the BSP-MP, then the PLR initiates a Downstream on 405 Demand (DoD) signaling mechanism defined in LDP [RFC5036] to setup 406 the BSP-LSP. Some extensions to the DoD mechanism are defined here. 407 A 'Failure Entity TLV' defined in Section 6.1 is included in all 408 messages that signal the BSP-LSP. Together with the FEC it uniquely 409 identifies the LSP that corresponds to the signaling message. The 410 PLR also includes a Backup Path Vector TLV in the label request that 411 indicates the path of the BSP-LSP. The Backup Path Vector TLV is 412 modeled as a simplified version of the ERO defined in RSVP-TE 413 [RFC3209]. The PLR initiates a Label Request message to the 414 immediate nexthop LSR that in turn generate Label Request messages 415 hop-by-hop by following the Backup Path Vector TLV. When the BSP-MP 416 receives the Label Request it responds with a Label Mapping message. 417 Successive Label Mapping messages are generated by intermediate LSRs 418 till one reaches the PLR and the BSP-LSP is set up. Note that the 419 PLR additionally needs the label from the BSP-MP for the protected 420 LSP's FEC and it continues to get that as explained earlier. 422 A BSP-LSP along a path that is not a shortest-path from the PLR to 423 the BSP-MP can have segments where it is tunneled through shortest- 424 path LSPs. The PLR signals such segments in the "Backup Path Vector 425 TLV". The head-end LSR of such a segment can decide how the LSP is 426 going to be signaled across the segment. It must support a method 427 where it is signaled on a hop-by-hop basis where the intermediate 428 LSRs on the shortest-path LSP tunnel do not allocate any labels for 429 the BSP-LSP. Alternately the head-end LSR may use a targeted LDP 430 session to the tail-end LSR of the shortest-path segment and send the 431 Label Request message. 433 6.1. Failure Entity TLV 435 A Failure entity TLV is defined to specify the topological entity 436 whose failure is being referenced in the signaling messages of the 437 BSP-LSP. Together with the FEC it uniquely identifies a label 438 mapping of the BSP-LSP. This TLV is modeled as a simple version of 439 the EXCLUDE_ROUTE Object defined in Exclude Routes [RFC4874]. This 440 TLV must be present in the Label Request message, Label Withdraw 441 message, Label Release message, Label Mapping Message and the 442 Notification message when the BSP-LSP is signaled. 444 This TLV consists of one of these TLVs 446 6.1.1. IP address 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |0|0| Type = IP Prefix (0xTBD) | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | IP Address | 454 . . 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Prefix Length | Attribute | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Type - This should be allocated by IANA for IPv4 and IPv6. 461 Length - This should be 6 for IPv4 and 22 for IPv6 463 IP Address - This is the IP address. 465 Prefix Length - This should be length (in bits) of the IP prefix. 467 Attribute - This should be 0 for link and 1 for the node. 469 6.1.2. SRLG 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 |0|0| Type = SRLG (0xTBD) | Length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | SRLG Id | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Type - This value should be allocated by IANA. 481 Length - This should be 4. 483 SRLG Id - The 32 bit identifier of the SRLG. 485 6.2. Backup Path Vector TLV 487 The TLV consists of a list of addresses of LSRs. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |0|0| Backup Path Vector (0xTBD)| Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Hop Type | Address Family | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Address | 497 . . 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 . . 500 . . 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Hop Type | Address Family | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Address | 505 . . 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Hop Type 510 0 - Non shortest-path link 512 1 - Shortest path LSP 514 2 - Inter-area LSP 516 Address Family - 0 is for IPv4 and 1 for IPv6 518 Address - A 4 or 16 octet IP address 520 This TLV is used in the "Label Request" message. It is processed as 521 follows by examining the first entry in the TLV. 523 1. If the first entry is its own address and it is the only entry in 524 the Backup Path Vector TLV then it responds to the sender with a 525 Label Mapping message for the FEC corresponding to that address. 527 2. If the first entry is its own address but it is not the only 528 entry in the Backup Path Vector TLV, then it allocates a label to 529 be sent in response i.e. the Label Mapping message. It also 530 generates a Label Request message towards the IP address in the 531 next entry of the Backup Path Vector TLV. This Label Request 532 will include the Backup Path Vector TLV with the first entry 533 removed. The way the Label Request is generated depends on the 534 "Hop Type" 535 A. If the "Hop Type"is 0 (Non shortest-path link) then the Label 536 Request is sent to that directly connected neighboring LSR. 537 When a reponse is received via a Label Mapping message, a 538 label swap operation from the label it allocated to the label 539 received with forwarding towards that IP address of the 540 neighboring LSR. 542 B. If the "Hop Type" is 1 (Shortest path LSP) then the LSR must 543 support generating the Label Request on that shortest-path 544 LSP segment on a hop-by-hop basis. In this method it sends 545 the Label Request to a nexthop LSR along the shortest-path 546 LSP. Alternately it may support sending the Label Request on 547 a targeted LDP session to the tail-end of the shortest-path 548 LSP. When it receives a response to this Label Request 549 message via a Label mapping message, then it installs a label 550 swap operation from the label it allocated to the label 551 received from the downstream LSR with a label forward action 552 to tunnel it over the shortest-path LSP. 554 C. If the "Hop Type" is 2 (Inter-area LSP) then this LSR is an 555 area border LSR that must compute a path that avoids the 556 Failure Entity and then generates a Label Request further 557 downstream. 559 3. If the first entry is not its own address then it generates a 560 Label Request message towards the IP address in the first entry 561 of the Backup Path Vector TLV by choosing one of the LSRs on the 562 nexthop. It does not change the Backup Path Vector TLV in this 563 case. Also it does not allocate a label. When it receives a 564 response in the form of a Label Mapping message it generates a 565 corresponding Label Mapping message to the upstream LSR. 567 6.3. Capability Advertisement TLVs 569 A Capability TLV is defined for LDP in accordance to LDP-CAP 570 [RFC5561] to advertise its capability to follow the procedures in 571 this document. This TLV has no additional Capability Data. 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| Type = Capability (0xTBD) | Length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |S| Reserved | 579 +-+-+-+-+-+-+-+-+ 581 To enable PLRs to compute BSP-LSPs the LSRs that are capable of 582 processing the extensions defined in this draft is advertised with 583 area scope via the link-state IGP. The following extensions are 584 required to advertise this capability: 586 1. For OSPF an additional bit must be defined in the Router 587 Information Capability bits defined in OSPF-CAP [RFC4970] 589 2. For ISIS an additional sub TLV to be carried in the CAPABILITY 590 TLV in ISIS-CAP [RFC4971] is defined. 592 7. Acknowledgements 594 The authors would like to thank Joel Halpern and TBD for their 595 comments. 597 8. IANA Considerations 599 The following LDP TLV Types need assignment. 601 1. Capability TLV 603 2. Failure Entity TLV 605 3. Backup Path Vector TLV 607 Also a bit for the OSPF Router Information Capability and a TLV value 608 for the ISIS CAPABILITY TLV. 610 9. Security Considerations 612 TBD. Security considerations for dynamic LDP sessions. 614 10. References 616 10.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 623 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 624 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 625 Tunnels", RFC 3209, December 2001. 627 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 628 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 629 May 2005. 631 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 632 Extension to Resource ReserVation Protocol-Traffic 633 Engineering (RSVP-TE)", RFC 4874, April 2007. 635 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 636 Shaffer, "Extensions to OSPF for Advertising Optional 637 Router Capabilities", RFC 4970, July 2007. 639 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 640 System to Intermediate System (IS-IS) Extensions for 641 Advertising Router Information", RFC 4971, July 2007. 643 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 644 Specification", RFC 5036, October 2007. 646 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 647 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 649 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 650 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 652 10.2. Informative References 654 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] 655 Bryant, S., Previdi, S., and M. Shand, "IP Fast Reroute 656 Using Not-via Addresses", 657 draft-ietf-rtgwg-ipfrr-notvia-addresses-09 (work in 658 progress), June 2012. 660 Authors' Addresses 662 Sriganesh Kini (editor) 663 Ericsson 665 Email: sriganesh.kini@ericsson.com 667 Srikanth Narayanan 668 Ericsson 670 Email: srikanth.narayanan@ericsson.com 671 Stephane Litkowski 672 Orange 674 Email: stephane.litkowski@orange-ftgroup.com