idnits 2.17.1 draft-ietf-teas-rsvp-ingress-protection-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (February 5, 2017) is 2631 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'S' is mentioned on line 165, but not defined == Missing Reference: 'Ra' is mentioned on line 168, but not defined == Missing Reference: 'Rb' is mentioned on line 168, but not defined == Missing Reference: 'L3' is mentioned on line 168, but not defined == Unused Reference: 'RFC2119' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'RFC6378' is defined on line 1075, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 11 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: Experimental R. Torvi, Ed. 5 Expires: August 9, 2017 Juniper Networks 6 February 5, 2017 8 Extensions to RSVP-TE for LSP Ingress FRR Protection 9 draft-ietf-teas-rsvp-ingress-protection-09.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 August 9, 2017. 35 Copyright Notice 37 Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. An Example of Ingress Local Protection . . . . . . . . . . 4 54 1.2. Ingress Local Protection with FRR . . . . . . . . . . . . 5 55 2. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 5 56 2.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 5 57 2.2. Backup and Source Detect Failure . . . . . . . . . . . . . 6 58 3. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6 59 3.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 6 60 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7 62 4.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 8 63 4.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 9 64 4.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 9 65 4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 10 66 4.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 10 67 4.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11 68 5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11 69 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 71 5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 72 5.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 13 73 5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 74 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14 75 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 15 76 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16 77 5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16 78 5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18 79 5.3.3. Failure Detection and Refresh PATH Messages . . . . . 19 80 5.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19 81 5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 20 82 5.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 20 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21 86 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 There is a need for a fast and efficient protection against the 95 failure of the ingress node of a MPLS TE LSP (either P2MP LSP or P2P 96 LSP). 98 For a MPLS TE LSP, protecting the failures of its transit nodes using 99 fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875 100 for P2MP LSP. However, protecting the failure of its ingress node 101 using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS 102 Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 103 can provide a protection against the failure of any transit node of a 104 LSP between the ingress node and the egress node of the LSP, but 105 cannot protect against the failure of the ingress node. 107 To protect against the failure of the (primary) ingress node of a 108 primary end to end P2MP (or P2P) TE LSP, a typical existing solution 109 is to set up a secondary backup end to end P2MP (or P2P) TE LSP from 110 a backup ingress node, which is different from the primary ingress 111 node, to the backup egress nodes (or node), which are (or is) 112 different from the primary egress nodes (or node) of the primary LSP. 113 For a P2MP TE LSP, on each of the primary (and backup) egress nodes, 114 a P2P LSP is created from the egress node to its primary (backup) 115 ingress node and configured with BFD. This is used to detect the 116 failure of the primary (backup) ingress node for the receiver to 117 switch to the backup (or primary) egress node to receive the traffic 118 after the primary (or backup) ingress node fails when both the 119 primary LSP and the secondary LSP carry the traffic. In addition, 120 FRR may be used to provide protections against the failures of the 121 transit nodes and the links of the primary and secondary end to end 122 TE LSPs. 124 There are a number of issues in this solution, which are briefed as 125 follows: 127 o It consumes lots of network resources. Double states need to be 128 maintained in the network since two end to end TE LSPs are 129 created. Double link bandwidth is reserved and used when both the 130 primary and the secondary end to end TE LSPs carry the traffic at 131 the same time. 133 o More operations are needed, which include the configurations of 134 two end to end TE LSPs and BFDs from each of the egress nodes to 135 its corresponding ingress node. 137 o The detection of the failure of the ingress node may not be 138 reliable. Any failure on the path of the BFD from an egress node 139 to an ingress node may cause the BFD down to indicate the failure 140 of the ingress node. 142 o The speed of protection against the failure of the ingress node 143 may be slow. 145 This specification defines a simple extension to RSVP-TE for local 146 protection (FRR) of the ingress node of a P2MP or P2P LSP to resolve 147 these issues. Ingress local protection and ingress FRR protection 148 will be used exchangeably. 150 1.1. An Example of Ingress Local Protection 152 Figure 1 shows an example of using a backup P2MP LSP to locally 153 protect the ingress of a primary P2MP LSP, which is from ingress R1 154 to three egresses: L1, L2 and L3. The backup LSP is from backup 155 ingress Ra to the next hops R2 and R4 of ingress R1. 157 [R2]******[R3]*****[L1] 158 * | **** Primary LSP 159 * | ---- Backup LSP 160 * / .... BFD Session 161 * / $ Link 162 ....[R1]*******[R4]****[R5]*****[L2] $ 163 : $ $ / / * $ 164 : $ $ / / * 165 [S] $ / / * 166 $ $ / / * 167 $ $/ / * 168 [Ra]----[Rb] [L3] 170 Figure 1: Backup P2MP LSP for Locally Protecting Ingress 172 In normal operations, source S sends the traffic to primary ingress 173 R1. R1 imports the traffic into the primary LSP. 175 When source S detects the failure of R1, it switches the traffic to 176 backup ingress Ra, which imports the traffic from S into the backup 177 LSP to R1's next hops R2 and R4, where the traffic is merged into the 178 primary LSP, and then sent to egresses L1, L2 and L3. Source S 179 detects the failure of R1 and switches the traffic within 10s of ms. 181 Note that the backup ingress is one logical hop away from the 182 ingress. A logical hop is a direct link or a tunnel such as a GRE 183 tunnel, over which RSVP-TE messages may be exchanged. 185 1.2. Ingress Local Protection with FRR 187 Through using the ingress local protection and the FRR, we can 188 locally protect the ingress, all the links and the transit nodes of 189 an LSP. The traffic switchover time is within 10s of ms whenever the 190 ingress, any of the links and the transit nodes of the LSP fails. 192 The ingress node of the LSP can be locally protected through using 193 the ingress local protection. All the links and all the transit 194 nodes of the LSP can be locally protected through using the FRR. 196 2. Ingress Failure Detection 198 Exactly how to detect the failure of the ingress is out of scope. 199 However, it is necessary to discuss different modes for detecting the 200 failure because they determine what is the required behavior for the 201 source and backup ingress. 203 2.1. Source Detects Failure 205 Source Detects Failure or Source-Detect for short means that the 206 source is responsible for fast detecting the failure of the primary 207 ingress of an LSP. The backup ingress is ready to import the traffic 208 from the source into the backup LSP(s) after the backup LSP(s) is up. 210 In normal operations, the source sends the traffic to the primary 211 ingress. When the source detects the failure of the primary ingress, 212 it switches the traffic to the backup ingress, which delivers the 213 traffic to the next hops of the primary ingress through the backup 214 LSP(s), where the traffic is merged into the primary LSP. 216 For a P2P LSP, after the primary ingress fails, the backup ingress 217 MUST use a method to reliably detect the failure of the primary 218 ingress before the PATH message for the LSP expires at the next hop 219 of the primary ingress. After reliably detecting the failure, the 220 backup ingress sends/refreshes the PATH message to the next hop 221 through the backup LSP as needed. 223 After the primary ingress fails, it will not be reachable after 224 routing convergence. Thus checking whether the primary ingress 225 (address) is reachable is a possible method. 227 2.2. Backup and Source Detect Failure 229 Backup and Source Detect Failure or Backup-Source-Detect for short 230 means that both the backup ingress and the source are concurrently 231 responsible for fast detecting the failure of the primary ingress. 233 In normal operations, the source sends the traffic to the primary 234 ingress. It switches the traffic to the backup ingress when it 235 detects the failure of the primary ingress. 237 The backup ingress does not import any traffic from the source into 238 the backup LSP in normal operations. When it detects the failure of 239 the primary ingress, it imports the traffic from the source into the 240 backup LSP to the next hops of the primary ingress, where the traffic 241 is merged into the primary LSP. 243 The source-detect is preferred. It is simpler than the backup- 244 source-detect, which needs both the source and the backup ingress 245 detect the ingress failure quickly. 247 3. Backup Forwarding State 249 Before the primary ingress fails, the backup ingress is responsible 250 for creating the necessary backup LSPs. These LSPs might be multiple 251 bypass P2P LSPs that avoid the ingress. Alternately, the backup 252 ingress could choose to use a single backup P2MP LSP as a bypass or 253 detour to protect the primary ingress of a primary P2MP LSP. 255 The backup ingress may be off-path or on-path of an LSP. If a backup 256 ingress is not any node of the LSP, we call it is off-path. If a 257 backup ingress is a next-hop of the primary ingress of the LSP, we 258 call it is on-path. If it is on-path, the primary forwarding state 259 associated with the primary LSP SHOULD be clearly separated from the 260 backup LSP(s) state. 262 3.1. Forwarding State for Backup LSP 264 A forwarding entry for a backup LSP is created on the backup ingress 265 after the LSP is set up. Depending on the failure-detection mode 266 (e.g., source-detect), it may be used to forward received traffic or 267 simply be inactive (e.g., backup-source-detect) until required. In 268 either case, when the primary ingress fails, this entry is used to 269 import the traffic into the backup LSP to the next hops of the 270 primary ingress, where the traffic is merged into the primary LSP. 272 The forwarding entry for a backup LSP is a local implementation 273 issue. In one device, it may have an inactive flag. This inactive 274 forwarding entry is not used to forward any traffic normally. When 275 the primary ingress fails, it is changed to active, and thus the 276 traffic from the source is imported into the backup LSP. 278 4. Protocol Extensions 280 A new object INGRESS_PROTECTION is defined for signaling ingress 281 local protection. It is backward compatible. 283 4.1. INGRESS_PROTECTION Object 285 The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH 286 message is used to control the backup for protecting the primary 287 ingress of a primary LSP. The primary ingress MUST insert this 288 object into the PATH message to be sent to the backup ingress for 289 protecting the primary ingress. It has the following format: 291 Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 292 C-Type = 2 for INGRESS_PROTECTION_IPv6 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Length (bytes) | Class-Num | C-Type | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Reserved (zero) | NUB | Flags | Options | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ (Subobjects) ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 NUB Number of Unprotected Branches 303 Flags 304 0x01 Ingress local protection available 305 0x02 Ingress local protection in use 306 0x04 Bandwidth protection 308 Options 309 0x01 Revert to Ingress 310 0x02 P2MP Backup 312 For protecting the ingress of a P2MP LSP, if the backup ingress 313 doesn't have a backup LSP to each of the next hops of the primary 314 ingress, it SHOULD clear "Ingress local protection available" and set 315 NUB to the number of the next hops to which there is no backup LSP. 317 The flags are used to communicate status information from the backup 318 ingress to the primary ingress. 320 o Ingress local protection available: The backup ingress MUST set 321 this flag after backup LSPs are up and ready for locally 322 protecting the primary ingress. The backup ingress sends this to 323 the primary ingress to indicate that the primary ingress is 324 locally protected. 326 o Ingress local protection in use: The backup ingress MUST set this 327 flag when it detects a failure in the primary ingress and actively 328 redirects the traffic into the backup LSPs. The backup ingress 329 keeps it and does not send it to the primary ingress since the 330 primary ingress is down. 332 o Bandwidth protection: The backup ingress MUST set this flag if the 333 backup LSPs guarantee to provide desired bandwidth for the 334 protected LSP against the primary ingress failure. 336 The options are used by the primary ingress to specify the desired 337 behavior to the backup ingress. 339 o Revert to Ingress: The primary ingress sets this option indicating 340 that the traffic for the primary LSP successfully re-signaled will 341 be switched back to the primary ingress from the backup ingress 342 when the primary ingress is restored. 344 o P2MP Backup: This option is set to ask for the backup ingress to 345 use P2MP backup LSP to protect the primary ingress. 347 The INGRESS_PROTECTION object may contain some sub objects of 348 following format: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length |Reserved (zero)| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Contents/Body of subobject | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 where Type is the type of a sub object, Length is the total size of 359 the sub object in bytes, including Type, Length and Contents fields. 361 4.1.1. Subobject: Backup Ingress IPv4 Address 363 When the primary ingress of a protected LSP sends a PATH message with 364 an INGRESS_PROTECTION object to the backup ingress, the object MUST 365 have a Backup Ingress IPv4 Address sub object containing an IPv4 366 address belonging to the backup ingress if IPv4 is used. The Type of 367 the sub object is TBD1 (the exact number to be assigned by IANA), and 368 the body of the sub object is given below: 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 | Backup ingress IPv4 address (4 bytes) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Backup ingress IPv4 address: An IPv4 host address of backup ingress 378 4.1.2. Subobject: Backup Ingress IPv6 Address 380 When the primary ingress of a protected LSP sends a PATH message with 381 an INGRESS_PROTECTION object to the backup ingress, the object MUST 382 have a Backup Ingress IPv6 Address sub object containing an IPv6 383 address belonging to the backup ingress if IPv6 is used. The Type of 384 the sub object is TBD2, the body of the sub object is given below: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Backup ingress IPv6 address (16 bytes) | 390 ~ ~ 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Backup ingress IPv6 address: An IPv6 host address of backup ingress 395 4.1.3. Subobject: Ingress IPv4 Address 397 The INGRESS_PROTECTION object may have an Ingress IPv4 Address sub 398 object containing an IPv4 address belonging to the primary ingress if 399 IPv4 is used. The Type of the sub object is TBD3. The sub object 400 has the following body: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Ingress IPv4 address (4 bytes) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Ingress IPv4 address: An IPv4 host address of ingress 410 4.1.4. Subobject: Ingress IPv6 Address 412 The INGRESS_PROTECTION object may have an Ingress IPv6 Address sub 413 object containing an IPv6 address belonging to the primary ingress if 414 IPv6 is used. The Type of the sub object is TBD4. The sub object 415 has the following body: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Ingress IPv6 address (16 bytes) | 421 ~ ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Ingress IPv6 address: An IPv6 host address of ingress 426 4.1.5. Subobject: Traffic Descriptor 428 The INGRESS_PROTECTION object may have a Traffic Descriptor sub 429 object describing the traffic to be mapped to the backup LSP on the 430 backup ingress for locally protecting the primary ingress. The Type 431 of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4 432 Prefix, IPv6 Prefix or Application Identifier respectively. The sub 433 object has the following body: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Traffic Element 1 | 439 ~ ~ 440 | Traffic Element n | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 The Traffic Descriptor sub object may contain multiple Traffic 444 Elements of same type as follows: 446 o Interface Traffic (Type TBD5): Each of the Traffic Elements is a 447 32 bit index of an interface, from which the traffic is imported 448 into the backup LSP. 450 o IPv4 Prefix Traffic (Type TBD6): Each of the Traffic Elements is 451 an IPv4 prefix, containing an 8-bit prefix length followed by an 452 IPv4 address prefix, whose length, in bits, is specified by the 453 prefix length, padded to a byte boundary. 455 o IPv6 Prefix Traffic (Type TBD7): Each of the Traffic Elements is 456 an IPv6 prefix, containing an 8-bit prefix length followed by an 457 IPv6 address prefix, whose length, in bits, is specified by the 458 prefix length, padded to a byte boundary. 460 o Application Traffic (Type TBD8): Each of the Traffic Elements is a 461 32 bit identifier of an application, from which the traffic is 462 imported into the backup LSP. 464 4.1.6. Subobject: Label-Routes 466 The INGRESS_PROTECTION object in a PATH message from the primary 467 ingress to the backup ingress will have a Label-Routes sub object 468 containing the labels and routes that the next hops of the ingress 469 use. The Type of the sub object is TBD9. The sub object has the 470 following body: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 ~ Subobjects ~ 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 The Subobjects in the Label-Routes are copied from those in the 479 RECORD_ROUTE objects in the RESV messages that the primary ingress 480 receives from its next hops for the primary LSP. They MUST contain 481 the first hops of the LSP, each of which is paired with its label. 483 5. Behavior of Ingress Protection 485 5.1. Overview 487 There are four parts of ingress protection: 1) setting up the 488 necessary backup LSP forwarding state based on the information for 489 ingress protection; 2) identifying the failure and providing the fast 490 repair (as discussed in Sections 3 and 4); 3) maintaining the RSVP-TE 491 control plane state until a global repair is done; and 4) performing 492 the global repair(see Section 6.4). 494 There are two different proposed signaling approaches to transfer the 495 information for ingress protection. They both use the same new 496 INGRESS_PROTECTION object. The object is sent in both PATH and RESV 497 messages. 499 5.1.1. Relay-Message Method 501 The primary ingress relays the information for ingress protection of 502 an LSP to the backup ingress via PATH messages. Once the LSP is 503 created, the ingress of the LSP sends the backup ingress a PATH 504 message with an INGRESS_PROTECTION object with Label-Routes 505 subobject, which is populated with the next-hops and labels. This 506 provides sufficient information for the backup ingress to create the 507 appropriate forwarding state and backup LSP(s). 509 The ingress also sends the backup ingress all the other PATH messages 510 for the LSP with an empty INGRESS_PROTECTION object. An 511 INGRESS_PROTECTION object without any Traffic-Descriptor sub-object 512 is called an empty INGRESS_PROTECTION object. Thus, the backup 513 ingress has access to all the PATH messages needed for modification 514 to refresh control-plane state after a failure. 516 The advantages of this method include: 1) the primary LSP is 517 independent of the backup ingress; 2) simple; 3) less configuration; 518 and 4) less control traffic. 520 5.1.2. Proxy-Ingress Method 522 Conceptually, a proxy ingress is created that starts the RSVP 523 signaling. The explicit path of the LSP goes from the proxy ingress 524 to the backup ingress and then to the real ingress. The behavior and 525 signaling for the proxy ingress is done by the real ingress; the use 526 of a proxy ingress address avoids problems with loop detection. 528 [ traffic source ] *** Primary LSP 529 $ $ --- Backup LSP 530 $ $ $$ Link 531 $ $ 532 [ proxy ingress ] [ backup ] 533 [ & ingress ] | 534 * | 535 *****[ MP ]----| 537 Figure 2: Example Protected LSP with Proxy Ingress Node 539 The backup ingress MUST know the merge points or next-hops and their 540 associated labels. This is accomplished by having the RSVP PATH and 541 RESV messages go through the backup ingress, although the forwarding 542 path need not go through the backup ingress. If the backup ingress 543 fails, the ingress simply removes the INGRESS_PROTECTION object and 544 forwards the PATH messages to the LSP's next-hop(s). If the ingress 545 has its LSP configured for ingress protection, then the ingress can 546 add the backup ingress and itself to the ERO and start forwarding the 547 PATH messages to the backup ingress. 549 Slightly different behavior can apply for the on-path and off-path 550 cases. In the on-path case, the backup ingress is a next hop node 551 after the ingress for the LSP. In the off-path, the backup ingress 552 is not any next-hop node after the ingress for all associated sub- 553 LSPs. 555 The key advantage of this approach is that it minimizes the special 556 handling code requires. Because the backup ingress is on the 557 signaling path, it can receive various notifications. It easily has 558 access to all the PATH messages needed for modification to be sent to 559 refresh control-plane state after a failure. 561 5.1.3. Comparing Two Methods 563 +-------+-----------+-------+--------------+---------------+---------+ 564 |\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse | 565 | \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some | 566 | \|Backup |Ingress|to Primary |to Backup |Existing | 567 |Method |Ingress |ID |Ingress |Ingress |Functions| 568 +-------+-----------+-------+--------------+---------------+---------+ 569 |Relay- | No | No | No | No | Yes- | 570 |Message| | | | | | 571 +-------+-----------+-------+--------------+---------------+---------+ 572 |Proxy- | Yes | Yes- | Yes | Yes | Yes | 573 |Ingress| | | | | | 574 +-------+-----------+-------+--------------+---------------+---------+ 576 5.2. Ingress Behavior 578 The primary ingress MUST be configured with a couple of pieces of 579 information for ingress protection. 581 o Backup Ingress Address: The primary ingress MUST know an IP 582 address for it to be included in the INGRESS_PROTECTION object. 584 o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The 585 Proxy-Ingress-Id is only used in the Record Route Object for 586 recording the proxy-ingress. If no proxy-ingress-id is specified, 587 then a local interface address that will not otherwise be included 588 in the Record Route Object can be used. A similar technique is 589 used in [RFC4090 Sec 6.1.1]. 591 o Application Traffic Identifier: The primary ingress and backup 592 ingress MUST both know what application traffic should be directed 593 into the LSP. If a list of prefixes in the Traffic Descriptor 594 sub-object will not suffice, then a commonly understood 595 Application Traffic Identifier can be sent between the primary 596 ingress and backup ingress. The exact meaning of the identifier 597 should be configured similarly at both the primary ingress and 598 backup ingress. The Application Traffic Identifier is understood 599 within the unique context of the primary ingress and backup 600 ingress. 602 o A connection between backup ingress and primary ingress: If there 603 is not any direct link between the primary ingress and the backup 604 ingress, a tunnel MUST be configured between them. 606 With this additional information, the primary ingress can create and 607 signal the necessary RSVP extensions to support ingress protection. 609 5.2.1. Relay-Message Method 611 To protect the primary ingress of an LSP, the primary ingress MUST do 612 the following after the LSP is up. 614 1. Select a PATH message P0 for the LSP. 616 2. If the backup ingress is off-path (the backup ingress is not the 617 next hop of the primary ingress for P0), then send it a PATH 618 message P0' with the content from P0 and an INGRESS_PROTECTION 619 object; else (the backup ingress is a next hop, i.e., on-path 620 case) add an INGRESS_PROTECTION object into the existing PATH 621 message to the backup ingress (i.e., the next hop). The object 622 contains the Traffic-Descriptor sub-object, the Backup Ingress 623 Address sub-object and the Label-Routes sub-object. The options 624 is set to indicate whether a Backup P2MP LSP is desired. The 625 Label-Routes sub-object contains the next-hops of the primary 626 ingress and their labels. 628 3. For each Pi of the other PATH messages for the LSP, send the 629 backup ingress a PATH message Pi' with the content copied from Pi 630 and an empty INGRESS_PROTECTION object. 632 For every PATH message Pj' (i.e., P0'/Pi') to be sent to the backup 633 ingress, it has the same SESSION as Pj (i.e., P0/Pi). If the backup 634 ingress is off-path, the primary ingress updates Pj' according to the 635 backup ingress as its next hop before sending it. It adds the backup 636 ingress to the beginning of the ERO, and sets RSVP_HOP based on the 637 interface to the backup ingress. The primary ingress MUST NOT set up 638 any forwarding state to the backup ingress if the backup ingress is 639 off-path. 641 5.2.2. Proxy-Ingress Method 643 The primary ingress is responsible for starting the RSVP signaling 644 for the proxy-ingress node. To do this, the following MUST be done 645 for the RSVP PATH message. 647 1. Compute the EROs for the LSP as normal for the ingress. 649 2. If the selected backup ingress node is not the first node on the 650 path (for all sub-LSPs), then insert at the beginning of the ERO 651 first the backup ingress node and then the ingress node. 653 3. In the PATH RRO, instead of recording the ingress node's address, 654 replace it with the Proxy-Ingress-Id. 656 4. Leave the HOP object populated as usual with information for the 657 ingress-node. 659 5. Add the INGRESS_PROTECTION object to the PATH message. Include 660 the Backup Ingress Address (IPv4 or IPv6) sub-object and the 661 Traffic-Descriptor sub-object. Set or clear the options 662 indicating that a Backup P2MP LSP is desired. 664 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path 665 message. Indicate whether one-to-one backup is desired. 666 Indicate whether facility backup is desired. 668 7. The RSVP PATH message is sent to the backup node as normal. 670 If the ingress detects that it can't communicate with the backup 671 ingress, then the ingress SHOULD instead send the PATH message to the 672 next-hop indicated in the ERO computed in step 1. Once the ingress 673 detects that it can communicate with the backup ingress, the ingress 674 SHOULD follow the steps 1-7 to obtain ingress failure protection. 676 When the ingress node receives an RSVP PATH message with an 677 INGRESS_PROTECTION object and the object specifies that node as the 678 ingress node and the PHOP as the backup ingress node, the ingress 679 node SHOULD remove the INGRESS_PROTECTION object from the PATH 680 message before sending it out. Additionally, the ingress node MUST 681 store that it will install ingress forwarding state for the LSP 682 rather than midpoint forwarding. 684 When an RSVP RESV message is received by the ingress, it uses the 685 NHOP to determine whether the message is received from the backup 686 ingress or from a different node. The stored associated PATH message 687 contains an INGRESS_PROTECTION object that identifies the backup 688 ingress node. If the RESV message is not from the backup node, then 689 ingress forwarding state SHOULD be set up, and the INGRESS_PROTECTION 690 object MUST be added to the RESV before it is sent to the NHOP, which 691 SHOULD be the backup node. If the RESV message is from the backup 692 node, then the LSP SHOULD be considered available for use. 694 If the backup ingress node is on the forwarding path, then a RESV is 695 received with an INGRESS_PROTECTION object and an NHOP that matches 696 the backup ingress. In this case, the ingress node's address will 697 not appear after the backup ingress in the RRO. The ingress node 698 SHOULD set up ingress forwarding state, just as is done if the LSP 699 weren't ingress-node protected. 701 5.3. Backup Ingress Behavior 703 An LER determines that the ingress local protection is requested for 704 an LSP if the INGRESS_PROTECTION object is included in the PATH 705 message it receives for the LSP. The LER can further determine that 706 it is the backup ingress if one of its addresses is in the Backup 707 Ingress Address sub-object of the INGRESS_PROTECTION object. The LER 708 as the backup ingress will assume full responsibility of the ingress 709 after the primary ingress fails. In addition, the LER determines 710 that it is off-path if it is not any node of the LSP. 712 5.3.1. Backup Ingress Behavior in Off-path Case 714 The backup ingress considers itself as a PLR and the primary ingress 715 as its next hop and provides a local protection for the primary 716 ingress. It behaves very similarly to a PLR providing fast-reroute 717 where the primary ingress is considered as the failure-point to 718 protect. Where not otherwise specified, the behavior given in 719 [RFC4090] for a PLR applies. 721 The backup ingress MUST follow the control-options specified in the 722 INGRESS_PROTECTION object and the flags and specifications in the 723 FAST-REROUTE object. This applies to providing a P2MP backup if the 724 "P2MP backup" is set, a one-to-one backup if "one-to-one desired" is 725 set, facility backup if the "facility backup desired" is set, and 726 backup paths that support the desired bandwidth, and administrative- 727 colors that are requested. 729 If multiple non empty INGRESS_PROTECTION objects have been received 730 via multiple PATH messages for the same LSP, then the most recent one 731 MUST be the one used. 733 The backup ingress creates the appropriate forwarding state for the 734 backup LSP tunnel(s) to the merge point(s). 736 When the backup ingress sends a RESV message to the primary ingress, 737 it MUST add an INGRESS_PROTECTION object into the message. It MUST 738 set or clear the flags in the object to report "Ingress local 739 protection available", "Ingress local protection in use", and 740 "bandwidth protection". 742 If the backup ingress doesn't have a backup LSP tunnel to each of the 743 merge points, it SHOULD clear "Ingress local protection available" 744 and set NUB to the number of the merge points to which there is no 745 backup LSP. 747 When the primary ingress fails, the backup ingress redirects the 748 traffic from a source into the backup P2P LSPs or the backup P2MP LSP 749 transmitting the traffic to the next hops of the primary ingress, 750 where the traffic is merged into the protected LSP. 752 In this case, the backup ingress MUST keep the PATH message with the 753 INGRESS_PROTECTION object received from the primary ingress and the 754 RESV message with the INGRESS_PROTECTION object to be sent to the 755 primary ingress. The backup ingress MUST set the "local protection 756 in use" flag in the RESV message, indicating that the backup ingress 757 is actively redirecting the traffic into the backup P2P LSPs or the 758 backup P2MP LSP for locally protecting the primary ingress failure. 760 Note that the RESV message with this piece of information will not be 761 sent to the primary ingress because the primary ingress has failed. 763 If the backup ingress has not received any PATH message from the 764 primary ingress for an extended period of time (e.g., a cleanup 765 timeout interval) and a confirmed primary ingress failure did not 766 occur, then the standard RSVP soft-state removal SHOULD occur. The 767 backup ingress SHALL remove the state for the PATH message from the 768 primary ingress, and tear down the one-to-one backup LSPs for 769 protecting the primary ingress if one-to-one backup is used or unbind 770 the facility backup LSPs if facility backup is used. 772 When the backup ingress receives a PATH message from the primary 773 ingress for locally protecting the primary ingress of a protected 774 LSP, it MUST check to see if any critical information has been 775 changed. If the next hops of the primary ingress are changed, the 776 backup ingress SHALL update its backup LSP(s) accordingly. 778 5.3.1.1. Relay-Message Method 780 When the backup ingress receives a PATH message with an non empty 781 INGRESS_PROTECTION object, it examines the object to learn what 782 traffic associated with the LSP. It determines the next-hops to be 783 merged to by examining the Label-Routes sub-object in the object. 785 The backup ingress MUST store the PATH message received from the 786 primary ingress, but NOT forward it. 788 The backup ingress responds with a RESV message to the PATH message 789 received from the primary ingress. If the backup ingress is off- 790 path, the LABEL object in the RESV message contains IMPLICIT-NULL. 791 If the INGRESS_PROTECTION object is not "empty", the backup ingress 792 SHALL send the RESV message with the state indicating protection is 793 available after the backup LSP(s) are successfully established. 795 5.3.1.2. Proxy-Ingress Method 797 The backup ingress determines the next-hops to be merged to by 798 collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- 799 object) from the Record Route Object of each RESV that are closest to 800 the top and not the Ingress router; this should be the second to the 801 top pair. If a Label-Routes sub-object is included in the 802 INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are 803 used to filter the set down to the specific next-hops where 804 protection is desired. A RESV message MUST have been received before 805 the Backup Ingress can create or select the appropriate backup LSP. 807 When the backup ingress receives a PATH message with the 808 INGRESS_PROTECTION object, the backup ingress examines the object to 809 learn what traffic associated with the LSP. The backup ingress 810 forwards the PATH message to the ingress node with the normal RSVP 811 changes. 813 When the backup ingress receives a RESV message with the 814 INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- 815 NULL label in the RRO. Then the backup ingress forwards the RESV 816 message to the ingress node, which is acting for the proxy ingress. 818 5.3.2. Backup Ingress Behavior in On-path Case 820 An LER as the backup ingress determines that it is on-path if one of 821 its addresses is a next hop of the primary ingress (and for Proxy- 822 Ingress Method the primary ingress is not its next hop via checking 823 the PATH message with the INGRESS_PROTECTION object received from the 824 primary ingress). The LER on-path MUST send the corresponding PATH 825 messages without any INGRESS_PROTECTION object to its next hops. It 826 creates a number of backup P2P LSPs or a backup P2MP LSP from itself 827 to the other next hops (i.e., the next hops other than the backup 828 ingress) of the primary ingress. The other next hops are from the 829 Label-Routes sub object. 831 It also creates a forwarding entry, which sends/multicasts the 832 traffic from the source to the next hops of the backup ingress along 833 the protected LSP when the primary ingress fails. The traffic is 834 described by the Traffic-Descriptor. 836 After the forwarding entry is created, all the backup P2P LSPs or the 837 backup P2MP LSP is up and associated with the protected LSP, the 838 backup ingress MUST send the primary ingress the RESV message with 839 the INGRESS_PROTECTION object containing the state of the local 840 protection such as "local protection available" flag set to one, 841 which indicates that the primary ingress is locally protected. 843 When the primary ingress fails, the backup ingress sends/multicasts 844 the traffic from the source to its next hops along the protected LSP 845 and imports the traffic into each of the backup P2P LSPs or the 846 backup P2MP LSP transmitting the traffic to the other next hops of 847 the primary ingress, where the traffic is merged into protected LSP. 849 During the local repair, the backup ingress MUST continue to send the 850 PATH messages to its next hops as before, keep the PATH message with 851 the INGRESS_PROTECTION object received from the primary ingress and 852 the RESV message with the INGRESS_PROTECTION object to be sent to the 853 primary ingress. It MUST set the "local protection in use" flag in 854 the RESV message. 856 5.3.3. Failure Detection and Refresh PATH Messages 858 As described in [RFC4090], it is necessary to refresh the PATH 859 messages via the backup LSP(s). The Backup Ingress MUST wait to 860 refresh the PATH messages until it can accurately detect that the 861 ingress node has failed. An example of such an accurate detection 862 would be that the IGP has no bi-directional links to the ingress node 863 or a BFD session to the primary ingress' loopback address has failed 864 and stayed failed after the network has reconverged. 866 As described in [RFC4090 Section 6.4.3], the backup ingress, acting 867 as PLR, MUST modify and send any saved PATH messages associated with 868 the primary LSP to the corresponding next hops through backup LSP(s). 869 Any PATH message sent will not contain any INGRESS_PROTECTION object. 870 The RSVP_HOP object in the message contains an IP source address 871 belonging to the backup ingress. The sender template object has the 872 backup ingress address as its tunnel sender address. 874 5.4. Revertive Behavior 876 Upon a failure event in the (primary) ingress of a protected LSP, the 877 protected LSP is locally repaired by the backup ingress. There are a 878 couple of basic strategies for restoring the LSP to a full working 879 path. 881 - Revert to Primary Ingress: When the primary ingress is restored, 882 it re-signals each of the LSPs that start from the primary 883 ingress. The traffic for every LSP successfully re-signaled is 884 switched back to the primary ingress from the backup ingress. 886 - Global Repair by Backup Ingress: After determining that the 887 primary ingress of an LSP has failed, the backup ingress computes 888 a new optimal path, signals a new LSP along the new path, and 889 switches the traffic to the new LSP. 891 5.4.1. Revert to Primary Ingress 893 If "Revert to Primary Ingress" is desired for a protected LSP, the 894 (primary) ingress of the LSP SHOULD re-signal the LSP that starts 895 from the primary ingress after the primary ingress restores. After 896 the LSP is re-signaled successfully, the traffic SHOULD be switched 897 back to the primary ingress from the backup ingress on the source 898 node and redirected into the LSP starting from the primary ingress. 900 The primary ingress can specify the "Revert to Ingress" control- 901 option in the INGRESS_PROTECTION object in the PATH messages to the 902 backup ingress. After receiving the "Revert to Ingress" control- 903 option, the backup ingress MUST stop sending/refreshing PATH messages 904 for the protected LSP. 906 5.4.2. Global Repair by Backup Ingress 908 When the backup ingress has determined that the primary ingress of 909 the protected LSP has failed (e.g., via the IGP), it can compute a 910 new path and signal a new LSP along the new path so that it no longer 911 relies upon local repair. To do this, the backup ingress MUST use 912 the same tunnel sender address in the Sender Template Object and 913 allocate a LSP ID different from the one of the old LSP as the LSP-ID 914 of the new LSP. This allows the new LSP to share resources with the 915 old LSP. Alternately, the Backup Ingress can create a new LSP with 916 no bandwidth reservation that duplicates the path(s) of the protected 917 LSP, move traffic to the new LSP, delete the protected LSP, and then 918 resignal the new LSP with bandwidth. 920 6. Security Considerations 922 In principle this document does not introduce new security issues. 923 The security considerations pertaining to RFC 4090, RFC 4875 and 924 other RSVP protocols remain relevant. 926 7. IANA Considerations 928 IANA maintains a registry called "Class Names, Class Numbers, and 929 Class Types" under "Resource Reservation Protocol-Traffic Engineering 930 (RSVP-TE) Parameters". IANA is requested to assign a new Class 931 Number for new object INGRESS_PROTECTION as follows: 933 +====================+===============+============================+ 934 | Class Names | Class Numbers | Class Types | 935 +====================+===============+============================+ 936 | INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | 937 | | is suggested +----------------------------+ 938 | | | 2: INGRESS_PROTECTION_IPv6 | 939 +--------------------+---------------+----------------------------+ 941 IANA is to create and maintain a new registry under 942 INGRESS_PROTECTION: 944 o Sub-object type - 206 INGRESS_PROTECTION 946 Initial values for the registry are given below. The future 947 assignments are to be made through IETF Review. 949 Value Name Definition 950 1 BACKUP_INGRESS_IPv4_ADDRESS Section 4.1.1 951 2 BACKUP_INGRESS_IPv6_ADDRESS Section 4.1.2 952 3 INGRESS_IPv4_ADDRESS Section 4.1.3 953 4 INGRESS_IPv6_ADDRESS Section 4.1.4 954 5 TRAFFIC_DESCRIPTOR_INTERFACE Section 4.1.5 955 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX Section 4.1.5 956 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX Section 4.1.5 957 8 TRAFFIC_DESCRIPTOR_APPLICATION Section 4.1.5 958 9 LabeL_Routes Section 4.1.6 960 8. Co-authors and Contributors 962 1. Co-authors 964 Ning So 965 Tata Communications 966 2613 Fairbourne Cir. 967 Plano, TX 75082 968 USA 969 Email: ningso01@gmail.com 970 Autumn Liu 971 Ciena 972 USA 973 Email: hliu@ciena.com 975 Zhenbin Li 976 Huawei Technologies 977 Email: zhenbin.li@huawei.com 979 Yimin Shen 980 Juniper Networks 981 10 Technology Park Drive 982 Westford, MA 01886 983 USA 984 Email: yshen@juniper.net 986 Tarek Saad 987 Cisco Systems 988 Email: tsaad@cisco.com 990 Fengman Xu 991 Verizon 992 2400 N. Glenville Dr 993 Richardson, TX 75082 994 USA 995 Email: fengman.xu@verizon.com 997 Mehmet Toy 998 Verizon 999 USA 1000 Email: mehmet.toy@verizon.com 1002 Lei Liu 1003 USA 1004 Email: liulei.kddi@gmail.com 1006 2. Contributors 1008 Renwei Li 1009 Huawei Technologies 1010 2330 Central Expressway 1011 Santa Clara, CA 95050 1012 USA 1013 Email: renwei.li@huawei.com 1015 Quintin Zhao 1016 Huawei Technologies 1017 Boston, MA 1018 USA 1019 Email: quintin.zhao@huawei.com 1021 Boris Zhang 1022 Telus Communications 1023 200 Consilium Pl Floor 15 1024 Toronto, ON M1H 3J3 1025 Canada 1026 Email: Boris.Zhang@telus.com 1028 Markus Jork 1029 Juniper Networks 1030 10 Technology Park Drive 1031 Westford, MA 01886 1032 USA 1033 Email: mjork@juniper.net 1035 9. Acknowledgement 1037 The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric 1038 Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia 1039 Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, 1040 Gregory Mirsky, and Ronhazli Adam for their valuable comments and 1041 suggestions on this draft. 1043 10. References 1044 10.1. Normative References 1046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1048 RFC2119, March 1997, 1049 . 1051 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1052 Label Switching Architecture", RFC 3031, DOI 10.17487/ 1053 RFC3031, January 2001, 1054 . 1056 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1057 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1058 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1059 . 1061 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1062 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1063 DOI 10.17487/RFC4090, May 2005, 1064 . 1066 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1067 Yasukawa, Ed., "Extensions to Resource Reservation 1068 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1069 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1070 DOI 10.17487/RFC4875, May 2007, 1071 . 1073 10.2. Informative References 1075 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 1076 N., and A. Fulignoli, Ed., "MPLS Transport Profile 1077 (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/ 1078 RFC6378, October 2011, 1079 . 1081 Authors' Addresses 1083 Huaimo Chen (editor) 1084 Huawei Technologies 1085 Boston, MA 1086 USA 1088 Email: huaimo.chen@huawei.com 1089 Raveendra Torvi (editor) 1090 Juniper Networks 1091 10 Technology Park Drive 1092 Westford, MA 01886 1093 USA 1095 Email: rtorvi@juniper.net