idnits 2.17.1 draft-chen-pce-compute-backup-egress-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 -- The document date (March 12, 2011) is 4787 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 438, but not defined == Missing Reference: 'RFC5511' is mentioned on line 489, but not defined == Unused Reference: 'RFC2119' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 614, 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 Egress of a Traffic Engineering Label Switched Path 9 draft-chen-pce-compute-backup-egress-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 egress for an MPLS TE P2MP LSP or an MPLS TE P2P 16 LSP to a PCE and for a PCE to compute the backup egress and reply to 17 the PCC with a computation result for the backup egress. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Backup Egress 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 Destination Nodes Object . . . . . . . . . . 7 63 4.2.3. Constraints between Egress and Backup Egress . . . . . 10 64 4.2.4. Constraints for Backup Path . . . . . . . . . . . . . 11 65 4.2.5. Backup Egress Node . . . . . . . . . . . . . . . . . . 11 66 4.2.6. Backup Egress PCEP Error Objects and Types . . . . . . 11 67 4.2.7. Request Message Format . . . . . . . . . . . . . . . . 12 68 4.2.8. Reply Message Format . . . . . . . . . . . . . . . . . 12 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Backup Egress Capability Flag . . . . . . . . . . . . . . 13 72 6.2. Backup Egress Capability TLV . . . . . . . . . . . . . . . 14 73 6.3. Request Parameter Bit Flags . . . . . . . . . . . . . . . 14 74 6.4. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 14 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 "A Path Computation Element-(PCE) Based Architecture" RFC4655 84 describes a set of building blocks for constructing solutions to 85 compute Point-to-Point (P2P) Traffic Engineering (TE) label switched 86 paths across multiple areas or Autonomous System (AS) domains. A 87 typical PCE-based system comprises one or more path computation 88 servers, traffic engineering databases (TED), and a number of path 89 computation clients (PCC). A routing protocol is used to exchange 90 traffic engineering information from which the TED is constructed. A 91 PCC sends a Point-to-Point traffic engineering Label Switched Path 92 (LSP) computation request to the path computation server, which uses 93 the TED to compute the path and responses to the PCC with the 94 computed path. A path computation server is named as a PCE. The 95 communications between a PCE and a PCC for Point-to-Point label 96 switched path computations follow the PCE communication protocol 97 (PCEP). 99 "Extensions to the Path Computation Element Communication Protocol 100 (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched 101 Paths" RFC6006 describes extensions to the PCE communication Protocol 102 (PCEP) to handle requests and responses for the computation of paths 103 for P2MP TE LSPs. 105 This document defines extensions to the Path Computation Element 106 Communication Protocol (PCEP) for a PCC to send a request for 107 computing a backup egress node for an MPLS TE P2MP LSP or an MPLS TE 108 P2P LSP to a PCE and for a PCE to compute the backup egress node and 109 reply to the PCC with a computation result for the backup egress 110 node. 112 2. Terminology 114 This document uses terminologies defined in RFC5440, and RFC4875. 116 3. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119. 122 4. Extensions to PCEP 124 This section describes the extensions to PCEP for computing a backup 125 egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 127 4.1. Backup Egress Capability Advertisement 129 4.1.1. Capability TLV in Existing PCE Discovery Protocol 131 There are two options for advertising a PCE capability for computing 132 a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP. 134 The first option is to define a new flag in the OSPF and IS-IS PCE 135 Capability Flags to indicate the capability that a PCE is capable to 136 compute both a backup egress for an MPLS TE P2MP LSP and a backup 137 egress for an MPLS TE P2P LSP. 139 The second option is to define two new flags. One new flag in the 140 OSPF and IS-IS PCE Capability Flags indicates the capability that a 141 PCE is capable to compute a backup egress for an MPLS TE P2MP LSP; 142 and another new flag in the OSPF and IS-IS PCE Capability Flags 143 indicates the capability that a PCE is capable to compute a backup 144 egress for an MPLS TE P2P LSP. 146 This second option is preferred now. 148 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type = 5 | Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 // PCE Capability Flags // 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Type: 5 161 Length: Multiple of 4 octets 162 Value: This contains an array of units of 32-bit flags 163 numbered from the most significant as bit zero, where 164 each bit represents one PCE capability. 166 The following capability bits have been assigned by IANA: 168 Bit Capabilities 170 0 Path computation with GMPLS link constraints 171 1 Bidirectional path computation 172 2 Diverse path computation 173 3 Load-balanced path computation 174 4 Synchronized path computation 175 5 Support for multiple objective functions 176 6 Support for additive path constraints 177 (max hop count, etc.) 178 7 Support for request prioritization 179 8 Support for multiple requests per message 180 9 Global Concurrent Optimization (GCO) 181 10 P2MP path computation 182 11-31 Reserved for future assignments by IANA. 184 Reserved bits SHOULD be set to zero on transmission and MUST be 185 ignored on receipt. 187 For the second option, one bit such as bit 13 may be assigned to 188 indicate that a PCE is capable to compute a backup egress for an MPLS 189 TE P2MP LSP and another bit such as bit 14 may be assigned to 190 indicate that a PCE is capable to compute a backup egress for an MPLS 191 TE P2P LSP. 193 Bit Capabilities 195 13 Backup egress computation for P2MP LSP 196 14 Backup egress computation for P2P LSP 198 15-31 Reserved for future assignments by IANA. 200 4.1.2. Open Message Extension 202 If a PCE does not advertise its backup egress compution capability 203 during discovery, PCEP should be used to allow a PCC to discover, 204 during the Open Message Exchange, which PCEs are capable of 205 supporting backup egress computation. 207 To achieve this, we extend the PCEP OPEN object by defining a new 208 optional TLV to indicate the PCE's capability to perform backup 209 egress computation for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 211 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 212 Indicators" subregistry, as documented in Section below ("Backup 213 Egress Capability TLV"). The description is "backup egress capable", 214 and the length value is 2 bytes. The value field is set to indicate 215 the capability of a PCE for backup egress computation for an MPLS TE 216 LSP in details. 218 We can use flag bits in the value field in the same way as the PCE 219 Capability Flags described in the previous section. 221 The inclusion of this TLV in an OPEN object indicates that the sender 222 can perform backup egress computation for an MPLS TE P2MP LSP or an 223 MPLS TE P2P LSP. 225 The capability TLV is meaningful only for a PCE, so it will typically 226 appear only in one of the two Open messages during PCE session 227 establishment. However, in case of PCE cooperation (e.g., inter- 228 domain), when a PCE behaving as a PCC initiates a PCE session it 229 SHOULD also indicate its path computation capabilities. 231 4.2. Request and Reply Message Extension 233 This section describes extensions to the existing RP (Request 234 Parameters) object to allow a PCC to request a PCE for computing a 235 backup egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 236 PCE receives the PCEP request. 238 4.2.1. RP Object Extension 240 The following flags are added into the RP Object: 242 The T bit is added in the flag bits field of the RP object to tell 243 the receiver of the message that the request/reply is for computing a 244 bcakup egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 246 o T ( Backup Egress bit - 1 bit): 248 0: This indicates that this is not PCReq/PCRep 249 for backup egress. 251 1: This indicates that this is PCReq or PCRep message 252 for backup egress. 254 The IANA request is referenced in Section below (Request Parameter 255 Bit Flags) of this document. 257 This T bit with the N bit defined in RFC 6006 can indicate whether a 258 request/reply is for a bcakup egress of an MPLS TE P2MP LSP or an 259 MPLS TE P2P LSP. 261 o T = 1 and N = 1: This indicates that this is a PCReq/PCRep 262 message for backup egress of an MPLS TE 263 P2MP LSP. 265 o T = 1 and N = 0: This indicates that this is a PCReq/PCRep 266 message for backup egress of an MPLS TE 267 P2P LSP. 269 4.2.2. External Destination Nodes Object 271 In addition to the information about the path that an MPLS TE P2MP 272 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 273 other information that may be used for computing the backup egress 274 for the P2MP LSP or P2P LSP. For example, the information about an 275 external destination node, to which data traffic is delivered from an 276 egress node of the P2MP LSP or P2P LSP, is useful for computing a 277 backup egress node. 279 The PCC can specify an external destination nodes (EDN) Object. In 280 order to represent the external destination nodes efficiently, we 281 define two types of encodes for the external destination nodes in the 282 object. 284 One encode indicates that the EDN object contains an external 285 destination node for every egress node of an MPLS TE P2MP LSP or an 286 MPLS TE P2P LSP. The order of the external destination nodes in the 287 object is the same as the egress node(s) of the P2MP LSP or P2P LSP 288 contained in the PCE messages. 290 Another encode indicates that the EDN object contains a list of 291 egress node and external destination node pairs. For an egress node 292 and external destination node pair, the data traffic is delivered to 293 the external destination node from the egress node of the LSP. 295 The format of the external destination nodes (EDN) object boby for 296 IPv4 with the first type of encodes is illustrated as follows: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Encode of External Destination Nodes (1) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | External Destination IPv4 address | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | External Destination IPv4 address | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 ~ ... ~ 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | External Destination IPv4 address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 1: Format of EDN Object with one Encode for IPv4 314 The format of the external destination nodes (EDN) object boby for 315 IPv4 with the second type of encodes is illustrated below: 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Encode of External Destination Nodes (2) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Egress IPv4 address | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | External Destination IPv4 address | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Egress IPv4 address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | External Destination IPv4 address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 ~ ... ~ 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Egress IPv4 address | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | External Destination IPv4 address | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 2: Format of EDN Object with another Encode for IPv4 339 The format of the external destination nodes (EDN) object boby for 340 IPv6 with the first type of encodes is illustrated as follows: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Encode of External Destination Nodes (1) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 | External Destination IPv6 address (16 bytes) | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 | External Destination IPv6 address (16 bytes) | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 ~ ... ~ 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | External Destination IPv6 address (16 bytes) | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: Format of EDN Object with one Encode for IPv6 364 The format of the external destination nodes (EDN) object boby for 365 IPv6 with the second type of encodes is illustrated below: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Encode of External Destination Nodes (2) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 | Egress IPv6 address | 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | External Destination IPv6 address (16 bytes) | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 | Egress IPv6 address | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | External Destination IPv6 address (16 bytes) | 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 ~ ... ~ 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | Egress IPv6 address | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 | External Destination IPv6 address (16 bytes) | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 4: Format of EDN Object with another Encode for IPv6 401 The object can only be carried in a PCReq message. A Path Request 402 may carry at most one external destination nodes Object. 404 The Object-Class and Object-types will need to be allocated by IANA. 405 The IANA request is documented in Section below (PCEP Objects). 407 4.2.3. Constraints between Egress and Backup Egress 409 A request message sent to a PCE from a PCC for computing a backup 410 egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 411 constraint indicating that there must be a path from the backup 412 egress node to be computed to the egress node of the P2MP LSP or P2P 413 LSP and that the length of the path is within a given hop limit such 414 as one hop. 416 This constraint can be considered as default by a PCE or explicitly 417 sent to the PCE by a PCC [TBD]. 419 4.2.4. Constraints for Backup Path 421 A request message sent to a PCE from a PCC for computing a backup 422 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 423 that the backup egress node to be computed may not be a node on the 424 P2MP LSP or P2P LSP. In addition, the request message may comprise a 425 list of nodes, each of which is a candidate for the backup egress 426 node. 428 A request message sent to a PCE from a PCC for computing a backup 429 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 430 that there must be a path from the previous hop node of the egress 431 node of the P2MP LSP or P2P LSP to the backup egress node to be 432 computed and that there is not an internal node of the path from the 433 previous hop node of the egress node of the P2MP LSP or P2P LSP to 434 the backup egress that is on the path of the P2MP LSP or P2P LSP. 436 Most of these constraints for the backup path can be considered as 437 default by a PCE. The constraints for the backup path may be 438 explicitly sent to the PCE by a PCC [TBD]. 440 4.2.5. Backup Egress Node 442 The PCE may send a reply message to the PCC in return to the request 443 message for computing a new backup egress node or a number of backup 444 egress nodes. The reply message may comprise information about the 445 computed backup egress node(s), which is contained in the path(s) 446 from the previous-hop node of the egress node of the P2MP LSP or P2P 447 LSP to the backup egress node(s) computed. 449 4.2.6. Backup Egress PCEP Error Objects and Types 451 In some cases, the PCE may not complete the backup egress computation 452 as requested, for example based on a set of constraints. As such, 453 the PCE may send a reply message to the PCC that indicates an 454 unsuccessful backup egress computation attempt. The reply message 455 may comprise a PCEP-error object, which may comprise an error-value, 456 error-type and some detail information. 458 4.2.7. Request Message Format 460 The PCReq message is encoded as follows using RBNF as defined in 461 [RFC5511]. 463 Below is the message format for a request message: 465 ::= 466 [] 467 468 ::= 469 470 [] 471 [] 472 [] 473 [] 474 [] 475 [] 476 [] 477 where: 478 is an external destination nodes object. 480 Figure 5: The Format for a Request Message 482 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 483 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 484 RFC5440 and RFC6006. 486 4.2.8. Reply Message Format 488 The PCRep message is encoded as follows using RBNF as defined in 489 [RFC5511]. 491 Below is the message format for a reply message: 493 ::= 494 495 ::= 496 497 [] 498 [] 499 where: 501 ::= 502 [][] 504 ::= (|) [] 506 ::= [] 507 [] 508 [] 509 [] 510 [] 512 Figure 6: The Format for a Reply Message 514 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 515 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 516 RFC4875. 518 5. Security Considerations 520 The mechanism described in this document does not raise any new 521 security issues for the PCEP, OSPF or IS-IS protocols. 523 6. IANA Considerations 525 This section specifies requests for IANA allocation. 527 6.1. Backup Egress Capability Flag 529 Two new OSPF Capability Flags are defined in this document to 530 indicate the capabilities for computing a backup egress for an MPLS 531 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 532 assignment from the "OSPF Parameters Path Computation Element (PCE) 533 Capability Flags" registry: 535 Bit Description Reference 537 13 Backup egress for P2MP LSP This I-D 538 14 Backup egress for P2P LSP This I-D 540 6.2. Backup Egress Capability TLV 542 A new backup egress capability TLV is defined in this document to 543 allow a PCE to advertize its backup egress computation capability. 544 IANA is requested to make the following allocation from the "PCEP TLV 545 Type Indicators" sub-registry. 547 Value Description Reference 549 8 Backup egress capable This I-D 551 6.3. Request Parameter Bit Flags 553 A new RP Object Flag has been defined in this document. IANA is 554 requested to make the following allocation from the "PCEP RP Object 555 Flag Field" Sub-Registry: 557 Bit Description Reference 559 15 Backup egress (T-bit) This I-D 561 6.4. PCEP Objects 563 An External Destination Nodes Object-Type is defined in this 564 document. IANA is requested to make the following Object-Type 565 allocation from the "PCEP Objects" sub-registry: 567 Object-Class Value 34 568 Name External Destination Nodes 569 Object-Type 1: IPv4 570 2: IPv6 571 3-15: Unassigned 572 Reference This I-D 574 7. Acknowledgement 576 The author would like to thank Quintin Zhao and others for their 577 valuable comments on this draft. 579 8. References 581 8.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 587 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 588 Tunnels", RFC 3209, December 2001. 590 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 591 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 592 May 2005. 594 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 595 (PCE) Communication Protocol (PCEP)", RFC 5440, 596 March 2009. 598 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 599 "Extensions to Resource Reservation Protocol - Traffic 600 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 601 Switched Paths (LSPs)", RFC 4875, May 2007. 603 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 604 and J. Meuric, "Extensions to the Path Computation Element 605 Communication Protocol (PCEP) for Point-to-Multipoint 606 Traffic Engineering Label Switched Paths", RFC 6006, 607 September 2010. 609 8.2. Informative References 611 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 612 Element (PCE)-Based Architecture", RFC 4655, August 2006. 614 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 615 (PCC) - Path Computation Element (PCE) Requirements for 616 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 618 Author's Address 620 Huaimo Chen 621 Huawei Technologies 622 Boston, MA 623 US 625 Email: Huaimochen@huawei.com