idnits 2.17.1 draft-chen-pce-compute-backup-ingress-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 8 has weird spacing: '...ress of a Tra...' -- The document date (March 12, 2011) is 4791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 339, but not defined == Missing Reference: 'RFC5511' is mentioned on line 392, but not defined == Unused Reference: 'RFC2119' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 517, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 2 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 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track March 12, 2011 5 Expires: September 13, 2011 7 Extensions to the Path Computation Element Communication Protocol (PCEP) 8 for Backup Ingress of a Traffic Engineering Label Switched Path 9 draft-chen-pce-compute-backup-ingress-01.txt 11 Abstract 13 This document presents extensions to the Path Computation Element 14 Communication Protocol (PCEP) for a PCC to send a request for 15 computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P 16 LSP to a PCE and for a PCE to compute the backup ingress and reply to 17 the PCC with a computation result for the backup ingress. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Backup Ingress Capability Advertisement . . . . . . . . . 4 58 4.1.1. Capability TLV in Existing PCE Discovery Protocol . . 4 59 4.1.2. Open Message Extension . . . . . . . . . . . . . . . . 6 60 4.2. Request and Reply Message Extension . . . . . . . . . . . 6 61 4.2.1. RP Object Extension . . . . . . . . . . . . . . . . . 7 62 4.2.2. External Source Node Object . . . . . . . . . . . . . 7 63 4.2.3. Constraints between Ingress and Backup Ingress . . . . 8 64 4.2.4. Constraints for Backup Path . . . . . . . . . . . . . 8 65 4.2.5. Backup Ingress Node . . . . . . . . . . . . . . . . . 8 66 4.2.6. Backup Ingress PCEP Error Objects and Types . . . . . 9 67 4.2.7. Request Message Format . . . . . . . . . . . . . . . . 9 68 4.2.8. Reply Message Format . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. Backup Ingress Capability Flag . . . . . . . . . . . . . . 10 72 6.2. Backup Ingress Capability TLV . . . . . . . . . . . . . . 11 73 6.3. Request Parameter Bit Flags . . . . . . . . . . . . . . . 11 74 6.4. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" RFC4090 84 describes two methods to backup P2P LSP tunnels or paths at local 85 repair points. The local repair points may comprise a number of 86 intermediate nodes between an ingress node and an egress node along 87 the path. The first method is a one-to-one backup method, where a 88 detour backup P2P LSP for each protected P2P LSP is created at each 89 potential point of local repair. The second method is a facility 90 bypass backup protection method, where a bypass backup P2P LSP tunnel 91 is created using MPLS label stacking to protect a potential failure 92 point for a set of P2P LSP tunnels. The bypass backup tunnel can 93 protect a set of P2P LSPs that have similar backup constraints. 95 "Extensions to RSVP-TE for P2MP TE LSPs" RFC4875 describes how to use 96 the one-to-one backup method and facility bypass backup method to 97 protect a link or intermediate node failure on the path of a P2MP 98 LSP. 100 However, there is no mention of locally protecting an ingress node 101 failure in a protected P2MP LSP or P2P LSP. 103 The methods for protecting an ingress node of a P2MP LSP or P2P LSP 104 may be classified into two categories. 106 A first category uses a backup P2MP LSP that is from a backup ingress 107 node to the number of destination nodes for the P2MP LSP, and a 108 backup P2P LSP that is from a backup ingress node to the destination 109 node for the P2P LSP. The disadvantages of this class of methods 110 include more network resource such as computer power and link 111 bandwidth consumption since the backup P2MP LSP or P2P LSP is from 112 the backup ingress node to the number of destination nodes or the 113 destination respectively. 115 A second category uses a local P2MP LSP or P2P LSP for protecting the 116 ingress of a P2MP LSP or P2P LSP locally. The local P2MP LSP is from 117 a backup ingress node to the next hop nodes of the ingress of the 118 P2MP LSP. The local P2P LSP is from a backup ingress node to the 119 next hop node of the ingress of the P2P LSP. It is desirable to let 120 PCE compute these backup ingress nodes. 122 This document defines extensions to the Path Computation Element 123 Communication Protocol (PCEP) for a PCC to send a request for 124 computing a backup ingress node for an MPLS TE P2MP LSP or an MPLS TE 125 P2P LSP to a PCE and for a PCE to compute the backup ingress node and 126 reply to the PCC with a computation result for the backup ingress 127 node. 129 2. Terminology 131 This document uses terminologies defined in RFC5440, RFC4090, and 132 RFC4875. 134 3. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC2119. 140 4. Extensions to PCEP 142 This section describes the extensions to PCEP for computing a backup 143 ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 145 4.1. Backup Ingress Capability Advertisement 147 4.1.1. Capability TLV in Existing PCE Discovery Protocol 149 There are a couple of options for advertising a PCE capability for 150 computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P 151 LSP. 153 The first option is to define a new flag in the OSPF and ISIS PCE 154 Capability Flags to indicate the capability that a PCE is capable to 155 compute both a backup ingress for an MPLS TE P2MP LSP and a backup 156 ingress for an MPLS TE P2P LSP. 158 The second option is to define two new flags. One new flag in the 159 OSPF and ISIS PCE Capability Flags indicates the capability that a 160 PCE is capable to compute a backup ingress for an MPLS TE P2MP LSP; 161 and another new flag in the OSPF and ISIS PCE Capability Flags 162 indicates the capability that a PCE is capable to compute a backup 163 ingress for an MPLS TE P2P LSP. 165 This second option is preferred now. 167 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type = 5 | Length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | 175 // PCE Capability Flags // 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Type: 5 180 Length: Multiple of 4 octets 181 Value: This contains an array of units of 32-bit flags 182 numbered from the most significant as bit zero, where 183 each bit represents one PCE capability. 185 The following capability bits have been assigned by IANA: 187 Bit Capabilities 189 0 Path computation with GMPLS link constraints 190 1 Bidirectional path computation 191 2 Diverse path computation 192 3 Load-balanced path computation 193 4 Synchronized path computation 194 5 Support for multiple objective functions 195 6 Support for additive path constraints 196 (max hop count, etc.) 197 7 Support for request prioritization 198 8 Support for multiple requests per message 199 9 Global Concurrent Optimization (GCO) 200 10 P2MP path computation 201 11-31 Reserved for future assignments by IANA. 203 Reserved bits SHOULD be set to zero on transmission and MUST be 204 ignored on receipt. 206 For the second option, one bit such as bit 11 may be assigned to 207 indicate that a PCE is capable to compute a backup ingress for an 208 MPLS TE P2MP LSP and another bit such as bit 12 may be assigned to 209 indicate that a PCE is capable to compute a backup ingress for an 210 MPLS TE P2P LSP. 212 Bit Capabilities 214 11 Backup ingress computation for P2MP LSP 215 12 Backup ingress computation for P2P LSP 217 13-31 Reserved for future assignments by IANA. 219 4.1.2. Open Message Extension 221 If a PCE does not advertise its backup ingress compution capability 222 during discovery, PCEP should be used to allow a PCC to discover, 223 during the Open Message Exchange, which PCEs are capable of 224 supporting backup ingress computation. 226 To achieve this, we extend the PCEP OPEN object by defining a new 227 optional TLV to indicate the PCE's capability to perform backup 228 ingress compution for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 230 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 231 Indicators" subregistry, as documented in Section below ("Backup 232 Ingress Capability TLV"). The description is "backup ingress 233 capable", and the length value is 2 bytes. The value field is set to 234 indicate the capability of a PCE for backup ingress compution for an 235 MPLS TE LSP in details. 237 We can use flag bits in the value field in the same way as the PCE 238 Capability Flags described in the previous section. 240 The inclusion of this TLV in an OPEN object indicates that the sender 241 can perform backup ingress compution for an MPLS TE P2MP LSP or an 242 MPLS TE P2P LSP. 244 The capability TLV is meaningful only for a PCE, so it will typically 245 appear only in one of the two Open messages during PCE session 246 establishment. However, in case of PCE cooperation (e.g., inter- 247 domain), when a PCE behaving as a PCC initiates a PCE session it 248 SHOULD also indicate its path computation capabilities. 250 4.2. Request and Reply Message Extension 252 This section describes extensions to the existing RP (Request 253 Parameters) object to allow a PCC to request a PCE for computing a 254 backup ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 255 PCE receives the PCEP request. 257 4.2.1. RP Object Extension 259 The following flags are added into the RP Object: 261 The I bit is added in the flag bits field of the RP object to tell 262 the receiver of the message that the request/reply is for computing a 263 bcakup ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 265 o I ( Backup Ingress bit - 1 bit): 267 0: This indicates that this is not PCReq/PCRep 268 for backup ingress. 270 1: This indicates that this is PCReq or PCRep message 271 for backup ingress. 273 The IANA request is referenced in Section below (Request Parameter 274 Bit Flags) of this document. 276 This I bit with the N bit defined in RFC6006 can indicate whether the 277 request/reply is for a bcakup ingress of an MPLS TE P2MP LSP or an 278 MPLS TE P2P LSP. 280 o I = 1 and N = 1: This indicates that this is a PCReq/PCRep 281 message for backup ingress of an MPLS TE 282 P2MP LSP. 284 o I = 1 and N = 0: This indicates that this is a PCReq/PCRep 285 message for backup ingress of an MPLS TE 286 P2P LSP. 288 4.2.2. External Source Node Object 290 In addition to the information about the path that an MPLS TE P2MP 291 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 292 other information that may be used for computing the backup ingress 293 for the P2MP LSP or P2P LSP. For example, the information about an 294 external source node, from which data traffic is delivered to the 295 ingress node of the P2MP LSP or P2P LSP and transported to the egress 296 node(s) via the P2MP LSP or P2P LSP, is useful for computing a backup 297 ingress node. 299 The PCC can specify an external source node (ESN) Object. The ESN 300 Object has the same format as the IRO object defined in [RFC5440] 301 except that it only supports IPv4 and IPv6 prefix sub-objects. 303 The object can only be carried in a PCReq message. A Path Request 304 may carry at most one external source node Object. 306 The Object-Class and Object-types will need to be allocated by IANA. 307 The IANA request is documented in Section below. (PCEP Objects). 309 4.2.3. Constraints between Ingress and Backup Ingress 311 A request message sent to a PCE from a PCC for computing a backup 312 ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 313 constraint indicating that there must be a path from the backup 314 ingress node to be computed to the ingress node of the P2MP LSP or 315 P2P LSP and that the length of the path is within a given hop limit 316 such as one hop. 318 This constraint can be considered as default by a PCE or explicitly 319 sent to the PCE by a PCC [TBD]. 321 4.2.4. Constraints for Backup Path 323 A request message sent to a PCE from a PCC for computing a backup 324 ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating 325 that the backup ingress node to be computed may not be a node on the 326 P2MP LSP or P2P LSP. In addition, the request message may comprise a 327 list of nodes, each of which is a candidate for the backup ingress 328 node. 330 A request message sent to a PCE from a PCC for computing a backup 331 ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating 332 that there must be a path from the backup ingress node to be computed 333 to the next-hop nodes of the ingress node of the P2MP LSP or P2P LSP 334 and that there is not an internal node of the path from the backup 335 ingress to the next-hop nodes on the P2MP LSP or P2P LSP . 337 Most of these constraints for the backup path can be considered as 338 default by a PCE. The constraints for the backup path may be 339 explicitly sent to the PCE by a PCC [TBD]. 341 4.2.5. Backup Ingress Node 343 The PCE may send a reply message to the PCC in return to the request 344 message for computing a new backup ingress node. The reply message 345 may comprise information about the computed backup ingress node, 346 which is contained in the path from the backup ingress computed to 347 the next-hop node(s) of the ingress node of the P2MP LSP or P2P LSP. 349 The backup ingress node is the root or head node of the backup path 350 computed. 352 4.2.6. Backup Ingress PCEP Error Objects and Types 354 In some cases, the PCE may not complete the backup ingress 355 computation as requested, for example based on a set of constraints. 356 As such, the PCE may send a reply message to the PCC that indicates 357 an unsuccessful backup ingress computation attempt. The reply 358 message may comprise a PCEP-error object, which may comprise an 359 error-value, error-type and some detail information. 361 4.2.7. Request Message Format 363 The PCReq message is encoded as follows using RBNF as defined in 364 [RFC5511]. 366 Below is the message format for a request message: 368 ::= 369 [] 370 371 ::= 372 373 [] 374 [] 375 [] 376 [] 377 [] 378 [] 379 [] 380 where: 381 is an external source node object. 383 Figure 1: The Format for a Request Message 385 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 386 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 387 RFC5440 and RFC6006. 389 4.2.8. Reply Message Format 391 The PCRep message is encoded as follows using RBNF as defined in 392 [RFC5511]. 394 Below is the message format for a reply message: 396 ::= 397 398 ::= 399 400 [] 401 [] 402 where: 404 ::= 405 [][] 407 ::= (|) [] 409 ::= [] 410 [] 411 [] 412 [] 413 [] 415 Figure 2: The Format for a Reply Message 417 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 418 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 419 RFC4875. 421 5. Security Considerations 423 The mechanism described in this document does not raise any new 424 security issues for the PCEP, OSPF and IS-IS protocols. 426 6. IANA Considerations 428 This section specifies requests for IANA allocation. 430 6.1. Backup Ingress Capability Flag 432 Two new OSPF Capability Flags are defined in this document to 433 indicate the capabilities for computing a backup ingress for an MPLS 434 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 435 assignment from the "OSPF Parameters Path Computation Element (PCE) 436 Capability Flags" registry: 438 Bit Description Reference 440 11 Backup ingress for P2MP LSP This I-D 441 12 Backup ingress for P2P LSP This I-D 443 6.2. Backup Ingress Capability TLV 445 A new backup ingress capability TLV is defined in this document to 446 allow a PCE to advertize its backup ingress computation capability. 447 IANA is requested to make the following allocation from the "PCEP TLV 448 Type Indicators" sub-registry. 450 Value Description Reference 452 8 Backup ingress capable This I-D 454 6.3. Request Parameter Bit Flags 456 A new RP Object Flag has been defined in this document. IANA is 457 requested to make the following allocation from the "PCEP RP Object 458 Flag Field" Sub-Registry: 460 Bit Description Reference 462 16 Backup ingress (I-bit) This I-D 464 6.4. PCEP Objects 466 An External Source Node Object-Type is defined in this document. 467 IANA is requested to make the following Object-Type allocation from 468 the "PCEP Objects" sub-registry: 470 Object-Class Value 33 471 Name External Source Node 472 Object-Type 1: IPv4 473 2: IPv6 474 3-15: Unassigned 475 Reference This I-D 477 7. Acknowledgement 479 The author would like to thank Quintin Zhao and others for their 480 valuable comments on this draft. 482 8. References 484 8.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 490 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 491 Tunnels", RFC 3209, December 2001. 493 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 494 (PCE) Communication Protocol (PCEP)", RFC 5440, 495 March 2009. 497 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 498 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 499 May 2005. 501 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 502 "Extensions to Resource Reservation Protocol - Traffic 503 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 504 Switched Paths (LSPs)", RFC 4875, May 2007. 506 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 507 and J. Meuric, "Extensions to the Path Computation Element 508 Communication Protocol (PCEP) for Point-to-Multipoint 509 Traffic Engineering Label Switched Paths", RFC 6006, 510 September 2010. 512 8.2. Informative References 514 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 515 Element (PCE)-Based Architecture", RFC 4655, August 2006. 517 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 518 (PCC) - Path Computation Element (PCE) Requirements for 519 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 521 Author's Address 523 Huaimo Chen 524 Huawei Technologies 525 Boston, MA 526 US 528 Email: Huaimochen@huawei.com