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