idnits 2.17.1 draft-ali-pce-additional-of-and-metric-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 61 lines 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2012) is 4211 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: 'RFC2119' is mentioned on line 78, but not defined == Missing Reference: 'OSPF-TE-METRIC' is mentioned on line 172, but not defined == Missing Reference: 'ISIS-TE-METRIC' is mentioned on line 173, but not defined == Missing Reference: 'RFC 5540' is mentioned on line 118, but not defined == Missing Reference: 'RFC 5541' is mentioned on line 241, but not defined == Unused Reference: 'DRAFT-OSPF-TE-METRIC' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'DRAFT-ISIS-TE-METRIC' is defined on line 325, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: April 14, 2013 Siva Sivabalan 6 Stefano Previdi 7 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 10 October 15, 2012 12 Additional Objective Functions and Metric Types in Path 13 Computation Element Communication Protocol (PCEP) 14 draft-ali-pce-additional-of-and-metric-00.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current 24 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 This Internet-Draft will expire on April 14, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 ID draft-ali-pce-additional-of-and-metric-00.txt 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) 57 controlling the copyright in such materials, this document may not 58 be modified outside the IETF Standards Process, and derivative 59 works of it may not be created outside the IETF Standards Process, 60 except to format it for publication as an RFC or to translate it 61 into languages other than English. 63 Abstract 65 Network performance criteria such as latency and latency variation 66 are becoming critical to data path selection, especially for 67 networks used by financial institutions. This draft defines 68 additional objective functions and metrics types related to latency 69 and latency variation in Path Computation Element Communication 70 Protocol (PCEP). 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 76 this document are to be interpreted as described in RFC 2119 77 [RFC2119]. 79 Table of Contents 81 Copyright Notice..................................................1 82 1. Introduction...................................................3 83 2. PCEP extensions................................................3 84 2.1. New Metric Object Types................................3 85 2.1.1. P2P Latency Metric................................4 86 2.1.2. P2P Latency Variation Metric......................4 87 2.1.3. P2MP Latency Metric...............................4 88 2.1.4. P2MP Latency Variation Metric.....................5 89 2.2. Handling of New Metric Object Types....................5 90 2.3. New Objective Functions................................5 91 2.3.1. Minimum Latency Path Objective Function...........6 92 2.3.2. Minimum Latency Variation Path Objective Function.6 93 2.4. Handling of New Objective Functions....................6 94 3. Security Considerations........................................6 95 ID draft-ali-pce-additional-of-and-metric-00.txt 97 4. IANA Considerations............................................6 98 5. References.....................................................7 99 5.1. Normative References...................................7 100 5.2. Informative References.................................7 102 1. Introduction 104 As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 105 networks such as financial information networks (e.g. stock 106 market data providers), performance criteria (e.g. latency, 107 latency variation) are becoming critical to data path selection 108 along with other metrics. Such networks may require selection of 109 a path that minimizes end-to-end latency and/or end-to-end 110 latency variation. Or a path may need to be found that optimizes 111 some other metric, but is subjected to a latency and/or latency 112 variation bound(s). 114 The METRIC object defined in [RFC5440] allows a PCC to specify a 115 bounded acceptable path cost and/or optimization metric. While 116 [RFC5440], [RFC5541] and [RFC6006] define various Metric Types, 117 these RFCs do not address latency and latency variation metrics. 118 This document extends [RFC 5540] with four new Metric Types 119 namely Point-to-Point (P2P) latency metric, P2P latency variation 120 metric, Point-to-Multipoint (P2MP) latency metric and P2MP 121 latency variation metric. 123 [RFC5541] defines a framework to extend the PCEP to allow a PCE 124 to indicate the set of objective functions it supports. [RFC5541] 125 also define procedure so that a PCC can indicate in a path 126 computation request the required objective function, and a PCE 127 can report in a path computation reply the objective function 128 that was used for path computation. While [RFC5541] and [RFC6006] 129 define various objective functions, these documents do not define 130 objective functions for optimizing network performance criteria 131 such as latency and latency variation. This document extends the 132 [RFC5541] with two new objective functions namely Minimum Latency 133 Path (MLP) OF and Minimum Latency Variation Path (MLVP) OF. 135 2. PCEP extensions 137 This section defines PCEP extensions for requirements outlined 138 in Section 1. 140 2.1. New Metric Object Types 142 This document defines the following four additional types for 143 the object defined in [RFC5440}. For explanation of 145 ID draft-ali-pce-additional-of-and-metric-00.txt 147 these metrics, the following terminology is used and expanded 148 along the way. 150 - A network comprises of a set of N links {Li, (i=1...N)}. 152 - A path P of a P2P LSP is a list of K links {Lpi,(i=1...K)}. 154 2.1.1. P2P Latency Metric 156 Link delay metric is defined in [OSPF-TE-METRIC] and [ISIS-TE- 157 METRIC]. P2P latency metric type of object in PCEP 158 encodes the sum of the link delay metric of all links along a 159 P2P Path. Specifically, extending on the above mentioned 160 terminology: 162 - Link delay metric of link L is denoted D(L). 164 - P2P latency metric for the Path P = Sum {D(Lpi), 165 (i=1...K)}. 167 Value for P2P latency metric type is to be assigned by IANA 168 (suggested value: 11). 170 2.1.2. P2P Latency Variation Metric 172 Link delay variation metric is defined in [OSPF-TE-METRIC] and 173 [ISIS-TE-METRIC]. P2P latency variation metric type of 174 object in PCEP encodes a function of the link delay variation 175 metric of all links along a P2P Path. Specifically, extending on 176 the above mentioned terminology: 178 - Latency variation of link L is denoted DV(L). 180 - P2P latency variation metric for the Path P = Function 181 {DV(Lpi), (i=1...K)}. 183 Specification of the "Function" used to drive latency variation 184 metric of a path from latency variation metrics of individual 185 links along the path is beyond the scope of this document. 187 Value for P2P latency variation metric is to be assigned by IANA 188 (suggested value: 12). 190 2.1.3. P2MP Latency Metric 192 P2MP latency metric type of object in PCEP encodes the 193 path latency metric for destination that observes the worst 195 ID draft-ali-pce-additional-of-and-metric-00.txt 197 latency metric among all destination of the P2MP tree. 198 Specifically, extending on the above mentioned terminology: 200 - A P2MP Tree T comprises of a set of M destinations {Dest_j, 201 (j=1...M)} 203 - P2P latency metric of the Path to destination Dest_j is 204 denoted by LM(Dest_j). 206 - P2MP latency metric for the P2MP tree T = Maximum 207 {LM(Dest_j), (j=1...M)}. 209 Value for P2MP latency metric is to be assigned by IANA 210 (suggested value: 13). 212 2.1.4. P2MP Latency Variation Metric 214 P2MP latency variation metric type of object in PCEP 215 encodes the path latency variation metric for destination that 216 observes the worst latency variation metric among all destination 217 of the P2MP tree. Specifically, extending on the above mentioned 218 terminology: 220 - A P2MP Tree T comprises of a set of M destinations {Dest_j, 221 (j=1...M)} 223 - P2P latency variation metric of the Path to destination 224 Dest_j is denoted by LVM(Dest_j). 226 - P2MP latency variation metric for the P2MP tree T = Maximum 227 {LVM(Dest_j), (j=1...M)}. 229 Value for P2MP latency variation metric is to be assigned by IANA 230 (suggested value: 14). 232 2.2. Handling of New Metric Object Types 234 This document does not propose any changes to handling of Metric 235 object. Specifically, the new metric types defined in this 236 document are handled in the same fashion as metric types defined 237 in [RFC5440]. 239 2.3. New Objective Functions 241 This document extends the [RFC 5541] with two new objective 242 functions namely Minimum Latency Path (MLP) OF and Minimum 243 Latency Variation Path (MLVP) OF. The objective function code 244 for each of the new objective function is also defined. 246 ID draft-ali-pce-additional-of-and-metric-00.txt 248 2.3.1. Minimum Latency Path Objective Function 250 Minimum Latency Path (MLP) OF is defined as an objective 251 function where a path is computed such that latency of the path 252 is minimized. 254 Objective function code for MLP OF is to be assigned by IANA 255 (suggested value: 9). 257 2.3.2. Minimum Latency Variation Path Objective Function 259 Minimum Latency Variation Path (MLVP) OF is defined as an 260 objective function where a path is computed such that latency 261 variation in the path is minimized. 263 Objective function code for MLVP OF is to be assigned by IANA 264 (suggested value: 10). 266 2.4. Handling of New Objective Functions 268 This document does not propose any changes to handling of 269 object. Specifically, the new OF types defined in this document 270 are handled in the same fashion as OF types defined in 271 [RFC5541]. 273 3. Security Considerations 275 This document does not introduce any additional security issues 276 beyond those identified in [RFC5440], [RFC5541] and [RFC6006]. 278 4. IANA Considerations 280 This document defines the following four additional types for 281 the object defined in [RFC5440]. 283 Value Description 285 ----- ------------ 287 TBA (suggest value: 11) P2P latency metric 289 TBA (suggest value: 12) P2P latency variation metric 291 TBA (suggest value: 13) P2MP latency metric 293 TBA (suggest value: 14) P2MP latency variation metric 295 ID draft-ali-pce-additional-of-and-metric-00.txt 297 This document defines the following two objective functions 298 codes for the object defined in [RFC5541]. 300 Value Description 302 ----- ------------ 304 TBA (suggest value: 9) Minimum Latency Path (MLP) OF 306 TBA (suggest value: 10) Minimum Latency Variation Path (MLVP) OF 308 5. References 310 5.1. Normative References 312 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 313 Computation Element (PCE) Communication Protocol 314 (PCEP)", RFC 5440, March 2009. 316 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 317 Objective Functions in the Path Computation Element 318 Communication Protocol (PCEP)", RFC 5541, June 2009. 320 [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. 321 Atlas, S. Previdi, "OSPF Traffic Engineering (TE) 322 Metric Extensions", draft-ietf-ospf-te-metric- 323 extensions, work in progress. 325 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 326 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 327 Engineering (TE) Metric Extensions", draft-previdi- 328 isis-te-metric-extensions, work in progress. 330 5.2. Informative References 332 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, 333 T., Ali, Z., and J. Meuric, "Extensions to the Path 334 Computation Element Communication Protocol (PCEP) for 335 Point-to-Multipoint Traffic Engineering Label Switched 336 Paths", RFC 6006, September 2010. 338 Authors' Addresses 339 ID draft-ali-pce-additional-of-and-metric-00.txt 341 Zafar Ali 342 Cisco Systems 343 Email: zali@cisco.com 345 George Swallow 346 Cisco Systems 347 swallow@cisco.com 349 Clarence Filsfils 350 Cisco Systems 351 cfilsfil@cisco.com 353 Siva Sivabalan 354 Cisco Systems 355 msiva@cisco.com 357 Stefano Previdi 358 Cisco Systems 359 sprevidi@cisco.com 361 Kenji Kumaki 362 KDDI Corporation 363 Email: ke-kumaki@kddi.com