idnits 2.17.1 draft-ietf-teas-rsvp-ingress-protection-01.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 (January 10, 2015) is 3394 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 121, but not defined == Missing Reference: 'Ra' is mentioned on line 124, but not defined == Missing Reference: 'Rb' is mentioned on line 124, but not defined == Missing Reference: 'L3' is mentioned on line 124, but not defined == Unused Reference: 'RFC1700' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'P2MP-FRR' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 762, 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: July 14, 2015 Juniper Networks 6 January 10, 2015 8 Extensions to RSVP-TE for LSP Ingress Local Protection 9 draft-ietf-teas-rsvp-ingress-protection-01.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 July 14, 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/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.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 9 70 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 11 71 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 11 72 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 13 73 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 13 74 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 14 75 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 14 76 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 14 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Co-authors 88 Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu, 89 Mehmet Toy, Lei Liu 91 2. Introduction 93 For MPLS LSPs it is important to have a fast-reroute method for 94 protecting its ingress node as well as transit nodes. This is not 95 covered either in the fast-reroute method defined in [RFC4090] or in 96 the P2MP fast-reroute extensions to fast-reroute in [RFC4875]. 98 An alternate approach to local protection (fast-reroute) is to use 99 global protection and set up a second backup LSP (whether P2MP or 100 P2P) from a backup ingress to the egresses. The main disadvantage of 101 this is that the backup LSP may reserve additional network bandwidth. 103 This specification defines a simple extension to RSVP-TE for local 104 protection of the ingress node of a P2MP or P2P LSP. 106 2.1. An Example of Ingress Local Protection 108 Figure 1 shows an example of using a backup P2MP LSP to locally 109 protect the ingress of a primary P2MP LSP, which is from ingress R1 110 to three egresses: L1, L2 and L3. The backup LSP is from backup 111 ingress Ra to the next hops R2 and R4 of ingress R1. 113 [R2]******[R3]*****[L1] 114 * | **** Primary LSP 115 * | ---- Backup LSP 116 * / .... BFD Session 117 * / $ Link 118 ....[R1]*******[R4]****[R5]*****[L2] $ 119 : $ $ / / * $ 120 : $ $ / / * 121 [S] $ / / * 122 $ $ / / * 123 $ $/ / * 124 [Ra]----[Rb] [L3] 126 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 128 In normal operations, source S sends the traffic to primary ingress 129 R1. R1 imports the traffic into the primary LSP. 131 When source S detects the failure of R1, it switches the traffic to 132 backup ingress Ra, which imports the traffic from S into the backup 133 LSP to R1's next hops R2 and R4, where the traffic is merged into the 134 primary LSP, and then sent to egresses L1, L2 and L3. 136 Source S should be able to detect the failure of R1 and switch the 137 traffic within 10s of ms. 139 Note that the backup ingress must be one logical hop away from the 140 ingress. A logical hop is a direct link or a tunnel such as a GRE 141 tunnel, over which RSVP-TE messages may be exchanged. 143 2.2. Ingress Local Protection with FRR 145 Through using the ingress local protection and the FRR, we can 146 locally protect the ingress, all the links and the transit nodes of 147 an LSP. The traffic switchover time is within 10s of ms whenever the 148 ingress, any of the links and the transit nodes of the LSP fails. 150 The ingress node of the LSP can be locally protected through using 151 the ingress local protection. All the links and all the transit 152 nodes of the LSP can be locally protected through using the FRR. 154 3. Ingress Failure Detection 156 Exactly how to detect the failure of the ingress is out of scope. 157 However, it is necessary to discuss different modes for detecting the 158 failure because they determine what is the required behavior for the 159 source and backup ingress. 161 3.1. Source Detects Failure 163 Source Detects Failure or Source-Detect for short means that the 164 source is responsible for fast detecting the failure of the primary 165 ingress of an LSP. The backup ingress is ready to import the traffic 166 from the source into the backup LSP after the backup LSP is up. 168 In normal operations, the source sends the traffic to the primary 169 ingress. When the source detects the failure of the primary ingress, 170 it switches the traffic to the backup ingress, which delivers the 171 traffic to the next hops of the primary ingress through the backup 172 LSP, where the traffic is merged into the primary LSP. 174 For a P2P LSP, after the primary ingress fails, the backup ingress 175 must use a method to reliably detect the failure of the primary 176 ingress before the PATH message for the LSP expires at the next hop 177 of the primary ingress. After reliably detecting the failure, the 178 backup ingress sends/refreshes the PATH message to the next hop 179 through the backup LSP as needed. 181 After the primary ingress fails, it will not be reachable after 182 routing convergence. Thus checking whether the primary ingress 183 (address) is reachable is a possible method. 185 3.2. Backup and Source Detect Failure 187 Backup and Source Detect Failure or Backup-Source-Detect for short 188 means that both the backup ingress and the source are concurrently 189 responsible for fast detecting the failure of the primary ingress. 191 In normal operations, the source sends the traffic to the primary 192 ingress. It switches the traffic to the backup ingress when it 193 detects the failure of the primary ingress. 195 The backup ingress does not import any traffic from the source into 196 the backup LSP in normal operations. When it detects the failure of 197 the primary ingress, it imports the traffic from the source into the 198 backup LSP to the next hops of the primary ingress, where the traffic 199 is merged into the primary LSP. 201 The source-detect is preferred. It is simpler than the backup- 202 source-detect, which needs both the source and the backup ingress 203 detect the ingress failure quickly. 205 4. Backup Forwarding State 207 Before the primary ingress fails, the backup ingress is responsible 208 for creating the necessary backup LSPs. These LSPs might be multiple 209 bypass P2P LSPs that avoid the ingress. Alternately, the backup 210 ingress could choose to use a single backup P2MP LSP as a bypass or 211 detour to protect the primary ingress of a primary P2MP LSP. 213 The backup ingress may be off-path or on-path of an LSP. If a backup 214 ingress is not any node of the LSP, we call it is off-path. If a 215 backup ingress is a next-hop of the primary ingress of the LSP, we 216 call it is on-path. If it is on-path, the primary forwarding state 217 associated with the primary LSP SHOULD be clearly separated from the 218 backup LSP(s) state. 220 4.1. Forwarding State for Backup LSP 222 A forwarding entry for a backup LSP is created on the backup ingress 223 after the LSP is set up. Depending on the failure-detection mode 224 (e.g., source-detect), it may be used to forward received traffic or 225 simply be inactive (e.g., backup-source-detect) until required. In 226 either case, when the primary ingress fails, this entry is used to 227 import the traffic into the backup LSP to the next hops of the 228 primary ingress, where the traffic is merged into the primary LSP. 230 The forwarding entry for a backup LSP is a local implementation 231 issue. In one device, it may have an inactive flag. This inactive 232 forwarding entry is not used to forward any traffic normally. When 233 the primary ingress fails, it is changed to active, and thus the 234 traffic from the source is imported into the backup LSP. 236 5. Protocol Extensions 238 A new object INGRESS_PROTECTION is defined for signaling ingress 239 local protection. It is backward compatible. 241 5.1. INGRESS_PROTECTION Object 243 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 244 message is used to control the backup for protecting the primary 245 ingress of a primary LSP. The primary ingress MUST insert this 246 object into the PATH message to be sent to the backup ingress for 247 protecting the primary ingress. It has the following format: 249 Class-Num = TBD C-Type = TBD 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Length (bytes) | Class-Num | C-Type | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Secondary LSP ID | Flags | Options | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 ~ (Subobjects) ~ 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Flags 261 0x01 Ingress local protection available 262 0x02 Ingress local protection in use 263 0x04 Bandwidth protection 265 Options 266 0x01 Revert to Ingress 267 0x02 P2MP Backup 269 The Secondary LSP ID in the object is an LSP ID that the primary 270 ingress has allocated for a protected LSP tunnel. The backup ingress 271 may use this LSP ID to set up a new LSP from the backup ingress to 272 the destinations of the protected LSP tunnel. This allows the new 273 LSP to share resources with the old one. 275 The flags are used to communicate status information from the backup 276 ingress to the primary ingress. 278 o Ingress local protection available: The backup ingress sets this 279 flag after backup LSPs are up and ready for locally protecting the 280 primary ingress. The backup ingress sends this to the primary 281 ingress to indicate that the primary ingress is locally protected. 283 o Ingress local protection in use: The backup ingress sets this flag 284 when it detects a failure in the primary ingress. The backup 285 ingress keeps it and does not send it to the primary ingress since 286 the primary ingress is down. 288 o Bandwidth protection: The backup ingress sets this flag if the 289 backup LSPs guarantee to provide desired bandwidth for the 290 protected LSP against the primary ingress failure. 292 The options are used by the primary ingress to specify the desired 293 behavior to the backup ingress. 295 o Revert to Ingress: The primary ingress sets this option indicating 296 that the traffic for the primary LSP successfully re-signaled will 297 be switched back to the primary ingress from the backup ingress 298 when the primary ingress is restored. 300 o P2MP Backup: This option is set to ask for the backup ingress to 301 use P2MP backup LSP to protect the primary ingress. Note that one 302 spare bit of the flags in the FAST-REROUTE object can be used to 303 indicate whether P2MP or P2P backup LSP is desired for protecting 304 an ingress and transit node. 306 The INGRESS_PROTECTION object may contain some sub objects below. 308 5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address 310 When the primary ingress of a protected LSP sends a PATH message with 311 an INGRESS_PROTECTION object to the backup ingress, the object may 312 have a Backup Ingress IPv4/IPv6 Address sub object containing an 313 IPv4/IPv6 address belonging to the backup ingress. The Type of the 314 sub object is TBD-1/TBD-2 for Backup Ingress IPv4/IPv6 Address. The 315 body of the sub object is given below: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | IPv4/IPv6 address (4/16 bytres) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 IPv4/IPv6 address: A 32/128-bit unicast, host address. 325 5.1.2. Subobject: Ingress IPv4/IPv6 Address 327 The INGRESS_PROTECTION object may have an Ingress IPv4/IPv6 Address 328 sub object containing an IPv4/IPv6 address belonging to the primary 329 ingress. The Type of the sub object is TBD-3/TBD-4 for Ingress IPv4/ 330 IPv6 Address. The sub object has the following body: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | IPv4/IPv6 address (4/16 bytres) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 IPv4/IPv6 address: A 32/128-bit unicast, host address. 340 5.1.3. Subobject: Traffic Descriptor 342 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 343 object describing the traffic to be mapped to the backup LSP on the 344 backup ingress for locally protecting the primary ingress. The Type 345 of the sub object is TBD-5/TBD-6/TBD-7 for Interface/IPv4/6 Prefix 346 respectively. The sub object has the following body: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Traffic Element 1 | 352 ~ ~ 353 | Traffic Element n | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 The Traffic Descriptor sub object may contain multiple Traffic 357 Elements of same type as follows: 359 o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a 360 32 bit index of an interface, from which the traffic is imported 361 into the backup LSP. 363 o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic 364 Elements is an IPv4/6 prefix, containing an 8-bit prefix length 365 followed by an IPv4/6 address prefix, whose length, in bits, was 366 specified by the prefix length, padded to a byte boundary. 368 5.1.4. Subobject: Label-Routes 370 The INGRESS_PROTECTION object in a PATH message from the primary 371 ingress to the backup ingress will have a Label-Routes sub object 372 containing the labels and routes that the next hops of the ingress 373 use. The Type of the sub object is TBD-8. The sub object has the 374 following body: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ Subobjects ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 The Subobjects in the Label-Routes are copied from those in the 383 RECORD_ROUTE objects in the RESV messages that the primary ingress 384 receives from its next hops for the primary LSP. They MUST contain 385 the first hops of the LSP, each of which is paired with its label. 387 6. Behavior of Ingress Protection 389 6.1. Overview 391 There are four parts of ingress protection: 1) setting up the 392 necessary backup LSP forwarding state; 2) identifying the failure and 393 providing the fast repair (as discussed in Sections 3 and 4); 3) 394 maintaining the RSVP-TE control plane state until a global repair can 395 be done; and 4) performing the global repair(see Section 6.4). 397 6.2. Ingress Behavior 399 The primary ingress must be configured with a couple of pieces of 400 information for ingress protection. 402 o Backup Ingress Address: The primary ingress must know an IP 403 address for it to be included in the INGRESS_PROTECTION object. 405 o Application Traffic Identifier: The primary ingress and backup 406 ingress must both know what application traffic should be directed 407 into the LSP. If a list of prefixes in the Traffic Descriptor 408 sub-object will not suffice, then a commonly understood 409 Application Traffic Identifier can be sent between the primary 410 ingress and backup ingress. The exact meaning of the identifier 411 should be configured similarly at both the primary ingress and 412 backup ingress. The Application Traffic Identifier is understood 413 within the unique context of the primary ingress and backup 414 ingress. 416 With this additional information, the primary ingress can create and 417 signal the necessary RSVP extensions to support ingress protection. 419 The primary ingress relays the information for ingress protection of 420 an LSP to the backup ingress via PATH messages. Once the LSP is 421 created, the ingress of the LSP sends the backup ingress a PATH 422 message with an INGRESS_PROTECTION object with Label-Routes 423 subobject, which is populated with the next-hops and labels. This 424 provides sufficient information for the backup ingress to create the 425 appropriate forwarding state and backup LSP(s). 427 The ingress also sends the backup ingress all the other PATH messages 428 for the LSP with an empty INGRESS_PROTECTION object. Thus, the 429 backup ingress has access to all the PATH messages needed for 430 modification to refresh control-plane state after a failure. 432 To protect the ingress of an LSP, the ingress does the following 433 after the LSP is up. 435 1. Select a PATH message. 437 2. If the backup ingress is off-path, then send it a PATH message 438 with the content from the selected PATH message and an 439 INGRESS_PROTECTION object; else (the backup ingress is a next 440 hop, i.e., on-path case) add an INGRESS_PROTECTION object into 441 the existing PATH message to the backup ingress (i.e., the next 442 hop). The object contains the Traffic-Descriptor sub-object, the 443 Backup Ingress Address sub-object and the Label-Routes sub- 444 object. The flags is set to indicate whether a Backup P2MP LSP 445 is desired. A second LSP-ID is allocated (if it is not allocated 446 yet) and used in the object. The Label-Routes sub-object 447 contains the next-hops of the ingress and their labels. 449 3. For each of the other PATH messages, send the backup ingress a 450 PATH message with the content copied from the message and an 451 empty INGRESS_PROTECTION object, which is an object without any 452 Traffic-Descriptor sub-object. 454 6.3. Backup Ingress Behavior 456 An LER determines that the ingress local protection is requested for 457 an LSP if the INGRESS_PROTECTION object is included in the PATH 458 message it receives for the LSP. The LER can further determine that 459 it is the backup ingress if one of its addresses is in the Backup 460 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 461 as the backup ingress will assume full responsibility of the ingress 462 after the primary ingress fails. In addition, the LER determines 463 that it is off-path if it is not a next hop of the primary ingress. 465 6.3.1. Backup Ingress Behavior in Off-path Case 467 The backup ingress considers itself as a PLR and the primary ingress 468 as its next hop and provides a local protection for the primary 469 ingress. It behaves very similarly to a PLR providing fast-reroute 470 where the primary ingress is considered as the failure-point to 471 protect. Where not otherwise specified, the behavior given in 472 [RFC4090] for a PLR should apply. 474 The backup ingress SHOULD follow the control-options specified in the 475 INGRESS_PROTECTION object and the flags and specifications in the 476 FAST-REROUTE object. This applies to providing a P2MP backup if the 477 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 478 set, facility backup if the "facility backup desired" is set, and 479 backup paths that support the desired bandwidth, and administrative- 480 colors that are requested. 482 If multiple non empty INGRESS_PROTECTION objects have been received 483 via multiple PATH messages for the same LSP, then the most recent one 484 MUST be the one used. 486 The backup ingress creates the appropriate forwarding state for the 487 backup LSP tunnel(s) to the merge point(s). 489 When the backup ingress sends a RESV message to the primary ingress, 490 it should add an INGRESS_PROTECTION object into the message. It 491 SHOULD set or clear the flags in the object to report "Ingress local 492 protection available", "Ingress local protection in use", and 493 "bandwidth protection". 495 If the backup ingress doesn't have a backup LSP tunnel to all the 496 merge points, it SHOULD clear "Ingress local protection available". 498 [Editor Note: It is possible to indicate the number or which are 499 unprotected via a sub-object if desired.] 501 When the primary ingress fails, the backup ingress redirects the 502 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 503 transmitting the traffic to the next hops of the primary ingress, 504 where the traffic is merged into the protected LSP. 506 In this case, the backup ingress keeps the PATH message with the 507 INGRESS_PROTECTION object received from the primary ingress and the 508 RESV message with the INGRESS_PROTECTION object to be sent to the 509 primary ingress. The backup ingress sets the "local protection in 510 use" flag in the RESV message, indicating that the backup ingress is 511 actively redirecting the traffic into the backup P2P LSPs or the 512 backup P2MP LSP for locally protecting the primary ingress failure. 514 Note that the RESV message with this piece of information will not be 515 sent to the primary ingress because the primary ingress has failed. 517 If the backup ingress has not received any PATH message from the 518 primary ingress for an extended period of time (e.g., a cleanup 519 timeout interval) and a confirmed primary ingress failure did not 520 occur, then the standard RSVP soft-state removal SHOULD occur. The 521 backup ingress SHALL remove the state for the PATH message from the 522 primary ingress, and tear down the one-to-one backup LSPs for 523 protecting the primary ingress if one-to-one backup is used or unbind 524 the facility backup LSPs if facility backup is used. 526 When the backup ingress receives a PATH message from the primary 527 ingress for locally protecting the primary ingress of a protected 528 LSP, it checks to see if any critical information has been changed. 529 If the next hops of the primary ingress are changed, the backup 530 ingress SHALL update its backup LSP(s) accordingly. 532 When the backup ingress receives a PATH message with an non empty 533 INGRESS_PROTECTION object, it examines the object to learn what 534 traffic associated with the LSP. It determines the next-hops to be 535 merged to by examining the Label-Routes sub-object in the object. 537 The backup ingress stores the PATH message received from the primary 538 ingress, but does NOT forward it. 540 The backup ingress responds with a RESV to the PATH message received 541 from the primary ingress. If the INGRESS_PROTECTION object is not 542 "empty", the backup ingress SHALL send the RESV message with the 543 state indicating protection is available after the backup LSP(s) are 544 successfully established. 546 6.3.2. Backup Ingress Behavior in On-path Case 548 An LER as the backup ingress determines that it is on-path if one of 549 its addresses is a next hop of the primary ingress. The LER on-path 550 sends the corresponding PATH messages without any INGRESS_PROTECTION 551 object to its next hops. It creates a number of backup P2P LSPs or a 552 backup P2MP LSP from itself to the other next hops (i.e., the next 553 hops other than the backup ingress) of the primary ingress. The 554 other next hops are from the Label-Routes sub object. 556 It also creates a forwarding entry, which sends/multicasts the 557 traffic from the source to the next hops of the backup ingress along 558 the protected LSP when the primary ingress fails. The traffic is 559 described by the Traffic-Descriptor. 561 After the forwarding entry is created, all the backup P2P LSPs or the 562 backup P2MP LSP is up and associated with the protected LSP, the 563 backup ingress sends the primary ingress the RESV message with the 564 INGRESS_PROTECTION object containing the state of the local 565 protection such as "local protection available" flag set to one, 566 which indicates that the primary ingress is locally protected. 568 When the primary ingress fails, the backup ingress sends/multicasts 569 the traffic from the source to its next hops along the protected LSP 570 and imports the traffic into each of the backup P2P LSPs or the 571 backup P2MP LSP transmitting the traffic to the other next hops of 572 the primary ingress, where the traffic is merged into protected LSP. 574 During the local repair, the backup ingress continues to send the 575 PATH messages to its next hops as before, keeps the PATH message with 576 the INGRESS_PROTECTION object received from the primary ingress and 577 the RESV message with the INGRESS_PROTECTION object to be sent to the 578 primary ingress. It sets the "local protection in use" flag in the 579 RESV message. 581 6.3.3. Failure Detection and Refresh PATH Messages 583 As described in [RFC4090], it is necessary to refresh the PATH 584 messages via the backup LSP(s). The Backup Ingress MUST wait to 585 refresh the PATH messages until it can accurately detect that the 586 ingress node has failed. An example of such an accurate detection 587 would be that the IGP has no bi-directional links to the ingress node 588 and the last change was long enough in the past that changes should 589 have been received (i.e., an IGP network convergence time or 590 approximately 2-3 seconds) or a BFD session to the primary ingress' 591 loopback address has failed and stayed failed after the network has 592 reconverged. 594 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 595 as PLR, SHOULD modify and send any saved PATH messages associated 596 with the primary LSP to the corresponding next hops through backup 597 LSP(s). Any PATH message sent will not contain any 598 INGRESS_PROTECTION object. The RSVP_HOP object in the message 599 contains an IP source address belonging to the backup ingress. The 600 sender template object has the backup ingress address as its tunnel 601 sender address. 603 6.4. Revertive Behavior 605 Upon a failure event in the (primary) ingress of a protected LSP, the 606 protected LSP is locally repaired by the backup ingress. There are a 607 couple of basic strategies for restoring the LSP to a full working 608 path. 610 - Revert to Primary Ingress: When the primary ingress is restored, 611 it re-signals each of the LSPs that start from the primary 612 ingress. The traffic for every LSP successfully re-signaled is 613 switched back to the primary ingress from the backup ingress. 615 - Global Repair by Backup Ingress: After determining that the 616 primary ingress of an LSP has failed, the backup ingress computes 617 a new optimal path, signals a new LSP along the new path, and 618 switches the traffic to the new LSP. 620 6.4.1. Revert to Primary Ingress 622 If "Revert to Primary Ingress" is desired for a protected LSP, the 623 (primary) ingress of the LSP re-signals the LSP that starts from the 624 primary ingress after the primary ingress restores. After the LSP is 625 re-signaled successfully, the traffic can be switched back to the 626 primary ingress from the backup ingress on the source node and 627 redirected into the LSP starting from the primary ingress. 629 The primary ingress can specify the "Revert to Ingress" control- 630 option in the INGRESS_PROTECTION object in the PATH messages to the 631 backup ingress. After receiving the "Revert to Ingress" control- 632 option, the backup ingress stops sending/refreshing PATH messages for 633 the protected LSP. 635 6.4.2. Global Repair by Backup Ingress 637 When the backup ingress has determined that the primary ingress of 638 the protected LSP has failed (e.g., via the IGP), it can compute a 639 new path and signal a new LSP along the new path so that it no longer 640 relies upon local repair. To do this, the backup ingress uses the 641 same tunnel sender address in the Sender Template Object and uses the 642 previously allocated second LSP-ID in the INGRESS_PROTECTION object 643 of the PATH message as the LSP-ID of the new LSP. This allows the 644 new LSP to share resources with the old LSP. In addition, if the 645 Ingress recovers, the Backup Ingress SHOULD send it RESVs with the 646 INGRESS_PROTECTION object where the "Revert to Ingress" is specified. 647 The Secondary LSP ID should be the unused LSP ID - while the LSP ID 648 signaled in the RESV will be that currently active. The Ingress can 649 learn from the RESVs what to signal. Even if the Ingress does not 650 take over, the RESVs notify it that the particular LSP IDs are in 651 use. The Backup Ingress can reoptimize the new LSP as necessary 652 until the Ingress recovers. Alternately, the Backup Ingress can 653 create a new LSP with no bandwidth reservation that duplicates the 654 path(s) of the protected LSP, move traffic to the new LSP, delete the 655 protected LSP, and then resignal the new LSP with bandwidth. 657 7. Security Considerations 659 In principle this document does not introduce new security issues. 660 The security considerations pertaining to RFC 4090, RFC 4875 and 661 other RSVP protocols remain relevant. 663 8. IANA Considerations 665 TBD 667 9. Contributors 669 Renwei Li 670 Huawei Technologies 671 2330 Central Expressway 672 Santa Clara, CA 95050 673 USA 674 Email: renwei.li@huawei.com 676 Quintin Zhao 677 Huawei Technologies 678 Boston, MA 679 USA 680 Email: quintin.zhao@huawei.com 681 Zhenbin Li 682 Huawei Technologies 683 2330 Central Expressway 684 Santa Clara, CA 95050 685 USA 686 Email: zhenbin.li@huawei.com 688 Boris Zhang 689 Telus Communications 690 200 Consilium Pl Floor 15 691 Toronto, ON M1H 3J3 692 Canada 693 Email: Boris.Zhang@telus.com 695 Markus Jork 696 Juniper Networks 697 10 Technology Park Drive 698 Westford, MA 01886 699 USA 700 Email: mjork@juniper.net 702 10. Acknowledgement 704 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 705 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, 706 Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, and 707 Ronhazli Adam for their valuable comments and suggestions on this 708 draft. 710 11. References 712 11.1. Normative References 714 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 715 October 1994. 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 721 Considered Useful", BCP 82, RFC 3692, January 2004. 723 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 724 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 725 Functional Specification", RFC 2205, September 1997. 727 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 728 Label Switching Architecture", RFC 3031, January 2001. 730 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 731 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 732 Tunnels", RFC 3209, December 2001. 734 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 735 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 736 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 738 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 739 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 740 May 2005. 742 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 743 Multipoint Traffic-Engineered MPLS Label Switched Paths 744 (LSPs)", RFC 4461, April 2006. 746 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 747 "Extensions to Resource Reservation Protocol - Traffic 748 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 749 Switched Paths (LSPs)", RFC 4875, May 2007. 751 [P2MP-FRR] 752 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 753 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 754 draft-leroux-mpls-p2mp-te-bypass , March 1997. 756 11.2. Informative References 758 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 759 McManus, "Requirements for Traffic Engineering Over MPLS", 760 RFC 2702, September 1999. 762 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 763 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 764 Encoding", RFC 3032, January 2001. 766 Appendix A. Authors' Addresses 767 Huaimo Chen 768 Huawei Technologies 769 Boston, MA 770 USA 771 Email: huaimo.chen@huawei.com 773 Raveendra Torvi 774 Juniper Networks 775 10 Technology Park Drive 776 Westford, MA 01886 777 USA 778 Email: rtorvi@juniper.net 780 Ning So 781 Tata Communications 782 2613 Fairbourne Cir. 783 Plano, TX 75082 784 USA 785 Email: ningso01@gmail.com 787 Autumn Liu 788 Ericsson 789 300 Holger Way 790 San Jose, CA 95134 791 USA 792 Email: autumn.liu@ericsson.com 794 Alia Atlas 795 Juniper Networks 796 10 Technology Park Drive 797 Westford, MA 01886 798 USA 799 Email: akatlas@juniper.net 800 Yimin Shen 801 Juniper Networks 802 10 Technology Park Drive 803 Westford, MA 01886 804 USA 805 Email: yshen@juniper.net 807 Tarek Saad 808 Cisco Systems 809 Email: tsaad@cisco.com 811 Fengman Xu 812 Verizon 813 2400 N. Glenville Dr 814 Richardson, TX 75082 815 USA 816 Email: fengman.xu@verizon.com 818 Mehmet Toy 819 Comcast 820 1800 Bishops Gate Blvd. 821 Mount Laurel, NJ 08054 822 USA 823 Email: mehmet_toy@cable.comcast.com 825 Lei Liu 826 UC Davis 827 USA 828 Email: liulei.kddi@gmail.com