idnits 2.17.1 draft-chen-pce-compute-backup-egress-14.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 date (July 7, 2019) is 1749 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 474, but not defined == Missing Reference: 'RFC5511' is mentioned on line 520, but not defined == Unused Reference: 'RFC2119' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 1 error (**), 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 Futurewei 4 Intended status: Standards Track July 7, 2019 5 Expires: January 8, 2020 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-14.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 https://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 January 8, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 (https://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. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. Backup Egress Capability Advertisement . . . . . . . . . 3 55 4.1.1. Capability TLV in Existing PCE Discovery Protocol . . 3 56 4.1.2. Open Message Extension . . . . . . . . . . . . . . . 5 57 4.2. Request and Reply Message Extension . . . . . . . . . . . 5 58 4.2.1. RP Object Extension . . . . . . . . . . . . . . . . . 5 59 4.2.2. External Destination Nodes . . . . . . . . . . . . . 6 60 4.2.3. Constraints between Egress and Backup Egress . . . . 11 61 4.2.4. Constraints for Backup Path . . . . . . . . . . . . . 11 62 4.2.5. Backup Egress Node . . . . . . . . . . . . . . . . . 11 63 4.2.6. Backup Egress PCEP Error Objects and Types . . . . . 12 64 4.2.7. Request Message Format . . . . . . . . . . . . . . . 12 65 4.2.8. Reply Message Format . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . 13 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. Backup Egress Capability Flag . . . . . . . . . . . . . . 13 69 6.2. Backup Egress Capability TLV . . . . . . . . . . . . . . 14 70 6.3. Request Parameter Bit Flags . . . . . . . . . . . . . . . 14 71 6.4. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 8.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 RFC 4655 "A Path Computation Element-(PCE) Based Architecture" 81 describes a set of building blocks for constructing solutions to 82 compute Point-to-Point (P2P) Traffic Engineering (TE) label switched 83 paths across multiple areas or Autonomous System (AS) domains. A 84 typical PCE-based system comprises one or more path computation 85 servers, traffic engineering databases (TED), and a number of path 86 computation clients (PCC). A routing protocol is used to exchange 87 traffic engineering information from which the TED is constructed. A 88 PCC sends a Point-to-Point traffic engineering Label Switched Path 89 (LSP) computation request to the path computation server, which uses 90 the TED to compute the path and responses to the PCC with the 91 computed path. A path computation server is named as a PCE. The 92 communications between a PCE and a PCC for Point-to-Point label 93 switched path computations follow the PCE communication protocol 94 (PCEP). 96 RFC6006 "Extensions to PCEP for Point-to-Multipoint Traffic 97 Engineering Label Switched Paths" describes extensions to PCEP to 98 handle requests and responses for the computation of paths for P2MP 99 TE LSPs. 101 This document defines extensions to the Path Computation Element 102 Communication Protocol (PCEP) for a PCC to send a request for 103 computing a backup egress node for an MPLS TE P2MP LSP or an MPLS TE 104 P2P LSP to a PCE and for a PCE to compute the backup egress node and 105 reply to the PCC with a computation result for the backup egress 106 node. 108 2. Terminology 110 This document uses terminologies defined in RFC5440, and RFC4875. 112 3. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119. 118 4. Extensions to PCEP 120 This section describes the extensions to PCEP for computing a backup 121 egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 123 4.1. Backup Egress Capability Advertisement 125 4.1.1. Capability TLV in Existing PCE Discovery Protocol 127 An option for advertising a PCE capability for computing a backup 128 egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP is to define two 129 new flags. One new flag in the OSPF and IS-IS PCE Capability Flags 130 indicates the capability that a PCE is capable to compute a backup 131 egress for an MPLS TE P2MP LSP; and another new flag in the OSPF and 132 IS-IS PCE Capability Flags indicates the capability that a PCE is 133 capable to compute a backup egress for an MPLS TE P2P LSP. 135 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type = 5 | Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 ~ PCE Capability Flags ~ 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Type: 5 147 Length: Multiple of 4 octets 148 Value: This contains an array of units of 32-bit flags 149 numbered from the most significant as bit zero, where 150 each bit represents one PCE capability. 152 The following capability bits have been assigned by IANA: 154 Bit Capabilities 155 0 Path computation with GMPLS link constraints 156 1 Bidirectional path computation 157 2 Diverse path computation 158 3 Load-balanced path computation 159 4 Synchronized path computation 160 5 Support for multiple objective functions 161 6 Support for additive path constraints 162 (max hop count, etc.) 163 7 Support for request prioritization 164 8 Support for multiple requests per message 165 9 Global Concurrent Optimization (GCO) 166 10 P2MP path computation 167 11-31 Reserved for future assignments by IANA. 169 Reserved bits SHOULD be set to zero on transmission and MUST be 170 ignored on receipt. 172 For the backup egress capabilities, one bit such as bit 13 may be 173 assigned to indicate that a PCE is capable to compute a backup egress 174 for an MPLS TE P2MP LSP and another bit such as bit 14 may be 175 assigned to indicate that a PCE is capable to compute a backup egress 176 for an MPLS TE P2P LSP as follows. 178 Bit Capabilities 179 13 Backup egress computation for P2MP LSP 180 14 Backup egress computation for P2P LSP 181 15-31 Reserved for future assignments by IANA. 183 4.1.2. Open Message Extension 185 If a PCE does not advertise its backup egress compution capability 186 during discovery, PCEP should be used to allow a PCC to discover, 187 during the Open Message Exchange, which PCEs are capable of 188 supporting backup egress computation. 190 To achieve this, we extend the PCEP OPEN object by defining a new 191 optional TLV to indicate the PCE's capability to perform backup 192 egress computation for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 194 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 195 Indicators" subregistry, as documented in Section below ("Backup 196 Egress Capability TLV"). The description is "backup egress capable", 197 and the length value is 2 bytes. The value field is set to indicate 198 the capability of a PCE for backup egress computation for an MPLS TE 199 LSP in details. 201 We can use flag bits in the value field in the same way as the PCE 202 Capability Flags described in the previous section. 204 The inclusion of this TLV in an OPEN object indicates that the sender 205 can perform backup egress computation for an MPLS TE P2MP LSP or an 206 MPLS TE P2P LSP. 208 The capability TLV is meaningful only for a PCE, so it will typically 209 appear only in one of the two Open messages during PCE session 210 establishment. However, in case of PCE cooperation (e.g., inter- 211 domain), when a PCE behaving as a PCC initiates a PCE session it 212 SHOULD also indicate its path computation capabilities. 214 4.2. Request and Reply Message Extension 216 This section describes extensions to the existing RP (Request 217 Parameters) object to allow a PCC to request a PCE for computing a 218 backup egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 219 PCE receives the PCEP request. 221 4.2.1. RP Object Extension 223 The following flags are added into the RP Object: 225 The T bit is added in the flag bits field of the RP object to tell 226 the receiver of the message that the request/reply is for computing a 227 bcakup egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 229 o T ( Backup Egress bit - 1 bit): 230 0: This indicates that this is not PCReq/PCRep 231 for backup egress. 232 1: This indicates that this is PCReq or PCRep message 233 for backup egress. 235 The IANA request is referenced in Section below (Request Parameter 236 Bit Flags) of this document. 238 This T bit with the N bit defined in RFC 6006 can indicate whether a 239 request/reply is for a bcakup egress of an MPLS TE P2MP LSP or an 240 MPLS TE P2P LSP. 242 o T = 1 and N = 1: This indicates that this is a PCReq/PCRep 243 message for backup egress of an MPLS TE 244 P2MP LSP. 245 o T = 1 and N = 0: This indicates that this is a PCReq/PCRep 246 message for backup egress of an MPLS TE 247 P2P LSP. 249 4.2.2. External Destination Nodes 251 In addition to the information about the path that an MPLS TE P2MP 252 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 253 other information that may be used for computing the backup egress 254 for the P2MP LSP or P2P LSP. For example, the information about an 255 external destination node, to which data traffic is delivered from an 256 egress node of the P2MP LSP or P2P LSP, is useful for computing a 257 backup egress node. 259 4.2.2.1. External Destination Nodes Object 261 The PCC can specify an external destination nodes (EDN) Object. In 262 order to represent the external destination nodes efficiently, we 263 define two types of encodes for the external destination nodes in the 264 object. 266 One encode indicates that the EDN object contains an external 267 destination node for every egress node of an MPLS TE P2MP LSP or an 268 MPLS TE P2P LSP. The order of the external destination nodes in the 269 object is the same as the egress node(s) of the P2MP LSP or P2P LSP 270 contained in the PCE messages. 272 Another encode indicates that the EDN object contains a list of 273 egress node and external destination node pairs. For an egress node 274 and external destination node pair, the data traffic is delivered to 275 the external destination node from the egress node of the LSP. 277 The format of the external destination nodes (EDN) object boby for 278 IPv4 with the first type of encodes is illustrated as follows: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Encode of External Destination Nodes (1) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | External Destination IPv4 address | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | External Destination IPv4 address | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 ~ ... ~ 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | External Destination IPv4 address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 The format of the external destination nodes (EDN) object boby for 295 IPv4 with the second type of encodes is illustrated below: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Encode of External Destination Nodes (2) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Egress IPv4 address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | External Destination IPv4 address | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Egress IPv4 address | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | External Destination IPv4 address | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ~ ... ~ 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Egress IPv4 address | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | External Destination IPv4 address | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 The format of the external destination nodes (EDN) object boby for 318 IPv6 with the first type of encodes is illustrated as follows: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Encode of External Destination Nodes (1) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | External Destination IPv6 address (16 bytes) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | External Destination IPv6 address (16 bytes) | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ ... ~ 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 | External Destination IPv6 address (16 bytes) | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 The format of the external destination nodes (EDN) object boby for 341 IPv6 with the second type of encodes is illustrated below: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Encode of External Destination Nodes (2) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 | Egress IPv6 address | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | External Destination IPv6 address (16 bytes) | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 | Egress IPv6 address | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 | External Destination IPv6 address (16 bytes) | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 ~ ... ~ 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 | Egress IPv6 address | 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | External Destination IPv6 address (16 bytes) | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 The object can only be carried in a PCReq message. A Path Request 376 may carry at most one external destination nodes Object. 378 The Object-Class and Object-types will need to be allocated by IANA. 379 The IANA request is documented in Section below (PCEP Objects). 381 4.2.2.2. New Type of END-POINTS Objects 383 Alternatively, we may use END-POINTS to represent external 384 destination nodes in a request message for computing backup egress 385 nodes of MPLS LSP. 387 The format of the external destination nodes (EDN) END-POINTS object 388 boby for IPv4 with the first type of encodes is illustrated as 389 follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Compact External Destination Nodes Type (12) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | External Destination IPv4 address | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | External Destination IPv4 address | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ~ ... ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | External Destination IPv4 address | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 The new type of END-POINTS is Compact External Destination Nodes Type 406 (12). The final value for the type will be assigned by IANA. The 407 EDN END-POINTS object of type 12 contains an external destination 408 node for every egress node of an MPLS TE P2MP LSP or an MPLS TE P2P 409 LSP. The order of the external destination nodes in the object is 410 the same as the egress node(s) of the P2MP LSP or P2P LSP contained 411 in the PCE messages. 413 The format of the external destination nodes END-POINTS object boby 414 for IPv4 with the second type of encodes is illustrated below: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | External Destination Nodes Type (13) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Egress IPv4 address | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | External Destination IPv4 address | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Egress IPv4 address | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | External Destination IPv4 address | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ~ ... ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Egress IPv4 address | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | External Destination IPv4 address | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 The new type of END-POINTS is External Destination Nodes Type (13). 437 The final value for the type will be assigned by IANA. The EDN END- 438 POINTS object of type 13 contains a list of egress node and external 439 destination node pairs. For an egress node and external destination 440 node pair, the data traffic is delivered to the external destination 441 node from the egress node of the LSP. 443 4.2.3. Constraints between Egress and Backup Egress 445 A request message sent to a PCE from a PCC for computing a backup 446 egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 447 constraint indicating that there must be a path from the backup 448 egress node to be computed to the egress node of the P2MP LSP or P2P 449 LSP and that the length of the path is within a given hop limit such 450 as one hop. 452 This constraint can be considered as default by a PCE or explicitly 453 sent to the PCE by a PCC [TBD]. 455 4.2.4. Constraints for Backup Path 457 A request message sent to a PCE from a PCC for computing a backup 458 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 459 that the backup egress node to be computed may not be a node on the 460 P2MP LSP or P2P LSP. In addition, the request message may comprise a 461 list of nodes, each of which is a candidate for the backup egress 462 node. 464 A request message sent to a PCE from a PCC for computing a backup 465 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 466 that there must be a path from the previous hop node of the egress 467 node of the P2MP LSP or P2P LSP to the backup egress node to be 468 computed and that there is not an internal node of the path from the 469 previous hop node of the egress node of the P2MP LSP or P2P LSP to 470 the backup egress that is on the path of the P2MP LSP or P2P LSP. 472 Most of these constraints for the backup path can be considered as 473 default by a PCE. The constraints for the backup path may be 474 explicitly sent to the PCE by a PCC [TBD]. 476 4.2.5. Backup Egress Node 478 The PCE may send a reply message to the PCC in return to the request 479 message for computing a new backup egress node or a number of backup 480 egress nodes. The reply message may comprise information about the 481 computed backup egress node(s), which is contained in the path(s) 482 from the previous-hop node of the egress node of the P2MP LSP or P2P 483 LSP to the backup egress node(s) computed. 485 4.2.6. Backup Egress PCEP Error Objects and Types 487 In some cases, the PCE may not complete the backup egress computation 488 as requested, for example based on a set of constraints. As such, 489 the PCE may send a reply message to the PCC that indicates an 490 unsuccessful backup egress computation attempt. The reply message 491 may comprise a PCEP-error object, which may comprise an error-value, 492 error-type and some detail information. 494 4.2.7. Request Message Format 496 The PCReq message is encoded as follows using RBNF as defined in 497 [RFC5511]. 499 Below is the message format for a request message: 501 ::= 502 [] 503 504 ::= 505 [] [] [] 506 [] 507 [] 508 [] 509 [] 510 where: 511 is an external destination nodes object. 513 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 514 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 515 RFC5440 and RFC6006. 517 4.2.8. Reply Message Format 519 The PCRep message is encoded as follows using RBNF as defined in 520 [RFC5511]. 522 Below is the message format for a reply message: 524 ::= 525 526 ::= 527 528 [] 529 [] 530 where: 531 ::= 532 [][] 534 ::= (|) [] 536 ::= [] 537 [] 538 [] 539 [] 540 [] 542 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 543 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 544 RFC4875. 546 5. Security Considerations 548 The mechanism described in this document does not raise any new 549 security issues for the PCEP, OSPF or IS-IS protocols. 551 6. IANA Considerations 553 This section specifies requests for IANA allocation. 555 6.1. Backup Egress Capability Flag 557 Two new OSPF Capability Flags are defined in this document to 558 indicate the capabilities for computing a backup egress for an MPLS 559 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 560 assignment from the "OSPF Parameters Path Computation Element (PCE) 561 Capability Flags" registry: 563 Bit Description Reference 564 13 Backup egress for P2MP LSP This I-D 565 14 Backup egress for P2P LSP This I-D 567 6.2. Backup Egress Capability TLV 569 A new backup egress capability TLV is defined in this document to 570 allow a PCE to advertize its backup egress computation capability. 571 IANA is requested to make the following allocation from the "PCEP TLV 572 Type Indicators" sub-registry. 574 Value Description Reference 575 8 Backup egress capable This I-D 577 6.3. Request Parameter Bit Flags 579 A new RP Object Flag has been defined in this document. IANA is 580 requested to make the following allocation from the "PCEP RP Object 581 Flag Field" Sub-Registry: 583 Bit Description Reference 584 15 Backup egress (T-bit) This I-D 586 6.4. PCEP Objects 588 An External Destination Nodes Object-Type is defined in this 589 document. IANA is requested to make the following Object-Type 590 allocation from the "PCEP Objects" sub-registry: 592 Object-Class Value 34 593 Name External Destination Nodes 594 Object-Type 1: IPv4 595 2: IPv6 596 3-15: Unassigned 597 Reference This I-D 599 7. Acknowledgement 601 The author would like to thank Ramon Casellas, Dhruv Dhody and 602 Quintin Zhao for their valuable comments on this draft. 604 8. References 606 8.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 614 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 615 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 616 . 618 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 619 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 620 DOI 10.17487/RFC4090, May 2005, 621 . 623 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 624 Yasukawa, Ed., "Extensions to Resource Reservation 625 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 626 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 627 DOI 10.17487/RFC4875, May 2007, 628 . 630 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 631 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 632 DOI 10.17487/RFC5440, March 2009, 633 . 635 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 636 Ali, Z., and J. Meuric, "Extensions to the Path 637 Computation Element Communication Protocol (PCEP) for 638 Point-to-Multipoint Traffic Engineering Label Switched 639 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 640 . 642 8.2. Informative References 644 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 645 Element (PCE)-Based Architecture", RFC 4655, 646 DOI 10.17487/RFC4655, August 2006, 647 . 649 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 650 (PCC) - Path Computation Element (PCE) Requirements for 651 Point-to-Multipoint MPLS-TE", RFC 5862, 652 DOI 10.17487/RFC5862, June 2010, 653 . 655 Author's Address 656 Huaimo Chen 657 Futurewei 658 Boston, MA 659 USA 661 Email: Huaimo.chen@futurewei.com