idnits 2.17.1 draft-dhody-pce-pcep-service-aware-05.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 abstract seems to contain references ([OSPF-TE-EXPRESS], [ISIS-TE-EXPRESS], [MPLS-DELAY-FWK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4079 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 informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Huawei Technologies India Pvt 4 Intended status: Standards Track Ltd 5 Expires: August 24, 2013 V. Manral 6 Hewlett-Packard Corp. 7 Z. Ali 8 G. Swallow 9 Cisco Systems 10 K. Kumaki 11 KDDI Corporation 12 February 25, 2013 14 Extensions to the Path Computation Element Communication Protocol (PCEP) 15 to compute service aware Label Switched Path (LSP). 16 draft-dhody-pce-pcep-service-aware-05 18 Abstract 20 In certain networks like financial information network (stock/ 21 commodity trading) and enterprises using cloud based applications, 22 Latency (delay), Latency-Variation (jitter) and Packet loss is 23 becoming a key requirement for path computation along with other 24 constraints and metrics. Latency, Latency-Variation and Packet Loss 25 is associated with the Service Level Agreement (SLA) between 26 customers and service providers. 28 [MPLS-DELAY-FWK] describes MPLS architecture to allow Latency 29 (delay), Latency-Variation (jitter) and Packet loss as properties. 30 [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with 31 which network performance information is distributed via OSPF and 32 ISIS respectively. This document describes the extension to PCEP to 33 carry Latency, Latency-Variation and Loss as constraints for end to 34 end path computation. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 4, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 74 4. PCEP extensions . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Latency (Delay) Metric . . . . . . . . . . . . . . . . . . 6 76 4.1.1. Latency (Delay) Metric Value . . . . . . . . . . . . . 6 77 4.2. Latency Variation (Jitter) Metric . . . . . . . . . . . . 7 78 4.2.1. Latency Variation (Jitter) Metric Value . . . . . . . 7 79 4.3. Packet Loss Metric . . . . . . . . . . . . . . . . . . . . 8 80 4.3.1. Packet Loss Metric Value . . . . . . . . . . . . . . . 9 81 4.4. Non-Understanding / Non-Support of Service Aware Path 82 Computation . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.5. Mode of Operation . . . . . . . . . . . . . . . . . . . . 9 84 4.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 10 85 5. Relationship with Objective function . . . . . . . . . . . . . 11 86 6. Protocol Consideration . . . . . . . . . . . . . . . . . . . . 11 87 6.1. Inter domain Consideration . . . . . . . . . . . . . . . . 11 88 6.1.1. Inter-AS Link . . . . . . . . . . . . . . . . . . . . 12 89 6.1.2. Inter-Layer Consideration . . . . . . . . . . . . . . 12 90 6.2. Reoptimization Consideration . . . . . . . . . . . . . . . 12 91 6.3. Point-to-Multipoint (P2MP) . . . . . . . . . . . . . . . . 12 92 6.3.1. P2MP Latency Metric . . . . . . . . . . . . . . . . . 12 93 6.3.2. P2MP Latency Variation Metric . . . . . . . . . . . . 13 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 9. Manageability Considerations . . . . . . . . . . . . . . . . . 14 97 9.1. Control of Function and Policy . . . . . . . . . . . . . . 14 98 9.2. Information and Data Models . . . . . . . . . . . . . . . 14 99 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 100 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 14 101 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 14 102 9.6. Impact On Network Operations . . . . . . . . . . . . . . . 14 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 107 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . . 16 109 1. Introduction 111 Real time Network Performance is becoming a critical in the path 112 computation in some networks. There exist mechanism described in 113 [RFC6374] to measure latency, latency-Variation and packet loss after 114 the LSP has been established, which is inefficient. It is important 115 that latency, latency-variation and packet loss are considered during 116 path selection process, even before the LSP is setup. 118 TED is populated with network performance information like link 119 latency, latency variation and packet loss through [OSPF-TE-EXPRESS] 120 or [ISIS-TE-EXPRESS]. Path Computation Client (PCC) can request Path 121 Computation Element (PCE) to provide a path meeting end to end 122 network performance criteria. This document extends Path Computation 123 Element Communication Protocol (PCEP) [RFC5440] to handle network 124 performance constraint. 126 PCE MAY use mechanism described in [MPLS-TE-EXPRESS-PATH] on how to 127 use the link latency, latency variation and packet loss information 128 for end to end path selection. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Terminology 138 The following terminology is used in this document. 140 IGP: Interior Gateway Protocol. Either of the two routing 141 protocols, Open Shortest Path First (OSPF) or Intermediate System 142 to Intermediate System (IS-IS). 144 IS-IS: Intermediate System to Intermediate System. 146 OSPF: Open Shortest Path First. 148 PCC: Path Computation Client: any client application requesting a 149 path computation to be performed by a Path Computation Element. 151 PCE: Path Computation Element. An entity (component, application, 152 or network node) that is capable of computing a network path or 153 route based on a network graph and applying computational 154 constraints. 156 TE: Traffic Engineering. 158 3. PCEP Requirements 160 End-to-end service optimization based on latency, latency-variation 161 and packet loss is a key requirement for service provider. Following 162 key requirements associated with latency, latency-variation and loss 163 are identified for PCEP: 165 1. Path Computation Element (PCE) supporting this draft MUST have 166 the capability to compute end-to-end path with latency, latency- 167 variation and packet loss constraints. It MUST also support the 168 combination of network performance constraint (latency, latency- 169 variation, loss...) with existing constraints (cost, hop- 170 limit...) 172 2. Path Computation Client (PCC) MUST be able to request for network 173 performance constraint in path request message as the key 174 constraint to be optimized or to suggest boundary condition that 175 should not be crossed. 177 3. PCEs are not required to support service aware path computation. 178 Therefore, it MUST be possible for a PCE to reject a Path 179 Computation Request message with a reason code that indicates no 180 support for service-aware path computation. 182 4. PCEP SHOULD provide a means to return end to end network 183 performance information of the computed path in the reply 184 message. 186 5. PCEP SHOULD provide mechanism to compute multi-domain (e.g., 187 Inter-AS, Inter-Area or Multi-Layer) service aware paths. 189 It is assumed that such constraints are only meaningful if used 190 consistently: for instance, if the delay of a computed path segment 191 is exchanged between two PCEs residing in different domains, 192 consistent ways of defining the delay must be used. 194 4. PCEP extensions 196 This section defines PCEP extensions (see [RFC5440]) for requirements 197 outlined in Section 3. The proposed solution is used to support 198 network performance and service aware path computation. 200 This document defines the following optional types for the METRIC 201 object defined in [RFC5440]. 203 For explanation of these metrics, the following terminology is used 204 and expanded along the way. 206 - A network comprises of a set of N links {Li, (i=1...N)}. 208 - A path P of a P2P LSP is a list of K links {Lpi,(i=1...K)}. 210 4.1. Latency (Delay) Metric 212 Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE- 213 EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes 214 the sum of the link delay metric of all links along a P2P Path. 215 Specifically, extending on the above mentioned terminology: 217 - A Link delay metric of link L is denoted D(L). 219 - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. 221 * T=13(IANA): Latency metric 223 PCC MAY use this latency metric In PCReq to request a path meeting 224 the end to end latency requirement. In this case B bit MUST be set 225 to suggest a bound (a maximum) for the path latency metric that must 226 not be exceeded for the PCC to consider the computed path as 227 acceptable. The path metric must be less than or equal to the value 228 specified in the metric-value field. 230 PCC MAY also use this metric to ask PCE to optimize delay during path 231 computation, in this case B flag will be cleared. 233 PCE MAY use this latency metric In PCRep along with NO-PATH object 234 incase PCE cannot compute a path meeting this constraint. PCE MAY 235 also use this metric to reply the computed end to end latency metric 236 to PCC. 238 4.1.1. Latency (Delay) Metric Value 240 [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional Link 241 Delay Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC 242 object with 32-bit metric value. Consequently, encoding for Latency 243 (Delay) Metric Value is defined as follows: 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Reserved | Latency (Delay) Metric | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Reserved (8 bits): Reserved field. This field MUST be set to zero on 251 transmission and MUST be ignored on receipt. 253 Latency (Delay) Metric (24 bits): Represents the end to end Latency 254 (delay) quantified in units of microseconds and MUST be encoded as 255 integer value. With the maximum value 16,777,215 representing 256 16.777215 sec. 258 4.2. Latency Variation (Jitter) Metric 260 Link delay variation metric is defined in [OSPF-TE-EXPRESS] and 261 [ISIS-TE-EXPRESS]. P2P latency variation metric type of METRIC 262 object in PCEP encodes a function of the link delay variation metric 263 of all links along a P2P Path. Specifically, extending on the above 264 mentioned terminology: 266 - A Latency variation of link L is denoted DV(L). 268 - A P2P latency variation metric for the Path P = function {DV(Lpi), 269 (i=1...K)}. 271 Specification of the "Function" used to drive latency variation 272 metric of a path from latency variation metrics of individual links 273 along the path is beyond the scope of this document. 275 * T=14(IANA): Latency Variation metric 277 PCC MAY use this latency variation metric In PCReq to request a path 278 meeting the end to end latency variation requirement. In this case B 279 bit MUST be set to suggest a bound (a maximum) for the path latency 280 variation metric that must not be exceeded for the PCC to consider 281 the computed path as acceptable. The path metric must be less than 282 or equal to the value specified in the metric-value field. 284 PCC MAY also use this metric to ask PCE to optimize jitter during 285 path computation, in this case B flag will be cleared. 287 PCE MAY use this latency variation metric In PCRep along with NO-PATH 288 object incase PCE cannot compute a path meeting this constraint. PCE 289 MAY also use this metric to reply the computed end to end latency 290 variation metric to PCC. 292 4.2.1. Latency Variation (Jitter) Metric Value 294 [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional Delay 295 Variation Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC 296 object with 32-bit metric value. Consequently, encoding for Latency 297 Variation (Jitter) Metric Value is defined as follows: 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Reserved | Latency variation (jitter) Metric | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Reserved (8 bits): Reserved field. This field MUST be set to zero on 305 transmission and MUST be ignored on receipt. 307 Latency variation (jitter) Metric (24 bits): Represents the end to 308 end Latency variation (jitter) quantified in units of microseconds 309 and MUST be encoded as integer value. With the maximum value 310 16,777,215 representing 16.777215 sec. 312 4.3. Packet Loss Metric 314 [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional Link 315 Loss". Packet Loss Metric metric type of METRIC object in PCEP 316 encodes a function of the link's unidirectional loss metric of all 317 links along a P2P Path. Specifically, extending on the above 318 mentioned terminology: 320 The end to end Packet Loss for the path is represented by this 321 metric. 323 - A Packet loss of link L is denoted PL(L). 325 - A P2P packet loss metric for the Path P = function {PL(Lpi), 326 (i=1...K)}. 328 Specification of the "Function" used to drive end to end packet loss 329 metric of a path from packet loss metrics of individual links along 330 the path is beyond the scope of this document. 332 * T=15(IANA): Packet Loss metric 334 PCC MAY use this packet loss metric In PCReq to request a path 335 meeting the end to end packet loss requirement. In this case B bit 336 MUST be set to suggest a bound (a maximum) for the path packet loss 337 metric that must not be exceeded for the PCC to consider the computed 338 path as acceptable. The path metric must be less than or equal to 339 the value specified in the metric-value field. 341 PCC MAY also use this metric to ask PCE to optimize packet loss 342 during path computation, in this case B flag will be cleared. 344 PCE MAY use this packet loss metric In PCRep along with NO-PATH 345 object incase PCE cannot compute a path meeting this constraint. PCE 346 MAY also use this metric to reply the computed end to end packet loss 347 metric to PCC. 349 4.3.1. Packet Loss Metric Value 351 [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional Link 352 Loss Sub-TLV" in a 24-bit field. [RFC5440] defines the METRIC object 353 with 32-bit metric value. Consequently, encoding for Packet Loss 354 Metric Value is defined as follows: 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Reserved | Packet loss Metric | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Reserved (8 bits): Reserved field. This field MUST be set to zero on 362 transmission and MUST be ignored on receipt. 364 Packet loss Metric (24 bits): Represents the end to end packet loss 365 quantified as a percentage of packets lost and MUST be encoded as 366 integer. The basic unit is 0.000003%, with the maximum value 367 16,777,215 representing 50.331645% (16,777,215 * 0.000003%). This 368 value is the highest packet loss percentage that can be expressed. 370 4.4. Non-Understanding / Non-Support of Service Aware Path Computation 372 If the P bit is clear in the object header and PCE does not 373 understand or does not support service aware path computation it 374 SHOULD simply ignore this METRIC. 376 If the P Bit is set in the object header and PCE receives new METRIC 377 type in path request and it understands the METRIC type, but the PCE 378 is not capable of service aware path computation, the PCE MUST send a 379 PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported 380 object) [RFC5440]. The path computation request MUST then be 381 cancelled. 383 If the PCE does not understand the new METRIC type, then the PCE MUST 384 send a PCErr message with a PCEP-ERROR Object Error-Type = 3 (Unknown 385 object) [RFC5440]. 387 4.5. Mode of Operation 389 As explained in [RFC5440], The METRIC object is optional and can be 390 used for several purposes. In a PCReq message, a PCC MAY insert one 391 or more METRIC objects: 393 o To indicate the metric that MUST be optimized by the path 394 computation algorithm (Latency, Latency-Variation or Loss) 396 o To indicate a bound on the path METRIC (Latency, Latency-Variation 397 or Loss) that MUST NOT be exceeded for the path to be considered 398 as acceptable by the PCC. 400 In a PCRep message, the METRIC object MAY be inserted so as to 401 provide the METRIC (Latency, Latency-Variation or Loss) for the 402 computed path. It MAY also be inserted within a PCRep with the NO- 403 PATH object to indicate that the metric constraint could not be 404 satisfied. 406 The path computation algorithmic aspects used by the PCE to optimize 407 a path with respect to a specific metric are outside the scope of 408 this document. 410 All the rules of processing METRIC object as explained in [RFC5440] 411 are applicable to the new metric types as well. 413 In a PCReq message, a PCC MAY insert more than one METRIC object to 414 be optimized, in such a case PCE should find the path that is optimal 415 when both the metrics are considered together. 417 4.5.1. Examples 419 Example 1: If a PCC sends a path computation request to a PCE where 420 two metric to optimize are the latency and the packet loss, two 421 METRIC objects are inserted in the PCReq message: 423 o First METRIC object with B=0, T=13 (TBA - IANA), C=1, metric- 424 value=0x0000 426 o Second METRIC object with B=0, T=15 (TBA - IANA), C=1, metric- 427 value=0x0000 429 PCE in such a case should try to optimize both the metrics and find a 430 path with the minimum latency and packet loss, if a path can be found 431 by the PCE and there is no policy that prevents the return of the 432 computed metric, the PCE inserts two METRIC object with B=0, T=13 433 (TBA - IANA), metric-value= computed end to end latency and second 434 METRIC object with B=1, T=15 (TBA - IANA), metric-value= computed end 435 to end packet loss. 437 Example 2: If a PCC sends a path computation request to a PCE where 438 the metric to optimize is the latency and the packet loss must not 439 exceed the value of M, two METRIC objects are inserted in the PCReq 440 message: 442 o First METRIC object with B=0, T=13 (TBA - IANA), C=1, metric- 443 value=0x0000 445 o Second METRIC object with B=1, T=15 (TBA - IANA), metric-value=M 447 If a path satisfying the set of constraints can be found by the PCE 448 and there is no policy that prevents the return of the computed 449 metric, the PCE inserts one METRIC object with B=0, T=13 (TBA - 450 IANA), metric-value= computed end to end latency. Additionally, the 451 PCE may insert a second METRIC object with B=1, T=15 (TBA - IANA), 452 metric-value= computed end to end packet loss. 454 5. Relationship with Objective function 456 [RFC5541] defines mechanism to specify an optimization criteria, 457 referred to as objective functions. The new metric types specified 458 in this document can continue to use the existing Objective function. 460 Minimum Cost Path (MCP) is one such objective function. 462 o A network comprises a set of N links {Li, (i=1...N)}. 464 o A path P is a list of K links {Lpi,(i=1...K)}. 466 o Metric of link L is denoted M(L). This can be any metric, 467 including the ones defined in this document. 469 o The cost of a path P is denoted C(P), where C(P) = sum 470 {M(Lpi),(i=1...K)}. 472 Name: Minimum Cost Path (MCP) 474 Description: Find a path P such that C(P) is minimized. 476 The new metric types for example latency (delay) can continue to use 477 the above objective function to find the minimum cost path where cost 478 is latency (delay). At the same time new objective functions can be 479 defined in future to optimize these new metric types. 481 6. Protocol Consideration 483 There is no change in the message format of Path Request and Reply 484 Message. 486 6.1. Inter domain Consideration 488 [RFC5441] describes the BRPC procedure to compute end to end 489 optimized inter domain path by cooperating PCEs. The network 490 performance constraints can be applied end to end in similar manner 491 as IGP or TE cost. 493 All domains should have the same understanding of the METRIC 494 (Latency-Variation etc) for end-to-end inter-domain path computation 495 to make sense. Otherwise some form of Metric Normalization as 496 described in [RFC5441] MAY need to be applied. 498 6.1.1. Inter-AS Link 500 The IGP in each neighbor domain can advertise its inter-domain TE 501 link capabilities, this has been described in [RFC5316] (ISIS) and 502 [RFC5392] (OSPF). The network performance link properties are 503 described in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS], the same 504 properties must be advertised using the mechanism described in 505 [RFC5392] (OSPF) and [RFC5316] (ISIS). 507 6.1.2. Inter-Layer Consideration 509 PCEP supporting this draft SHOULD provide mechanism to support 510 different Metric requirements for different Layers. This is 511 important as the network performance metric would be different for 512 Packet and Optical (TDM, LSC etc) Layers. In order to allow 513 different Metric-Value to be applied within different network layers, 514 multiple METRIC objects of the same type MAY be present. In such a 515 case, the first METRIC object specifies an metric for the higher- 516 layer network, and subsequent METRIC objects specify objection 517 functions of the subsequent lower-layer networks. 519 6.2. Reoptimization Consideration 521 PCC can monitor the setup LSPs and incase of degradation of network 522 performance constraints, it MAY ask PCE for reoptimization as per 523 [RFC5440]. 525 6.3. Point-to-Multipoint (P2MP) 527 This document defines the following optional types for the METRIC 528 object defined in [RFC5440] for P2MP TE LSPs. Additional metric 529 types for P2MP TE LSPs are to be added in a future revision 531 6.3.1. P2MP Latency Metric 533 P2MP latency metric type of METRIC object in PCEP encodes the path 534 latency metric for destination that observes the worst latency metric 535 among all destination of the P2MP tree. Specifically, extending on 536 the above mentioned terminology: 538 - A P2MP Tree T comprises of a set of M destinations {Dest_j, 539 (j=1...M)} 541 - P2P latency metric of the Path to destination Dest_j is denoted by 542 LM(Dest_j). 544 - P2MP latency metric for the P2MP tree T = Maximum {LM(Dest_j), 545 (j=1...M)}. 547 Value for P2MP latency metric is to be assigned by IANA 549 6.3.2. P2MP Latency Variation Metric 551 P2MP latency variation metric type of METRIC object in PCEP encodes 552 the path latency variation metric for destination that observes the 553 worst latency variation metric among all destination of the P2MP 554 tree. Specifically, extending on the above mentioned terminology: 556 - A P2MP Tree T comprises of a set of M destinations {Dest_j, 557 (j=1...M)} 559 - P2P latency variation metric of the Path to destination Dest_j is 560 denoted by LVM(Dest_j). 562 - P2MP latency variation metric for the P2MP tree T = Maximum 563 {LVM(Dest_j), (j=1...M)}. 565 Value for P2MP latency variation metric is to be assigned by IANA 567 7. IANA Considerations 569 IANA has defined a registry for new METRIC type. 571 Type Meaning 572 13(TBD) Latency (delay) metric 573 14(TBD) Latency Variation (jitter) metric 574 15(TBD) Packet Loss metric 575 16(TBD) P2MP latency metric 576 17(TBD) P2MP latency variation metric 578 8. Security Considerations 580 This document defines three new METRIC Types which does not add any 581 new security concerns to PCEP protocol. 583 9. Manageability Considerations 585 9.1. Control of Function and Policy 587 The only configurable item is the support of the new service-aware 588 METRICS on a PCE which MAY be controlled by a policy module. If the 589 new METRIC is not supported/allowed on a PCE, it MUST send a PCErr 590 message as specified in Section 4.4. 592 9.2. Information and Data Models 594 [PCEP-MIB] describes the PCEP MIB, there are no new MIB Objects for 595 this document. 597 9.3. Liveness Detection and Monitoring 599 Mechanisms defined in this document do not imply any new liveness 600 detection and monitoring requirements in addition to those already 601 listed in [RFC5440]. 603 9.4. Verify Correct Operations 605 Mechanisms defined in this document do not imply any new operation 606 verification requirements in addition to those already listed in 607 [RFC5440]. 609 9.5. Requirements On Other Protocols 611 PCE requires the TED to be populated with network performance 612 information like link latency, latency variation and packet loss. 613 This mechanism is described in [OSPF-TE-EXPRESS] or 614 [ISIS-TE-EXPRESS]. 616 9.6. Impact On Network Operations 618 Mechanisms defined in this document do not have any impact on network 619 operations in addition to those already listed in [RFC5440]. 621 10. Acknowledgments 623 We would like to thank Young Lee, Venugopal Reddy, Reeja Paul, 624 Sandeep Kumar Boina, Suresh babu, Quintin Zhao and Chen Huaimo for 625 their useful comments and suggestions. 627 11. References 628 11.1. Normative References 630 [RFC2119] Bradner, S., "Key words for use in RFCs to 631 Indicate Requirement Levels", BCP 14, 632 RFC 2119, March 1997. 634 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path 635 Computation Element (PCE) Communication 636 Protocol (PCEP)", RFC 5440, March 2009. 638 11.2. Informative References 640 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. 641 Le Roux, "A Backward-Recursive PCE-Based 642 Computation (BRPC) Procedure to Compute 643 Shortest Constrained Inter-Domain Traffic 644 Engineering Label Switched Paths", RFC 5441, 645 April 2009. 647 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS 648 Extensions in Support of Inter-Autonomous 649 System (AS) MPLS and GMPLS Traffic 650 Engineering", RFC 5316, December 2008. 652 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF 653 Extensions in Support of Inter-Autonomous 654 System (AS) MPLS and GMPLS Traffic 655 Engineering", RFC 5392, January 2009. 657 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, 658 "Encoding of Objective Functions in the Path 659 Computation Element Communication Protocol 660 (PCEP)", RFC 5541, June 2009. 662 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and 663 Delay Measurement for MPLS Networks", 664 RFC 6374, September 2011. 666 [MPLS-DELAY-FWK] Fu, X., Manral, V., McDysan, D., Malis, A., 667 Giacalone, S., Betts, M., Wang, Q., and J. 668 Drake, "Traffic Engineering architecture for 669 services aware MPLS 670 [draft-fuxh-mpls-delay-loss-te-framework]", 671 Oct 2012. 673 [OSPF-TE-EXPRESS] Giacalone, S., Ward, D., Drake, J., Atlas, 674 A., and S. Previdi, "OSPF Traffic Engineering 675 (TE) Metric Extensions 677 [draft-ietf-ospf-te-metric-extensions]", 678 May 2012. 680 [ISIS-TE-EXPRESS] Previdi, S., Giacalone, S., Ward, D., Drake, 681 J., Atlas, A., and C. Filsfils, "IS-IS 682 Traffic Engineering (TE) Metric Extensions 683 [draft-previdi-isis-te-metric-extensions]", 684 Oct 2012. 686 [MPLS-TE-EXPRESS-PATH] Atlas, A., Drake, J., Ward, D., Giacalone, 687 S., Previdi, S., and C. Filsfils, 688 "Performance-based Path Selection for 689 Explicitly Routed LSPs 690 [draft-atlas-mpls-te-express-path]", 691 June 2012. 693 [PCEP-MIB] Kiran Koushik, A S., Stephan, E., Zhao, Q., 694 King, D., and J. Hardwick, "PCE communication 695 protocol(PCEP) Management Information Base 696 [draft-ietf-pce-pcep-mib]", July 2012. 698 Appendix A. Contributor Addresses 700 Clarence Filsfils 701 Cisco Systems 702 EMail: cfilsfil@cisco.com 704 Siva Sivabalan 705 Cisco Systems 706 EMail: msiva@cisco.com 708 Stefano Previdi 709 Cisco Systems 710 EMail: sprevidi@cisco.com 712 Udayasree Palle 713 Huawei Technologies India Pvt Ltd 714 Leela Palace 715 Bangalore, Karnataka 560008 716 INDIA 717 EMail: udayasree.palle@huawei.com 719 Authors' Addresses 721 Dhruv Dhody 722 Huawei Technologies India Pvt Ltd 723 Leela Palace 724 Bangalore, Karnataka 560008 725 INDIA 727 EMail: dhruv.dhody@huawei.com 729 Vishwas Manral 730 Hewlett-Packard Corp. 731 191111 Pruneridge Ave. 732 Cupertino, CA 95014 733 USA 735 EMail: vishwas.manral@hp.com 737 Zafar Ali 738 Cisco Systems 740 EMail: zali@cisco.com 742 George Swallow 743 Cisco Systems 745 EMail: swallow@cisco.com 747 Kenji Kumaki 748 KDDI Corporation 750 EMail: ke-kumaki@kddi.com