idnits 2.17.1 draft-ietf-alto-performance-metrics-07.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 -- The document date (July 08, 2019) is 1748 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: 'RFC3630' is mentioned on line 958, but not defined == Missing Reference: 'RFC3784' is mentioned on line 958, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Unused Reference: 'RFC5234' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1140, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-11 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Downref: Normative reference to an Informational RFC: RFC 6349 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 7 errors (**), 0 flaws (~~), 6 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: January 9, 2020 Yale University 6 Y. Lee 7 D. Dhody 8 Huawei 9 S. Randriamasy 10 Nokia Bell Labs 11 July 08, 2019 13 ALTO Performance Cost Metrics 14 draft-ietf-alto-performance-metrics-07 16 Abstract 18 Cost metric is a basic concept in Application-Layer Traffic 19 Optimization (ALTO), and is used in basic services including both the 20 cost map service and the endpoint cost service. 22 Different applications may use different cost metrics, but the ALTO 23 base protocol documents only one single cost metric, i.e., the 24 generic "routingcost" metric; see Sec. 14.2 of ALTO base 25 specification [RFC7285]. Hence, if the resource consumer of an 26 application prefers a resource provider that offers low-delay 27 delivery to the resource consumer, the base protocol does not define 28 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. These metrics can be derived and 33 aggregated from routing protocols with different granularity and 34 scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end 35 traffic management tools. These metrics may then be exposed by an 36 ALTO Server to allow applications to determine "where" to connect 37 based on network performance criteria. Additional cost metrics may 38 be documented in other documents. 40 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", 41 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 42 and "OPTIONAL" in this document are to be interpreted as described in 43 RFC 2119 [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on January 9, 2020. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Network Performance Cost Metrics . . . . . . . . . . . . . . 5 81 2.1. Cost Metric: One Way Delay (owdelay) . . . . . . . . . . 5 82 2.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 6 83 2.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 6 84 2.1.3. Measurement Considerations . . . . . . . . . . . . . 7 85 2.2. Cost Metric: RoundTrip Time (rtt) . . . . . . . . . . . . 7 86 2.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 8 87 2.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 8 88 2.2.3. Measurement Considerations . . . . . . . . . . . . . 9 89 2.3. Cost Metric: Packet Delay Variation (pdv) . . . . . . . . 9 90 2.3.1. Intended Semantics . . . . . . . . . . . . . . . . . 10 91 2.3.2. Use and Example . . . . . . . . . . . . . . . . . . . 10 92 2.3.3. Measurement Considerations . . . . . . . . . . . . . 11 94 2.4. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . 12 95 2.4.1. Intended Semantics . . . . . . . . . . . . . . . . . 12 96 2.4.2. Use and Example . . . . . . . . . . . . . . . . . . . 13 97 2.4.3. Measurement Considerations . . . . . . . . . . . . . 14 98 2.5. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . 14 99 2.5.1. Intended Semantics . . . . . . . . . . . . . . . . . 14 100 2.5.2. Use and Example . . . . . . . . . . . . . . . . . . . 15 101 2.5.3. Measurement Considerations . . . . . . . . . . . . . 16 102 2.6. Cost Metric: Throughput . . . . . . . . . . . . . . . . . 16 103 2.6.1. Intended Semantics . . . . . . . . . . . . . . . . . 17 104 2.6.2. Use and Example . . . . . . . . . . . . . . . . . . . 17 105 2.6.3. Measurement Considerations . . . . . . . . . . . . . 18 106 3. Traffic Engineering Performance Cost Metrics . . . . . . . . 18 107 3.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 19 108 3.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 19 109 3.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 19 110 3.1.3. Measurement Considerations . . . . . . . . . . . . . 20 111 3.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 21 112 3.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 21 113 3.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 21 114 3.2.3. Measurement Considerations . . . . . . . . . . . . . 22 115 4. Operational Considerations . . . . . . . . . . . . . . . . . 23 116 4.1. Data Source Considerations . . . . . . . . . . . . . . . 23 117 4.2. Computation Considerations . . . . . . . . . . . . . . . 24 118 4.2.1. Configuration Parameters Considerations . . . . . . . 24 119 4.2.2. Availability Considerations . . . . . . . . . . . . . 24 120 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 121 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 122 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 123 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 124 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 125 8.2. Informative References . . . . . . . . . . . . . . . . . 27 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 128 1. Introduction 130 Cost Metric is a basic concept in Application-Layer Traffic 131 Optimization (ALTO). It is used in both the ALTO cost map service 132 and the ALTO endpoint cost service, to allow applications to request 133 network cost metrics. 135 Different applications may use different cost metrics. Hence, the 136 ALTO base protocol [RFC7285] introduces an ALTO Cost Metric Registry 137 (Section 14.2 of [RFC7285]) as a systematic mechanism to allow 138 different metrics to be specified. For example, a more delay- 139 sensitive application may want to use latency related metrics, and a 140 more bandwidth-sensitive application may want to use bandwidth 141 related metrics. The ALTO base protocol [RFC7285], however, has 142 registered only one single cost metric, i.e., the generic 143 "routingcost" metric; no latency or bandwidth related metrics are 144 defined. 146 This document registers a set of new cost metrics specified in 147 Table 1, to support the aforementioned applications, to allow them to 148 determine "where" to connect based on network performance criteria. 149 This document follows the guideline (Section 14.2 of [RFC7285]) of 150 the ALTO base protocol on registering ALTO cost metrics. Hence it 151 specifies the identifier, the intended semantics, and the security 152 considerations of each one of the metrics defined in Table 1. 154 +--------------------------+-------------+-----------------------+ 155 | Metric | Definition | Origin | 156 +--------------------------+-------------+-----------------------+ 157 | One Way Delay | Section 2.1 | [RFC2679] Section 3.6 | 158 | Round Trip Delay | Section 2.2 | [RFC2681] Section 2.6 | 159 | Packet Delay Variation | Section 2.3 | [RFC3393] Section 2.6 | 160 | Hop Count | Section 2.4 | [RFC7285] | 161 | Packet Loss | Section 2.5 | [RFC7680] Section 2.6 | 162 | Throughput | Section 2.6 | [RFC6349] Section 3.3 | 163 | Max Reservable Bandwidth | Section 3.1 | [RFC5305] Section 3.5 | 164 | Residue Bandwidth | Section 3.2 | [RFC7810] Section 4.5 | 165 +------------+---------------------------------------------------+ 166 Table 1. Cost Metrics Defined in this Document 168 The purpose of this document is to ensure proper usage of the metrics 169 by ALTO clients. It does not claim novelty of the metrics. Some of 170 these metrics are already specified by standards such as IPPM; some 171 are ISP dependent such as those registered in ISIS or OSPF-TE. This 172 document will refer to the relevant specifications. 174 An ALTO server may provide only a subset of the cost metrics 175 described in this document. Hence, all cost metrics defined in this 176 document are optional and not all them need to be exposed to 177 applications. For example, those that are subject to privacy 178 concerns should not be provided to unauthorized ALTO clients. 180 When an ALTO server supports a cost metric defined in this document, 181 it MUST announce this metric in its information resource directory 182 (IRD). 184 The cost metrics defined in this document can be retrieved and 185 aggregated from routing protocols or other traffic measurement 186 management tools, with corresponding operational issues. A potential 187 architecture on computing these metrics is shown in Figure 1 below. 188 In Section 4, we discuss in more detail the operations issues and how 189 to address them. 191 +--------+ +--------+ +--------+ 192 | Client | | Client | | Client | 193 +----^---+ +---^----+ +---^----+ 194 | | | 195 +-----------|-----------+ 196 NBI |ALTO protocol 197 | 198 | 199 +--+-----+ retrieval +---------+ 200 | ALTO |<----------------| Routing | 201 | Server | and aggregation| | 202 | |<-------------+ | Protocol| 203 +--------+ | +---------+ 204 | 205 | +---------+ 206 | |Management 207 ---| | 208 | Tool | 209 +---------+ 210 Figure 1. Potential framework to compute performance cost metrics 212 An ALTO server introducing these metrics should also consider 213 security issues. As a generic security consideration on the 214 reliability and trust in the exposed metric values, applications 215 SHOULD rapidly give up using ALTO-based guidance if they feel the 216 exposed information does not preserve their performance level or even 217 degrades it. We discuss security considerations in more details in 218 Section 5. 220 Following the ALTO base protocol, this document uses JSON to specify 221 the value type of each defined metric. See [RFC4627] for JSON data 222 type specification. 224 2. Network Performance Cost Metrics 226 This section introduces generic ALTO network performance metrics such 227 as one way delay,round trip delay,hop count,packet loss,throughput 228 derived and aggregated from routing protocols or from end to end 229 traffic management tools. 231 2.1. Cost Metric: One Way Delay (owdelay) 233 Metric name: 235 One Way Delay 237 Metric Identifier: 239 owdelay 241 2.1.1. Intended Semantics 243 Metric Description: To specify spatial and temporal aggregated delay 244 of a stream of packets exchanged between the specified source and 245 destination or the time that the packet spends to travel from source 246 to destination. The spatial aggregation level is specified in the 247 query context (e.g., PID to PID, or endpoint to endpoint). 249 Metric Representation: The metric value type is a single 'JSONNumber' 250 type value containing a non-negative integer component that may be 251 followed by an exponent part. See section 8.4.3 of [I-D.ietf-ippm- 252 initial-registry] for metric unit. The unit is expressed in 253 milliseconds in this document. 255 2.1.2. Use and Example 257 This metric could be used as a cost metric constraint attribute used 258 either together with cost metric attribute 'routingcost' or on its 259 own or as a returned cost metric in the response. 261 Example 1: Delay value on source-destination endpoint pairs 263 POST /endpointcost/lookup HTTP/1.1 264 Host: alto.example.com 265 Content-Length: TBA 266 Content-Type: application/alto-endpointcostparams+json 267 Accept: 268 application/alto-endpointcost+json,application/alto-error+json 270 { 271 "cost-type": {"cost-mode" : "numerical", 272 "cost-metric" : "owdelay"}, 273 "endpoints" : { 274 "srcs": [ "ipv4:192.0.2.2" ], 275 "dsts": [ 276 "ipv4:192.0.2.89", 277 "ipv4:198.51.100.34", 278 "ipv6:2000::1:2345:6789:abcd" 279 ] 280 } 281 } 282 HTTP/1.1 200 OK 283 Content-Length: TBA 284 Content-Type: application/alto-endpointcost+json 285 { 286 "meta" :{ 287 "cost-type": {"cost-mode" : "numerical", 288 "cost-metric" : "owdelay" 289 } 290 }, 291 "endpoint-cost-map" : { 292 "ipv4:192.0.2.2": { 293 "ipv4:192.0.2.89" : 10, 294 "ipv4:198.51.100.34" : 20, 295 "ipv6:2000::1:2345:6789:abcd" : 30, 296 } 297 } 298 } 300 2.1.3. Measurement Considerations 302 Method of Measurement or Calculation: 304 See section 8.3 of [I-D.ietf-ippm-initial-registry] for potential 305 measurement method. 307 Measurement Point(s) with Potential Measurement Domain: 309 See Section 4.1, Data sources for potential data sources. 311 Measurement Timing: 313 See section 8.3.5 of [I-D.ietf-ippm-initial-registry] for 314 potential measurement timing considerations. 316 2.2. Cost Metric: RoundTrip Time (rtt) 318 Metric name: 320 Round Trip Time 322 Metric Identifier: 324 rtt 326 2.2.1. Intended Semantics 328 Metric Description: To specify spatial and temporal aggregated round 329 trip delay between the specified source and destination or the time 330 that the packet spends to travel from source to destination and then 331 from destination to source. The spatial aggregation level is 332 specified in the query context (e.g., PID to PID, or endpoint to 333 endpoint). 335 Metric Representation: The metric value type is a single 'JSONNumber' 336 type value containing a non-negative integer component that may be 337 followed by an exponent part. See section 4.4.3 of [I-D.ietf-ippm- 338 initial-registry] for Measurement Unit. The unit is expressed in 339 milliseconds in this document. 341 2.2.2. Use and Example 343 This metric could be used as a cost metric constraint attribute used 344 either together with cost metric attribute 'routingcost' or on its 345 own or as a returned cost metric in the response. 347 Example 2: Roundtrip Delay value on source-destination endpoint pairs 349 POST /endpointcost/lookup HTTP/1.1 350 Host: alto.example.com 351 Content-Length: TBA 352 Content-Type: application/alto-endpointcostparams+json 353 Accept: 354 application/alto-endpointcost+json,application/alto-error+json 356 { 357 "cost-type": {"cost-mode" : "numerical", 358 "cost-metric" : "rtt"}, 359 "endpoints" : { 360 "srcs": [ "ipv4:192.0.2.2" ], 361 "dsts": [ 362 "ipv4:192.0.2.89", 363 "ipv4:198.51.100.34", 364 "ipv6:2000::1:2345:6789:abcd" 365 ] 366 } 367 } 368 HTTP/1.1 200 OK 369 Content-Length: TBA 370 Content-Type: application/alto-endpointcost+json 371 { 372 "meta" :{ 373 "cost-type": {"cost-mode" : "numerical", 374 "cost-metric" : "rtt" 375 } 376 }, 377 "endpoint-cost-map" : { 378 "ipv4:192.0.2.2": { 379 "ipv4:192.0.2.89" : 4, 380 "ipv4:198.51.100.34" : 3, 381 "ipv6:2000::1:2345:6789:abcd" : 2, 382 } 383 } 384 } 386 2.2.3. Measurement Considerations 388 Method of Measurement or Calculation: 390 See section 4.3 of [I-D.ietf-ippm-initial-registry] for potential 391 measurement method. 393 Measurement Point(s) with Potential Measurement Domain: 395 See section 4.1, Data sources. 397 Measurement Timing: 399 See section 4.3.5 of [I-D.ietf-ippm-initial-registry] for 400 Measurement Timing. 402 2.3. Cost Metric: Packet Delay Variation (pdv) 404 Metric name: 406 Packet Delay Variation 408 Metric Identifier: 410 pdv 412 2.3.1. Intended Semantics 414 Metric Description: To specify spatial and temporal aggregated jitter 415 (packet delay variation) with respect to the minimum delay observed 416 on the stream over the specified source and destination. The spatial 417 aggregation level is specified in the query context (e.g., PID to 418 PID, or endpoint to endpoint). 420 Metric Representation: The metric value type is a single 'JSONNumber' 421 type value containing a non-negative integer component that may be 422 followed by an exponent part. See section 5.4.4 of [I-D.ietf-ippm- 423 initial-registry] for Measurement Unit. The unit is expressed in 424 milliseconds in this document. 426 2.3.2. Use and Example 428 This metric could be used as a cost metric constraint attribute used 429 either together with cost metric attribute 'routingcost' or on its 430 own or as a returned cost metric in the response. 432 Example 3: PDV value on source-destination endpoint pairs 434 POST /endpointcost/lookup HTTP/1.1 435 Host: alto.example.com 436 Content-Length: TBA 437 Content-Type: application/alto-endpointcostparams+json 438 Accept: 439 application/alto-endpointcost+json,application/alto-error+json 441 { 442 "cost-type": {"cost-mode" : "numerical", 443 "cost-metric" : "pdv"}, 444 "endpoints" : { 445 "srcs": [ "ipv4:192.0.2.2" ], 446 "dsts": [ 447 "ipv4:192.0.2.89", 448 "ipv4:198.51.100.34", 449 "ipv6:2000::1:2345:6789:abcd" 450 ] 451 } 452 } 453 HTTP/1.1 200 OK 454 Content-Length: TBA 455 Content-Type: application/alto-endpointcost+json 456 { 457 "meta": { 458 "cost type": { 459 "cost-mode": "numerical", 460 "cost-metric":"delayjitter" 461 } 462 }, 463 "endpoint-cost-map": { 464 "ipv4:192.0.2.2": { 465 "ipv4:192.0.2.89" : 0 466 "ipv4:198.51.100.34" : 1 467 "ipv6:2000::1:2345:6789:abcd" : 5 468 } 469 } 470 } 472 2.3.3. Measurement Considerations 474 Method of Measurement or Calculation: 476 See Section 5.3 of [I-D.ietf-ippm-initial-registry] for potential 477 measurement method. 479 Measurement Point(s) with Potential Measurement Domain: 481 See Section 4.1, Data sources for potential data sources. 483 Measurement Timing: 485 See Section 5.3.5 of [I-D.ietf-ippm-initial-registry] for 486 Measurement Timing. 488 2.4. Cost Metric: Hop Count 490 The metric hopcount is mentioned in [RFC7285] Section 9.2.3 as an 491 example. This section further clarifies its properties. 493 Metric name: 495 Hop count 497 Metric Identifier: 499 hopcount 501 2.4.1. Intended Semantics 503 Metric Description: 505 To specify the number of hops in the path between the source 506 endpoint and the destination endpoint. The hop count is a basic 507 measurement of distance in a network and can be exposed as Router 508 Hops, in direct relation to the routing protocols originating this 509 information. 511 Metric Representation: 513 The metric value type is a single 'JSONNumber' type value 514 containing a non-negative integer component. The unit is integer 515 number. 517 2.4.2. Use and Example 519 This metric could be used as a cost metric constraint attribute used 520 either together with cost metric attribute 'routingcost' or on its 521 own or as a returned cost metric in the response. 523 Example 4: hopcount value on source-destination endpoint pairs 525 POST /endpointcost/lookup HTTP/1.1 526 Host: alto.example.com 527 Content-Length: TBA 528 Content-Type: application/alto-endpointcostparams+json 529 Accept: 530 application/alto-endpointcost+json,application/alto-error+json 532 { 533 "cost-type": {"cost-mode" : "numerical", 534 "cost-metric" : "hopcount"}, 535 "endpoints" : { 536 "srcs": [ "ipv4:192.0.2.2" ], 537 "dsts": [ 538 "ipv4:192.0.2.89", 539 "ipv4:198.51.100.34", 540 "ipv6:2000::1:2345:6789:abcd" 541 ] 542 } 543 } 545 HTTP/1.1 200 OK 546 Content-Length: TBA 547 Content-Type: application/alto-endpointcost+json 548 { 549 "meta": { 550 "cost type": { 551 "cost-mode": "numerical", 552 "cost-metric":"hopcount"} 553 } 554 }, 555 "endpoint-cost-map": { 556 "ipv4:192.0.2.2": { 557 "ipv4:192.0.2.89" : 5, 558 "ipv4:198.51.100.34": 3, 559 "ipv6:2000::1:2345:6789:abcd" : 2, 560 } 561 } 562 } 564 2.4.3. Measurement Considerations 566 Method of Measurement or Calculation: 568 The hop count can be calculated based on the number of routers 569 from the source endpoint through which data must pass to reach the 570 destination endpoint. 572 Measurement Point(s) with Potential Measurement Domain: 574 The hop count can be measured at the source endpoint by 575 traceroute. 577 Measurement Timing: 579 Upon need, the traceroute can use UDP probe message or other 580 implementations that use ICMP and TCP to discover the hop counts 581 along the path from source endpoint to destination endpoint. 583 2.5. Cost Metric: Packet Loss 585 Metric name: 587 Packet loss 589 Metric Identifier: 591 pktloss 593 2.5.1. Intended Semantics 595 Metric Description: 597 To specify spatial and temporal aggregated packet loss over the 598 specified source and destination. The spatial aggregation level 599 is specified in the query context (e.g., PID to PID, or endpoint 600 to endpoint). 602 Metric Representation: 604 The metric value type is a single 'JSONNumber' type value which be 605 be non-negative integer. The unit is percentile. 607 2.5.2. Use and Example 609 This metric could be used as a cost metric constraint attribute used 610 either together with cost metric attribute 'routingcost' or on its 611 own or as a returned cost metric in the response. 613 Example 5: pktloss value on source-destination endpoint pairs 615 POST /endpointcost/lookup HTTP/1.1 616 Host: alto.example.com 617 Content-Length: TBA 618 Content-Type: application/alto-endpointcostparams+json 619 Accept: 620 application/alto-endpointcost+json,application/alto-error+json 622 { 623 "cost-type": {"cost-mode" : "numerical", 624 "cost-metric" : "pktloss"}, 625 "endpoints" : { 626 "srcs": [ "ipv4:192.0.2.2" ], 627 "dsts": [ 628 "ipv4:192.0.2.89", 629 "ipv4:198.51.100.34", 630 "ipv6:2000::1:2345:6789:abcd" 631 ] 632 } 633 } 635 HTTP/1.1 200 OK 636 Content-Length: TBA 637 Content-Type: application/alto-endpointcost+json 638 { 639 "meta": { 640 "cost type": { 641 "cost-mode": "numerical", 642 "cost-metric":"pktloss"} 643 } 644 }, 645 "endpoint-cost-map": { 646 "ipv4:192.0.2.2": { 647 "ipv4:192.0.2.89" : 0, 648 "ipv4:198.51.100.34": 0, 649 "ipv6:2000::1:2345:6789:abcd" : 0, 650 } 651 } 652 } 654 2.5.3. Measurement Considerations 656 Method of Measurement or Calculation: 658 See Section 2.6 of [RFC7680] for Measurement Method. 660 Measurement Point(s) with Potential Measurement Domain: 662 See Section 4.1 this document, Data sources. 664 Measurement Timing: 666 See Section 2 and Section 3 of [RFC7680] for Measurement Timing. 668 2.6. Cost Metric: Throughput 670 Metric name: 672 Throughput 674 Metric Identifier: 676 throughput 678 2.6.1. Intended Semantics 680 Metric Description: 682 To specify spatial and temporal throughput over the specified 683 source and destination. The spatial aggregation level is 684 specified in the query context (e.g., PID to PID, or endpoint to 685 endpoint). 687 Metric Representation: 689 The unit is Mbps. 691 2.6.2. Use and Example 693 This metric could be used as a cost metric constraint attribute used 694 either together with cost metric attribute 'routingcost' or on its 695 own or as a returned cost metric in the response. 697 Example 5: throughtput value on source-destination endpoint pairs 699 POST /endpointcost/lookup HTTP/1.1 700 Host: alto.example.com 701 Content-Length: TBA 702 Content-Type: application/alto-endpointcostparams+json 703 Accept: 704 application/alto-endpointcost+json,application/alto-error+json 706 { 707 "cost-type": {"cost-mode" : "numerical", 708 "cost-metric" : "throughput"}, 709 "endpoints" : { 710 "srcs": [ "ipv4:192.0.2.2" ], 711 "dsts": [ 712 "ipv4:192.0.2.89", 713 "ipv4:198.51.100.34", 714 "ipv6:2000::1:2345:6789:abcd" 715 ] 716 } 717 } 718 HTTP/1.1 200 OK 719 Content-Length: TBA 720 Content-Type: application/alto-endpointcost+json 721 { 722 "meta": { 723 "cost type": { 724 "cost-mode": "numerical", 725 "cost-metric":"throughput" 726 } 727 } 728 "endpoint-cost-map": { 729 "ipv4:192.0.2.2": { 730 "ipv4:192.0.2.89" : 25.6, 731 "ipv4:198.51.100.34": 12.8, 732 "ipv6:2000::1:2345:6789:abcd" : 42.8, 733 } 734 } 736 2.6.3. Measurement Considerations 738 Method of Measurement or Calculation: 740 See Section 3.3 of [RFC6349] for Measurement Method. 742 Measurement Point(s) with Potential Measurement Domain: 744 See Section 4.1 of this document. 746 Measurement Timing: 748 Similar to RTT. See Section 4.3.5 of [I-D.ietf-ippm-initial- 749 registry] for Measurement Timing. 751 3. Traffic Engineering Performance Cost Metrics 753 This section introduces ALTO network performance metrics that may be 754 aggregated from network metrics measured on links and specified in 755 other documents. In particular, the bandwidth related metrics 756 specified in this section are only available through link level 757 measurements. For some of these metrics, the ALTO Server may further 758 expose aggregated values while specifying the aggregation laws. 760 3.1. Cost Metric: Link Maximum Reservable Bandwidth 762 Metric name: 764 Maximum Reservable Bandwidth 766 Metric Identifier: 768 maxresbw 770 3.1.1. Intended Semantics 772 Metric Description: 774 To specify spatial and temporal maximum reservable bandwidth over 775 the specified source and destination. The value is corresponding 776 to the maximum bandwidth that can be reserved (motivated from RFC 777 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 778 the query context (e.g., PID to PID, or endpoint to endpoint). 780 Metric Representation: 782 The metric value type is a single 'JSONNumber' type value that is 783 non-negative. The unit of measurement is mbps. 785 3.1.2. Use and Example 787 This metric could be used as a cost metric constraint attribute used 788 either together with cost metric attribute 'routingcost' or on its 789 own or as a returned cost metric in the response. 791 Example 6: maxresbw value on source-destination endpoint pairs 793 POST/ endpointcost/lookup HTTP/1.1 794 Host: alto.example.com 795 Content-Length: TBA 796 Content-Type: application/alto-endpointcostparams+json 797 Accept: 798 application/alto-endpointcost+json,application/alto-error+json 800 { 801 "cost-type" { "cost-mode": "numerical", 802 "cost-metric": "maxresbw"}, 803 "endpoints": { 804 "srcs": [ "ipv4 : 192.0.2.2" ], 805 "dsts": [ 806 "ipv4:192.0.2.89", 807 "ipv4:198.51.100.34", 808 "ipv6:2000::1:2345:6789:abcd" 809 ] 810 } 811 } 813 HTTP/1.1 200 OK 814 Content-Length: TBA 815 Content-Type: application/alto-endpointcost+json 816 { 817 "meta": { 818 "cost-type": { 819 "cost-mode": "numerical", 820 "cost-metric": "maxresbw" 821 } 822 }, 823 " endpoint-cost-map": { 824 "ipv4:192.0.2.2" { 825 "ipv4:192.0.2.89" : 0, 826 "ipv4:198.51.100.34": 2000, 827 "ipv6:2000::1:2345:6789:abcd": 5000, 828 } 829 } 830 } 832 3.1.3. Measurement Considerations 834 Method of Measurement or Calculation: 836 Maximum Reservable Bandwidth is the bandwidth measured between two 837 directly connected IS-IS neighbors or OSPF neighbors. See 838 Section 3.5 of [RFC5305] for Measurement Method. 840 Measurement Point(s) with Potential Measurement Domain: 842 See Section 4.1 this document for discussions. 844 Measurement Timing: 846 See Section 3.5 of [RFC5305] and Section 5 of [RFC7810] for 847 Measurement Timing. 849 3.2. Cost Metric: Link Residue Bandwidth 851 Metric name: 853 Residue Bandwidth 855 Metric Identifier: 857 residuebw 859 3.2.1. Intended Semantics 861 Metric Description: 863 To specify spatial and temporal residual bandwidth over the 864 specified source and destination. The value is calculated by 865 subtracting tunnel reservations from Maximum Bandwidth (motivated 866 from [RFC7810], Section 4.5.). The spatial aggregation unit is 867 specified in the query context (e.g., PID to PID, or endpoint to 868 endpoint). 870 Metric Representation: 872 The metric value type is a single 'JSONNumber' type value that is 873 non-negative. The unit of measurement is mbps. 875 3.2.2. Use and Example 877 This metric could be used as a cost metric constraint attribute used 878 either together with cost metric attribute 'routingcost' or on its 879 own or as a returned cost metric in the response. 881 Example 7: residuebw value on source-destination endpoint pairs 883 POST/ endpointcost/lookup HTTP/1.1 884 Host: alto.example.com 885 Content-Length: TBA 886 Content-Type: application/alto-endpointcostparams+json 887 Accept: 888 application/alto-endpointcost+json,application/alto-error+json 890 { 891 "cost-type": { "cost-mode": "numerical", 892 "cost-metric": "residuebw"}, 893 "endpoints": { 894 "srcs": [ "ipv4 : 192.0.2.2" ], 895 "dsts": [ 896 "ipv4:192.0.2.89", 897 "ipv4:198.51.100.34", 898 "ipv6:2000::1:2345:6789:abcd" 899 ] 900 } 901 } 903 HTTP/1.1 200 OK 904 Content-Length: TBA 905 Content-Type: application/alto-endpointcost+json 906 { 907 "meta": { 908 "cost-type" { 909 "cost-mode": "numerical", 910 "cost-metric": "residuebw" 911 } 912 }, 913 "endpoint-cost-map" { 914 "ipv4:192.0.2.2" { 915 "ipv4:192.0.2.89" : 0, 916 "ipv4:198.51.100.34": 2000, 917 "ipv6:2000::1:2345:6789:abcd": 5000, 918 } 919 } 920 } 922 3.2.3. Measurement Considerations 924 Method of Measurement or Calculation: 926 Residue Bandwidth is the Unidirectional Residue bandwidth measured 927 between two directly connected IS-IS neighbors or OSPF neighbors. 928 See Section 4.5 of [RFC7810] for Measurement Method. 930 Measurement Point(s) with Potential Measurement Domain: 932 See Section 4.1 of this document. 934 Measurement Timing: 936 See Section 5 of [RFC7810] for Measurement Timing. 938 4. Operational Considerations 940 It can be non-trivial for an ALTO server to derive the metrics. 941 Also, the exact infrastructure and algorithms can vary from different 942 networks, and are outside the scope of this document. However, since 943 they present challenges, we discuss these common challenges. 945 Also, the performance metrics specified in this document are similar, 946 in that they may use similar data sources and have similar issues in 947 their calculation. Hence, we specify common issues unless one metric 948 has its unique challenges. 950 4.1. Data Source Considerations 952 An ALTO server needs data sources to compute the cost metrics 953 described in this document. This document does not define the exact 954 data sources. For example, the ALTO server may use log servers or 955 the OAM system as its data source [RFC7971]. In particular, the cost 956 metrics defined in this document can be computed using routing 957 systems as the data sources. Mechanisms defined in [RFC2681], 958 [RFC3393], [RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471], 959 [RFC7810], [RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO 960 Server to retrieve and derive the necessary information to compute 961 the metrics that we describe in this document. 963 One challenge lies in the data sources originating the ALTO metric 964 values. The very important purpose of ALTO is to guide application 965 traffic with provider network centric information that may be exposed 966 to ALTO Clients in the form of network performance metric values. 967 Not all of these metrics have values produced by standardized 968 measurement methods or routing protocols. Some of them involve 969 provider-centric policy considerations. Some of them may describe 970 wireless or cellular networks. To reliably guide users and 971 applications while preserving provider privacy, ALTO performance 972 metric values may also add abstraction to measurements or provide 973 unitless performance scores. 975 4.2. Computation Considerations 977 The metric values exposed by an ALTO server may result from 978 additional processing on measurements from data sources to compute 979 exposed metrics. This may involve data processing tasks such as 980 aggregating the results across multiple systems, removing outliers, 981 and creating additional statistics. There are two challenges on the 982 computation of ALTO performance metrics. 984 4.2.1. Configuration Parameters Considerations 986 Performance metrics often depend on configuration parameters. For 987 example, the value of packet loss rate depends on the measurement 988 interval and varies over time. To handle this issue, an ALTO server 989 may collect data on time periods covering the previous and current 990 time or only collect data on present time. The ALTO server may 991 further aggregate these data to provide an abstract and unified view 992 that can be more useful to applications. To make the ALTO client 993 better understand how to use these performance data, the ALTO server 994 may provide the client with the validity period of the exposed metric 995 values. 997 4.2.2. Availability Considerations 999 Applications value information relating to bandwidth availability 1000 whereas bandwidth related metrics can often be only measured at the 1001 link level. This document specifies a set of link-level bandwidth 1002 related values that may be exposed as such by an ALTO server. The 1003 server may also expose other metrics derived from their aggregation 1004 and having different levels of endpoint granularity, e.g., link 1005 endpoints or session endpoints. The metric specifications may also 1006 expose the utilized aggregation laws. 1008 5. Security Considerations 1010 The properties defined in this document present no security 1011 considerations beyond those in Section 15 of the base ALTO 1012 specification [RFC7285]. 1014 However concerns addressed in Sections "15.1 Authenticity and 1015 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 1016 from Authenticated ALTO Information" and "15.3 Confidentiality of 1017 ALTO Information" remain of utmost importance. Indeed, TE 1018 performance is a highly sensitive ISP information, therefore, sharing 1019 TE metric values in numerical mode requires full mutual confidence 1020 between the entities managing the ALTO Server and Client. Numerical 1021 TE performance information will most likely be distributed by ALTO 1022 Servers to Clients under strict and formal mutual trust agreements. 1024 On the other hand, ALTO Clients must be cognizant on the risks 1025 attached to such information that they would have acquired outside 1026 formal conditions of mutual trust. 1028 6. IANA Considerations 1030 IANA has created and now maintains the "ALTO Cost Metric Registry", 1031 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1032 located at . This document requests to add the 1034 following entries to "ALTO Cost Metric Registry". 1036 +------------+--------------------+ 1037 | Identifier | Intended Semantics | 1038 +------------+--------------------+ 1039 | owdelay | See Section 2.1 | 1040 | rtt | See Section 2.2 | 1041 | pdv | See Section 2.3 | 1042 | hopcount | See Section 2.4 | 1043 | pktloss | See Section 2.5 | 1044 | throughput | See Section 2.6 | 1045 | maxresbw | See Section 3.1 | 1046 | residuebw | See Section 3.2 | 1047 +------------+--------------------+ 1049 7. Acknowledgments 1051 The authors of this document would also like to thank Brian Trammell, 1052 Haizhou Du, Kai Gao, Lili Liu, Li, Geng, Danny Alex Lachos Perez for 1053 the reviews and comments. 1055 8. References 1057 8.1. Normative References 1059 [I-D.ietf-idr-te-pm-bgp] 1060 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 1061 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 1062 Performance Metric Extensions", draft-ietf-idr-te-pm- 1063 bgp-18 (work in progress), December 2018. 1065 [I-D.ietf-ippm-initial-registry] 1066 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 1067 "Initial Performance Metrics Registry Entries", draft- 1068 ietf-ippm-initial-registry-11 (work in progress), March 1069 2019. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", March 1997. 1074 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1075 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1076 September 1999, . 1078 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1079 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1080 September 1999, . 1082 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1083 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1084 10.17487/RFC3393, November 2002, . 1087 [RFC4627] Crockford, D., "The application/json Media Type for 1088 JavaScript Object Notation (JSON)", RFC 4627, DOI 1089 10.17487/RFC4627, July 2006, . 1092 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1093 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1094 RFC5234, January 2008, . 1097 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1098 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1099 2008, . 1101 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1102 "Framework for TCP Throughput Testing", RFC 6349, DOI 1103 10.17487/RFC6349, August 2011, . 1106 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1107 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1108 "Application-Layer Traffic Optimization (ALTO) Protocol", 1109 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1110 . 1112 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1113 Previdi, "OSPF Traffic Engineering (TE) Metric 1114 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1115 . 1117 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1118 Ed., "A One-Way Delay Metric for IP Performance Metrics 1119 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1120 2016, . 1122 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1123 Ed., "A One-Way Loss Metric for IP Performance Metrics 1124 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1125 2016, . 1127 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1128 S. Ray, "North-Bound Distribution of Link-State and 1129 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1130 DOI 10.17487/RFC7752, March 2016, . 1133 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1134 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1135 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1136 . 1138 8.2. Informative References 1140 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 1141 Development", RFC 6390, July 2011. 1143 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1144 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1145 Deployment Considerations", RFC 7971, DOI 10.17487/ 1146 RFC7971, October 2016, . 1149 Authors' Addresses 1151 Qin Wu 1152 Huawei 1153 101 Software Avenue, Yuhua District 1154 Nanjing, Jiangsu 210012 1155 China 1157 Email: bill.wu@huawei.com 1158 Y. Richard Yang 1159 Yale University 1160 51 Prospect St 1161 New Haven, CT 06520 1162 USA 1164 Email: yry@cs.yale.edu 1166 Young Lee 1167 Huawei 1168 1700 Alma Drive, Suite 500 1169 Plano, TX 75075 1170 USA 1172 Email: leeyoung@huawei.com 1174 Dhruv Dhody 1175 Huawei 1176 Leela Palace 1177 Bangalore, Karnataka 560008 1178 INDIA 1180 Email: dhruv.ietf@gmail.com 1182 Sabine Randriamasy 1183 Nokia Bell Labs 1184 Route de Villejust 1185 Nozay 91460 1186 FRANCE 1188 Email: sabine.randriamasy@nokia-bell-labs.com