idnits 2.17.1 draft-chen-pce-compute-backup-egress-03.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 30, 2011) is 4560 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 497, but not defined == Missing Reference: 'RFC5511' is mentioned on line 548, but not defined == Unused Reference: 'RFC2119' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 673, 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 C. Margaria 5 Expires: May 2, 2012 Nokia Siemens Networks 6 October 30, 2011 8 Extensions to the Path Computation Element Communication Protocol (PCEP) 9 for Backup Egress of a Traffic Engineering Label Switched Path 10 draft-chen-pce-compute-backup-egress-03.txt 12 Abstract 14 This document presents extensions to the Path Computation Element 15 Communication Protocol (PCEP) for a PCC to send a request for 16 computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P 17 LSP to a PCE and for a PCE to compute the backup egress and reply to 18 the PCC with a computation result for the backup egress. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 2, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Backup Egress Capability Advertisement . . . . . . . . . . 4 59 4.1.1. Capability TLV in Existing PCE Discovery Protocol . . 4 60 4.1.2. Open Message Extension . . . . . . . . . . . . . . . . 5 61 4.2. Request and Reply Message Extension . . . . . . . . . . . 6 62 4.2.1. RP Object Extension . . . . . . . . . . . . . . . . . 6 63 4.2.2. External Destination Nodes . . . . . . . . . . . . . . 6 64 4.2.3. Constraints between Egress and Backup Egress . . . . . 11 65 4.2.4. Constraints for Backup Path . . . . . . . . . . . . . 11 66 4.2.5. Backup Egress Node . . . . . . . . . . . . . . . . . . 12 67 4.2.6. Backup Egress PCEP Error Objects and Types . . . . . . 12 68 4.2.7. Request Message Format . . . . . . . . . . . . . . . . 12 69 4.2.8. Reply Message Format . . . . . . . . . . . . . . . . . 13 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 6.1. Backup Egress Capability Flag . . . . . . . . . . . . . . 14 73 6.2. Backup Egress Capability TLV . . . . . . . . . . . . . . . 15 74 6.3. Request Parameter Bit Flags . . . . . . . . . . . . . . . 15 75 6.4. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 15 76 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 RFC 4655 "A Path Computation Element-(PCE) Based Architecture" 85 describes a set of building blocks for constructing solutions to 86 compute Point-to-Point (P2P) Traffic Engineering (TE) label switched 87 paths across multiple areas or Autonomous System (AS) domains. A 88 typical PCE-based system comprises one or more path computation 89 servers, traffic engineering databases (TED), and a number of path 90 computation clients (PCC). A routing protocol is used to exchange 91 traffic engineering information from which the TED is constructed. A 92 PCC sends a Point-to-Point traffic engineering Label Switched Path 93 (LSP) computation request to the path computation server, which uses 94 the TED to compute the path and responses to the PCC with the 95 computed path. A path computation server is named as a PCE. The 96 communications between a PCE and a PCC for Point-to-Point label 97 switched path computations follow the PCE communication protocol 98 (PCEP). 100 RFC6006 "Extensions to PCEP for Point-to-Multipoint Traffic 101 Engineering Label Switched Paths" describes extensions to PCEP to 102 handle requests and responses for the computation of paths for P2MP 103 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 An option for advertising a PCE capability for computing a backup 132 egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP is to define two 133 new flags. One new flag in the OSPF and IS-IS PCE Capability Flags 134 indicates the capability that a PCE is capable to compute a backup 135 egress for an MPLS TE P2MP LSP; and another new flag in the OSPF and 136 IS-IS PCE Capability Flags indicates the capability that a PCE is 137 capable to compute a backup egress for an MPLS TE P2P LSP.. 139 The format of the PCE-CAP-FLAGS sub-TLV is as follows: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type = 5 | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 // PCE Capability Flags // 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Type: 5 152 Length: Multiple of 4 octets 153 Value: This contains an array of units of 32-bit flags 154 numbered from the most significant as bit zero, where 155 each bit represents one PCE capability. 157 The following capability bits have been assigned by IANA: 159 Bit Capabilities 161 0 Path computation with GMPLS link constraints 162 1 Bidirectional path computation 163 2 Diverse path computation 164 3 Load-balanced path computation 165 4 Synchronized path computation 166 5 Support for multiple objective functions 167 6 Support for additive path constraints 168 (max hop count, etc.) 169 7 Support for request prioritization 170 8 Support for multiple requests per message 171 9 Global Concurrent Optimization (GCO) 172 10 P2MP path computation 173 11-31 Reserved for future assignments by IANA. 175 Reserved bits SHOULD be set to zero on transmission and MUST be 176 ignored on receipt. 178 For the backup egress capabilities, one bit such as bit 13 may be 179 assigned to indicate that a PCE is capable to compute a backup egress 180 for an MPLS TE P2MP LSP and another bit such as bit 14 may be 181 assigned to indicate that a PCE is capable to compute a backup egress 182 for an MPLS TE P2P LSP as follows. 184 Bit Capabilities 186 13 Backup egress computation for P2MP LSP 187 14 Backup egress computation for P2P LSP 189 15-31 Reserved for future assignments by IANA. 191 4.1.2. Open Message Extension 193 If a PCE does not advertise its backup egress compution capability 194 during discovery, PCEP should be used to allow a PCC to discover, 195 during the Open Message Exchange, which PCEs are capable of 196 supporting backup egress computation. 198 To achieve this, we extend the PCEP OPEN object by defining a new 199 optional TLV to indicate the PCE's capability to perform backup 200 egress computation for an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 202 We request IANA to allocate a value such as 8 from the "PCEP TLV Type 203 Indicators" subregistry, as documented in Section below ("Backup 204 Egress Capability TLV"). The description is "backup egress capable", 205 and the length value is 2 bytes. The value field is set to indicate 206 the capability of a PCE for backup egress computation for an MPLS TE 207 LSP in details. 209 We can use flag bits in the value field in the same way as the PCE 210 Capability Flags described in the previous section. 212 The inclusion of this TLV in an OPEN object indicates that the sender 213 can perform backup egress computation for an MPLS TE P2MP LSP or an 214 MPLS TE P2P LSP. 216 The capability TLV is meaningful only for a PCE, so it will typically 217 appear only in one of the two Open messages during PCE session 218 establishment. However, in case of PCE cooperation (e.g., inter- 219 domain), when a PCE behaving as a PCC initiates a PCE session it 220 SHOULD also indicate its path computation capabilities. 222 4.2. Request and Reply Message Extension 224 This section describes extensions to the existing RP (Request 225 Parameters) object to allow a PCC to request a PCE for computing a 226 backup egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the 227 PCE receives the PCEP request. 229 4.2.1. RP Object Extension 231 The following flags are added into the RP Object: 233 The T bit is added in the flag bits field of the RP object to tell 234 the receiver of the message that the request/reply is for computing a 235 bcakup egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP. 237 o T ( Backup Egress bit - 1 bit): 239 0: This indicates that this is not PCReq/PCRep 240 for backup egress. 242 1: This indicates that this is PCReq or PCRep message 243 for backup egress. 245 The IANA request is referenced in Section below (Request Parameter 246 Bit Flags) of this document. 248 This T bit with the N bit defined in RFC 6006 can indicate whether a 249 request/reply is for a bcakup egress of an MPLS TE P2MP LSP or an 250 MPLS TE P2P LSP. 252 o T = 1 and N = 1: This indicates that this is a PCReq/PCRep 253 message for backup egress of an MPLS TE 254 P2MP LSP. 256 o T = 1 and N = 0: This indicates that this is a PCReq/PCRep 257 message for backup egress of an MPLS TE 258 P2P LSP. 260 4.2.2. External Destination Nodes 262 In addition to the information about the path that an MPLS TE P2MP 263 LSP or an MPLS TE P2P LSP traverses, a request message may comprise 264 other information that may be used for computing the backup egress 265 for the P2MP LSP or P2P LSP. For example, the information about an 266 external destination node, to which data traffic is delivered from an 267 egress node of the P2MP LSP or P2P LSP, is useful for computing a 268 backup egress node. 270 4.2.2.1. External Destination Nodes Object 272 The PCC can specify an external destination nodes (EDN) Object. In 273 order to represent the external destination nodes efficiently, we 274 define two types of encodes for the external destination nodes in the 275 object. 277 One encode indicates that the EDN object contains an external 278 destination node for every egress node of an MPLS TE P2MP LSP or an 279 MPLS TE P2P LSP. The order of the external destination nodes in the 280 object is the same as the egress node(s) of the P2MP LSP or P2P LSP 281 contained in the PCE messages. 283 Another encode indicates that the EDN object contains a list of 284 egress node and external destination node pairs. For an egress node 285 and external destination node pair, the data traffic is delivered to 286 the external destination node from the egress node of the LSP. 288 The format of the external destination nodes (EDN) object boby for 289 IPv4 with the first type of encodes is illustrated as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Encode of External Destination Nodes (1) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | External Destination IPv4 address | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | External Destination IPv4 address | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ ... ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | External Destination IPv4 address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 1: Format of EDN Object with one Encode for IPv4 307 The format of the external destination nodes (EDN) object boby for 308 IPv4 with the second type of encodes is illustrated below: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Encode of External Destination Nodes (2) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Egress IPv4 address | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | External Destination IPv4 address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Egress IPv4 address | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | External Destination IPv4 address | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ ... ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Egress IPv4 address | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | External Destination IPv4 address | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 2: Format of EDN Object with another Encode for IPv4 332 The format of the external destination nodes (EDN) object boby for 333 IPv6 with the first type of encodes is illustrated as follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Encode of External Destination Nodes (1) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 | External Destination IPv6 address (16 bytes) | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 | External Destination IPv6 address (16 bytes) | 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 ~ ... ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 | External Destination IPv6 address (16 bytes) | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 3: Format of EDN Object with one Encode for IPv6 357 The format of the external destination nodes (EDN) object boby for 358 IPv6 with the second type of encodes is illustrated below: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Encode of External Destination Nodes (2) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 | Egress IPv6 address | 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 | External Destination IPv6 address (16 bytes) | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 | Egress IPv6 address | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | External Destination IPv6 address (16 bytes) | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 ~ ... ~ 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | Egress IPv6 address | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | External Destination IPv6 address (16 bytes) | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 4: Format of EDN Object with another Encode for IPv6 394 The object can only be carried in a PCReq message. A Path Request 395 may carry at most one external destination nodes Object. 397 The Object-Class and Object-types will need to be allocated by IANA. 398 The IANA request is documented in Section below (PCEP Objects). 400 4.2.2.2. New Type of END-POINTS Objects 402 Alternatively, we may use END-POINTS to represent external 403 destination nodes in a request message for computing backup egress 404 nodes of MPLS LSP. 406 The format of the external destination nodes (EDN) END-POINTS object 407 boby for IPv4 with the first type of encodes is illustrated as 408 follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Compact External Destination Nodes Type (12) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | External Destination IPv4 address | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | External Destination IPv4 address | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 ~ ... ~ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | External Destination IPv4 address | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 5: EDN END-POINTS Body with one Encode for IPv4 426 The new type of END-POINTS is Compact External Destination Nodes Type 427 (12). The final value for the type will be assigned by IANA. The 428 EDN END-POINTS object of type 12 contains an external destination 429 node for every egress node of an MPLS TE P2MP LSP or an MPLS TE P2P 430 LSP. The order of the external destination nodes in the object is 431 the same as the egress node(s) of the P2MP LSP or P2P LSP contained 432 in the PCE messages. 434 The format of the external destination nodes END-POINTS object boby 435 for IPv4 with the second type of encodes is illustrated below: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | External Destination Nodes Type (13) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Egress IPv4 address | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | External Destination IPv4 address | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Egress IPv4 address | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | External Destination IPv4 address | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 ~ ... ~ 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Egress IPv4 address | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | External Destination IPv4 address | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 6: EDN END-POINTS Body with another Encode for IPv4 459 The new type of END-POINTS is External Destination Nodes Type (13). 460 The final value for the type will be assigned by IANA. The EDN END- 461 POINTS object of type 13 contains a list of egress node and external 462 destination node pairs. For an egress node and external destination 463 node pair, the data traffic is delivered to the external destination 464 node from the egress node of the LSP. 466 4.2.3. Constraints between Egress and Backup Egress 468 A request message sent to a PCE from a PCC for computing a backup 469 egress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a 470 constraint indicating that there must be a path from the backup 471 egress node to be computed to the egress node of the P2MP LSP or P2P 472 LSP and that the length of the path is within a given hop limit such 473 as one hop. 475 This constraint can be considered as default by a PCE or explicitly 476 sent to the PCE by a PCC [TBD]. 478 4.2.4. Constraints for Backup Path 480 A request message sent to a PCE from a PCC for computing a backup 481 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 482 that the backup egress node to be computed may not be a node on the 483 P2MP LSP or P2P LSP. In addition, the request message may comprise a 484 list of nodes, each of which is a candidate for the backup egress 485 node. 487 A request message sent to a PCE from a PCC for computing a backup 488 egress of a P2MP LSP or P2P LSP may comprise a constraint indicating 489 that there must be a path from the previous hop node of the egress 490 node of the P2MP LSP or P2P LSP to the backup egress node to be 491 computed and that there is not an internal node of the path from the 492 previous hop node of the egress node of the P2MP LSP or P2P LSP to 493 the backup egress that is on the path of the P2MP LSP or P2P LSP. 495 Most of these constraints for the backup path can be considered as 496 default by a PCE. The constraints for the backup path may be 497 explicitly sent to the PCE by a PCC [TBD]. 499 4.2.5. Backup Egress Node 501 The PCE may send a reply message to the PCC in return to the request 502 message for computing a new backup egress node or a number of backup 503 egress nodes. The reply message may comprise information about the 504 computed backup egress node(s), which is contained in the path(s) 505 from the previous-hop node of the egress node of the P2MP LSP or P2P 506 LSP to the backup egress node(s) computed. 508 4.2.6. Backup Egress PCEP Error Objects and Types 510 In some cases, the PCE may not complete the backup egress computation 511 as requested, for example based on a set of constraints. As such, 512 the PCE may send a reply message to the PCC that indicates an 513 unsuccessful backup egress computation attempt. The reply message 514 may comprise a PCEP-error object, which may comprise an error-value, 515 error-type and some detail information. 517 4.2.7. Request Message Format 519 The PCReq message is encoded as follows using RBNF as defined in 520 [RFC5511]. 522 Below is the message format for a request message: 524 ::= 525 [] 526 527 ::= 528 529 [] 530 [] 531 [] 532 [] 533 [] 534 [] 535 [] 536 where: 537 is an external destination nodes object. 539 Figure 7: The Format for a Request Message 541 The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, 542 BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in 543 RFC5440 and RFC6006. 545 4.2.8. Reply Message Format 547 The PCRep message is encoded as follows using RBNF as defined in 548 [RFC5511]. 550 Below is the message format for a reply message: 552 ::= 553 554 ::= 555 556 [] 557 [] 558 where: 560 ::= 561 [][] 563 ::= (|) [] 565 ::= [] 566 [] 567 [] 568 [] 569 [] 571 Figure 8: The Format for a Reply Message 573 The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, 574 metric-list, IRO, and SERO are described in RFC5440, RFC6006 and 575 RFC4875. 577 5. Security Considerations 579 The mechanism described in this document does not raise any new 580 security issues for the PCEP, OSPF or IS-IS protocols. 582 6. IANA Considerations 584 This section specifies requests for IANA allocation. 586 6.1. Backup Egress Capability Flag 588 Two new OSPF Capability Flags are defined in this document to 589 indicate the capabilities for computing a backup egress for an MPLS 590 TE P2MP LSP and an MPLS TE P2P LSP. IANA is requested to make the 591 assignment from the "OSPF Parameters Path Computation Element (PCE) 592 Capability Flags" registry: 594 Bit Description Reference 596 13 Backup egress for P2MP LSP This I-D 597 14 Backup egress for P2P LSP This I-D 599 6.2. Backup Egress Capability TLV 601 A new backup egress capability TLV is defined in this document to 602 allow a PCE to advertize its backup egress computation capability. 603 IANA is requested to make the following allocation from the "PCEP TLV 604 Type Indicators" sub-registry. 606 Value Description Reference 608 8 Backup egress capable This I-D 610 6.3. Request Parameter Bit Flags 612 A new RP Object Flag has been defined in this document. IANA is 613 requested to make the following allocation from the "PCEP RP Object 614 Flag Field" Sub-Registry: 616 Bit Description Reference 618 15 Backup egress (T-bit) This I-D 620 6.4. PCEP Objects 622 An External Destination Nodes Object-Type is defined in this 623 document. IANA is requested to make the following Object-Type 624 allocation from the "PCEP Objects" sub-registry: 626 Object-Class Value 34 627 Name External Destination Nodes 628 Object-Type 1: IPv4 629 2: IPv6 630 3-15: Unassigned 631 Reference This I-D 633 7. Acknowledgement 635 The author would like to thank Ramon Casellas, Dhruv Dhody and 636 Quintin Zhao for their valuable comments on this draft. 638 8. References 640 8.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 646 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 647 Tunnels", RFC 3209, December 2001. 649 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 650 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 651 May 2005. 653 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 654 (PCE) Communication Protocol (PCEP)", RFC 5440, 655 March 2009. 657 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 658 "Extensions to Resource Reservation Protocol - Traffic 659 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 660 Switched Paths (LSPs)", RFC 4875, May 2007. 662 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 663 and J. Meuric, "Extensions to the Path Computation Element 664 Communication Protocol (PCEP) for Point-to-Multipoint 665 Traffic Engineering Label Switched Paths", RFC 6006, 666 September 2010. 668 8.2. Informative References 670 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 671 Element (PCE)-Based Architecture", RFC 4655, August 2006. 673 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 674 (PCC) - Path Computation Element (PCE) Requirements for 675 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 677 Authors' Addresses 679 Huaimo Chen 680 Huawei Technologies 681 Boston, MA 682 USA 684 Email: Huaimochen@huawei.com 686 Cyril Margaria 687 Nokia Siemens Networks 688 St Martin Strasse 76, Munich, 81541 689 Germany 691 Email: cyril.margaria@nsn.com