idnits 2.17.1 draft-ietf-pce-pcep-service-aware-13.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 (September 22, 2016) is 2772 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) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-16 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: March 26, 2017 V. Manral 6 Ionos Network 7 Z. Ali 8 Cisco Systems 9 K. Kumaki 10 KDDI Corporation 11 September 22, 2016 13 Extensions to the Path Computation Element Communication Protocol (PCEP) 14 to compute service aware Label Switched Path (LSP). 15 draft-ietf-pce-pcep-service-aware-13 17 Abstract 19 In certain networks, such as, but not limited to, financial 20 information networks (e.g. stock market data providers), network 21 performance criteria (e.g. latency) are becoming as critical to data 22 path selection as other metrics and constraints. These metrics are 23 associated with the Service Level Agreement (SLA) between customers 24 and service providers. The link bandwidth utilization (the total 25 bandwidth of a link in actual use for the forwarding) is another 26 important factor to consider during path computation. 28 IGP Traffic Engineering (TE) Metric extensions describe mechanisms 29 with which network performance information is distributed via OSPF 30 and IS-IS respectively. The Path Computation Element Communication 31 Protocol (PCEP) provides mechanisms for Path Computation Elements 32 (PCEs) to perform path computations in response to Path Computation 33 Clients (PCCs) requests. This document describes the extension to 34 PCEP to carry latency, delay variation, packet loss and link 35 bandwidth utilization as constraints for end to end path computation. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 26, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Extensions to METRIC Object . . . . . . . . . . . . . . . 5 76 3.1.1. Path Delay Metric . . . . . . . . . . . . . . . . . . 6 77 3.1.1.1. Path Delay Metric Value . . . . . . . . . . . . . 7 78 3.1.2. Path Delay Variation Metric . . . . . . . . . . . . . 7 79 3.1.2.1. Path Delay Variation Metric Value . . . . . . . . 8 80 3.1.3. Path Loss Metric . . . . . . . . . . . . . . . . . . 8 81 3.1.3.1. Path Loss Metric Value . . . . . . . . . . . . . 9 82 3.1.4. Non-Understanding / Non-Support of Service Aware Path 83 Computation . . . . . . . . . . . . . . . . . . . . . 9 84 3.1.5. Mode of Operation . . . . . . . . . . . . . . . . . . 10 85 3.1.5.1. Examples . . . . . . . . . . . . . . . . . . . . 10 86 3.1.6. Point-to-Multipoint (P2MP) . . . . . . . . . . . . . 11 87 3.1.6.1. P2MP Path Delay Metric . . . . . . . . . . . . . 11 88 3.1.6.2. P2MP Path Delay Variation Metric . . . . . . . . 11 89 3.1.6.3. P2MP Path Loss Metric . . . . . . . . . . . . . . 12 90 3.2. Bandwidth Utilization . . . . . . . . . . . . . . . . . . 12 91 3.2.1. Link Bandwidth Utilization (LBU) . . . . . . . . . . 12 92 3.2.2. Link Reserved Bandwidth Utilization (LRBU) . . . . . 12 93 3.2.3. Bandwidth Utilization (BU) Object . . . . . . . . . . 13 94 3.2.3.1. Elements of Procedure . . . . . . . . . . . . . . 14 95 3.3. Objective Functions . . . . . . . . . . . . . . . . . . . 15 96 4. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . . . 16 97 5. PCEP Message Extension . . . . . . . . . . . . . . . . . . . 16 98 5.1. The PCReq message . . . . . . . . . . . . . . . . . . . . 17 99 5.2. The PCRep message . . . . . . . . . . . . . . . . . . . . 17 100 5.3. The PCRpt message . . . . . . . . . . . . . . . . . . . . 18 101 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 102 6.1. Inter-domain Path Computation . . . . . . . . . . . . . . 19 103 6.1.1. Inter-AS Links . . . . . . . . . . . . . . . . . . . 19 104 6.1.2. Inter-Layer Path Computation . . . . . . . . . . . . 19 105 6.2. Reoptimizing Paths . . . . . . . . . . . . . . . . . . . 20 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 107 7.1. METRIC types . . . . . . . . . . . . . . . . . . . . . . 20 108 7.2. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 21 109 7.3. BU Object . . . . . . . . . . . . . . . . . . . . . . . . 21 110 7.4. OF Codes . . . . . . . . . . . . . . . . . . . . . . . . 22 111 7.5. New Error-Values . . . . . . . . . . . . . . . . . . . . 22 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 113 9. Manageability Considerations . . . . . . . . . . . . . . . . 23 114 9.1. Control of Function and Policy . . . . . . . . . . . . . 23 115 9.2. Information and Data Models . . . . . . . . . . . . . . . 23 116 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 117 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 23 118 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 23 119 9.6. Impact On Network Operations . . . . . . . . . . . . . . 23 120 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 122 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 123 11.2. Informative References . . . . . . . . . . . . . . . . . 25 124 Appendix A. PCEP Requirements . . . . . . . . . . . . . . . . . 28 125 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 28 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 128 1. Introduction 130 Real time network performance information is becoming critical in the 131 path computation in some networks. Mechanisms to measure latency, 132 delay variation, and packet loss in an MPLS network are described in 133 [RFC6374]. It is important that latency, delay variation, and packet 134 loss are considered during the path selection process, even before 135 the LSP is set up. 137 Link bandwidth utilization based on real time traffic along the path 138 is also becoming critical during path computation in some networks. 139 Thus it is important that the link bandwidth utilization is factored 140 in during the path computation. 142 The Traffic Engineering Database (TED) is populated with network 143 performance information like link latency, delay variation, packet 144 loss, as well as parameters related to bandwidth (residual bandwidth, 145 available bandwidth and utilized bandwidth) via TE Metric Extensions 146 in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. 147 [RFC7823] describes how a Path Computation Element (PCE) [RFC4655], 148 can use that information for path selection for explicitly routed 149 LSPs. 151 A Path Computation Client (PCC) can request a PCE to provide a path 152 meeting end to end network performance criteria. This document 153 extends Path Computation Element Communication Protocol (PCEP) 154 [RFC5440] to handle network performance constraints which include any 155 combination of latency, delay variation, packet loss and bandwidth 156 utilization constraints. 158 [RFC7471] and [RFC7810] describe various considerations regarding - 160 o Announcement thresholds and filters 162 o Announcement suppression 164 o Announcement periodicity and network stability 166 The first two provide configurable mechanisms to bound the number of 167 re-advertisements in IGP. The third provides a way to throttle 168 announcements. Section 1.2 of [RFC7823] also describes the 169 oscillation and stability considerations while advertising and 170 considering service aware information. 172 1.1. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 2. Terminology 180 The following terminology is used in this document. 182 IGP: Interior Gateway Protocol; Either of the two routing protocols, 183 Open Shortest Path First (OSPF) or Intermediate System to 184 Intermediate System (IS-IS). 186 IS-IS: Intermediate System to Intermediate System 188 LBU: Link Bandwidth Utilization (See Section 3.2.1.) 190 LRBU: Link Reserved Bandwidth Utilization (See Section 3.2.2.) 192 MPLP: Minimum Packet Loss Path (See Section 3.3.) 193 MRUP: Maximum Reserved Under-Utilized Path (See Section 3.3.) 195 MUP: Maximum Under-Utilized Path (See Section 3.3.) 197 OF: Objective Function; A set of one or more optimization criteria 198 used for the computation of a single path (e.g., path cost 199 minimization) or for the synchronized computation of a set of 200 paths (e.g., aggregate bandwidth consumption minimization, etc). 201 (See [RFC5541].) 203 OSPF: Open Shortest Path First 205 PCC: Path Computation Client; any client application requesting a 206 path computation to be performed by a Path Computation Element. 208 PCE: Path Computation Element; An entity (component, application, or 209 network node) that is capable of computing a network path or route 210 based on a network graph and applying computational constraints. 212 RSVP: Resource Reservation Protocol 214 TE: Traffic Engineering 216 TED: Traffic Engineering Database 218 3. PCEP Extensions 220 This section defines PCEP extensions (see [RFC5440]) for requirements 221 outlined in Appendix A. The proposed solution is used to support 222 network performance and service aware path computation. 224 3.1. Extensions to METRIC Object 226 The METRIC object is defined in section 7.8 of [RFC5440], comprising 227 metric-value, metric-type (T field) and a flags field comprising a 228 number of bit-flags (B bit, P bit). This document defines the 229 following types for the METRIC object. 231 o T=TBD1: Path Delay metric (Section 3.1.1) 233 o T=TBD2: Path Delay Variation metric (Section 3.1.2) 235 o T=TBD3: Path Loss metric (Section 3.1.3) 237 o T=TBD8: P2MP Path Delay metric (Section 3.1.6.1) 239 o T=TBD9: P2MP Path Delay Variation metric (Section 3.1.6.2) 240 o T=TBD10: P2MP Path Loss metric (Section 3.1.6.3) 242 The following terminology is used and expanded along the way. 244 o A network comprises of a set of N links {Li, (i=1...N)}. 246 o A path P of a point to point (P2P) LSP is a list of K links 247 {Lpi,(i=1...K)}. 249 3.1.1. Path Delay Metric 251 The link delay metric is defined in [RFC7471] and [RFC7810] as 252 "Unidirectional Link Delay". The path delay metric type of the 253 METRIC object in PCEP represents the sum of the link delay metric of 254 all links along a P2P path. Specifically, extending on the above 255 mentioned terminology: 257 o A link delay metric of link L is denoted D(L). 259 o A path delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}. 261 This is as per the sum of means composition function (section 4.2.5 262 of [RFC6049]). The section 1.2 of [RFC7823] describes oscillation 263 and stability considerations, and section 2.1 of [RFC7823] describes 264 the calculation of end to end path delay metric. Further section 265 4.2.9 of [RFC6049] states when this composition function may fail. 267 Metric Type T=TBD1: Path Delay metric 269 A PCC MAY use the path delay metric in a PCReq message to request a 270 path meeting the end to end latency requirement. In this case, the B 271 bit MUST be set to suggest a bound (a maximum) for the path delay 272 metric that must not be exceeded for the PCC to consider the computed 273 path as acceptable. The path delay metric must be less than or equal 274 to the value specified in the metric-value field. 276 A PCC can also use this metric to ask PCE to optimize the path delay 277 during path computation. In this case, the B bit MUST be cleared. 279 A PCE MAY use the path delay metric in a PCRep message along with a 280 NO-PATH object in the case where the PCE cannot compute a path 281 meeting this constraint. A PCE can also use this metric to send the 282 computed path delay metric to the PCC. 284 3.1.1.1. Path Delay Metric Value 286 [RFC7471] and [RFC7810] define the "Unidirectional Link Delay Sub- 287 TLV" to advertise the link delay in microseconds in a 24-bit field. 288 [RFC5440] defines the METRIC object with a 32-bit metric value 289 encoded in IEEE floating point format (see [IEEE.754.1985]). 290 Consequently, the encoding for the path delay metric value is 291 quantified in units of microseconds and encoded in IEEE floating 292 point format. The conversion from 24 bit integer to 32 bit IEEE 293 floating point could introduce some loss of precision. 295 3.1.2. Path Delay Variation Metric 297 The link delay variation metric is defined in [RFC7471] and [RFC7810] 298 as "Unidirectional Delay Variation". The path delay variation metric 299 type of the METRIC object in PCEP encodes the sum of the link delay 300 variation metric of all links along the path. Specifically, 301 extending on the above mentioned terminology: 303 o A delay variation of link L is denoted DV(L) (average delay 304 variation for link L). 306 o A path delay variation metric for the P2P path P = Sum {DV(Lpi), 307 (i=1...K)}. 309 The section 1.2 of [RFC7823] describes oscillation and stability 310 considerations, and section 2.1 of [RFC7823] describes the 311 calculation of end to end path delay variation metric. Further 312 section 4.2.9 of [RFC6049] states when this composition function may 313 fail. 315 Note that the IGP advertisement for link attributes includes the 316 average delay variation over a period of time. An implementation, 317 therefore, MAY use the sum of the average delay variation of links 318 along a path to derive the delay variation of the path. An end-to- 319 end bound on delay variation is typically used as constraint in the 320 path computation. An implementation MAY also use some enhanced 321 composition function for computing the delay variation of a path with 322 better accuracy. 324 Metric Type T=TBD2: Path Delay Variation metric 326 A PCC MAY use the path delay variation metric in a PCReq message to 327 request a path meeting the path delay variation requirement. In this 328 case, the B bit MUST be set to suggest a bound (a maximum) for the 329 path delay variation metric that must not be exceeded for the PCC to 330 consider the computed path as acceptable. The path delay variation 331 must be less than or equal to the value specified in the metric-value 332 field. 334 A PCC can also use this metric to ask the PCE to optimize the path 335 delay variation during path computation. In this case, the B flag 336 MUST be cleared. 338 A PCE MAY use the path delay variation metric in PCRep message along 339 with a NO-PATH object in the case where the PCE cannot compute a path 340 meeting this constraint. A PCE can also use this metric to send the 341 computed end to end path delay variation metric to the PCC. 343 3.1.2.1. Path Delay Variation Metric Value 345 [RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub- 346 TLV" to advertise the link delay variation in microseconds in a 347 24-bit field. [RFC5440] defines the METRIC object with a 32-bit 348 metric value encoded in IEEE floating point format (see 349 [IEEE.754.1985]). Consequently, the encoding for the path delay 350 variation metric value is quantified in units of microseconds and 351 encoded in IEEE floating point format. The conversion from 24 bit 352 integer to 32 bit IEEE floating point could introduce some loss of 353 precision. 355 3.1.3. Path Loss Metric 357 [RFC7471] and [RFC7810] define "Unidirectional Link Loss". The path 358 loss (as a packet percentage) metric type of the METRIC object in 359 PCEP encodes a function of the unidirectional loss metrics of all 360 links along a P2P path. The end to end packet loss for the path is 361 represented by this metric. Specifically, extending on the above 362 mentioned terminology: 364 o The percentage link loss of link L is denoted PL(L). 366 o The fractional link loss of link L is denoted FL(L) = PL(L)/100. 368 o The percentage path loss metric for the P2P path P = (1 - 369 ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P 370 with links Lp1 to LpK. 372 This is as per the composition function described in section 5.1.5 of 373 [RFC6049]. 375 Metric Type T=TBD3: Path Loss metric 377 A PCC MAY use the path loss metric in a PCReq message to request a 378 path meeting the end to end packet loss requirement. In this case, 379 the B bit MUST be set to suggest a bound (a maximum) for the path 380 loss metric that must not be exceeded for the PCC to consider the 381 computed path as acceptable. The path loss metric must be less than 382 or equal to the value specified in the metric-value field. 384 A PCC can also use this metric to ask the PCE to optimize the path 385 loss during path computation. In this case, the B flag MUST be 386 cleared. 388 A PCE MAY use the path loss metric in a PCRep message along with a 389 NO-PATH object in the case where the PCE cannot compute a path 390 meeting this constraint. A PCE can also use this metric to send the 391 computed end to end path loss metric to the PCC. 393 3.1.3.1. Path Loss Metric Value 395 [RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to 396 advertise the link loss in percentage in a 24-bit field. [RFC5440] 397 defines the METRIC object with 32-bit metric value encoded in IEEE 398 floating point format (see [IEEE.754.1985]). Consequently, the 399 encoding for the path loss metric value is quantified as a percentage 400 and encoded in IEEE floating point format. 402 3.1.4. Non-Understanding / Non-Support of Service Aware Path 403 Computation 405 If a PCE receives a PCReq message containing a METRIC object with a 406 type defined in this document, and the PCE does not understand or 407 support that metric type, and the P bit is clear in the METRIC object 408 header then the PCE SHOULD simply ignore the METRIC object as per the 409 processing specified in [RFC5440]. 411 If the PCE does not understand the new METRIC type, and the P bit is 412 set in the METRIC object header, then the PCE MUST send a PCErr 413 message containing a PCEP-ERROR Object with Error-Type = 4 (Not 414 supported object) and Error-value = 4 (Unsupported parameter) 415 [RFC5440][RFC5441]. 417 If the PCE understands but does not support the new METRIC type, and 418 the P bit is set in the METRIC object header, then the PCE MUST send 419 a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 420 (Not supported object) with Error-value = TBD11 (Unsupported network 421 performance constraint). The path computation request MUST then be 422 cancelled. 424 If the PCE understands the new METRIC type, but the local policy has 425 been configured on the PCE to not allow network performance 426 constraint, and the P bit is set in the METRIC object header, then 427 the PCE MUST send a PCErr message containing a PCEP-ERROR Object with 428 Error-Type = 5 (Policy violation) with Error-value = TBD12 (Not 429 allowed network performance constraint). The path computation 430 request MUST then be cancelled. 432 3.1.5. Mode of Operation 434 As explained in [RFC5440], the METRIC object is optional and can be 435 used for several purposes. In a PCReq message, a PCC MAY insert one 436 or more METRIC objects: 438 o To indicate the metric that MUST be optimized by the path 439 computation algorithm (path delay, path delay variation or path 440 loss). 442 o To indicate a bound on the METRIC (path delay, path delay 443 variation or path loss) that MUST NOT be exceeded for the path to 444 be considered as acceptable by the PCC. 446 In a PCRep message, the PCE MAY insert the METRIC object with an 447 Explicit Route Object (ERO) so as to provide the METRIC (path delay, 448 path delay variation or path loss) for the computed path. The PCE 449 MAY also insert the METRIC object with a NO-PATH object to indicate 450 that the metric constraint could not be satisfied. 452 The path computation algorithmic aspects used by the PCE to optimize 453 a path with respect to a specific metric are outside the scope of 454 this document. 456 All the rules of processing the METRIC object as explained in 457 [RFC5440] are applicable to the new metric types as well. 459 3.1.5.1. Examples 461 If a PCC sends a path computation request to a PCE where the metric 462 to optimize is the path delay and the path loss must not exceed the 463 value of M, then two METRIC objects are inserted in the PCReq 464 message: 466 o First METRIC object with B=0, T=TBD1, C=1, metric-value=0x0000 468 o Second METRIC object with B=1, T=TBD3, metric-value=M 470 As per [RFC5440], if a path satisfying the set of constraints can be 471 found by the PCE and there is no policy that prevents the return of 472 the computed metric, then the PCE inserts one METRIC object with B=0, 473 T=TBD1, metric-value= computed path delay. Additionally, the PCE MAY 474 insert a second METRIC object with B=1, T=TBD3, metric-value=computed 475 path loss. 477 3.1.6. Point-to-Multipoint (P2MP) 479 This section defines the following types for the METRIC object to be 480 used for the P2MP TE LSPs. 482 3.1.6.1. P2MP Path Delay Metric 484 The P2MP path delay metric type of the METRIC object in PCEP encodes 485 the path delay metric for the destination that observes the worst 486 delay metric among all destinations of the P2MP tree. Specifically, 487 extending on the above mentioned terminology: 489 o A P2MP tree T comprises a set of M destinations {Dest_j, 490 (j=1...M)}. 492 o The P2P path delay metric of the path to destination Dest_j is 493 denoted by PDM(Dest_j). 495 o The P2MP path delay metric for the P2MP tree T = Maximum 496 {PDM(Dest_j), (j=1...M)}. 498 The value for the P2MP path delay metric type (T) = TBD8. 500 3.1.6.2. P2MP Path Delay Variation Metric 502 The P2MP path delay variation metric type of the METRIC object in 503 PCEP encodes the path delay variation metric for the destination that 504 observes the worst delay variation metric among all destinations of 505 the P2MP tree. Specifically, extending on the above mentioned 506 terminology: 508 o A P2MP tree T comprises a set of M destinations {Dest_j, 509 (j=1...M)}. 511 o The P2P path delay variation metric of the path to the destination 512 Dest_j is denoted by PDVM(Dest_j). 514 o The P2MP path delay variation metric for the P2MP tree T = Maximum 515 {PDVM(Dest_j), (j=1...M)}. 517 The value for the P2MP path delay variation metric type (T) = TBD9. 519 3.1.6.3. P2MP Path Loss Metric 521 The P2MP path loss metric type of the METRIC object in PCEP encodes 522 the path packet loss metric for the destination that observes the 523 worst packet loss metric among all destinations of the P2MP tree. 524 Specifically, extending on the above mentioned terminology: 526 o A P2MP tree T comprises of a set of M destinations {Dest_j, 527 (j=1...M)}. 529 o The P2P path loss metric of the path to destination Dest_j is 530 denoted by PLM(Dest_j). 532 o The P2MP path loss metric for the P2MP tree T = Maximum 533 {PLM(Dest_j), (j=1...M)}. 535 The value for the P2MP path loss metric type (T) = TBD10. 537 3.2. Bandwidth Utilization 539 3.2.1. Link Bandwidth Utilization (LBU) 541 The Link Bandwidth Utilization (LBU) on a link, forwarding adjacency, 542 or bundled link is populated in the TED ("Unidirectional Utilized 543 Bandwidth" in [RFC7471] and [RFC7810]). For a link or forwarding 544 adjacency, the bandwidth utilization represents the actual 545 utilization of the link (i.e., as measured in the router). For a 546 bundled link, the bandwidth utilization is defined to be the sum of 547 the component link bandwidth utilization. This includes traffic for 548 both RSVP-TE and non-RSVP-TE label switched path packets. 550 The LBU in percentage is described as the (utilized bandwidth / 551 maximum bandwidth) * 100. 553 Where "maximum bandwidth" is defined in [RFC3630] and [RFC5305] and 554 "utilized bandwidth" in [RFC7471] and [RFC7810]. 556 3.2.2. Link Reserved Bandwidth Utilization (LRBU) 558 The Link Reserved Bandwidth Utilization (LRBU) on a link, forwarding 559 adjacency, or bundled link can be calculated from the TED. The 560 utilized bandwidth includes traffic for both RSVP-TE and non-RSVP-TE 561 LSPs, the reserved bandwidth utilization considers only the RSVP-TE 562 LSPs. 564 The reserved bandwidth utilization can be calculated by using the 565 residual bandwidth, the available bandwidth and utilized bandwidth 566 described in [RFC7471] and [RFC7810]. The actual bandwidth by non- 567 RSVP-TE traffic can be calculated by subtracting the available 568 bandwidth from the residual bandwidth ([RFC7471] and [RFC7810]). 569 Which is further deducted from utilized bandwidth to get the reserved 570 bandwidth utilization. Thus, 572 reserved bandwidth utilization = utilized bandwidth - (residual 573 bandwidth - available bandwidth) 575 The LRBU in percentage is described as the (reserved bandwidth 576 utilization / maximum reservable bandwidth) * 100. 578 Where the "maximum reservable bandwidth" is defined in [RFC3630] and 579 [RFC5305]. The "utilized bandwidth", "residual bandwidth", and 580 "available bandwidth" are defined in [RFC7471] and [RFC7810]. 582 3.2.3. Bandwidth Utilization (BU) Object 584 The BU object is used to indicate the upper limit of the acceptable 585 link bandwidth utilization percentage. 587 The BU object MAY be carried within the PCReq message and PCRep 588 messages. 590 BU Object-Class is TBD4. 592 BU Object-Type is 1. 594 The format of the BU object body is as follows: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Reserved | Type | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Bandwidth Utilization | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 BU Object Body Format 606 Reserved (24 bits): This field MUST be set to zero on transmission 607 and MUST be ignored on receipt. 609 Type (8 bits): Represents the bandwidth utilization type. Two 610 values are currently defined. 612 * Type 1 is Link Bandwidth Utilization (LBU) 613 * Type 2 is Link Reserved Bandwidth Utilization (LRBU) 615 Bandwidth Utilization (32 bits): Represents the bandwidth 616 utilization quantified as a percentage (as described in 617 Section 3.2.1 and Section 3.2.2) and encoded in IEEE floating 618 point format (see [IEEE.754.1985]). 620 The BU object body has a fixed length of 8 bytes. 622 3.2.3.1. Elements of Procedure 624 A PCC that wants the PCE to factor in the bandwidth utilization 625 during path computation includes a BU object in the PCReq message. A 626 PCE that supports this object MUST ensure that no link on the 627 computed path has the LBU or LRBU percentage exceeding the given 628 value. 630 A PCReq or PCRep message MAY contain multiple BU objects so long as 631 each is for a different bandwidth utilization type. If a message 632 contains more than one BU object with the same bandwidth utilization 633 type, the first MUST be processed by the receiver and subsequent 634 instances MUST be ignored. 636 If the BU object is unknown/unsupported, the PCE is expected to 637 follow procedures defined in [RFC5440]. That is, if the P bit is 638 set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / 639 Not supported object) and error value 1 or 2 (unknown / unsupported 640 object class / object type), and the related path computation request 641 will be discarded. If the P bit is cleared, the PCE is free to 642 ignore the object. 644 If the PCE understands but does not support path computation requests 645 using the BU object, and the P bit is set in the BU object header, 646 then the PCE MUST send a PCErr message with a PCEP-ERROR Object 647 Error-Type = 4 (Not supported object) with Error-value = TBD11 648 (Unsupported network performance constraint) and the related path 649 computation request MUST be discarded. 651 If the PCE understands the BU object but the local policy has been 652 configured on the PCE to not allow network performance constraint, 653 and the P bit is set in the BU object header, then the PCE MUST send 654 a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy 655 Violation) with Error-value = TBD12 (Not allowed network performance 656 constraint). The path computation request MUST then be cancelled. 658 If path computation is unsuccessful, then a PCE MAY insert a BU 659 object (along with a NO-PATH object) into a PCRep message to indicate 660 the constraints that could not be satisfied. 662 Usage of the BU object for P2MP LSPs is outside the scope of this 663 document. 665 3.3. Objective Functions 667 [RFC5541] defines a mechanism to specify an objective function that 668 is used by a PCE when it computes a path. The new metric types for 669 path delay and path delay variation can continue to use the existing 670 objective function - Minimum Cost Path (MCP) [RFC5541]. For path 671 loss, the following new OF is defined. 673 o A network comprises a set of N links {Li, (i=1...N)}. 675 o A path P is a list of K links {Lpi,(i=1...K)}. 677 o The percentage link loss of link L is denoted PL(L). 679 o The fractional link loss of link L is denoted FL(L) = PL(L) / 100. 681 o The percentage path loss of a path P is denoted PL(P), where PL(P) 682 = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100. 684 Objective Function Code: TBD5 685 Name: Minimum Packet Loss Path (MPLP) 686 Description: Find a path P such that PL(P) is minimized. 688 Two additional objective functions -- namely, MUP (the Maximum Under- 689 Utilized Path) and MRUP (the Maximum Reserved Under-Utilized Path) 690 are needed to optimize bandwidth utilization. These two new 691 objective function codes are defined below. 693 These objective functions are formulated using the following 694 additional terminology: 696 o The bandwidth utilization on link L is denoted u(L). 698 o The reserved bandwidth utilization on link L is denoted ru(L). 700 o The maximum bandwidth on link L is denoted M(L). 702 o The maximum reservable bandwidth on link L is denoted R(L). 704 The description of the two new objective functions is as follows. 706 Objective Function Code: TBD6 707 Name: Maximum Under-Utilized Path (MUP) 708 Description: Find a path P such that (Min {(M(Lpi)- u(Lpi)) 709 / M(Lpi), i=1...K } ) is maximized. 711 Objective Function Code: TBD7 712 Name: Maximum Reserved Under-Utilized Path (MRUP) 713 Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) 714 / R(Lpi), i=1...K } ) is maximized. 716 These new objective functions are used to optimize paths based on the 717 bandwidth utilization as the optimization criteria. 719 If the objective functions defined in this document are unknown/ 720 unsupported by a PCE, then the procedure as defined in section 3.1.1 721 of [RFC5541] is followed. 723 4. Stateful PCE and PCE Initiated LSPs 725 [STATEFUL-PCE] specifies a set of extensions to PCEP to enable 726 stateful control of MPLS-TE and GMPLS LSPs via PCEP and maintaining 727 of these LSPs at the stateful PCE. It further distinguishes between 728 an active and a passive stateful PCE. A passive stateful PCE uses 729 LSP state information learned from PCCs to optimize path computations 730 but does not actively update LSP state. In contrast, an active 731 stateful PCE utilizes the LSP delegation mechanism to update LSP 732 parameters in those PCCs that delegated control over their LSPs to 733 the PCE. [PCE-INITIATED] describes the setup, maintenance and 734 teardown of PCE-initiated LSPs under the stateful PCE model. The 735 document defines the PCInitiate message that is used by a PCE to 736 request a PCC to set up a new LSP. 738 The new metric type and objective functions defined in this document 739 can also be used with the stateful PCE extensions. The format of 740 PCEP messages described in [STATEFUL-PCE] and [PCE-INITIATED] uses 741 (which is extended in Section 5.2) for the purpose 742 of including the service aware parameters. 744 The stateful PCE implementation MAY use the extension of PCReq and 745 PCRep messages as defined in Section 5.1 and Section 5.2 to enable 746 the use of service aware parameters during passive stateful 747 operations. 749 5. PCEP Message Extension 751 Message formats in this document are expressed using Reduced BNF as 752 used in [RFC5440] and defined in [RFC5511]. 754 5.1. The PCReq message 756 The extensions to PCReq message are - 758 o new metric types using existing METRIC object 760 o a new optional BU object 762 o new objective functions using existing OF object ([RFC5541]) 764 The format of the PCReq message (with [RFC5541] and [STATEFUL-PCE] as 765 a base) is updated as follows: 767 ::= 768 [] 769 770 where: 771 ::= 772 [] 773 [] 774 [] 776 ::= [] 778 ::= 779 780 [] 781 [] 782 [] 783 [] 784 [] 785 [] 786 [[]] 787 [] 788 [] 790 and where: 791 ::=[] 792 ::= [] 794 5.2. The PCRep message 796 The extensions to PCRep message are - 798 o new metric types using existing METRIC object 800 o a new optional BU object (during unsuccessful path computation, to 801 indicate the bandwidth utilization as a reason for failure) 803 o new objective functions using existing OF object ([RFC5541]) 805 The format of the PCRep message (with [RFC5541] and [STATEFUL-PCE] as 806 a base) is updated as follows: 808 ::= 809 [] 810 812 where: 814 ::= 815 [] 816 [] 817 [] 819 ::= [] 821 ::= 822 [] 823 [] 824 [] 825 [] 827 ::= [] 829 ::= 830 832 and where: 834 ::= [] 835 [] 836 [] 837 [] 838 [] 839 [] 841 ::=[] 842 ::= [] 844 5.3. The PCRpt message 846 A Path Computation LSP State Report message (also referred to as 847 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 848 current state or delegate control of an LSP. The BU object in a 849 PCRpt message specifies the upper limit set at the PCC at the time of 850 LSP delegation to an active stateful PCE. 852 The format of the PCRpt message is described in [STATEFUL-PCE] which 853 uses the as defined in [RFC5440] and extended by 854 PCEP extensions. 856 The PCRpt message can use the updated (as extended 857 in Section 5.2) for the purpose of including the BU object. 859 6. Other Considerations 861 6.1. Inter-domain Path Computation 863 [RFC5441] describes the Backward Recursive PCE-Based Computation 864 (BRPC) procedure to compute end to end optimized inter-domain path by 865 cooperating PCEs. The new metric types defined in this document can 866 be applied to end to end path computation, in a similar manner to the 867 existing IGP or TE metrics. The new BU object defined in this 868 document can be applied to end to end path computation, in a similar 869 manner to a METRIC object with its B bit set to 1. 871 All domains should have the same understanding of the METRIC (path 872 delay variation etc.) and the BU object for end-to-end inter-domain 873 path computation to make sense. Otherwise, some form of metric 874 normalization as described in [RFC5441] MUST be applied. 876 6.1.1. Inter-AS Links 878 The IGP in each neighbour domain can advertise its inter-domain TE 879 link capabilities. This has been described in [RFC5316] (IS-IS) and 880 [RFC5392] (OSPF). The network performance link properties are 881 described in [RFC7471] and [RFC7810]. The same properties must be 882 advertised using the mechanism described in [RFC5392] (OSPF) and 883 [RFC5316] (IS-IS). 885 6.1.2. Inter-Layer Path Computation 887 [RFC5623] provides a framework for PCE-Based inter-layer MPLS and 888 GMPLS Traffic Engineering. Lower-layer LSPs that are advertised as 889 TE links into the higher-layer network form a Virtual Network 890 Topology (VNT). The advertisement into the higher-layer network 891 should include network performance link properties based on the end 892 to end metric of the lower-layer LSP. Note that the new metrics 893 defined in this document are applied to end to end path computation, 894 even though the path may cross multiple layers. 896 6.2. Reoptimizing Paths 898 [RFC6374] defines the measurement of loss, delay, and related metrics 899 over LSPs. A PCC can utilize these measurement techniques. In case 900 it detects a degradation of network performance parameters relative 901 to the value of the constraint it gave when the path was set up, or 902 relative to an implementation-specific threshold, it MAY ask the PCE 903 to reoptimize the path by sending a PCReq with the R bit set in the 904 RP object, as per [RFC5440]. 906 A PCC may also detect the degradation of an LSP without making any 907 direct measurements, by monitoring the TED (as populated by the IGP) 908 for changes in the network performance parameters of the links that 909 carry its LSPs. The PCC can issue a reoptimization request for any 910 impacted LSPs. For example, a PCC can monitor the link bandwidth 911 utilization along the path by monitoring changes in the bandwidth 912 utilization parameters of one or more links on the path in the TED. 913 If the bandwidth utilization percentage of any of the links in the 914 path changes to a value less than that required when the path was set 915 up, or otherwise less than an implementation-specific threshold, then 916 the PCC can issue an reoptimization request to a PCE. 918 A stateful PCE can also determine which LSPs should be re-optimized 919 based on network events or triggers from external monitoring systems. 920 For example, when a particular link deteriorates and its loss 921 increases, this can trigger the stateful PCE to automatically 922 determine which LSP are impacted and should be reoptimized. 924 7. IANA Considerations 926 7.1. METRIC types 928 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 929 at . Within this registry IANA 930 maintains one sub-registry for "METRIC object T field". Six new 931 metric types are defined in this document for the METRIC object 932 (specified in [RFC5440]). 934 IANA is requested to make the following allocations: 936 Value Description Reference 937 ---------------------------------------------------------- 938 TBD1 Path Delay metric [This I.D.] 939 TBD2 Path Delay Variation metric [This I.D.] 940 TBD3 Path Loss metric [This I.D.] 941 TBD8 P2MP Path Delay metric [This I.D.] 942 TBD9 P2MP Path Delay variation metric [This I.D.] 943 TBD10 P2MP Path Loss metric [This I.D.] 945 7.2. New PCEP Object 947 IANA maintains object class in the registry of PCEP Objects at the 948 sub-registry "PCEP Objects". One new allocation is requested as 949 follows. 951 Object Object Name Reference 952 Class Type 953 --------------------------------------------------- 954 TBD4 1 BU [This I.D.] 956 7.3. BU Object 958 This document requests that a new sub-registry, named "BU Object Type 959 Field", is created within the "Path Computation Element Protocol 960 (PCEP) Numbers" registry to manage the Type field of the BU object. 961 New values are to be assigned by Standards Action [RFC5226]. Each 962 value should be tracked with the following qualities: 964 o Type 966 o Name 968 o Defining RFC 970 The following values are defined in this document: 972 Type Name Reference 973 -------------------------------------------------- 974 1 LBU (Link Bandwidth [This I.D.] 975 Utilization 976 2 LRBU (Link Residual [This I.D.] 977 Bandwidth Utilization 979 7.4. OF Codes 981 IANA maintains registry of Objective Function (described in 982 [RFC5541]) at the sub-registry "Objective Function". Three new 983 Objective Functions have been defined in this document. 985 IANA is requested to make the following allocations: 987 Code Name Reference 988 Point 989 -------------------------------------------------- 990 TBD5 Minimum Packet Loss Path [This I.D.] 991 (MPLP) 992 TBD6 Maximum Under-Utilized [This I.D.] 993 Path (MUP) 994 TBD7 Maximum Reserved [This I.D.] 995 Under-Utilized Path (MRUP) 997 7.5. New Error-Values 999 IANA maintains a registry of Error-Types and Error-values for use in 1000 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 1001 Types and Values" sub-registry of the "Path Computation Element 1002 Protocol (PCEP) Numbers" registry. 1004 IANA is requested to make the following allocations - 1006 Two new Error-values are defined for the Error-Type "Not supported 1007 object" (type 4) and "Policy violation" (type 5). 1009 Error-Type Meaning and error values Reference 1010 4 Not supported object 1012 Error-value=TBD11 Unsupported [This I.D.] 1013 network performance constraint 1015 5 Policy violation 1017 Error-value=TBD12 Not allowed [This I.D.] 1018 network performance constraint 1020 8. Security Considerations 1022 This document defines new METRIC types, a new BU object, and new OF 1023 codes which does not add any new security concerns beyond those 1024 discussed in [RFC5440] and [RFC5541] in itself. Some deployments may 1025 find the service aware information like delay and packet loss to be 1026 extra sensitive and could be used to influence path computation and 1027 setup with adverse effect. Additionally snooping of PCEP messages 1028 with such data or using PCEP messages for network reconnaissance, may 1029 give an attacker sensitive information about the operations of the 1030 network. Thus, such deployment should employ suitable PCEP security 1031 mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or 1032 [PCEPS]. The Transport Layer Security (TLS) based procedure in 1033 [PCEPS] is considered as a security enhancement and thus much better 1034 suited for the sensitive service aware information. 1036 9. Manageability Considerations 1038 9.1. Control of Function and Policy 1040 The only configurable item is the support of the new constraints on a 1041 PCE which MAY be controlled by a policy module on individual basis. 1042 If the new constraint is not supported/allowed on a PCE, it MUST send 1043 a PCErr message accordingly. 1045 9.2. Information and Data Models 1047 [RFC7420] describes the PCEP MIB. There are no new MIB Objects for 1048 this document. 1050 9.3. Liveness Detection and Monitoring 1052 The mechanisms defined in this document do not imply any new liveness 1053 detection and monitoring requirements in addition to those already 1054 listed in [RFC5440]. 1056 9.4. Verify Correct Operations 1058 The mechanisms defined in this document do not imply any new 1059 operation verification requirements in addition to those already 1060 listed in [RFC5440]. 1062 9.5. Requirements On Other Protocols 1064 The PCE requires the TED to be populated with network performance 1065 information like link latency, delay variation, packet loss, and 1066 utilized bandwidth. This mechanism is described in [RFC7471] and 1067 [RFC7810]. 1069 9.6. Impact On Network Operations 1071 The mechanisms defined in this document do not have any impact on 1072 network operations in addition to those already listed in [RFC5440]. 1074 10. Acknowledgments 1076 We would like to thank Alia Atlas, John E Drake, David Ward, Young 1077 Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu, 1078 Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their 1079 useful comments and suggestions. 1081 Also the authors gratefully acknowledge reviews and feedback provided 1082 by Qin Wu, Alfred Morton and Paul Aitken during performance 1083 directorate review. 1085 Thanks to Jonathan Hardwick for shepherding this document and 1086 providing valuable comments. His help in fixing the editorial and 1087 grammatical issues is also appreciated. 1089 Thanks to Christian Hopps for the routing directorate review. 1091 Thanks to Jouni Korhonen and Alfred Morton for the operational 1092 directorate review. 1094 Thanks to Christian Huitema for the security directorate review. 1096 Thanks to Deborah Brungard for being the responsible AD. 1098 Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen 1099 Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko and Alia 1100 Atlas for the IESG reviews. 1102 11. References 1104 11.1. Normative References 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1112 (TE) Extensions to OSPF Version 2", RFC 3630, 1113 DOI 10.17487/RFC3630, September 2003, 1114 . 1116 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1117 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1118 2008, . 1120 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1121 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1122 DOI 10.17487/RFC5440, March 2009, 1123 . 1125 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1126 Used to Form Encoding Rules in Various Routing Protocol 1127 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1128 2009, . 1130 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1131 Objective Functions in the Path Computation Element 1132 Communication Protocol (PCEP)", RFC 5541, 1133 DOI 10.17487/RFC5541, June 2009, 1134 . 1136 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1137 Previdi, "OSPF Traffic Engineering (TE) Metric 1138 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1139 . 1141 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1142 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1143 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1144 . 1146 [STATEFUL-PCE] 1147 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1148 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1149 pce-16 (work in progress), September 2016. 1151 11.2. Informative References 1153 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1154 Element (PCE)-Based Architecture", RFC 4655, 1155 DOI 10.17487/RFC4655, August 2006, 1156 . 1158 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1159 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1160 DOI 10.17487/RFC5226, May 2008, 1161 . 1163 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1164 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1165 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1166 December 2008, . 1168 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1169 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1170 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 1171 January 2009, . 1173 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1174 "A Backward-Recursive PCE-Based Computation (BRPC) 1175 Procedure to Compute Shortest Constrained Inter-Domain 1176 Traffic Engineering Label Switched Paths", RFC 5441, 1177 DOI 10.17487/RFC5441, April 2009, 1178 . 1180 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 1181 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 1182 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 1183 September 2009, . 1185 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1186 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1187 June 2010, . 1189 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 1190 Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, 1191 . 1193 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1194 Measurement for MPLS Networks", RFC 6374, 1195 DOI 10.17487/RFC6374, September 2011, 1196 . 1198 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1199 Hardwick, "Path Computation Element Communication Protocol 1200 (PCEP) Management Information Base (MIB) Module", 1201 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1202 . 1204 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1205 "Performance-Based Path Selection for Explicitly Routed 1206 Label Switched Paths (LSPs) Using TE Metric Extensions", 1207 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1208 . 1210 [PCE-INITIATED] 1211 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1212 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1213 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 1214 progress), July 2016. 1216 [PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1217 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 1218 progress), July 2016. 1220 [IEEE.754.1985] 1221 IEEE, "Standard for Binary Floating-Point Arithmetic", 1222 IEEE 754, August 1985. 1224 Appendix A. PCEP Requirements 1226 End-to-end service optimization based on latency, delay variation, 1227 packet loss, and link bandwidth utilization are key requirements for 1228 service providers. The following associated key requirements are 1229 identified for PCEP: 1231 1. A PCE supporting this draft MUST have the capability to compute 1232 end-to-end (E2E) paths with latency, delay variation, packet 1233 loss, and bandwidth utilization constraints. It MUST also 1234 support the combination of network performance constraints 1235 (latency, delay variation, loss...) with existing constraints 1236 (cost, hop-limit...). 1238 2. A PCC MUST be able to specify any network performance constraint 1239 in a Path Computation Request (PCReq) message to be applied 1240 during the path computation. 1242 3. A PCC MUST be able to request that a PCE optimizes a path using 1243 any network performance criteria. 1245 4. A PCE that supports this specification is not required to provide 1246 service aware path computation to any PCC at any time. 1247 Therefore, it MUST be possible for a PCE to reject a PCReq 1248 message with a reason code that indicates service-aware path 1249 computation is not supported. Furthermore, a PCE that does not 1250 support this specification will either ignore or reject such 1251 requests using pre-existing mechanisms, therefore the requests 1252 MUST be identifiable to legacy PCEs and rejections by legacy PCEs 1253 MUST be acceptable within this specification. 1255 5. A PCE SHOULD be able to return end to end network performance 1256 information of the computed path in a Path Computation Reply 1257 (PCRep) message. 1259 6. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, 1260 Inter-Area or Multi-Layer) service aware paths. 1262 Such constraints are only meaningful if used consistently: for 1263 instance, if the delay of a computed path segment is exchanged 1264 between two PCEs residing in different domains, a consistent way of 1265 defining the delay must be used. 1267 Appendix B. Contributor Addresses 1268 Clarence Filsfils 1269 Cisco Systems 1270 Email: cfilsfil@cisco.com 1272 Siva Sivabalan 1273 Cisco Systems 1274 Email: msiva@cisco.com 1276 George Swallow 1277 Cisco Systems 1278 Email: swallow@cisco.com 1280 Stefano Previdi 1281 Cisco Systems, Inc 1282 Via Del Serafico 200 1283 Rome 00191 1284 Italy 1285 Email: sprevidi@cisco.com 1287 Udayasree Palle 1288 Huawei Technologies 1289 Divyashree Techno Park, Whitefield 1290 Bangalore, Karnataka 560066 1291 India 1292 Email: udayasree.palle@huawei.com 1294 Avantika 1295 Huawei Technologies 1296 Divyashree Techno Park, Whitefield 1297 Bangalore, Karnataka 560066 1298 India 1299 Email: avantika.sushilkumar@huawei.com 1301 Xian Zhang 1302 Huawei Technologies 1303 F3-1-B R&D Center, Huawei Base Bantian, Longgang District 1304 Shenzhen, Guangdong 518129 1305 P.R.China 1306 Email: zhang.xian@huawei.com 1308 Authors' Addresses 1309 Dhruv Dhody 1310 Huawei Technologies 1311 Divyashree Techno Park, Whitefield 1312 Bangalore, Karnataka 560066 1313 India 1315 EMail: dhruv.ietf@gmail.com 1317 Qin Wu 1318 Huawei Technologies 1319 101 Software Avenue, Yuhua District 1320 Nanjing, Jiangsu 210012 1321 China 1323 EMail: bill.wu@huawei.com 1325 Vishwas Manral 1326 Ionos Network 1327 4100 Moorpark Av 1328 San Jose, CA 1329 USA 1331 EMail: vishwas.ietf@gmail.com 1333 Zafar Ali 1334 Cisco Systems 1336 EMail: zali@cisco.com 1338 Kenji Kumaki 1339 KDDI Corporation 1341 EMail: ke-kumaki@kddi.com