idnits 2.17.1 draft-chen-pce-compute-backup-egress-10.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 (October 31, 2016) is 2705 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 478, but not defined == Missing Reference: 'RFC5511' is mentioned on line 524, but not defined == Unused Reference: 'RFC2119' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 653, 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 October 31, 2016 5 Expires: May 4, 2017 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-10.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 May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 5 60 4.2. Request and Reply Message Extension . . . . . . . . . . . 6 61 4.2.1. RP Object Extension . . . . . . . . . . . . . . . . . 6 62 4.2.2. External Destination Nodes . . . . . . . . . . . . . . 6 63 4.2.3. Constraints between Egress and Backup Egress . . . . . 11 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 . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 14 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 RFC 4655 "A Path Computation Element-(PCE) Based Architecture" 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 RFC6006 "Extensions to PCEP for Point-to-Multipoint Traffic 100 Engineering Label Switched Paths" describes extensions to PCEP to 101 handle requests and responses for the computation of paths for P2MP 102 TE LSPs. 104 This document defines extensions to the Path Computation Element 105 Communication Protocol (PCEP) for a PCC to send a request for 106 computing a backup egress node for an MPLS TE P2MP LSP or an MPLS TE 107 P2P LSP to a PCE and for a PCE to compute the backup egress node and 108 reply to the PCC with a computation result for the backup egress 109 node. 111 2. Terminology 113 This document uses terminologies defined in RFC5440, and RFC4875. 115 3. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119. 121 4. Extensions to PCEP 123 This section describes the extensions to PCEP for computing a backup 124 egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 126 4.1. Backup Egress Capability Advertisement 128 4.1.1. Capability TLV in Existing PCE Discovery Protocol 130 An option for advertising a PCE capability for computing a backup 131 egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP is to define two 132 new flags. One new flag in the OSPF and IS-IS PCE Capability Flags 133 indicates the capability that a PCE is capable to compute a backup 134 egress for an MPLS TE P2MP LSP; and another new flag in the OSPF and 135 IS-IS PCE Capability Flags indicates the capability that a PCE is 136 capable to compute a backup egress for an MPLS TE P2P LSP. 138 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type = 5 | Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 ~ PCE Capability Flags ~ 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Type: 5 150 Length: Multiple of 4 octets 151 Value: This contains an array of units of 32-bit flags 152 numbered from the most significant as bit zero, where 153 each bit represents one PCE capability. 155 The following capability bits have been assigned by IANA: 157 Bit Capabilities 158 0 Path computation with GMPLS link constraints 159 1 Bidirectional path computation 160 2 Diverse path computation 161 3 Load-balanced path computation 162 4 Synchronized path computation 163 5 Support for multiple objective functions 164 6 Support for additive path constraints 165 (max hop count, etc.) 166 7 Support for request prioritization 167 8 Support for multiple requests per message 168 9 Global Concurrent Optimization (GCO) 169 10 P2MP path computation 170 11-31 Reserved for future assignments by IANA. 172 Reserved bits SHOULD be set to zero on transmission and MUST be 173 ignored on receipt. 175 For the backup egress capabilities, one bit such as bit 13 may be 176 assigned to indicate that a PCE is capable to compute a backup egress 177 for an MPLS TE P2MP LSP and another bit such as bit 14 may be 178 assigned to indicate that a PCE is capable to compute a backup egress 179 for an MPLS TE P2P LSP as follows. 181 Bit Capabilities 182 13 Backup egress computation for P2MP LSP 183 14 Backup egress computation for P2P LSP 184 15-31 Reserved for future assignments by IANA. 186 4.1.2. Open Message Extension 188 If a PCE does not advertise its backup egress compution capability 189 during discovery, PCEP should be used to allow a PCC to discover, 190 during the Open Message Exchange, which PCEs are capable of 191 supporting backup egress computation. 193 To achieve this, we extend the PCEP OPEN object by defining a new 194 optional TLV to indicate the PCE's capability to perform backup 195 egress computation for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 197 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 198 Indicators" subregistry, as documented in Section below ("Backup 199 Egress Capability TLV"). The description is "backup egress capable", 200 and the length value is 2 bytes. The value field is set to indicate 201 the capability of a PCE for backup egress computation for an MPLS TE 202 LSP in details. 204 We can use flag bits in the value field in the same way as the PCE 205 Capability Flags described in the previous section. 207 The inclusion of this TLV in an OPEN object indicates that the sender 208 can perform backup egress computation for an MPLS TE P2MP LSP or an 209 MPLS TE P2P LSP. 211 The capability TLV is meaningful only for a PCE, so it will typically 212 appear only in one of the two Open messages during PCE session 213 establishment. However, in case of PCE cooperation (e.g., inter- 214 domain), when a PCE behaving as a PCC initiates a PCE session it 215 SHOULD also indicate its path computation capabilities. 217 4.2. Request and Reply Message Extension 219 This section describes extensions to the existing RP (Request 220 Parameters) object to allow a PCC to request a PCE for computing a 221 backup egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 222 PCE receives the PCEP request. 224 4.2.1. RP Object Extension 226 The following flags are added into the RP Object: 228 The T bit is added in the flag bits field of the RP object to tell 229 the receiver of the message that the request/reply is for computing a 230 bcakup egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 232 o T ( Backup Egress bit - 1 bit): 233 0: This indicates that this is not PCReq/PCRep 234 for backup egress. 235 1: This indicates that this is PCReq or PCRep message 236 for backup egress. 238 The IANA request is referenced in Section below (Request Parameter 239 Bit Flags) of this document. 241 This T bit with the N bit defined in RFC 6006 can indicate whether a 242 request/reply is for a bcakup egress of an MPLS TE P2MP LSP or an 243 MPLS TE P2P LSP. 245 o T = 1 and N = 1: This indicates that this is a PCReq/PCRep 246 message for backup egress of an MPLS TE 247 P2MP LSP. 248 o T = 1 and N = 0: This indicates that this is a PCReq/PCRep 249 message for backup egress of an MPLS TE 250 P2P LSP. 252 4.2.2. External Destination Nodes 254 In addition to the information about the path that an MPLS TE P2MP 255 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 256 other information that may be used for computing the backup egress 257 for the P2MP LSP or P2P LSP. For example, the information about an 258 external destination node, to which data traffic is delivered from an 259 egress node of the P2MP LSP or P2P LSP, is useful for computing a 260 backup egress node. 262 4.2.2.1. External Destination Nodes Object 264 The PCC can specify an external destination nodes (EDN) Object. In 265 order to represent the external destination nodes efficiently, we 266 define two types of encodes for the external destination nodes in the 267 object. 269 One encode indicates that the EDN object contains an external 270 destination node for every egress node of an MPLS TE P2MP LSP or an 271 MPLS TE P2P LSP. The order of the external destination nodes in the 272 object is the same as the egress node(s) of the P2MP LSP or P2P LSP 273 contained in the PCE messages. 275 Another encode indicates that the EDN object contains a list of 276 egress node and external destination node pairs. For an egress node 277 and external destination node pair, the data traffic is delivered to 278 the external destination node from the egress node of the LSP. 280 The format of the external destination nodes (EDN) object boby for 281 IPv4 with the first type of encodes is illustrated as follows: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Encode of External Destination Nodes (1) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | External Destination IPv4 address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | External Destination IPv4 address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 ~ ... ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | External Destination IPv4 address | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The format of the external destination nodes (EDN) object boby for 298 IPv4 with the second type of encodes is illustrated below: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Encode of External Destination Nodes (2) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Egress IPv4 address | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | External Destination IPv4 address | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Egress IPv4 address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | External Destination IPv4 address | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 ~ ... ~ 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Egress IPv4 address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | External Destination IPv4 address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 The format of the external destination nodes (EDN) object boby for 321 IPv6 with the first type of encodes is illustrated as follows: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Encode of External Destination Nodes (1) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 | External Destination IPv6 address (16 bytes) | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 | External Destination IPv6 address (16 bytes) | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ~ ... ~ 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | External Destination IPv6 address (16 bytes) | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 The format of the external destination nodes (EDN) object boby for 344 IPv6 with the second type of encodes is illustrated below: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Encode of External Destination Nodes (2) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 | Egress IPv6 address | 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 | External Destination IPv6 address (16 bytes) | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 | Egress IPv6 address | 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | External Destination IPv6 address (16 bytes) | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ~ ... ~ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 | Egress IPv6 address | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 | External Destination IPv6 address (16 bytes) | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 The object can only be carried in a PCReq message. A Path Request 379 may carry at most one external destination nodes Object. 381 The Object-Class and Object-types will need to be allocated by IANA. 382 The IANA request is documented in Section below (PCEP Objects). 384 4.2.2.2. New Type of END-POINTS Objects 386 Alternatively, we may use END-POINTS to represent external 387 destination nodes in a request message for computing backup egress 388 nodes of MPLS LSP. 390 The format of the external destination nodes (EDN) END-POINTS object 391 boby for IPv4 with the first type of encodes is illustrated as 392 follows: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Compact External Destination Nodes Type (12) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | External Destination IPv4 address | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | External Destination IPv4 address | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 ~ ... ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | External Destination IPv4 address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 The new type of END-POINTS is Compact External Destination Nodes Type 409 (12). The final value for the type will be assigned by IANA. The 410 EDN END-POINTS object of type 12 contains an external destination 411 node for every egress node of an MPLS TE P2MP LSP or an MPLS TE P2P 412 LSP. The order of the external destination nodes in the object is 413 the same as the egress node(s) of the P2MP LSP or P2P LSP contained 414 in the PCE messages. 416 The format of the external destination nodes END-POINTS object boby 417 for IPv4 with the second type of encodes is illustrated below: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | External Destination Nodes Type (13) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Egress IPv4 address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | External Destination IPv4 address | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Egress IPv4 address | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | External Destination IPv4 address | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 ~ ... ~ 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Egress IPv4 address | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | External Destination IPv4 address | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 The new type of END-POINTS is External Destination Nodes Type (13). 441 The final value for the type will be assigned by IANA. The EDN END- 442 POINTS object of type 13 contains a list of egress node and external 443 destination node pairs. For an egress node and external destination 444 node pair, the data traffic is delivered to the external destination 445 node from the egress node of the LSP. 447 4.2.3. Constraints between Egress and Backup Egress 449 A request message sent to a PCE from a PCC for computing a backup 450 egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 451 constraint indicating that there must be a path from the backup 452 egress node to be computed to the egress node of the P2MP LSP or P2P 453 LSP and that the length of the path is within a given hop limit such 454 as one hop. 456 This constraint can be considered as default by a PCE or explicitly 457 sent to the PCE by a PCC [TBD]. 459 4.2.4. Constraints for Backup Path 461 A request message sent to a PCE from a PCC for computing a backup 462 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 463 that the backup egress node to be computed may not be a node on the 464 P2MP LSP or P2P LSP. In addition, the request message may comprise a 465 list of nodes, each of which is a candidate for the backup egress 466 node. 468 A request message sent to a PCE from a PCC for computing a backup 469 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 470 that there must be a path from the previous hop node of the egress 471 node of the P2MP LSP or P2P LSP to the backup egress node to be 472 computed and that there is not an internal node of the path from the 473 previous hop node of the egress node of the P2MP LSP or P2P LSP to 474 the backup egress that is on the path of the P2MP LSP or P2P LSP. 476 Most of these constraints for the backup path can be considered as 477 default by a PCE. The constraints for the backup path may be 478 explicitly sent to the PCE by a PCC [TBD]. 480 4.2.5. Backup Egress Node 482 The PCE may send a reply message to the PCC in return to the request 483 message for computing a new backup egress node or a number of backup 484 egress nodes. The reply message may comprise information about the 485 computed backup egress node(s), which is contained in the path(s) 486 from the previous-hop node of the egress node of the P2MP LSP or P2P 487 LSP to the backup egress node(s) computed. 489 4.2.6. Backup Egress PCEP Error Objects and Types 491 In some cases, the PCE may not complete the backup egress computation 492 as requested, for example based on a set of constraints. As such, 493 the PCE may send a reply message to the PCC that indicates an 494 unsuccessful backup egress computation attempt. The reply message 495 may comprise a PCEP-error object, which may comprise an error-value, 496 error-type and some detail information. 498 4.2.7. Request Message Format 500 The PCReq message is encoded as follows using RBNF as defined in 501 [RFC5511]. 503 Below is the message format for a request message: 505 ::= 506 [] 507 508 ::= 509 [] [] [] 510 [] 511 [] 512 [] 513 [] 514 where: 515 is an external destination nodes object. 517 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 518 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 519 RFC5440 and RFC6006. 521 4.2.8. Reply Message Format 523 The PCRep message is encoded as follows using RBNF as defined in 524 [RFC5511]. 526 Below is the message format for a reply message: 528 ::= 529 530 ::= 531 532 [] 533 [] 534 where: 535 ::= 536 [][] 538 ::= (|) [] 540 ::= [] 541 [] 542 [] 543 [] 544 [] 546 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 547 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 548 RFC4875. 550 5. Security Considerations 552 The mechanism described in this document does not raise any new 553 security issues for the PCEP, OSPF or IS-IS protocols. 555 6. IANA Considerations 557 This section specifies requests for IANA allocation. 559 6.1. Backup Egress Capability Flag 561 Two new OSPF Capability Flags are defined in this document to 562 indicate the capabilities for computing a backup egress for an MPLS 563 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 564 assignment from the "OSPF Parameters Path Computation Element (PCE) 565 Capability Flags" registry: 567 Bit Description Reference 568 13 Backup egress for P2MP LSP This I-D 569 14 Backup egress for P2P LSP This I-D 571 6.2. Backup Egress Capability TLV 573 A new backup egress capability TLV is defined in this document to 574 allow a PCE to advertize its backup egress computation capability. 575 IANA is requested to make the following allocation from the "PCEP TLV 576 Type Indicators" sub-registry. 578 Value Description Reference 579 8 Backup egress capable This I-D 581 6.3. Request Parameter Bit Flags 583 A new RP Object Flag has been defined in this document. IANA is 584 requested to make the following allocation from the "PCEP RP Object 585 Flag Field" Sub-Registry: 587 Bit Description Reference 588 15 Backup egress (T-bit) This I-D 590 6.4. PCEP Objects 592 An External Destination Nodes Object-Type is defined in this 593 document. IANA is requested to make the following Object-Type 594 allocation from the "PCEP Objects" sub-registry: 596 Object-Class Value 34 597 Name External Destination Nodes 598 Object-Type 1: IPv4 599 2: IPv6 600 3-15: Unassigned 601 Reference This I-D 603 7. Acknowledgement 605 The author would like to thank Ramon Casellas, Dhruv Dhody and 606 Quintin Zhao for their valuable comments on this draft. 608 8. References 610 8.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 614 RFC2119, March 1997, 615 . 617 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 618 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 619 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 620 . 622 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 623 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 624 DOI 10.17487/RFC4090, May 2005, 625 . 627 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 628 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 629 DOI 10.17487/RFC5440, March 2009, 630 . 632 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 633 Yasukawa, Ed., "Extensions to Resource Reservation 634 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 635 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 636 DOI 10.17487/RFC4875, May 2007, 637 . 639 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 640 Ali, Z., and J. Meuric, "Extensions to the Path 641 Computation Element Communication Protocol (PCEP) for 642 Point-to-Multipoint Traffic Engineering Label Switched 643 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 644 . 646 8.2. Informative References 648 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 649 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 650 RFC4655, August 2006, 651 . 653 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 654 (PCC) - Path Computation Element (PCE) Requirements for 655 Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/ 656 RFC5862, June 2010, 657 . 659 Author's Address 661 Huaimo Chen 662 Huawei Technologies 663 Boston, MA 664 USA 666 Email: Huaimo.chen@huawei.com