idnits 2.17.1 draft-ietf-alto-performance-metrics-09.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 ([RFC2119], [RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 227 has weird spacing: '...tMetric cost...' == Line 230 has weird spacing: '...NString descr...' == Line 234 has weird spacing: '...NString cos...' == Line 235 has weird spacing: '...ONValue par...' -- The document date (March 09, 2020) is 1508 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: 'RFC7679' is mentioned on line 917, but not defined == Missing Reference: 'RFC7680' is mentioned on line 917, but not defined == Missing Reference: 'I-D.ietf-ippm-initial-registry' is mentioned on line 642, but not defined == Missing Reference: 'RFC3630' is mentioned on line 917, but not defined == Missing Reference: 'RFC3784' is mentioned on line 917, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC7471' is mentioned on line 917, but not defined == Missing Reference: 'RFC7752' is mentioned on line 918, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'I-D.ietf-idr-te-pm-bgp' is mentioned on line 918, but not defined == Unused Reference: 'RFC2679' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1078, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Downref: Normative reference to an Informational RFC: RFC 6349 ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track Y. Yang 5 Expires: September 10, 2020 Yale University 6 D. Dhody 7 Huawei 8 S. Randriamasy 9 Nokia Bell Labs 10 L. Contreras 11 Telefonica 12 March 09, 2020 14 ALTO Performance Cost Metrics 15 draft-ietf-alto-performance-metrics-09 17 Abstract 19 Cost metric is a basic concept in Application-Layer Traffic 20 Optimization (ALTO), and is used in basic ALTO services including 21 both the cost map service and the endpoint cost service. 23 Different applications may use different cost metrics, but the ALTO 24 base protocol [RFC7285] documents only one single cost metric, i.e., 25 the generic "routingcost" metric; see Sec. 14.2 of [RFC7285]. Hence, 26 if the resource consumer of an application prefers a resource 27 provider that offers low-delay delivery to the resource consumer, the 28 base protocol does not define the cost metric to be used. 30 ALTO cost metrics can be generic metrics and this document focuses on 31 network performance metrics, including network delay, jitter, packet 32 loss, hop count, and bandwidth. 34 When using an ALTO performance metric, an application may need 35 additional contextual information beyond the metric value. For 36 example, whether the metric is an estimation based on measurements or 37 a service-level agreement (SLA) can define the meaning of a 38 performance metric. Hence, this document introduces an additional 39 "cost-context" field to the ALTO "cost-type" field to convey such 40 information. To report an estimated value of a performance metric, 41 the ALTO server may derive and aggregate from routing protocols with 42 different granularity and scope, such as BGP-LS, OSPF-TE and ISIS-TE, 43 or from end-to-end traffic management tools. These metrics may then 44 be exposed by an ALTO Server to allow applications to determine 45 "where" to connect based on network performance criteria. 47 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", 48 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 49 and "OPTIONAL" in this document are to be interpreted as described in 50 [RFC2119]. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on September 10, 2020. 69 Copyright Notice 71 Copyright (c) 2020 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 87 2. Performance Metric Context: cost-context . . . . . . . . . . 5 88 3. Network Performance Cost Metrics . . . . . . . . . . . . . . 7 89 3.1. Cost Metric: One Way Delay (owdelay) . . . . . . . . . . 7 90 3.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 7 91 3.1.2. Value Representation . . . . . . . . . . . . . . . . 7 92 3.1.3. Intended Semantics and Use . . . . . . . . . . . . . 7 93 3.1.4. Measurement Considerations and Parameters . . . . . . 8 94 3.2. Cost Metric: RoundTrip Time (rtt) . . . . . . . . . . . . 9 95 3.2.1. Identifier . . . . . . . . . . . . . . . . . . . . . 9 96 3.2.2. Value Representation . . . . . . . . . . . . . . . . 9 97 3.2.3. Intended Semantics and Use . . . . . . . . . . . . . 9 98 3.2.4. Measurement Considerations and Parameters . . . . . . 10 99 3.3. Cost Metric: Packet Delay Variation (pdv) . . . . . . . . 11 100 3.3.1. Identifier . . . . . . . . . . . . . . . . . . . . . 11 101 3.3.2. Value Representation . . . . . . . . . . . . . . . . 11 102 3.3.3. Intended Semantics and Use . . . . . . . . . . . . . 11 103 3.3.4. Measurement Considerations and Parameters . . . . . . 12 104 3.4. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . 13 105 3.4.1. Identifier . . . . . . . . . . . . . . . . . . . . . 13 106 3.4.2. Value Representation . . . . . . . . . . . . . . . . 13 107 3.4.3. Intended Semantics and Use . . . . . . . . . . . . . 13 108 3.4.4. Measurement Considerations and Parameters . . . . . . 14 109 3.5. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . 15 110 3.5.1. Identifier . . . . . . . . . . . . . . . . . . . . . 15 111 3.5.2. Value Representation . . . . . . . . . . . . . . . . 15 112 3.5.3. Intended Semantics and Use . . . . . . . . . . . . . 15 113 3.5.4. Measurement Considerations and Parameters . . . . . . 16 114 3.6. Cost Metric: Throughput . . . . . . . . . . . . . . . . . 16 115 3.6.1. Identifier . . . . . . . . . . . . . . . . . . . . . 16 116 3.6.2. Value Representation . . . . . . . . . . . . . . . . 16 117 3.6.3. Intended Semantics and Use . . . . . . . . . . . . . 16 118 3.6.4. Measurement Considerations and Parameters . . . . . . 17 119 4. Traffic Engineering Performance Cost Metrics . . . . . . . . 18 120 4.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 18 121 4.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 18 122 4.1.2. Value Representation . . . . . . . . . . . . . . . . 18 123 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 18 124 4.1.4. Measurement Considerations and Parameters . . . . . . 19 125 4.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 20 126 4.2.1. Identifier . . . . . . . . . . . . . . . . . . . . . 20 127 4.2.2. Value Representation . . . . . . . . . . . . . . . . 20 128 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 20 129 4.2.4. Measurement Considerations and Parameters . . . . . . 21 130 5. Operational Considerations . . . . . . . . . . . . . . . . . 22 131 5.1. Source Considerations . . . . . . . . . . . . . . . . . . 22 132 5.2. Backward Compatibility Considerations . . . . . . . . . . 23 133 5.3. Computation Considerations . . . . . . . . . . . . . . . 23 134 5.3.1. Configuration Parameters Considerations . . . . . . . 23 135 5.3.2. Availability Considerations . . . . . . . . . . . . . 23 136 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 137 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 138 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 139 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 140 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 141 9.2. Informative References . . . . . . . . . . . . . . . . . 26 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 144 1. Introduction 146 Cost Metric is a basic concept in Application-Layer Traffic 147 Optimization (ALTO). It is used in both the ALTO cost map service 148 and the ALTO endpoint cost service, to allow applications to request 149 network cost metrics. 151 Different applications may use different cost metrics. Hence, the 152 ALTO base protocol [RFC7285] introduces an ALTO Cost Metric Registry 153 (Section 14.2 of [RFC7285]), as a systematic mechanism to allow 154 different metrics to be specified. For example, a delay-sensitive 155 application may want to use latency related metrics, and a bandwidth- 156 sensitive application may want to use bandwidth related metrics. The 157 ALTO base protocol [RFC7285], however, has registered only one single 158 cost metric, i.e., the generic "routingcost" metric; no latency or 159 bandwidth related metrics are defined. 161 This document registers a set of new cost metrics specified in 162 Table 1, to support the aforementioned applications, to allow them to 163 better determine "where" to connect based on network performance 164 criteria. This document follows the guideline (Section 14.2 of 165 [RFC7285]) of the ALTO base protocol on registering ALTO cost 166 metrics. Hence it specifies the identifier, the intended semantics, 167 and the security considerations of each one of the metrics defined in 168 Table 1. 170 +--------------------------+-------------+-------------+ 171 | Metric | Definition | Origin | 172 +--------------------------+-------------+-------------+ 173 | One Way Delay | Section 2.1 | [RFC7679] | 174 | Round Trip Delay | Section 2.2 | [RFC2681] | 175 | Packet Delay Variation | Section 2.3 | [RFC3393] | 176 | Hop Count | Section 2.4 | [RFC7285] | 177 | Packet Loss | Section 2.5 | [RFC7680] | 178 | Throughput | Section 2.6 | [RFC6349] | 179 | Max Reservable Bandwidth | Section 3.1 | [RFC5305] | 180 | Residue Bandwidth | Section 3.2 | [RFC7810] | 181 +------------+-----------------------------------------+ 182 Table 1. Cost Metrics Defined in this Document. 184 The purpose of this document is to ensure proper usage of the metrics 185 by ALTO clients. It does not claim novelty of the metrics; see 186 Table 1 for the source definition of each metric. 188 An ALTO server may provide only a subset of the cost metrics 189 described in this document. Hence, all cost metrics defined in this 190 document are optional and not all of them need to be exposed to a 191 given application. For example, those that are subject to privacy 192 concerns should not be provided to unauthorized ALTO clients. 194 When an ALTO server supports a cost metric defined in this document, 195 it MUST announce this metric in its information resource directory 196 (IRD). 198 An ALTO server introducing these metrics should also consider 199 security issues. As a generic security consideration on the 200 reliability and trust in the exposed metric values, applications 201 SHOULD rapidly give up using ALTO-based guidance if they detect that 202 the exposed information does not preserve their performance level or 203 even degrades it. We discuss security considerations in more details 204 in Section 6. 206 Following the ALTO base protocol, this document uses JSON to specify 207 the value type of each defined metric. See [RFC8259] for JSON data 208 type specification. 210 2. Performance Metric Context: cost-context 212 The semantics of a performance metric depends on the context. 213 Specifically, this document defines three sources when defining 214 performance metrics: "estimation", "nominal", and "sla". 216 Even given the source, precise interpretation of a performance metric 217 value, if needed, depends on an additional set of measurement and 218 computation parameters. For example, see Section 3.8 of [RFC7679] on 219 items which a more complete measurement-based report should include. 221 To make it possible to specify both the source and the additional 222 parameters, this document introduces an optional "cost-context" field 223 to the "cost-type" field defined by the ALTO base protocol 224 (Section 10.7 of [RFC7285]) as the following: 226 object { 227 CostMetric cost-metric; 228 CostMode cost-mode; 229 [CostContext cost-context;] 230 [JSONString description;] 231 } CostType; 233 object { 234 JSONString cost-source; 235 [JSONValue parameters;] 236 } CostContext; 238 The "cost-source" MUST be one of only three values: "estimation", 239 "nominal", and "sla". If a "cost-type" does not include the optional 240 "cost-context" field which includes the "cost-source" field, the 241 application MUST assume that the value of "cost-source" is 242 "estimation". 244 An ALTO server may compute "estimation" values by retrieving and/or 245 aggregating information from routing protocols or other traffic 246 measurement management tools, with corresponding operational issues. 247 A potential architecture on estimating these metrics is shown in 248 Figure 1 below. In Section 5, we discuss in more detail the 249 operational issues and how a network may address them. 251 +--------+ +--------+ +--------+ 252 | Client | | Client | | Client | 253 +----^---+ +---^----+ +---^----+ 254 | | | 255 +-----------|-----------+ 256 NBI |ALTO protocol 257 | 258 | 259 +--+-----+ retrieval +---------+ 260 | ALTO |<----------------| Routing | 261 | Server | and aggregation| | 262 | |<-------------+ | Protocol| 263 +--------+ | +---------+ 264 | 265 | +---------+ 266 | |Management 267 ---| | 268 | Tool | 269 +---------+ 270 Figure 1. Potential framework to compute performance cost metrics 272 3. Network Performance Cost Metrics 274 This section introduces generic ALTO network performance metrics such 275 as one way delay, round trip delay, hop count, packet loss, and 276 throughput. 278 3.1. Cost Metric: One Way Delay (owdelay) 280 3.1.1. Identifier 282 The identifier for this performance metric is "owdelay". 284 3.1.2. Value Representation 286 The metric value type is a single 'JSONNumber' type value conforming 287 to the number specification of [RFC8259] Section 6. The number MUST 288 be non-negative. The unit is expressed in milliseconds. 290 3.1.3. Intended Semantics and Use 292 Intended Semantics: To specify spatial and temporal aggregated delay 293 of a stream of packets exchanged between the specified source and 294 destination or the time that the packet spends to travel from source 295 to destination. The spatial aggregation level is specified in the 296 query context (e.g., PID to PID, or endpoint to endpoint). 298 Use: This metric could be used as a cost metric constraint attribute 299 used either together with cost metric attribute 'routingcost' or on 300 its own or as a returned cost metric in the response. 302 Example 1: Delay value on source-destination endpoint pairs 304 POST /endpointcost/lookup HTTP/1.1 305 Host: alto.example.com 306 Content-Length: TBA 307 Content-Type: application/alto-endpointcostparams+json 308 Accept: 309 application/alto-endpointcost+json,application/alto-error+json 311 { 312 "cost-type": {"cost-mode" : "numerical", 313 "cost-metric" : "owdelay"}, 314 "endpoints" : { 315 "srcs": [ "ipv4:192.0.2.2" ], 316 "dsts": [ 317 "ipv4:192.0.2.89", 318 "ipv4:198.51.100.34", 319 "ipv6:2000::1:2345:6789:abcd" 320 ] 321 } 322 } 324 HTTP/1.1 200 OK 325 Content-Length: TBA 326 Content-Type: application/alto-endpointcost+json 327 { 328 "meta" :{ 329 "cost-type": {"cost-mode" : "numerical", 330 "cost-metric" : "owdelay" 331 } 332 }, 333 "endpoint-cost-map" : { 334 "ipv4:192.0.2.2": { 335 "ipv4:192.0.2.89" : 10, 336 "ipv4:198.51.100.34" : 20, 337 "ipv6:2000::1:2345:6789:abcd" : 30, 338 } 339 } 340 } 342 Comment: Since the "cost-type" does not include the "cost-source" 343 field, the values are based on "estimation". 345 3.1.4. Measurement Considerations and Parameters 347 See Section 4 of [I-D.ietf-ippm-initial-registry] for measurement 348 considerations and parameters which may be specified in "parameters". 350 Note that the "parameters" field is an optional field providing non- 351 normative information. 353 3.2. Cost Metric: RoundTrip Time (rtt) 355 3.2.1. Identifier 357 The identifier for this performance metric is "rtt". 359 3.2.2. Value Representation 361 The metric value type is a single 'JSONNumber' type value conforming 362 to the number specification of [RFC8259] Section 6. The number MUST 363 be non-negative. The unit is expressed in milliseconds. 365 3.2.3. Intended Semantics and Use 367 Intended Semantics: To specify spatial and temporal aggregated round 368 trip delay between the specified source and destination or the time 369 that the packet spends to travel from source to destination and then 370 from destination to source. The spatial aggregation level is 371 specified in the query context (e.g., PID to PID, or endpoint to 372 endpoint). 374 Use: This metric could be used as a cost metric constraint attribute 375 used either together with cost metric attribute 'routingcost' or on 376 its own or as a returned cost metric in the response. 378 Example 2: Roundtrip Delay value on source-destination endpoint pairs 380 POST /endpointcost/lookup HTTP/1.1 381 Host: alto.example.com 382 Content-Length: TBA 383 Content-Type: application/alto-endpointcostparams+json 384 Accept: 385 application/alto-endpointcost+json,application/alto-error+json 387 { 388 "cost-type": {"cost-mode" : "numerical", 389 "cost-metric" : "rtt"}, 390 "endpoints" : { 391 "srcs": [ "ipv4:192.0.2.2" ], 392 "dsts": [ 393 "ipv4:192.0.2.89", 394 "ipv4:198.51.100.34", 395 "ipv6:2000::1:2345:6789:abcd" 396 ] 397 } 398 } 400 HTTP/1.1 200 OK 401 Content-Length: TBA 402 Content-Type: application/alto-endpointcost+json 403 { 404 "meta" :{ 405 "cost-type": {"cost-mode" : "numerical", 406 "cost-metric" : "rtt" 407 } 408 }, 409 "endpoint-cost-map" : { 410 "ipv4:192.0.2.2": { 411 "ipv4:192.0.2.89" : 4, 412 "ipv4:198.51.100.34" : 3, 413 "ipv6:2000::1:2345:6789:abcd" : 2, 414 } 415 } 416 } 418 3.2.4. Measurement Considerations and Parameters 420 See Section 4 of [I-D.ietf-ippm-initial-registry] for measurement 421 considerations and parameters which may be specified in "parameters". 422 Note that the "parameters" field is an optional field providing non- 423 normative information. 425 3.3. Cost Metric: Packet Delay Variation (pdv) 427 3.3.1. Identifier 429 The identifier for this performance metric is "pdv". 431 3.3.2. Value Representation 433 The metric value type is a single 'JSONNumber' type value conforming 434 to the number specification of [RFC8259] Section 6. The number MUST 435 be non-negative. The unit is expressed in milliseconds. 437 3.3.3. Intended Semantics and Use 439 Intended Semantics: To specify spatial and temporal aggregated jitter 440 (packet delay variation) with respect to the minimum delay observed 441 on the stream over the specified source and destination. The spatial 442 aggregation level is specified in the query context (e.g., PID to 443 PID, or endpoint to endpoint). 445 Use: This metric could be used as a cost metric constraint attribute 446 used either together with cost metric attribute 'routingcost' or on 447 its own or as a returned cost metric in the response. 449 Example 3: PDV value on source-destination endpoint pairs 451 POST /endpointcost/lookup HTTP/1.1 452 Host: alto.example.com 453 Content-Length: TBA 454 Content-Type: application/alto-endpointcostparams+json 455 Accept: 456 application/alto-endpointcost+json,application/alto-error+json 458 { 459 "cost-type": {"cost-mode" : "numerical", 460 "cost-metric" : "pdv"}, 461 "endpoints" : { 462 "srcs": [ "ipv4:192.0.2.2" ], 463 "dsts": [ 464 "ipv4:192.0.2.89", 465 "ipv4:198.51.100.34", 466 "ipv6:2000::1:2345:6789:abcd" 467 ] 468 } 469 } 470 HTTP/1.1 200 OK 471 Content-Length: TBA 472 Content-Type: application/alto-endpointcost+json 473 { 474 "meta": { 475 "cost type": { 476 "cost-mode": "numerical", 477 "cost-metric":"delayjitter" 478 } 479 }, 480 "endpoint-cost-map": { 481 "ipv4:192.0.2.2": { 482 "ipv4:192.0.2.89" : 0 483 "ipv4:198.51.100.34" : 1 484 "ipv6:2000::1:2345:6789:abcd" : 5 485 } 486 } 487 } 489 3.3.4. Measurement Considerations and Parameters 491 See Section 5 of [I-D.ietf-ippm-initial-registry] for measurement 492 considerations and parameters which may be specified in "parameters". 493 Note that the "parameters" field is an optional field providing non- 494 normative information. 496 3.4. Cost Metric: Hop Count 498 The metric hopcount is mentioned in [RFC7285] Section 9.2.3 as an 499 example. This section further clarifies its properties. 501 3.4.1. Identifier 503 The identifier for this performance metric is "hopcount". 505 3.4.2. Value Representation 507 The metric value type is a single 'JSONNumber' type value conforming 508 to the number specification of [RFC8259] Section 6. The number MUST 509 be an integer and non-negative. The value represents the number of 510 hops. 512 3.4.3. Intended Semantics and Use 514 Intended Semantics: To specify the number of hops in the path between 515 the source endpoint and the destination endpoint. The hop count is a 516 basic measurement of distance in a network and can be exposed as 517 Router Hops, in direct relation to the routing protocols originating 518 this information. 520 Use: This metric could be used as a cost metric constraint attribute 521 used either together with cost metric attribute 'routingcost' or on 522 its own or as a returned cost metric in the response. 524 Example 4: hopcount value on source-destination endpoint pairs 526 POST /endpointcost/lookup HTTP/1.1 527 Host: alto.example.com 528 Content-Length: TBA 529 Content-Type: application/alto-endpointcostparams+json 530 Accept: 531 application/alto-endpointcost+json,application/alto-error+json 533 { 534 "cost-type": {"cost-mode" : "numerical", 535 "cost-metric" : "hopcount"}, 536 "endpoints" : { 537 "srcs": [ "ipv4:192.0.2.2" ], 538 "dsts": [ 539 "ipv4:192.0.2.89", 540 "ipv4:198.51.100.34", 541 "ipv6:2000::1:2345:6789:abcd" 542 ] 543 } 544 } 546 HTTP/1.1 200 OK 547 Content-Length: TBA 548 Content-Type: application/alto-endpointcost+json 549 { 550 "meta": { 551 "cost type": { 552 "cost-mode": "numerical", 553 "cost-metric":"hopcount"} 554 } 555 }, 556 "endpoint-cost-map": { 557 "ipv4:192.0.2.2": { 558 "ipv4:192.0.2.89" : 5, 559 "ipv4:198.51.100.34": 3, 560 "ipv6:2000::1:2345:6789:abcd" : 2, 561 } 562 } 563 } 565 3.4.4. Measurement Considerations and Parameters 567 The hop count can be calculated based on the number of routers from 568 the source endpoint through which data must pass to reach the 569 destination endpoint. This count can be measured at the source 570 endpoint by traceroute. 572 Upon need, the traceroute can use UDP probe message or other 573 implementations that use ICMP and TCP to discover the hop counts 574 along the path from source endpoint to destination endpoint. 576 3.5. Cost Metric: Packet Loss 578 3.5.1. Identifier 580 The identifier for this performance metric is "pktloss". 582 3.5.2. Value Representation 584 The metric value type is a single 'JSONNumber' type value conforming 585 to the number specification of [RFC8259] Section 6. The number MUST 586 be non-negative. The value represents the percentage of packet loss. 588 3.5.3. Intended Semantics and Use 590 Intended Semantics: To specify spatial and temporal aggregated packet 591 loss over the specified source and destination. The spatial 592 aggregation level is specified in the query context (e.g., PID to 593 PID, or endpoint to endpoint). 595 Use: This metric could be used as a cost metric constraint attribute 596 used either together with cost metric attribute 'routingcost' or on 597 its own or as a returned cost metric in the response. 599 Example 5: pktloss value on source-destination endpoint pairs 601 POST /endpointcost/lookup HTTP/1.1 602 Host: alto.example.com 603 Content-Length: TBA 604 Content-Type: application/alto-endpointcostparams+json 605 Accept: 606 application/alto-endpointcost+json,application/alto-error+json 608 { 609 "cost-type": {"cost-mode" : "numerical", 610 "cost-metric" : "pktloss"}, 611 "endpoints" : { 612 "srcs": [ "ipv4:192.0.2.2" ], 613 "dsts": [ 614 "ipv4:192.0.2.89", 615 "ipv4:198.51.100.34", 616 "ipv6:2000::1:2345:6789:abcd" 617 ] 618 } 619 } 621 HTTP/1.1 200 OK 622 Content-Length: TBA 623 Content-Type: application/alto-endpointcost+json 624 { 625 "meta": { 626 "cost type": { 627 "cost-mode": "numerical", 628 "cost-metric":"pktloss"} 629 } 630 }, 631 "endpoint-cost-map": { 632 "ipv4:192.0.2.2": { 633 "ipv4:192.0.2.89" : 0, 634 "ipv4:198.51.100.34": 0, 635 "ipv6:2000::1:2345:6789:abcd" : 0, 636 } 637 } 638 } 640 3.5.4. Measurement Considerations and Parameters 642 See Section 4 of [I-D.ietf-ippm-initial-registry] for measurement 643 considerations and parameters which may be specified in "parameters". 644 Note that the "parameters" field is an optional field providing non- 645 normative information. 647 3.6. Cost Metric: Throughput 649 3.6.1. Identifier 651 The identifier for this performance metric is "throughput". 653 3.6.2. Value Representation 655 The metric value type is a single 'JSONNumber' type value conforming 656 to the number specification of [RFC8259] Section 6. The number MUST 657 be non-negative. The unit is Mbps. 659 3.6.3. Intended Semantics and Use 661 Intended Semantics: To specify spatial and temporal throughput over 662 the specified source and destination. The spatial aggregation level 663 is specified in the query context (e.g., PID to PID, or endpoint to 664 endpoint). 666 Use: This metric could be used as a cost metric constraint attribute 667 used either together with cost metric attribute 'routingcost' or on 668 its own or as a returned cost metric in the response. 670 Example 5: throughtput value on source-destination endpoint pairs 672 POST /endpointcost/lookup HTTP/1.1 673 Host: alto.example.com 674 Content-Length: TBA 675 Content-Type: application/alto-endpointcostparams+json 676 Accept: 677 application/alto-endpointcost+json,application/alto-error+json 679 { 680 "cost-type": {"cost-mode" : "numerical", 681 "cost-metric" : "throughput"}, 682 "endpoints" : { 683 "srcs": [ "ipv4:192.0.2.2" ], 684 "dsts": [ 685 "ipv4:192.0.2.89", 686 "ipv4:198.51.100.34", 687 "ipv6:2000::1:2345:6789:abcd" 688 ] 689 } 690 } 692 HTTP/1.1 200 OK 693 Content-Length: TBA 694 Content-Type: application/alto-endpointcost+json 695 { 696 "meta": { 697 "cost type": { 698 "cost-mode": "numerical", 699 "cost-metric":"throughput" 700 } 701 } 702 "endpoint-cost-map": { 703 "ipv4:192.0.2.2": { 704 "ipv4:192.0.2.89" : 25.6, 705 "ipv4:198.51.100.34": 12.8, 706 "ipv6:2000::1:2345:6789:abcd" : 42.8, 707 } 708 } 710 3.6.4. Measurement Considerations and Parameters 712 See Section 3.3 of [RFC6349] for measurement method and parameters 713 which may be specified in "parameters". Note that the "parameters" 714 field is an optional field providing non-normative information. 716 4. Traffic Engineering Performance Cost Metrics 718 This section introduces ALTO network performance metrics that may be 719 aggregated from network metrics measured on links and specified in 720 other documents. In particular, the bandwidth related metrics 721 specified in this section are only available through link level 722 measurements. For some of these metrics, the ALTO Server may further 723 expose aggregated values while specifying the aggregation laws. 725 4.1. Cost Metric: Link Maximum Reservable Bandwidth 727 4.1.1. Identifier 729 The identifier for this performance metric is "maxresbw". 731 4.1.2. Value Representation 733 The metric value type is a single 'JSONNumber' type value that is 734 non-negative. The unit of measurement is Mbps. 736 4.1.3. Intended Semantics and Use 738 Intended Semantics: To specify spatial and temporal maximum 739 reservable bandwidth over the specified source and destination. The 740 value is corresponding to the maximum bandwidth that can be reserved 741 (motivated from RFC 3630 Sec. 2.5.7.). The spatial aggregation unit 742 is specified in the query context (e.g., PID to PID, or endpoint to 743 endpoint). 745 Use: This metric could be used as a cost metric constraint attribute 746 used either together with cost metric attribute 'routingcost' or on 747 its own or as a returned cost metric in the response. 749 Example 6: maxresbw value on source-destination endpoint pairs 751 POST/ endpointcost/lookup HTTP/1.1 752 Host: alto.example.com 753 Content-Length: TBA 754 Content-Type: application/alto-endpointcostparams+json 755 Accept: 756 application/alto-endpointcost+json,application/alto-error+json 758 { 759 "cost-type" { "cost-mode": "numerical", 760 "cost-metric": "maxresbw"}, 761 "endpoints": { 762 "srcs": [ "ipv4 : 192.0.2.2" ], 763 "dsts": [ 764 "ipv4:192.0.2.89", 765 "ipv4:198.51.100.34", 766 "ipv6:2000::1:2345:6789:abcd" 767 ] 768 } 769 } 771 HTTP/1.1 200 OK 772 Content-Length: TBA 773 Content-Type: application/alto-endpointcost+json 774 { 775 "meta": { 776 "cost-type": { 777 "cost-mode": "numerical", 778 "cost-metric": "maxresbw" 779 } 780 }, 781 " endpoint-cost-map": { 782 "ipv4:192.0.2.2" { 783 "ipv4:192.0.2.89" : 0, 784 "ipv4:198.51.100.34": 2000, 785 "ipv6:2000::1:2345:6789:abcd": 5000, 786 } 787 } 788 } 790 4.1.4. Measurement Considerations and Parameters 792 Method of Measurement or Calculation: 794 Maximum Reservable Bandwidth is the bandwidth measured between two 795 directly connected IS-IS neighbors or OSPF neighbors. See 796 Section 3.5 of [RFC5305] for Measurement Method. 798 Measurement Point(s) with Potential Measurement Domain: 800 See Section 4.1 this document for discussions. 802 Measurement Timing: 804 See Section 3.5 of [RFC5305] and Section 5 of [RFC7810] for 805 Measurement Timing. 807 4.2. Cost Metric: Link Residue Bandwidth 809 4.2.1. Identifier 811 The identifier for this performance metric is "residuebw". 813 4.2.2. Value Representation 815 The metric value type is a single 'JSONNumber' type value that is 816 non-negative. The unit of measurement is Mbps. 818 4.2.3. Intended Semantics and Use 820 Intended Semantics: To specify spatial and temporal residual 821 bandwidth over the specified source and destination. The value is 822 calculated by subtracting tunnel reservations from Maximum Bandwidth 823 (motivated from [RFC7810], Section 4.5.). The spatial aggregation 824 unit is specified in the query context (e.g., PID to PID, or endpoint 825 to endpoint). 827 Use: This metric could be used as a cost metric constraint attribute 828 used either together with cost metric attribute 'routingcost' or on 829 its own or as a returned cost metric in the response. 831 Example 7: residuebw value on source-destination endpoint pairs 833 POST/ endpointcost/lookup HTTP/1.1 834 Host: alto.example.com 835 Content-Length: TBA 836 Content-Type: application/alto-endpointcostparams+json 837 Accept: 838 application/alto-endpointcost+json,application/alto-error+json 840 { 841 "cost-type": { "cost-mode": "numerical", 842 "cost-metric": "residuebw"}, 843 "endpoints": { 844 "srcs": [ "ipv4 : 192.0.2.2" ], 845 "dsts": [ 846 "ipv4:192.0.2.89", 847 "ipv4:198.51.100.34", 848 "ipv6:2000::1:2345:6789:abcd" 849 ] 850 } 851 } 853 HTTP/1.1 200 OK 854 Content-Length: TBA 855 Content-Type: application/alto-endpointcost+json 856 { 857 "meta": { 858 "cost-type" { 859 "cost-mode": "numerical", 860 "cost-metric": "residuebw" 861 } 862 }, 863 "endpoint-cost-map" { 864 "ipv4:192.0.2.2" { 865 "ipv4:192.0.2.89" : 0, 866 "ipv4:198.51.100.34": 2000, 867 "ipv6:2000::1:2345:6789:abcd": 5000, 868 } 869 } 870 } 872 4.2.4. Measurement Considerations and Parameters 874 Method of Measurement or Calculation: 876 Residue Bandwidth is the Unidirectional Residue bandwidth measured 877 between two directly connected IS-IS neighbors or OSPF neighbors. 878 See Section 4.5 of [RFC7810] for Measurement Method. 880 Measurement Point(s) with Potential Measurement Domain: 882 See Section 4.1 of this document. 884 Measurement Timing: 886 See Section 5 of [RFC7810] for Measurement Timing. 888 5. Operational Considerations 890 The exact measurement infrastructure, measurement condition and 891 computation algorithms can vary from different networks, and are 892 outside the scope of this document. Both the ALTO server and the 893 ALTO clients, however, need to be cognizant of the operational issues 894 discussed below. 896 Also, the performance metrics specified in this document are similar, 897 in that they may use similar data sources and have similar issues in 898 their calculation. Hence, we specify common issues unless one metric 899 has its unique challenges. 901 5.1. Source Considerations 903 The addition of the "cost-source" field is to solve a key issue: An 904 ALTO server needs data sources to compute the cost metrics described 905 in this document and an ALTO client needs to know the data sources to 906 better interpret the values. 908 To avoid too fine-grained information, this document introduces 909 "cost-source" to indicate only the high-level type of data sources: 910 "estimation" or "sla", where "estimation" is a type of measurement 911 data source and "sla" is a type that is more based on policy. 913 For estimation, for example, the ALTO server may use log servers or 914 the OAM system as its data source [RFC7971]. In particular, the cost 915 metrics defined in this document can be computed using routing 916 systems as the data sources. Mechanisms defined in [RFC2681], 917 [RFC3393], [RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471], 918 [RFC7810], [RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO 919 Server to retrieve and derive the necessary information to compute 920 the metrics that we describe in this document. 922 5.2. Backward Compatibility Considerations 924 One potential issue introduced by the optional "cost-source" field is 925 backward compatibility. Consider that an IRD which defines two cost- 926 types with the same "cost-mode" and "cost-metric", but one with 927 "cost-source" being "estimation" and the other being "sla". Then an 928 ALTO client that is not aware of the extension will not be able to 929 distinguish between these two types. A similar issue can arise even 930 with a single cost-type which has "cost-source" being "sla", but the 931 backward client will ignore this field and consider the metric 932 estimation. 934 To address this issue, the only defined "routingcost" metric can be 935 ONLY "estimation". 937 5.3. Computation Considerations 939 The metric values exposed by an ALTO server may result from 940 additional processing on measurements from data sources to compute 941 exposed metrics. This may involve data processing tasks such as 942 aggregating the results across multiple systems, removing outliers, 943 and creating additional statistics. There are two challenges on the 944 computation of ALTO performance metrics. 946 5.3.1. Configuration Parameters Considerations 948 Performance metrics often depend on configuration parameters. For 949 example, the value of packet loss rate depends on the measurement 950 interval and varies over time. To handle this issue, an ALTO server 951 may collect data on time periods covering the previous and current 952 time or only collect data on present time. The ALTO server may 953 further aggregate these data to provide an abstract and unified view 954 that can be more useful to applications. To make the ALTO client 955 better understand how to use these performance data, the ALTO server 956 may provide the client with the validity period of the exposed metric 957 values. 959 5.3.2. Availability Considerations 961 Applications value information relating to bandwidth availability 962 whereas bandwidth related metrics can often be only measured at the 963 link level. This document specifies a set of link-level bandwidth 964 related values that may be exposed as such by an ALTO server. The 965 server may also expose other metrics derived from their aggregation 966 and having different levels of endpoint granularity, e.g., link 967 endpoints or session endpoints. The metric specifications may also 968 expose the utilized aggregation laws. 970 6. Security Considerations 972 The properties defined in this document present no security 973 considerations beyond those in Section 15 of the base ALTO 974 specification [RFC7285]. 976 However concerns addressed in Sections "15.1 Authenticity and 977 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 978 from Authenticated ALTO Information" and "15.3 Confidentiality of 979 ALTO Information" remain of utmost importance. Indeed, TE 980 performance is a highly sensitive ISP information, therefore, sharing 981 TE metric values in numerical mode requires full mutual confidence 982 between the entities managing the ALTO Server and Client. Numerical 983 TE performance information will most likely be distributed by ALTO 984 Servers to Clients under strict and formal mutual trust agreements. 985 On the other hand, ALTO Clients must be cognizant on the risks 986 attached to such information that they would have acquired outside 987 formal conditions of mutual trust. 989 7. IANA Considerations 991 IANA has created and now maintains the "ALTO Cost Metric Registry", 992 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 993 located at . This document requests to add the 995 following entries to "ALTO Cost Metric Registry". 997 +------------+--------------------+ 998 | Identifier | Intended Semantics | 999 +------------+--------------------+ 1000 | owdelay | See Section 2.1 | 1001 | rtt | See Section 2.2 | 1002 | pdv | See Section 2.3 | 1003 | hopcount | See Section 2.4 | 1004 | pktloss | See Section 2.5 | 1005 | throughput | See Section 2.6 | 1006 | maxresbw | See Section 3.1 | 1007 | residuebw | See Section 3.2 | 1008 +------------+--------------------+ 1010 This document requests the creation of the "ALTO Cost Source 1011 Registry" with the following currently defined values: 1013 +------------+---------------------------+ 1014 | Identifier | Intended Semantics | 1015 +------------+---------------------------+ 1016 | estimation | Values by estimation | 1017 | nominal | Values in nominal cases | 1018 | sla | Values reflecting service | 1019 | | level agreement | 1020 +------------+---------------------------+ 1022 8. Acknowledgments 1024 The authors of this document would also like to thank Brian Trammell, 1025 Haizhou Du, Kai Gao, Lili Liu, Li, Geng, Danny Alex Lachos Perez for 1026 the reviews and comments. Young Lee is an author of an earlier 1027 version of the document. 1029 9. References 1031 9.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1035 RFC2119, March 1997, . 1038 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1039 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1040 September 1999, . 1042 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1043 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1044 September 1999, . 1046 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1047 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1048 10.17487/RFC3393, November 2002, . 1051 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1052 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1053 2008, . 1055 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1056 "Framework for TCP Throughput Testing", RFC 6349, DOI 1057 10.17487/RFC6349, August 2011, . 1060 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1061 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1062 "Application-Layer Traffic Optimization (ALTO) Protocol", 1063 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1064 . 1066 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1067 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1068 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1069 . 1071 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1072 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1073 RFC8259, December 2017, . 1076 9.2. Informative References 1078 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1079 Performance Metric Development", BCP 170, RFC 6390, DOI 1080 10.17487/RFC6390, October 2011, . 1083 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1084 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1085 Deployment Considerations", RFC 7971, DOI 10.17487/ 1086 RFC7971, October 2016, . 1089 Authors' Addresses 1091 Qin Wu 1092 Huawei 1093 101 Software Avenue, Yuhua District 1094 Nanjing, Jiangsu 210012 1095 China 1097 Email: bill.wu@huawei.com 1099 Y. Richard Yang 1100 Yale University 1101 51 Prospect St 1102 New Haven, CT 06520 1103 USA 1105 Email: yry@cs.yale.edu 1106 Dhruv Dhody 1107 Huawei 1108 Leela Palace 1109 Bangalore, Karnataka 560008 1110 INDIA 1112 Email: dhruv.ietf@gmail.com 1114 Sabine Randriamasy 1115 Nokia Bell Labs 1116 Route de Villejust 1117 Nozay 91460 1118 FRANCE 1120 Email: sabine.randriamasy@nokia-bell-labs.com 1122 Luis Miguel Contreras Murillo 1123 Telefonica 1125 Email: luismiguel.contrerasmurillo@telefonica.com