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