idnits 2.17.1 draft-ietf-mpls-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 (October 26, 2014) is 3463 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 126, but not defined == Missing Reference: 'Ra' is mentioned on line 129, but not defined == Missing Reference: 'Rb' is mentioned on line 129, but not defined == Missing Reference: 'L3' is mentioned on line 129, but not defined == Unused Reference: 'RFC1700' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'P2MP-FRR' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 935, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 4461 -- Possible downref: Normative reference to a draft: ref. 'P2MP-FRR' Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). 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: April 29, 2015 Juniper Networks 6 October 26, 2014 8 Extensions to RSVP-TE for LSP Ingress Local Protection 9 draft-ietf-mpls-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) in a Multi- 16 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. 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 April 29, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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/IPv6 Address . . . . . 7 64 5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 8 65 5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 8 66 5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 67 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 9 68 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 9 70 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 10 71 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 11 72 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 11 73 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 74 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 75 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 13 76 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14 77 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 16 78 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17 79 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 17 80 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 81 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 18 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 89 A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Co-authors 93 Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu, 94 Mehmet Toy, Lei Liu 96 2. Introduction 98 For MPLS LSPs it is important to have a fast-reroute method for 99 protecting its ingress node as well as transit nodes. This is not 100 covered either in the fast-reroute method defined in [RFC4090] or in 101 the P2MP fast-reroute extensions to fast-reroute in [RFC4875]. 103 An alternate approach to local protection (fast-reroute) is to use 104 global protection and set up a second backup LSP (whether P2MP or 105 P2P) from a backup ingress to the egresses. The main disadvantage of 106 this is that the backup LSP may reserve additional network bandwidth. 108 This specification defines a simple extension to RSVP-TE for local 109 protection of the ingress node of a P2MP or P2P LSP. 111 2.1. An Example of Ingress Local Protection 113 Figure 1 shows an example of using a backup P2MP LSP to locally 114 protect the ingress of a primary P2MP LSP, which is from ingress R1 115 to three egresses: L1, L2 and L3. The backup LSP is from backup 116 ingress Ra to the next hops R2 and R4 of ingress R1. 118 [R2]******[R3]*****[L1] 119 * | **** Primary LSP 120 * | ---- Backup LSP 121 * / .... BFD Session 122 * / $ Link 123 ....[R1]*******[R4]****[R5]*****[L2] $ 124 : $ $ / / * $ 125 : $ $ / / * 126 [S] $ / / * 127 $ $ / / * 128 $ $/ / * 129 [Ra]----[Rb] [L3] 131 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 133 In normal operations, source S sends the traffic to primary ingress 134 R1. R1 imports the traffic into the primary LSP. 136 When source S detects the failure of R1, it switches the traffic to 137 backup ingress Ra, which imports the traffic from S into the backup 138 LSP to R1's next hops R2 and R4, where the traffic is merged into the 139 primary LSP, and then sent to egresses L1, L2 and L3. 141 Source S should be able to detect the failure of R1 and switch the 142 traffic within 10s of ms. 144 Note that the backup ingress must be one logical hop away from the 145 ingress. A logical hop is a direct link or a tunnel such as a GRE 146 tunnel, over which RSVP-TE messages may be exchanged. 148 2.2. Ingress Local Protection with FRR 150 Through using the ingress local protection and the FRR, we can 151 locally protect the ingress, all the links and the transit nodes of 152 an LSP. The traffic switchover time is within 10s of ms whenever the 153 ingress, any of the links and the transit nodes of the LSP fails. 155 The ingress node of the LSP can be locally protected through using 156 the ingress local protection. All the links and all the transit 157 nodes of the LSP can be locally protected through using the FRR. 159 3. Ingress Failure Detection 161 Exactly how to detect the failure of the ingress is out of scope. 162 However, it is necessary to discuss different modes for detecting the 163 failure because they determine what is the required behavior for the 164 source and backup ingress. 166 3.1. Source Detects Failure 168 Source Detects Failure or Source-Detect for short means that the 169 source is responsible for fast detecting the failure of the primary 170 ingress of an LSP. The backup ingress is ready to import the traffic 171 from the source into the backup LSP after the backup LSP is up. 173 In normal operations, the source sends the traffic to the primary 174 ingress. When the source detects the failure of the primary ingress, 175 it switches the traffic to the backup ingress, which delivers the 176 traffic to the next hops of the primary ingress through the backup 177 LSP, where the traffic is merged into the primary LSP. 179 For a P2P LSP, after the primary ingress fails, the backup ingress 180 must use a method to reliably detect the failure of the primary 181 ingress before the PATH message for the LSP expires at the next hop 182 of the primary ingress. After reliably detecting the failure, the 183 backup ingress sends/refreshes the PATH message to the next hop 184 through the backup LSP as needed. 186 After the primary ingress fails, it will not be reachable after 187 routing convergence. Thus checking whether the primary ingress 188 (address) is reachable is a possible method. 190 3.2. Backup and Source Detect Failure 192 Backup and Source Detect Failure or Backup-Source-Detect for short 193 means that both the backup ingress and the source are concurrently 194 responsible for fast detecting the failure of the primary ingress. 196 In normal operations, the source sends the traffic to the primary 197 ingress. It switches the traffic to the backup ingress when it 198 detects the failure of the primary ingress. 200 The backup ingress does not import any traffic from the source into 201 the backup LSP in normal operations. When it detects the failure of 202 the primary ingress, it imports the traffic from the source into the 203 backup LSP to the next hops of the primary ingress, where the traffic 204 is merged into the primary LSP. 206 The source-detect is preferred. It is simpler than the backup- 207 source-detect, which needs both the source and the backup ingress 208 detect the ingress failure quickly. 210 4. Backup Forwarding State 212 Before the primary ingress fails, the backup ingress is responsible 213 for creating the necessary backup LSPs. These LSPs might be multiple 214 bypass P2P LSPs that avoid the ingress. Alternately, the backup 215 ingress could choose to use a single backup P2MP LSP as a bypass or 216 detour to protect the primary ingress of a primary P2MP LSP. 218 The backup ingress may be off-path or on-path of an LSP. If a backup 219 ingress is not any node of the LSP, we call it is off-path. If a 220 backup ingress is a next-hop of the primary ingress of the LSP, we 221 call it is on-path. If it is on-path, the primary forwarding state 222 associated with the primary LSP SHOULD be clearly separated from the 223 backup LSP(s) state. 225 4.1. Forwarding State for Backup LSP 227 A forwarding entry for a backup LSP is created on the backup ingress 228 after the LSP is set up. Depending on the failure-detection mode 229 (e.g., source-detect), it may be used to forward received traffic or 230 simply be inactive (e.g., backup-source-detect) until required. In 231 either case, when the primary ingress fails, this entry is used to 232 import the traffic into the backup LSP to the next hops of the 233 primary ingress, where the traffic is merged into the primary LSP. 235 The forwarding entry for a backup LSP is a local implementation 236 issue. In one device, it may have an inactive flag. This inactive 237 forwarding entry is not used to forward any traffic normally. When 238 the primary ingress fails, it is changed to active, and thus the 239 traffic from the source is imported into the backup LSP. 241 5. Protocol Extensions 243 A new object INGRESS_PROTECTION is defined for signaling ingress 244 local protection. It is backward compatible. 246 5.1. INGRESS_PROTECTION Object 248 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 249 message is used to control the backup for protecting the primary 250 ingress of a primary LSP. The primary ingress MUST insert this 251 object into the PATH message to be sent to the backup ingress for 252 protecting the primary ingress. It has the following format: 254 Class-Num = TBD C-Type = TBD 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Length (bytes) | Class-Num | C-Type | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Secondary LSP ID | Flags | Options | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 ~ (Subobjects) ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Flags 266 0x01 Ingress local protection available 267 0x02 Ingress local protection in use 268 0x04 Bandwidth protection 270 Options 271 0x01 Revert to Ingress 272 0x02 P2MP Backup 274 The Secondary LSP ID in the object is an LSP ID that the primary 275 ingress has allocated for a protected LSP tunnel. The backup ingress 276 may use this LSP ID to set up a new LSP from the backup ingress to 277 the destinations of the protected LSP tunnel. This allows the new 278 LSP to share resources with the old one. 280 The flags are used to communicate status information from the backup 281 ingress to the primary ingress. 283 o Ingress local protection available: The backup ingress sets this 284 flag after backup LSPs are up and ready for locally protecting the 285 primary ingress. The backup ingress sends this to the primary 286 ingress to indicate that the primary ingress is locally protected. 288 o Ingress local protection in use: The backup ingress sets this flag 289 when it detects a failure in the primary ingress. The backup 290 ingress keeps it and does not send it to the primary ingress since 291 the primary ingress is down. 293 o Bandwidth protection: The backup ingress sets this flag if the 294 backup LSPs guarantee to provide desired bandwidth for the 295 protected LSP against the primary ingress failure. 297 The options are used by the primary ingress to specify the desired 298 behavior to the backup ingress. 300 o Revert to Ingress: The primary ingress sets this option indicating 301 that the traffic for the primary LSP successfully re-signaled will 302 be switched back to the primary ingress from the backup ingress 303 when the primary ingress is restored. 305 o P2MP Backup: This option is set to ask for the backup ingress to 306 use P2MP backup LSP to protect the primary ingress. Note that one 307 spare bit of the flags in the FAST-REROUTE object can be used to 308 indicate whether P2MP or P2P backup LSP is desired for protecting 309 an ingress and transit node. 311 The INGRESS_PROTECTION object may contain some sub objects below. 313 5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address 315 When the primary ingress of a protected LSP sends a PATH message with 316 an INGRESS_PROTECTION object to the backup ingress, the object may 317 have a Backup Ingress IPv4/IPv6 Address sub object containing an 318 IPv4/IPv6 address belonging to the backup ingress. The Type of the 319 sub object is TBD-1/TBD-2 for Backup Ingress IPv4/IPv6 Address. The 320 body of the sub object is given below: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | IPv4/IPv6 address (4/16 bytres) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 IPv4/IPv6 address: A 32/128-bit unicast, host address. 330 5.1.2. Subobject: Ingress IPv4/IPv6 Address 332 The INGRESS_PROTECTION object may have an Ingress IPv4/IPv6 Address 333 sub object containing an IPv4/IPv6 address belonging to the primary 334 ingress. The Type of the sub object is TBD-3/TBD-4 for Ingress IPv4/ 335 IPv6 Address. The sub object has the following body: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | IPv4/IPv6 address (4/16 bytres) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 IPv4/IPv6 address: A 32/128-bit unicast, host address. 345 5.1.3. Subobject: Traffic Descriptor 347 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 348 object describing the traffic to be mapped to the backup LSP on the 349 backup ingress for locally protecting the primary ingress. The Type 350 of the sub object is TBD-5/TBD-6/TBD-7 for Interface/IPv4/6 Prefix 351 respectively. The sub object has the following body: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Traffic Element 1 | 357 ~ ~ 358 | Traffic Element n | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 The Traffic Descriptor sub object may contain multiple Traffic 362 Elements of same type as follows: 364 o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a 365 32 bit index of an interface, from which the traffic is imported 366 into the backup LSP. 368 o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic 369 Elements is an IPv4/6 prefix, containing an 8-bit prefix length 370 followed by an IPv4/6 address prefix, whose length, in bits, was 371 specified by the prefix length, padded to a byte boundary. 373 5.1.4. Subobject: Label-Routes 375 The INGRESS_PROTECTION object in a PATH message from the primary 376 ingress to the backup ingress will have a Label-Routes sub object 377 containing the labels and routes that the next hops of the ingress 378 use. The Type of the sub object is TBD-8. The sub object has the 379 following body: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ~ Subobjects ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The Subobjects in the Label-Routes are copied from those in the 388 RECORD_ROUTE objects in the RESV messages that the primary ingress 389 receives from its next hops for the primary LSP. They MUST contain 390 the first hops of the LSP, each of which is paired with its label. 392 6. Behavior of Ingress Protection 394 6.1. Overview 396 There are four parts of ingress protection: 1) setting up the 397 necessary backup LSP forwarding state; 2) identifying the failure and 398 providing the fast repair (as discussed in Sections 3 and 4); 3) 399 maintaining the RSVP-TE control plane state until a global repair can 400 be done; and 4) performing the global repair(see Section 6.4). 402 There are two different proposed signaling approaches to obtain 403 ingress protection. They both use the same new INGRESS_PROTECTION 404 object. The object is sent in both PATH and RESV messages. 406 6.1.1. Relay-Message Method 408 The primary ingress relays the information for ingress protection of 409 an LSP to the backup ingress via PATH messages. Once the LSP is 410 created, the ingress of the LSP sends the backup ingress a PATH 411 message with an INGRESS_PROTECTION object with Label-Routes 412 subobject, which is populated with the next-hops and labels. This 413 provides sufficient information for the backup ingress to create the 414 appropriate forwarding state and backup LSP(s). 416 The ingress also sends the backup ingress all the other PATH messages 417 for the LSP with an empty INGRESS_PROTECTION object. Thus, the 418 backup ingress has access to all the PATH messages needed for 419 modification to refresh control-plane state after a failure. 421 The advantages of this method include: 1) the primary LSP is 422 independent of the backup ingress; 2) simple; 3) less configuration; 423 and 4) less control traffic. 425 6.1.2. Proxy-Ingress Method 427 Conceptually, a proxy ingress is created that starts the RSVP 428 signaling. The explicit path of the LSP goes from the proxy ingress 429 to the backup ingress and then to the real ingress. The behavior and 430 signaling for the proxy ingress is done by the real ingress; the use 431 of a proxy ingress address avoids problems with loop detection. 433 [ traffic source ] *** Primary LSP 434 $ $ --- Backup LSP 435 $ $ $$ Link 436 $ $ 437 [ proxy ingress ] [ backup ] 438 [ & ingress ] | 439 * | 440 *****[ MP ]----| 442 Figure 2: Example Protected LSP with Proxy Ingress Node 444 The backup ingress must know the merge points or next-hops and their 445 associated labels. This is accomplished by having the RSVP PATH and 446 RESV messages go through the backup ingress, although the forwarding 447 path need not go through the backup ingress. If the backup ingress 448 fails, the ingress simply removes the INGRESS_PROTECTION object and 449 forwards the PATH messages to the LSP's next-hop(s). If the ingress 450 has its LSP configured for ingress protection, then the ingress can 451 add the backup ingress and itself to the ERO and start forwarding the 452 PATH messages to the backup ingress. 454 Slightly different behavior can apply for the on-path and off-path 455 cases. In the on-path case, the backup ingress is a next hop node 456 after the ingress for the LSP. In the off-path, the backup ingress 457 is not any next-hop node after the ingress for all associated sub- 458 LSPs. 460 The key advantage of this approach is that it minimizes the special 461 handling code requires. Because the backup ingress is on the 462 signaling path, it can receive various notifications. It easily has 463 access to all the PATH messages needed for modification to be sent to 464 refresh control-plane state after a failure. 466 6.1.3. Comparing Two Methods 468 +-------+-----------+------+--------+-----------------+---------+ 469 | |Primary LSP|Simple|Config |PATH Msg from |Reuse | 470 |Method |Depends on | |Proxy- |Backup to primary|Some of | 471 | |Backup | |Ingress-|RESV Msg from |Existing | 472 | |Ingress | |ID |Primary to backup|Functions| 473 +-------+-----------+------+--------+-----------------+---------+ 474 |Relay- | No |Yes | No | No | Yes- | 475 |Message| | | | | | 476 +-------+-----------+------+--------+-----------------+---------+ 477 |Proxy- | Yes |Yes- | Yes | Yes | Yes | 478 |Ingress| | | | | | 479 +-------+-----------+------+--------+-----------------+---------+ 481 6.2. Ingress Behavior 483 The primary ingress must be configured with two or three pieces of 484 information for ingress protection. 486 o Backup Ingress Address: The primary ingress must know an IP 487 address for it to be included in the INGRESS_PROTECTION object. 489 o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The 490 Proxy-Ingress-Id is only used in the Record Route Object for 491 recording the proxy-ingress. If no proxy-ingress-id is specified, 492 then a local interface address that will not otherwise be included 493 in the Record Route Object can be used. A similar technique is 494 used in [RFC4090 Sec 6.1.1]. 496 o Application Traffic Identifier: The primary ingress and backup 497 ingress must both know what application traffic should be directed 498 into the LSP. If a list of prefixes in the Traffic Descriptor 499 sub-object will not suffice, then a commonly understood 500 Application Traffic Identifier can be sent between the primary 501 ingress and backup ingress. The exact meaning of the identifier 502 should be configured similarly at both the primary ingress and 503 backup ingress. The Application Traffic Identifier is understood 504 within the unique context of the primary ingress and backup 505 ingress. 507 With this additional information, the primary ingress can create and 508 signal the necessary RSVP extensions to support ingress protection. 510 6.2.1. Relay-Message Method 512 To protect the ingress of an LSP, the ingress does the following 513 after the LSP is up. 515 1. Select a PATH message. 517 2. If the backup ingress is off-path, then send it a PATH message 518 with the content from the selected PATH message and an 519 INGRESS_PROTECTION object; else (the backup ingress is a next 520 hop, i.e., on-path case) add an INGRESS_PROTECTION object into 521 the existing PATH message to the backup ingress (i.e., the next 522 hop). The object contains the Traffic-Descriptor sub-object, the 523 Backup Ingress Address sub-object and the Label-Routes sub- 524 object. The flags is set to indicate whether a Backup P2MP LSP 525 is desired. A second LSP-ID is allocated (if it is not allocated 526 yet) and used in the object. The Label-Routes sub-object 527 contains the next-hops of the ingress and their labels. 529 3. For each of the other PATH messages, send the backup ingress a 530 PATH message with the content copied from the message and an 531 empty INGRESS_PROTECTION object, which is an object without any 532 Traffic-Descriptor sub-object. 534 6.2.2. Proxy-Ingress Method 536 The primary ingress is responsible for starting the RSVP signaling 537 for the proxy-ingress node. To do this, the following is done for 538 the RSVP PATH message. 540 1. Compute the EROs for the LSP as normal for the ingress. 542 2. If the selected backup ingress node is not the first node on the 543 path (for all sub-LSPs), then insert at the beginning of the ERO 544 first the backup ingress node and then the ingress node. 546 3. In the PATH RRO, instead of recording the ingress node's address, 547 replace it with the Proxy-Ingress-Id. 549 4. Leave the HOP object populated as usual with information for the 550 ingress-node. 552 5. Add the INGRESS_PROTECTION object to the PATH message. Allocate 553 a second LSP-ID to be used in the INGRESS-PROTECTION object. 554 Include the Backup Ingress Address (IPv4 or IPv6) sub-object and 555 the Traffic-Descriptor sub-object. Set or clear the flag 556 indicating that a Backup P2MP LSP is desired. 558 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path 559 message. Indicate whether one-to-one backup is desired. 560 Indicate whether facility backup is desired. 562 7. The RSVP PATH message is sent to the backup node as normal. 564 If the ingress detects that it can't communicate with the backup 565 ingress, then the ingress should instead send the PATH message to the 566 next-hop indicated in the ERO computed in step 1. Once the ingress 567 detects that it can communicate with the backup ingress, the ingress 568 SHOULD follow the steps 1-7 to obtain ingress failure protection. 570 When the ingress node receives an RSVP PATH message with an INGRESS- 571 PROTECTION object and the object specifies that node as the ingress 572 node and the PHOP as the backup ingress node, the ingress node SHOULD 573 remove the INGRESS_PROTECTION object from the PATH message before 574 sending it out. Additionally, the ingress node must store that it 575 will install ingress forwarding state for the LSP rather than 576 midpoint forwarding. 578 When an RSVP RESV message is received by the ingress, it uses the 579 NHOP to determine whether the message is received from the backup 580 ingress or from a different node. The stored associated PATH message 581 contains an INGRESS_PROTECTION object that identifies the backup 582 ingress node. If the RESV message is not from the backup node, then 583 ingress forwarding state should be set up, and the INGRESS_PROTECTION 584 object MUST be added to the RESV before it is sent to the NHOP, which 585 should be the backup node. If the RESV message is from the backup 586 node, then the LSP should be considered available for use. 588 If the backup ingress node is on the forwarding path, then a RESV is 589 received with an INGRESS_PROTECTION object and an NHOP that matches 590 the backup ingress. In this case, the ingress node's address will 591 not appear after the backup ingress in the RRO. The ingress node 592 should set up ingress forwarding state, just as is done if the LSP 593 weren't ingress-node protected. 595 6.3. Backup Ingress Behavior 597 An LER determines that the ingress local protection is requested for 598 an LSP if the INGRESS_PROTECTION object is included in the PATH 599 message it receives for the LSP. The LER can further determine that 600 it is the backup ingress if one of its addresses is in the Backup 601 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 602 as the backup ingress will assume full responsibility of the ingress 603 after the primary ingress fails. In addition, the LER determines 604 that it is off-path if it is not a next hop of the primary ingress. 606 6.3.1. Backup Ingress Behavior in Off-path Case 608 The backup ingress considers itself as a PLR and the primary ingress 609 as its next hop and provides a local protection for the primary 610 ingress. It behaves very similarly to a PLR providing fast-reroute 611 where the primary ingress is considered as the failure-point to 612 protect. Where not otherwise specified, the behavior given in 613 [RFC4090] for a PLR should apply. 615 The backup ingress SHOULD follow the control-options specified in the 616 INGRESS_PROTECTION object and the flags and specifications in the 617 FAST-REROUTE object. This applies to providing a P2MP backup if the 618 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 619 set, facility backup if the "facility backup desired" is set, and 620 backup paths that support the desired bandwidth, and administrative- 621 colors that are requested. 623 If multiple non empty INGRESS_PROTECTION objects have been received 624 via multiple PATH messages for the same LSP, then the most recent one 625 MUST be the one used. 627 The backup ingress creates the appropriate forwarding state for the 628 backup LSP tunnel(s) to the merge point(s). 630 When the backup ingress sends a RESV message to the primary ingress, 631 it should add an INGRESS_PROTECTION object into the message. It 632 SHOULD set or clear the flags in the object to report "Ingress local 633 protection available", "Ingress local protection in use", and 634 "bandwidth protection". 636 If the backup ingress doesn't have a backup LSP tunnel to all the 637 merge points, it SHOULD clear "Ingress local protection available". 638 [Editor Note: It is possible to indicate the number or which are 639 unprotected via a sub-object if desired.] 641 When the primary ingress fails, the backup ingress redirects the 642 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 643 transmitting the traffic to the next hops of the primary ingress, 644 where the traffic is merged into the protected LSP. 646 In this case, the backup ingress keeps the PATH message with the 647 INGRESS_PROTECTION object received from the primary ingress and the 648 RESV message with the INGRESS_PROTECTION object to be sent to the 649 primary ingress. The backup ingress sets the "local protection in 650 use" flag in the RESV message, indicating that the backup ingress is 651 actively redirecting the traffic into the backup P2P LSPs or the 652 backup P2MP LSP for locally protecting the primary ingress failure. 654 Note that the RESV message with this piece of information will not be 655 sent to the primary ingress because the primary ingress has failed. 657 If the backup ingress has not received any PATH message from the 658 primary ingress for an extended period of time (e.g., a cleanup 659 timeout interval) and a confirmed primary ingress failure did not 660 occur, then the standard RSVP soft-state removal SHOULD occur. The 661 backup ingress SHALL remove the state for the PATH message from the 662 primary ingress, and tear down the one-to-one backup LSPs for 663 protecting the primary ingress if one-to-one backup is used or unbind 664 the facility backup LSPs if facility backup is used. 666 When the backup ingress receives a PATH message from the primary 667 ingress for locally protecting the primary ingress of a protected 668 LSP, it checks to see if any critical information has been changed. 669 If the next hops of the primary ingress are changed, the backup 670 ingress SHALL update its backup LSP(s) accordingly. 672 6.3.1.1. Relay-Message Method 674 When the backup ingress receives a PATH message with an non empty 675 INGRESS_PROTECTION object, it examines the object to learn what 676 traffic associated with the LSP. It determines the next-hops to be 677 merged to by examining the Label-Routes sub-object in the object. 679 The backup ingress stores the PATH message received from the primary 680 ingress, but does NOT forward it. 682 The backup ingress MUST respond with a RESV to the PATH message 683 received from the primary ingress. If the INGRESS_PROTECTION object 684 is not "empty", the backup ingress SHALL send the RESV message with 685 the state indicating protection is available after the backup LSP(s) 686 are successfully established. 688 6.3.1.2. Proxy-Ingress Method 690 The backup ingress determines the next-hops to be merged to by 691 collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- 692 object) from the Record Route Object of each RESV that are closest to 693 the top and not the Ingress router; this should be the second to the 694 top pair. If a Label-Routes sub-object is included in the 695 INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are 696 used to filter the set down to the specific next-hops where 697 protection is desired. A RESV message must have been received before 698 the Backup Ingress can create or select the appropriate backup LSP. 700 When the backup ingress receives a PATH message with the 701 INGRESS_PROTECTION object, the backup ingress examines the object to 702 learn what traffic associated with the LSP. The backup ingress 703 forwards the PATH message to the ingress node with the normal RSVP 704 changes. 706 When the backup ingress receives a RESV message with the 707 INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- 708 NULL label in the RRO. Then the backup ingress forwards the RESV 709 message to the ingress node, which is acting for the proxy ingress. 711 6.3.2. Backup Ingress Behavior in On-path Case 713 An LER as the backup ingress determines that it is on-path if one of 714 its addresses is a next hop of the primary ingress (and the primary 715 ingress is not its next hop via checking the PATH message with the 716 INGRESS_PROTECTION object received from the primary ingress for 717 Proxy-Ingress Method). The LER on-path sends the corresponding PATH 718 messages without any INGRESS_PROTECTION object to its next hops. It 719 creates a number of backup P2P LSPs or a backup P2MP LSP from itself 720 to the other next hops (i.e., the next hops other than the backup 721 ingress) of the primary ingress. The other next hops are from the 722 Label-Routes sub object. 724 It also creates a forwarding entry, which sends/multicasts the 725 traffic from the source to the next hops of the backup ingress along 726 the protected LSP when the primary ingress fails. The traffic is 727 described by the Traffic-Descriptor. 729 After the forwarding entry is created, all the backup P2P LSPs or the 730 backup P2MP LSP is up and associated with the protected LSP, the 731 backup ingress sends the primary ingress the RESV message with the 732 INGRESS_PROTECTION object containing the state of the local 733 protection such as "local protection available" flag set to one, 734 which indicates that the primary ingress is locally protected. 736 When the primary ingress fails, the backup ingress sends/multicasts 737 the traffic from the source to its next hops along the protected LSP 738 and imports the traffic into each of the backup P2P LSPs or the 739 backup P2MP LSP transmitting the traffic to the other next hops of 740 the primary ingress, where the traffic is merged into protected LSP. 742 During the local repair, the backup ingress continues to send the 743 PATH messages to its next hops as before, keeps the PATH message with 744 the INGRESS_PROTECTION object received from the primary ingress and 745 the RESV message with the INGRESS_PROTECTION object to be sent to the 746 primary ingress. It sets the "local protection in use" flag in the 747 RESV message. 749 6.3.3. Failure Detection and Refresh PATH Messages 751 As described in [RFC4090], it is necessary to refresh the PATH 752 messages via the backup LSP(s). The Backup Ingress MUST wait to 753 refresh the PATH messages until it can accurately detect that the 754 ingress node has failed. An example of such an accurate detection 755 would be that the IGP has no bi-directional links to the ingress node 756 and the last change was long enough in the past that changes should 757 have been received (i.e., an IGP network convergence time or 758 approximately 2-3 seconds) or a BFD session to the primary ingress' 759 loopback address has failed and stayed failed after the network has 760 reconverged. 762 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 763 as PLR, SHOULD modify and send any saved PATH messages associated 764 with the primary LSP to the corresponding next hops through backup 765 LSP(s). Any PATH message sent will not contain any 766 INGRESS_PROTECTION object. The RSVP_HOP object in the message 767 contains an IP source address belonging to the backup ingress. The 768 sender template object has the backup ingress address as its tunnel 769 sender address. 771 6.4. Revertive Behavior 773 Upon a failure event in the (primary) ingress of a protected LSP, the 774 protected LSP is locally repaired by the backup ingress. There are a 775 couple of basic strategies for restoring the LSP to a full working 776 path. 778 - Revert to Primary Ingress: When the primary ingress is restored, 779 it re-signals each of the LSPs that start from the primary 780 ingress. The traffic for every LSP successfully re-signaled is 781 switched back to the primary ingress from the backup ingress. 783 - Global Repair by Backup Ingress: After determining that the 784 primary ingress of an LSP has failed, the backup ingress computes 785 a new optimal path, signals a new LSP along the new path, and 786 switches the traffic to the new LSP. 788 6.4.1. Revert to Primary Ingress 790 If "Revert to Primary Ingress" is desired for a protected LSP, the 791 (primary) ingress of the LSP re-signals the LSP that starts from the 792 primary ingress after the primary ingress restores. When the LSP is 793 re-signaled successfully, the traffic is switched back to the primary 794 ingress from the backup ingress and redirected into the LSP starting 795 from the primary ingress. 797 If the ingress can resignal the PATH messages for the LSP, then the 798 ingress can specify the "Revert to Ingress" control-option in the 799 INGRESS_PROTECTION object. Doing so may cause a duplication of 800 traffic while the Ingress starts sending traffic again before the 801 Backup Ingress stops; the alternative is to drop traffic for a short 802 period of time. 804 Additionally, the Backup Ingress can set the "Revert To Ingress" 805 control-option as a request for the Ingress to take over. 807 6.4.2. Global Repair by Backup Ingress 809 When the backup ingress has determined that the primary ingress of 810 the protected LSP has failed (e.g., via the IGP), it can compute a 811 new path and signal a new LSP along the new path so that it no longer 812 relies upon local repair. To do this, the backup ingress uses the 813 same tunnel sender address in the Sender Template Object and uses the 814 previously allocated second LSP-ID in the INGRESS_PROTECTION object 815 of the PATH message as the LSP-ID of the new LSP. This allows the 816 new LSP to share resources with the old LSP. In addition, if the 817 Ingress recovers, the Backup Ingress SHOULD send it RESVs with the 818 INGRESS_PROTECTION object where the "Revert to Ingress" is specified. 819 The Secondary LSP ID should be the unused LSP ID - while the LSP ID 820 signaled in the RESV will be that currently active. The Ingress can 821 learn from the RESVs what to signal. Even if the Ingress does not 822 take over, the RESVs notify it that the particular LSP IDs are in 823 use. The Backup Ingress can reoptimize the new LSP as necessary 824 until the Ingress recovers. Alternately, the Backup Ingress can 825 create a new LSP with no bandwidth reservation that duplicates the 826 path(s) of the protected LSP, move traffic to the new LSP, delete the 827 protected LSP, and then resignal the new LSP with bandwidth. 829 7. Security Considerations 831 In principle this document does not introduce new security issues. 832 The security considerations pertaining to RFC 4090, RFC 4875 and 833 other RSVP protocols remain relevant. 835 8. IANA Considerations 837 TBD 839 9. Contributors 841 Renwei Li 842 Huawei Technologies 843 2330 Central Expressway 844 Santa Clara, CA 95050 845 USA 846 Email: renwei.li@huawei.com 848 Quintin Zhao 849 Huawei Technologies 850 Boston, MA 851 USA 852 Email: quintin.zhao@huawei.com 854 Zhenbin Li 855 Huawei Technologies 856 2330 Central Expressway 857 Santa Clara, CA 95050 858 USA 859 Email: zhenbin.li@huawei.com 861 Boris Zhang 862 Telus Communications 863 200 Consilium Pl Floor 15 864 Toronto, ON M1H 3J3 865 Canada 866 Email: Boris.Zhang@telus.com 868 Markus Jork 869 Juniper Networks 870 10 Technology Park Drive 871 Westford, MA 01886 872 USA 873 Email: mjork@juniper.net 875 10. Acknowledgement 877 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 878 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, 879 Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, and 880 Ronhazli Adam for their valuable comments and suggestions on this 881 draft. 883 11. References 885 11.1. Normative References 887 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 888 October 1994. 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, March 1997. 893 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 894 Considered Useful", BCP 82, RFC 3692, January 2004. 896 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 897 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 898 Functional Specification", RFC 2205, September 1997. 900 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 901 Label Switching Architecture", RFC 3031, January 2001. 903 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 904 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 905 Tunnels", RFC 3209, December 2001. 907 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 908 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 909 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 911 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 912 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 913 May 2005. 915 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 916 Multipoint Traffic-Engineered MPLS Label Switched Paths 917 (LSPs)", RFC 4461, April 2006. 919 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 920 "Extensions to Resource Reservation Protocol - Traffic 921 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 922 Switched Paths (LSPs)", RFC 4875, May 2007. 924 [P2MP-FRR] 925 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 926 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 927 draft-leroux-mpls-p2mp-te-bypass , March 1997. 929 11.2. Informative References 931 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 932 McManus, "Requirements for Traffic Engineering Over MPLS", 933 RFC 2702, September 1999. 935 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 936 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 937 Encoding", RFC 3032, January 2001. 939 Appendix A. Authors' Addresses 941 Huaimo Chen 942 Huawei Technologies 943 Boston, MA 944 USA 945 Email: huaimo.chen@huawei.com 947 Raveendra Torvi 948 Juniper Networks 949 10 Technology Park Drive 950 Westford, MA 01886 951 USA 952 Email: rtorvi@juniper.net 954 Ning So 955 Tata Communications 956 2613 Fairbourne Cir. 957 Plano, TX 75082 958 USA 959 Email: ningso01@gmail.com 960 Autumn Liu 961 Ericsson 962 300 Holger Way 963 San Jose, CA 95134 964 USA 965 Email: autumn.liu@ericsson.com 967 Alia Atlas 968 Juniper Networks 969 10 Technology Park Drive 970 Westford, MA 01886 971 USA 972 Email: akatlas@juniper.net 974 Yimin Shen 975 Juniper Networks 976 10 Technology Park Drive 977 Westford, MA 01886 978 USA 979 Email: yshen@juniper.net 981 Tarek Saad 982 Cisco Systems 983 Email: tsaad@cisco.com 985 Fengman Xu 986 Verizon 987 2400 N. Glenville Dr 988 Richardson, TX 75082 989 USA 990 Email: fengman.xu@verizon.com 992 Mehmet Toy 993 Comcast 994 1800 Bishops Gate Blvd. 995 Mount Laurel, NJ 08054 996 USA 997 Email: mehmet_toy@cable.comcast.com 998 Lei Liu 999 UC Davis 1000 USA 1001 Email: liulei.kddi@gmail.com