idnits 2.17.1 draft-ietf-teas-rsvp-ingress-protection-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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 9, 2015) is 3337 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: 'S' is mentioned on line 127, but not defined == Missing Reference: 'Ra' is mentioned on line 130, but not defined == Missing Reference: 'Rb' is mentioned on line 130, but not defined == Missing Reference: 'L3' is mentioned on line 130, but not defined == Unused Reference: 'RFC2119' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 948, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track R. Torvi, Ed. 5 Expires: September 10, 2015 Juniper Networks 6 March 9, 2015 8 Extensions to RSVP-TE for LSP Ingress Local Protection 9 draft-ietf-teas-rsvp-ingress-protection-02.txt 11 Abstract 13 This document describes extensions to Resource Reservation Protocol - 14 Traffic Engineering (RSVP-TE) for locally protecting the ingress node 15 of a Traffic Engineered (TE) Label Switched Path (LSP), which is a 16 Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. An Example of Ingress Local Protection . . . . . . . . . . 3 55 2.2. Ingress Local Protection with FRR . . . . . . . . . . . . 4 56 3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4 57 3.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 4 58 3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5 59 4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5 60 4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5 61 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 63 5.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 7 64 5.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 8 65 5.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 8 66 5.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 8 67 5.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 9 68 5.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 69 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 10 70 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 10 72 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11 73 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 11 74 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 12 75 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 76 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13 77 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 14 78 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14 79 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 17 80 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17 81 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 18 82 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 83 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 8.1. A New Class Number . . . . . . . . . . . . . . . . . . . . 19 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 89 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 90 A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Co-authors 94 Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu, 95 Mehmet Toy, Lei Liu 97 2. Introduction 99 For MPLS LSPs it is important to have a fast-reroute method for 100 protecting its ingress node as well as transit nodes. This is not 101 covered either in the fast-reroute method defined in [RFC4090] or in 102 the P2MP fast-reroute extensions to fast-reroute in [RFC4875]. 104 An alternate approach to local protection (fast-reroute) is to use 105 global protection and set up a second backup LSP (whether P2MP or 106 P2P) from a backup ingress to the egresses. The main disadvantage of 107 this is that the backup LSP may reserve additional network bandwidth. 109 This specification defines a simple extension to RSVP-TE for local 110 protection of the ingress node of a P2MP or P2P LSP. 112 2.1. An Example of Ingress Local Protection 114 Figure 1 shows an example of using a backup P2MP LSP to locally 115 protect the ingress of a primary P2MP LSP, which is from ingress R1 116 to three egresses: L1, L2 and L3. The backup LSP is from backup 117 ingress Ra to the next hops R2 and R4 of ingress R1. 119 [R2]******[R3]*****[L1] 120 * | **** Primary LSP 121 * | ---- Backup LSP 122 * / .... BFD Session 123 * / $ Link 124 ....[R1]*******[R4]****[R5]*****[L2] $ 125 : $ $ / / * $ 126 : $ $ / / * 127 [S] $ / / * 128 $ $ / / * 129 $ $/ / * 130 [Ra]----[Rb] [L3] 132 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 134 In normal operations, source S sends the traffic to primary ingress 135 R1. R1 imports the traffic into the primary LSP. 137 When source S detects the failure of R1, it switches the traffic to 138 backup ingress Ra, which imports the traffic from S into the backup 139 LSP to R1's next hops R2 and R4, where the traffic is merged into the 140 primary LSP, and then sent to egresses L1, L2 and L3. 142 Source S should be able to detect the failure of R1 and switch the 143 traffic within 10s of ms. 145 Note that the backup ingress must be one logical hop away from the 146 ingress. A logical hop is a direct link or a tunnel such as a GRE 147 tunnel, over which RSVP-TE messages may be exchanged. 149 2.2. Ingress Local Protection with FRR 151 Through using the ingress local protection and the FRR, we can 152 locally protect the ingress, all the links and the transit nodes of 153 an LSP. The traffic switchover time is within 10s of ms whenever the 154 ingress, any of the links and the transit nodes of the LSP fails. 156 The ingress node of the LSP can be locally protected through using 157 the ingress local protection. All the links and all the transit 158 nodes of the LSP can be locally protected through using the FRR. 160 3. Ingress Failure Detection 162 Exactly how to detect the failure of the ingress is out of scope. 163 However, it is necessary to discuss different modes for detecting the 164 failure because they determine what is the required behavior for the 165 source and backup ingress. 167 3.1. Source Detects Failure 169 Source Detects Failure or Source-Detect for short means that the 170 source is responsible for fast detecting the failure of the primary 171 ingress of an LSP. The backup ingress is ready to import the traffic 172 from the source into the backup LSP after the backup LSP is up. 174 In normal operations, the source sends the traffic to the primary 175 ingress. When the source detects the failure of the primary ingress, 176 it switches the traffic to the backup ingress, which delivers the 177 traffic to the next hops of the primary ingress through the backup 178 LSP, where the traffic is merged into the primary LSP. 180 For a P2P LSP, after the primary ingress fails, the backup ingress 181 must use a method to reliably detect the failure of the primary 182 ingress before the PATH message for the LSP expires at the next hop 183 of the primary ingress. After reliably detecting the failure, the 184 backup ingress sends/refreshes the PATH message to the next hop 185 through the backup LSP as needed. 187 After the primary ingress fails, it will not be reachable after 188 routing convergence. Thus checking whether the primary ingress 189 (address) is reachable is a possible method. 191 3.2. Backup and Source Detect Failure 193 Backup and Source Detect Failure or Backup-Source-Detect for short 194 means that both the backup ingress and the source are concurrently 195 responsible for fast detecting the failure of the primary ingress. 197 In normal operations, the source sends the traffic to the primary 198 ingress. It switches the traffic to the backup ingress when it 199 detects the failure of the primary ingress. 201 The backup ingress does not import any traffic from the source into 202 the backup LSP in normal operations. When it detects the failure of 203 the primary ingress, it imports the traffic from the source into the 204 backup LSP to the next hops of the primary ingress, where the traffic 205 is merged into the primary LSP. 207 The source-detect is preferred. It is simpler than the backup- 208 source-detect, which needs both the source and the backup ingress 209 detect the ingress failure quickly. 211 4. Backup Forwarding State 213 Before the primary ingress fails, the backup ingress is responsible 214 for creating the necessary backup LSPs. These LSPs might be multiple 215 bypass P2P LSPs that avoid the ingress. Alternately, the backup 216 ingress could choose to use a single backup P2MP LSP as a bypass or 217 detour to protect the primary ingress of a primary P2MP LSP. 219 The backup ingress may be off-path or on-path of an LSP. If a backup 220 ingress is not any node of the LSP, we call it is off-path. If a 221 backup ingress is a next-hop of the primary ingress of the LSP, we 222 call it is on-path. If it is on-path, the primary forwarding state 223 associated with the primary LSP SHOULD be clearly separated from the 224 backup LSP(s) state. 226 4.1. Forwarding State for Backup LSP 228 A forwarding entry for a backup LSP is created on the backup ingress 229 after the LSP is set up. Depending on the failure-detection mode 230 (e.g., source-detect), it may be used to forward received traffic or 231 simply be inactive (e.g., backup-source-detect) until required. In 232 either case, when the primary ingress fails, this entry is used to 233 import the traffic into the backup LSP to the next hops of the 234 primary ingress, where the traffic is merged into the primary LSP. 236 The forwarding entry for a backup LSP is a local implementation 237 issue. In one device, it may have an inactive flag. This inactive 238 forwarding entry is not used to forward any traffic normally. When 239 the primary ingress fails, it is changed to active, and thus the 240 traffic from the source is imported into the backup LSP. 242 5. Protocol Extensions 244 A new object INGRESS_PROTECTION is defined for signaling ingress 245 local protection. It is backward compatible. 247 5.1. INGRESS_PROTECTION Object 249 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 250 message is used to control the backup for protecting the primary 251 ingress of a primary LSP. The primary ingress MUST insert this 252 object into the PATH message to be sent to the backup ingress for 253 protecting the primary ingress. It has the following format: 255 Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 256 C-Type = 2 for INGRESS_PROTECTION_IPv6 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Length (bytes) | Class-Num | C-Type | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Secondary LSP ID | Flags | Options | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 ~ (Subobjects) ~ 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Flags 268 0x01 Ingress local protection available 269 0x02 Ingress local protection in use 270 0x04 Bandwidth protection 272 Options 273 0x01 Revert to Ingress 274 0x02 P2MP Backup 276 The Secondary LSP ID in the object is an LSP ID that the primary 277 ingress has allocated for a protected LSP tunnel. The backup ingress 278 may use this LSP ID to set up a new LSP from the backup ingress to 279 the destinations of the protected LSP tunnel. This allows the new 280 LSP to share resources with the old one. 282 The flags are used to communicate status information from the backup 283 ingress to the primary ingress. 285 o Ingress local protection available: The backup ingress sets this 286 flag after backup LSPs are up and ready for locally protecting the 287 primary ingress. The backup ingress sends this to the primary 288 ingress to indicate that the primary ingress is locally protected. 290 o Ingress local protection in use: The backup ingress sets this flag 291 when it detects a failure in the primary ingress. The backup 292 ingress keeps it and does not send it to the primary ingress since 293 the primary ingress is down. 295 o Bandwidth protection: The backup ingress sets this flag if the 296 backup LSPs guarantee to provide desired bandwidth for the 297 protected LSP against the primary ingress failure. 299 The options are used by the primary ingress to specify the desired 300 behavior to the backup ingress. 302 o Revert to Ingress: The primary ingress sets this option indicating 303 that the traffic for the primary LSP successfully re-signaled will 304 be switched back to the primary ingress from the backup ingress 305 when the primary ingress is restored. 307 o P2MP Backup: This option is set to ask for the backup ingress to 308 use P2MP backup LSP to protect the primary ingress. Note that one 309 spare bit of the flags in the FAST-REROUTE object can be used to 310 indicate whether P2MP or P2P backup LSP is desired for protecting 311 an ingress and transit node. 313 The INGRESS_PROTECTION object may contain some sub objects below. 315 5.1.1. Subobject: Backup Ingress IPv4 Address 317 When the primary ingress of a protected LSP sends a PATH message with 318 an INGRESS_PROTECTION object to the backup ingress, the object may 319 have a Backup Ingress IPv4 Address sub object containing an IPv4 320 address belonging to the backup ingress. The Type of the sub object 321 is TBD-1, and the body of the sub object is given below: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | IPv4 address (4 bytes) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 IPv4 address: A 32-bit unicast, host address. 331 5.1.2. Subobject: Backup Ingress IPv6 Address 333 When the primary ingress of a protected LSP sends a PATH message with 334 an INGRESS_PROTECTION object to the backup ingress, the object may 335 have a Backup Ingress IPv6 Address sub object containing an IPv6 336 address belonging to the backup ingress. The Type of the sub object 337 is TBD-2, the body of the sub object is given below: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | IPv6 address (16 bytes) | 343 ~ ~ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 IPv6 address: A 128-bit unicast, host address. 348 5.1.3. Subobject: Ingress IPv4 Address 350 The INGRESS_PROTECTION object may have an Ingress IPv4 Address sub 351 object containing an IPv4 address belonging to the primary ingress. 352 The Type of the sub object is TBD-3. The sub object has the 353 following body: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | IPv4 address (4 bytes) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 IPv4 address: A 32-bit unicast, host address. 363 5.1.4. Subobject: Ingress IPv6 Address 365 The INGRESS_PROTECTION object may have an Ingress IPv6 Address sub 366 object containing an IPv6 address belonging to the primary ingress. 367 The Type of the sub object is TBD-4. The sub object has the 368 following body: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | IPv6 address (16 bytes) | 374 ~ ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 IPv6 address: A 128-bit unicast, host address. 379 5.1.5. Subobject: Traffic Descriptor 381 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 382 object describing the traffic to be mapped to the backup LSP on the 383 backup ingress for locally protecting the primary ingress. The Type 384 of the sub object is TBD-5/TBD-6/TBD-7 for Interface/IPv4/IPv6 Prefix 385 respectively. The sub object has the following body: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Traffic Element 1 | 391 ~ ~ 392 | Traffic Element n | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 The Traffic Descriptor sub object may contain multiple Traffic 396 Elements of same type as follows: 398 o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a 399 32 bit index of an interface, from which the traffic is imported 400 into the backup LSP. 402 o IPv4/IPv6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic 403 Elements is an IPv4/IPv6 prefix, containing an 8-bit prefix length 404 followed by an IPv4/IPv6 address prefix, whose length, in bits, 405 was specified by the prefix length, padded to a byte boundary. 407 5.1.6. Subobject: Label-Routes 409 The INGRESS_PROTECTION object in a PATH message from the primary 410 ingress to the backup ingress will have a Label-Routes sub object 411 containing the labels and routes that the next hops of the ingress 412 use. The Type of the sub object is TBD-8. The sub object has the 413 following body: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ~ Subobjects ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The Subobjects in the Label-Routes are copied from those in the 422 RECORD_ROUTE objects in the RESV messages that the primary ingress 423 receives from its next hops for the primary LSP. They MUST contain 424 the first hops of the LSP, each of which is paired with its label. 426 6. Behavior of Ingress Protection 428 6.1. Overview 430 There are four parts of ingress protection: 1) setting up the 431 necessary backup LSP forwarding state; 2) identifying the failure and 432 providing the fast repair (as discussed in Sections 3 and 4); 3) 433 maintaining the RSVP-TE control plane state until a global repair can 434 be done; and 4) performing the global repair(see Section 6.4). 436 There are two different proposed signaling approaches to obtain 437 ingress protection. They both use the same new INGRESS_PROTECTION 438 object. The object is sent in both PATH and RESV messages. 440 6.1.1. Relay-Message Method 442 The primary ingress relays the information for ingress protection of 443 an LSP to the backup ingress via PATH messages. Once the LSP is 444 created, the ingress of the LSP sends the backup ingress a PATH 445 message with an INGRESS_PROTECTION object with Label-Routes 446 subobject, which is populated with the next-hops and labels. This 447 provides sufficient information for the backup ingress to create the 448 appropriate forwarding state and backup LSP(s). 450 The ingress also sends the backup ingress all the other PATH messages 451 for the LSP with an empty INGRESS_PROTECTION object. Thus, the 452 backup ingress has access to all the PATH messages needed for 453 modification to refresh control-plane state after a failure. 455 The advantages of this method include: 1) the primary LSP is 456 independent of the backup ingress; 2) simple; 3) less configuration; 457 and 4) less control traffic. 459 6.1.2. Proxy-Ingress Method 461 Conceptually, a proxy ingress is created that starts the RSVP 462 signaling. The explicit path of the LSP goes from the proxy ingress 463 to the backup ingress and then to the real ingress. The behavior and 464 signaling for the proxy ingress is done by the real ingress; the use 465 of a proxy ingress address avoids problems with loop detection. 467 [ traffic source ] *** Primary LSP 468 $ $ --- Backup LSP 469 $ $ $$ Link 470 $ $ 471 [ proxy ingress ] [ backup ] 472 [ & ingress ] | 473 * | 474 *****[ MP ]----| 476 Figure 2: Example Protected LSP with Proxy Ingress Node 478 The backup ingress must know the merge points or next-hops and their 479 associated labels. This is accomplished by having the RSVP PATH and 480 RESV messages go through the backup ingress, although the forwarding 481 path need not go through the backup ingress. If the backup ingress 482 fails, the ingress simply removes the INGRESS_PROTECTION object and 483 forwards the PATH messages to the LSP's next-hop(s). If the ingress 484 has its LSP configured for ingress protection, then the ingress can 485 add the backup ingress and itself to the ERO and start forwarding the 486 PATH messages to the backup ingress. 488 Slightly different behavior can apply for the on-path and off-path 489 cases. In the on-path case, the backup ingress is a next hop node 490 after the ingress for the LSP. In the off-path, the backup ingress 491 is not any next-hop node after the ingress for all associated sub- 492 LSPs. 494 The key advantage of this approach is that it minimizes the special 495 handling code requires. Because the backup ingress is on the 496 signaling path, it can receive various notifications. It easily has 497 access to all the PATH messages needed for modification to be sent to 498 refresh control-plane state after a failure. 500 6.1.3. Comparing Two Methods 501 +-------+-----------+-------+--------------+---------------+---------+ 502 |\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse | 503 | \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some | 504 | \|Backup |Ingress|to Primary |to Backup |Existing | 505 |Method |Ingress |ID |Ingress |Ingress |Functions| 506 +-------+-----------+-------+--------------+---------------+---------+ 507 |Relay- | No | No | No | No | Yes- | 508 |Message| | | | | | 509 +-------+-----------+-------+--------------+---------------+---------+ 510 |Proxy- | Yes | Yes | Yes | Yes | Yes | 511 |Ingress| | | | | | 512 +-------+-----------+-------+--------------+---------------+---------+ 514 6.2. Ingress Behavior 516 The primary ingress must be configured with a couple of pieces of 517 information for ingress protection. 519 o Backup Ingress Address: The primary ingress must know an IP 520 address for it to be included in the INGRESS_PROTECTION object. 522 o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The 523 Proxy-Ingress-Id is only used in the Record Route Object for 524 recording the proxy-ingress. If no proxy-ingress-id is specified, 525 then a local interface address that will not otherwise be included 526 in the Record Route Object can be used. A similar technique is 527 used in [RFC4090 Sec 6.1.1]. 529 o Application Traffic Identifier: The primary ingress and backup 530 ingress must both know what application traffic should be directed 531 into the LSP. If a list of prefixes in the Traffic Descriptor 532 sub-object will not suffice, then a commonly understood 533 Application Traffic Identifier can be sent between the primary 534 ingress and backup ingress. The exact meaning of the identifier 535 should be configured similarly at both the primary ingress and 536 backup ingress. The Application Traffic Identifier is understood 537 within the unique context of the primary ingress and backup 538 ingress. 540 With this additional information, the primary ingress can create and 541 signal the necessary RSVP extensions to support ingress protection. 543 6.2.1. Relay-Message Method 545 To protect the ingress of an LSP, the ingress does the following 546 after the LSP is up. 548 1. Select a PATH message. 550 2. If the backup ingress is off-path, then send it a PATH message 551 with the content from the selected PATH message and an 552 INGRESS_PROTECTION object; else (the backup ingress is a next 553 hop, i.e., on-path case) add an INGRESS_PROTECTION object into 554 the existing PATH message to the backup ingress (i.e., the next 555 hop). The object contains the Traffic-Descriptor sub-object, the 556 Backup Ingress Address sub-object and the Label-Routes sub- 557 object. The flags is set to indicate whether a Backup P2MP LSP 558 is desired. A second LSP-ID is allocated (if it is not allocated 559 yet) and used in the object. The Label-Routes sub-object 560 contains the next-hops of the ingress and their labels. 562 3. For each of the other PATH messages, send the backup ingress a 563 PATH message with the content copied from the message and an 564 empty INGRESS_PROTECTION object, which is an object without any 565 Traffic-Descriptor sub-object. 567 6.2.2. Proxy-Ingress Method 569 The primary ingress is responsible for starting the RSVP signaling 570 for the proxy-ingress node. To do this, the following is done for 571 the RSVP PATH message. 573 1. Compute the EROs for the LSP as normal for the ingress. 575 2. If the selected backup ingress node is not the first node on the 576 path (for all sub-LSPs), then insert at the beginning of the ERO 577 first the backup ingress node and then the ingress node. 579 3. In the PATH RRO, instead of recording the ingress node's address, 580 replace it with the Proxy-Ingress-Id. 582 4. Leave the HOP object populated as usual with information for the 583 ingress-node. 585 5. Add the INGRESS_PROTECTION object to the PATH message. Allocate 586 a second LSP-ID to be used in the INGRESS-PROTECTION object. 587 Include the Backup Ingress Address (IPv4 or IPv6) sub-object and 588 the Traffic-Descriptor sub-object. Set or clear the flag 589 indicating that a Backup P2MP LSP is desired. 591 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path 592 message. Indicate whether one-to-one backup is desired. 593 Indicate whether facility backup is desired. 595 7. The RSVP PATH message is sent to the backup node as normal. 597 If the ingress detects that it can't communicate with the backup 598 ingress, then the ingress should instead send the PATH message to the 599 next-hop indicated in the ERO computed in step 1. Once the ingress 600 detects that it can communicate with the backup ingress, the ingress 601 SHOULD follow the steps 1-7 to obtain ingress failure protection. 603 When the ingress node receives an RSVP PATH message with an INGRESS- 604 PROTECTION object and the object specifies that node as the ingress 605 node and the PHOP as the backup ingress node, the ingress node SHOULD 606 remove the INGRESS_PROTECTION object from the PATH message before 607 sending it out. Additionally, the ingress node must store that it 608 will install ingress forwarding state for the LSP rather than 609 midpoint forwarding. 611 When an RSVP RESV message is received by the ingress, it uses the 612 NHOP to determine whether the message is received from the backup 613 ingress or from a different node. The stored associated PATH message 614 contains an INGRESS_PROTECTION object that identifies the backup 615 ingress node. If the RESV message is not from the backup node, then 616 ingress forwarding state should be set up, and the INGRESS_PROTECTION 617 object MUST be added to the RESV before it is sent to the NHOP, which 618 should be the backup node. If the RESV message is from the backup 619 node, then the LSP should be considered available for use. 621 If the backup ingress node is on the forwarding path, then a RESV is 622 received with an INGRESS_PROTECTION object and an NHOP that matches 623 the backup ingress. In this case, the ingress node's address will 624 not appear after the backup ingress in the RRO. The ingress node 625 should set up ingress forwarding state, just as is done if the LSP 626 weren't ingress-node protected. 628 6.3. Backup Ingress Behavior 630 An LER determines that the ingress local protection is requested for 631 an LSP if the INGRESS_PROTECTION object is included in the PATH 632 message it receives for the LSP. The LER can further determine that 633 it is the backup ingress if one of its addresses is in the Backup 634 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 635 as the backup ingress will assume full responsibility of the ingress 636 after the primary ingress fails. In addition, the LER determines 637 that it is off-path if it is not a next hop of the primary ingress. 639 6.3.1. Backup Ingress Behavior in Off-path Case 641 The backup ingress considers itself as a PLR and the primary ingress 642 as its next hop and provides a local protection for the primary 643 ingress. It behaves very similarly to a PLR providing fast-reroute 644 where the primary ingress is considered as the failure-point to 645 protect. Where not otherwise specified, the behavior given in 646 [RFC4090] for a PLR should apply. 648 The backup ingress SHOULD follow the control-options specified in the 649 INGRESS_PROTECTION object and the flags and specifications in the 650 FAST-REROUTE object. This applies to providing a P2MP backup if the 651 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 652 set, facility backup if the "facility backup desired" is set, and 653 backup paths that support the desired bandwidth, and administrative- 654 colors that are requested. 656 If multiple non empty INGRESS_PROTECTION objects have been received 657 via multiple PATH messages for the same LSP, then the most recent one 658 MUST be the one used. 660 The backup ingress creates the appropriate forwarding state for the 661 backup LSP tunnel(s) to the merge point(s). 663 When the backup ingress sends a RESV message to the primary ingress, 664 it should add an INGRESS_PROTECTION object into the message. It 665 SHOULD set or clear the flags in the object to report "Ingress local 666 protection available", "Ingress local protection in use", and 667 "bandwidth protection". 669 If the backup ingress doesn't have a backup LSP tunnel to all the 670 merge points, it SHOULD clear "Ingress local protection available". 671 [Editor Note: It is possible to indicate the number or which are 672 unprotected via a sub-object if desired.] 674 When the primary ingress fails, the backup ingress redirects the 675 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 676 transmitting the traffic to the next hops of the primary ingress, 677 where the traffic is merged into the protected LSP. 679 In this case, the backup ingress keeps the PATH message with the 680 INGRESS_PROTECTION object received from the primary ingress and the 681 RESV message with the INGRESS_PROTECTION object to be sent to the 682 primary ingress. The backup ingress sets the "local protection in 683 use" flag in the RESV message, indicating that the backup ingress is 684 actively redirecting the traffic into the backup P2P LSPs or the 685 backup P2MP LSP for locally protecting the primary ingress failure. 687 Note that the RESV message with this piece of information will not be 688 sent to the primary ingress because the primary ingress has failed. 690 If the backup ingress has not received any PATH message from the 691 primary ingress for an extended period of time (e.g., a cleanup 692 timeout interval) and a confirmed primary ingress failure did not 693 occur, then the standard RSVP soft-state removal SHOULD occur. The 694 backup ingress SHALL remove the state for the PATH message from the 695 primary ingress, and tear down the one-to-one backup LSPs for 696 protecting the primary ingress if one-to-one backup is used or unbind 697 the facility backup LSPs if facility backup is used. 699 When the backup ingress receives a PATH message from the primary 700 ingress for locally protecting the primary ingress of a protected 701 LSP, it checks to see if any critical information has been changed. 702 If the next hops of the primary ingress are changed, the backup 703 ingress SHALL update its backup LSP(s) accordingly. 705 6.3.1.1. Relay-Message Method 707 When the backup ingress receives a PATH message with an non empty 708 INGRESS_PROTECTION object, it examines the object to learn what 709 traffic associated with the LSP. It determines the next-hops to be 710 merged to by examining the Label-Routes sub-object in the object. 712 The backup ingress stores the PATH message received from the primary 713 ingress, but does NOT forward it. 715 The backup ingress responds with a RESV to the PATH message received 716 from the primary ingress. If the INGRESS_PROTECTION object is not 717 "empty", the backup ingress SHALL send the RESV message with the 718 state indicating protection is available after the backup LSP(s) are 719 successfully established. 721 6.3.1.2. Proxy-Ingress Method 723 The backup ingress determines the next-hops to be merged to by 724 collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- 725 object) from the Record Route Object of each RESV that are closest to 726 the top and not the Ingress router; this should be the second to the 727 top pair. If a Label-Routes sub-object is included in the 728 INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are 729 used to filter the set down to the specific next-hops where 730 protection is desired. A RESV message must have been received before 731 the Backup Ingress can create or select the appropriate backup LSP. 733 When the backup ingress receives a PATH message with the 734 INGRESS_PROTECTION object, the backup ingress examines the object to 735 learn what traffic associated with the LSP. The backup ingress 736 forwards the PATH message to the ingress node with the normal RSVP 737 changes. 739 When the backup ingress receives a RESV message with the 740 INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- 741 NULL label in the RRO. Then the backup ingress forwards the RESV 742 message to the ingress node, which is acting for the proxy ingress. 744 6.3.2. Backup Ingress Behavior in On-path Case 746 An LER as the backup ingress determines that it is on-path if one of 747 its addresses is a next hop of the primary ingress (and the primary 748 ingress is not its next hop via checking the PATH message with the 749 INGRESS_PROTECTION object received from the primary ingress for 750 Proxy-Ingress Method). The LER on-path sends the corresponding PATH 751 messages without any INGRESS_PROTECTION object to its next hops. It 752 creates a number of backup P2P LSPs or a backup P2MP LSP from itself 753 to the other next hops (i.e., the next hops other than the backup 754 ingress) of the primary ingress. The other next hops are from the 755 Label-Routes sub object. 757 It also creates a forwarding entry, which sends/multicasts the 758 traffic from the source to the next hops of the backup ingress along 759 the protected LSP when the primary ingress fails. The traffic is 760 described by the Traffic-Descriptor. 762 After the forwarding entry is created, all the backup P2P LSPs or the 763 backup P2MP LSP is up and associated with the protected LSP, the 764 backup ingress sends the primary ingress the RESV message with the 765 INGRESS_PROTECTION object containing the state of the local 766 protection such as "local protection available" flag set to one, 767 which indicates that the primary ingress is locally protected. 769 When the primary ingress fails, the backup ingress sends/multicasts 770 the traffic from the source to its next hops along the protected LSP 771 and imports the traffic into each of the backup P2P LSPs or the 772 backup P2MP LSP transmitting the traffic to the other next hops of 773 the primary ingress, where the traffic is merged into protected LSP. 775 During the local repair, the backup ingress continues to send the 776 PATH messages to its next hops as before, keeps the PATH message with 777 the INGRESS_PROTECTION object received from the primary ingress and 778 the RESV message with the INGRESS_PROTECTION object to be sent to the 779 primary ingress. It sets the "local protection in use" flag in the 780 RESV message. 782 6.3.3. Failure Detection and Refresh PATH Messages 784 As described in [RFC4090], it is necessary to refresh the PATH 785 messages via the backup LSP(s). The Backup Ingress MUST wait to 786 refresh the PATH messages until it can accurately detect that the 787 ingress node has failed. An example of such an accurate detection 788 would be that the IGP has no bi-directional links to the ingress node 789 and the last change was long enough in the past that changes should 790 have been received (i.e., an IGP network convergence time or 791 approximately 2-3 seconds) or a BFD session to the primary ingress' 792 loopback address has failed and stayed failed after the network has 793 reconverged. 795 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 796 as PLR, SHOULD modify and send any saved PATH messages associated 797 with the primary LSP to the corresponding next hops through backup 798 LSP(s). Any PATH message sent will not contain any 799 INGRESS_PROTECTION object. The RSVP_HOP object in the message 800 contains an IP source address belonging to the backup ingress. The 801 sender template object has the backup ingress address as its tunnel 802 sender address. 804 6.4. Revertive Behavior 806 Upon a failure event in the (primary) ingress of a protected LSP, the 807 protected LSP is locally repaired by the backup ingress. There are a 808 couple of basic strategies for restoring the LSP to a full working 809 path. 811 - Revert to Primary Ingress: When the primary ingress is restored, 812 it re-signals each of the LSPs that start from the primary 813 ingress. The traffic for every LSP successfully re-signaled is 814 switched back to the primary ingress from the backup ingress. 816 - Global Repair by Backup Ingress: After determining that the 817 primary ingress of an LSP has failed, the backup ingress computes 818 a new optimal path, signals a new LSP along the new path, and 819 switches the traffic to the new LSP. 821 6.4.1. Revert to Primary Ingress 823 If "Revert to Primary Ingress" is desired for a protected LSP, the 824 (primary) ingress of the LSP re-signals the LSP that starts from the 825 primary ingress after the primary ingress restores. After the LSP is 826 re-signaled successfully, the traffic can be switched back to the 827 primary ingress from the backup ingress on the source node and 828 redirected into the LSP starting from the primary ingress. 830 The primary ingress can specify the "Revert to Ingress" control- 831 option in the INGRESS_PROTECTION object in the PATH messages to the 832 backup ingress. After receiving the "Revert to Ingress" control- 833 option, the backup ingress stops sending/refreshing PATH messages for 834 the protected LSP. 836 6.4.2. Global Repair by Backup Ingress 838 When the backup ingress has determined that the primary ingress of 839 the protected LSP has failed (e.g., via the IGP), it can compute a 840 new path and signal a new LSP along the new path so that it no longer 841 relies upon local repair. To do this, the backup ingress uses the 842 same tunnel sender address in the Sender Template Object and uses the 843 previously allocated second LSP-ID in the INGRESS_PROTECTION object 844 of the PATH message as the LSP-ID of the new LSP. This allows the 845 new LSP to share resources with the old LSP. In addition, if the 846 Ingress recovers, the Backup Ingress SHOULD send it RESVs with the 847 INGRESS_PROTECTION object where the "Revert to Ingress" is specified. 848 The Secondary LSP ID should be the unused LSP ID - while the LSP ID 849 signaled in the RESV will be that currently active. The Ingress can 850 learn from the RESVs what to signal. Even if the Ingress does not 851 take over, the RESVs notify it that the particular LSP IDs are in 852 use. The Backup Ingress can reoptimize the new LSP as necessary 853 until the Ingress recovers. Alternately, the Backup Ingress can 854 create a new LSP with no bandwidth reservation that duplicates the 855 path(s) of the protected LSP, move traffic to the new LSP, delete the 856 protected LSP, and then resignal the new LSP with bandwidth. 858 7. Security Considerations 860 In principle this document does not introduce new security issues. 861 The security considerations pertaining to RFC 4090, RFC 4875 and 862 other RSVP protocols remain relevant. 864 8. IANA Considerations 866 IANA is requested to administer the assignment of new values defined 867 in this document and summarized in this section. 869 8.1. A New Class Number 871 IANA maintains a registry called "Class Names, Class Numbers, and 872 Class Types" under "Resource Reservation Protocol-Traffic Engineering 873 (RSVP-TE) Parameters". IANA is requested to assign a new Class 874 Number for new object EGRESS_BACKUP as follows: 876 +====================+===============+============================+ 877 | Class Names | Class Numbers | Class Types | 878 +====================+===============+============================+ 879 | INGRESS_PROTECTION | TBD1 (>192) | 1: INGRESS_PROTECTION_IPv4 | 880 | | +----------------------------+ 881 | | | 2: INGRESS_PROTECTION_IPv6 | 882 +--------------------+---------------+----------------------------+ 884 IANA is requested to assign Types for new TLVs in the new objects as 885 follows: 887 Type Name Allowed in 888 1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 889 2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 890 3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 891 4 INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 892 5 TRAFFIC_DESCRIPTOR_INTERFACE INGRESS_PROTECTION 893 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX INGRESS_PROTECTION_IPv4 894 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX INGRESS_PROTECTION_IPv6 895 8 LabeL_Routes INGRESS_PROTECTION 897 9. Contributors 899 Renwei Li 900 Huawei Technologies 901 2330 Central Expressway 902 Santa Clara, CA 95050 903 USA 904 Email: renwei.li@huawei.com 906 Quintin Zhao 907 Huawei Technologies 908 Boston, MA 909 USA 910 Email: quintin.zhao@huawei.com 912 Zhenbin Li 913 Huawei Technologies 914 2330 Central Expressway 915 Santa Clara, CA 95050 916 USA 917 Email: zhenbin.li@huawei.com 918 Boris Zhang 919 Telus Communications 920 200 Consilium Pl Floor 15 921 Toronto, ON M1H 3J3 922 Canada 923 Email: Boris.Zhang@telus.com 925 Markus Jork 926 Juniper Networks 927 10 Technology Park Drive 928 Westford, MA 01886 929 USA 930 Email: mjork@juniper.net 932 10. Acknowledgement 934 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 935 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, 936 Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, and 937 Ronhazli Adam for their valuable comments and suggestions on this 938 draft. 940 11. Normative References 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 946 Label Switching Architecture", RFC 3031, January 2001. 948 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 949 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 950 Tunnels", RFC 3209, December 2001. 952 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 953 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 954 May 2005. 956 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 957 "Extensions to Resource Reservation Protocol - Traffic 958 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 959 Switched Paths (LSPs)", RFC 4875, May 2007. 961 Appendix A. Authors' Addresses 963 Huaimo Chen 964 Huawei Technologies 965 Boston, MA 966 USA 967 Email: huaimo.chen@huawei.com 969 Raveendra Torvi 970 Juniper Networks 971 10 Technology Park Drive 972 Westford, MA 01886 973 USA 974 Email: rtorvi@juniper.net 976 Ning So 977 Tata Communications 978 2613 Fairbourne Cir. 979 Plano, TX 75082 980 USA 981 Email: ningso01@gmail.com 983 Autumn Liu 984 Ericsson 985 300 Holger Way 986 San Jose, CA 95134 987 USA 988 Email: autumn.liu@ericsson.com 990 Alia Atlas 991 Juniper Networks 992 10 Technology Park Drive 993 Westford, MA 01886 994 USA 995 Email: akatlas@juniper.net 996 Yimin Shen 997 Juniper Networks 998 10 Technology Park Drive 999 Westford, MA 01886 1000 USA 1001 Email: yshen@juniper.net 1003 Tarek Saad 1004 Cisco Systems 1005 Email: tsaad@cisco.com 1007 Fengman Xu 1008 Verizon 1009 2400 N. Glenville Dr 1010 Richardson, TX 75082 1011 USA 1012 Email: fengman.xu@verizon.com 1014 Mehmet Toy 1015 Comcast 1016 1800 Bishops Gate Blvd. 1017 Mount Laurel, NJ 08054 1018 USA 1019 Email: mehmet_toy@cable.comcast.com 1021 Lei Liu 1022 UC Davis 1023 USA 1024 Email: liulei.kddi@gmail.com