idnits 2.17.1 draft-ietf-alto-performance-metrics-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [ALTO]), 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 (October 21, 2018) is 2013 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: 'ALTO' is mentioned on line 881, but not defined == Missing Reference: 'ALTO-DEPLOYMENT' is mentioned on line 194, but not defined == Missing Reference: 'RFC3630' is mentioned on line 197, but not defined == Missing Reference: 'RFC3784' is mentioned on line 197, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'BGP-PM' is mentioned on line 198, but not defined == Unused Reference: 'I-D.ietf-idr-te-pm-bgp' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1006, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-14 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-07 ** 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 (~~), 13 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: April 24, 2019 Yale University 6 Y. Lee 7 D. Dhody 8 Huawei 9 S. Randriamasy 10 Nokia Bell Labs 11 October 21, 2018 13 ALTO Performance Cost Metrics 14 draft-ietf-alto-performance-metrics-05 16 Abstract 18 Cost Metric is a basic concept in Application-Layer Traffic 19 Optimization (ALTO). It is used in both the Cost Map Service and the 20 Endpoint Cost Service. 22 Different applications may benefit from different Cost Metrics. For 23 example, a Resource Consumer may prefer Resource Providers that offer 24 a low delay delivery to the Resource Consumer. However the base ALTO 25 protocol [ALTO] has documented only one single cost metric, i.e., the 26 generic "routingcost" metric (Sec. 14.2 of ALTO base specification 27 [ALTO]). 29 This document, proposes a set of Cost Metrics, derived and aggregated 30 from routing protocols with different granularity and scope, such as 31 BGP-LS,OSPF-TE and ISIS-TE, or from end-to-end traffic management 32 tools. It currently documents Network Performance Cost Metrics 33 reporting on network delay, jitter, packet loss, hop count, and 34 bandwidth. These metrics may be exposed by an ALTO Server to allow 35 applications to determine "where" to connect based on network 36 performance criteria. Additional Cost Metrics involving ISP specific 37 considerations or other network technologies may be documented in 38 further versions of this draft. 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 https://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 April 24, 2019. 62 Copyright Notice 64 Copyright (c) 2018 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 (https://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. Challenges on data sources and computation of ALTO 81 performance metrics . . . . . . . . . . . . . . . . . . . . . 5 82 2.1. Data sources Challenge . . . . . . . . . . . . . . . . . 5 83 2.2. ALTO performance metrics Computation Challenges . . . . . 5 84 2.2.1. Configuration Parameters Challenge . . . . . . . . . 5 85 2.2.2. Availability of end to end path values Challenge . . 6 86 3. Cost Metric: OWDelay . . . . . . . . . . . . . . . . . . . . 6 87 4. Cost Metric: RTT . . . . . . . . . . . . . . . . . . . . . . 8 88 5. Cost Metric: PDV . . . . . . . . . . . . . . . . . . . . . . 10 89 6. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . . . 12 90 7. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . . . 14 91 8. Cost Metric: Throughput . . . . . . . . . . . . . . . . . . . 16 92 9. Traffic Engineering Performance Cost Metrics . . . . . . . . 18 93 9.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 19 94 9.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 20 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 99 12.2. Informative References . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 Cost Metric is a basic concept in Application-Layer Traffic 105 Optimization (ALTO). It is used in both the Cost Map Service and the 106 Endpoint Cost Service. In particular, applications may benefit from 107 knowing network performance measured on several Cost Metrics. For 108 example, a more delay-sensitive application may focus on latency, and 109 a more bandwidth-sensitive application may focus on available 110 bandwidth. 112 This document introduces a set of new cost metrics, listed in 113 Table 1, to support the aforementioned applications and allow them to 114 determine "where" to connect based on network performance criteria. 115 Hence, this document extends the base ALTO protocol [ALTO], which 116 defines only a single cost metric, i.e., the generic "routingcost" 117 metric (Sec. 14.2 of ALTO base specification [ALTO]). 119 +----------+--------------+----------------------------------------+ 120 |Namespace | Property | Reference | 121 +----------+--------------+----------------------------------------+ 122 | | owdelay | See Section 3,[RFC2679] Section 3.6 | 123 | | rtt | See Section 4,[RFC2681] Section 2.6 | 124 | | pdv | See Section 5,[RFC3393] Section 2.6 | 125 | | hopcount | See Section 6,[RFC7285] | 126 | | pktloss | See Section 7,[RFC7680] Section 2.6 | 127 | | throughput | See Section x, [RFC6349] Section 3.3 | 128 | | maxresbw | See Section 8.1,[RFC5305] Section 3.5 | 129 | | residbw | See Section 8.2,[RFC7810] Section 4.5 | 130 +----------+--------------+----------------------------------------+ 131 Table 1. 133 The purpose of this draft is to list the metrics likely to be exposed 134 to ALTO Clients, including those already specified in other 135 standardization groups and as such it does not claim novelty on all 136 the specified metrics. Some metrics may have values produced by 137 standard measurement methods such as those specified in IPPM, some 138 may be ISP dependent such as those registered in ISIS or OSPF-TE. In 139 this case, this document will refer to the relevant specifications. 141 An ALTO server may provide a subset of the cost metrics described in 142 this document. These cost metrics can be retrieved and aggregated 143 from routing protocols or other traffic measurement management tools 144 (See Figure 1). Note that these cost metrics are optional and not 145 all them need to be exposed to applications. For example, those that 146 are subject to privacy concerns should not be provided to 147 unauthorized ALTO clients. 149 +--------+ +--------+ +--------+ 150 | Client | | Client | | Client | 151 +----^---+ +---^----+ +---^----+ 152 | | | 153 +-----------|-----------+ 154 NBI |ALTO protocol 155 | 156 | 157 +--+-----+ retrieval +---------+ 158 | ALTO |<----------------| Routing | 159 | Server | and aggregation| | 160 | |<-------------+ | Protocol| 161 +--------+ | +---------+ 162 | 163 | +---------+ 164 | |Management 165 ---| | 166 | Tool | 167 +---------+ 168 Figure 1.End-to-End Path Cost Metrics Exposing 170 When an ALTO server supports a cost metric defined in this document, 171 it MUST announce this metric in its IRD. 173 Additionally, future versions of this document may define network 174 metric values that stem from both measurements and provider policies 175 such as many metrics related to end-to-end path bandwidth. 177 As for the reliability and trust in the exposed metric values, 178 applications SHOULD rapidly give up using ALTO-based guidance if they 179 feel the exposed information does not preserve their performance 180 level or even degrades it. 182 Following the ALTO base protocol, this document uses JSON to specify 183 the value type of each defined metric. See [RFC4627] for JSON data 184 type specification. 186 2. Challenges on data sources and computation of ALTO performance 187 metrics 189 2.1. Data sources Challenge 191 An ALTO server needs data sources to compute the cost metrics 192 described in this document. This document does not define the exact 193 data sources. For example, the ALTO server may use log servers or 194 the OAM system as its data source [ALTO-DEPLOYMENT]. In particular, 195 the cost metrics defined in this document can be computed using 196 routing systems as the data sources. Mechanisms defined in 197 [RFC2681],[RFC3393],[RFC7679],[RFC7680],[RFC3630], [RFC3784], 198 [RFC7471], [RFC7810], [RFC7752] and [BGP-PM] that allow an ALTO 199 Server to retrieve and derive the necessary information to compute 200 the metrics that we describe in this document. 202 One challenge lies in the data sources originating the ALTO metric 203 values. The very important purpose of ALTO is to guide application 204 traffic with provider network centric information that may be exposed 205 to ALTO Clients in the form of network performance metric values. 206 Not all of these metrics have values produced by standardized 207 measurement methods or routing protocols. Some of them involve 208 provider-centric policy considerations. Some of them may describe 209 wireless or cellular networks. To reliably guide users and 210 applications while preserving provider privacy, ALTO performance 211 metric values may also add abstraction to measurements or provide 212 unitless performance scores. 214 2.2. ALTO performance metrics Computation Challenges 216 The metric values exposed by an ALTO server may result from 217 additional processing on measurements from data sources to compute 218 exposed metrics. This may involve data processing tasks such as 219 aggregating the results across multiple systems, removing outliers, 220 and creating additional statistics. There are two challenges on 221 computation of ALTO performance metrics. 223 2.2.1. Configuration Parameters Challenge 225 Performance metrics often depend on configuration parameters. For 226 example, the value of packet loss rate depends on the measurement 227 interval and varies over time. To handle this issue, an ALTO server 228 may collect data on time periods covering the previous and current 229 time or only collect data on present time. The ALTO server may 230 further aggregate these data to provide an abstract and unified view 231 that can be more useful to applications. To make the ALTO client 232 better understand how to use these performance data, the ALTO server 233 may provide the client with the validity period of the exposed metric 234 values. 236 2.2.2. Availability of end to end path values Challenge 238 Applications value information relating to bandwidth availability 239 where as bandwidth related metrics can often be only measured at the 240 link level. This document specifies a set of link-level bandwidth 241 related values that may be exposed as such by an ALTO server. The 242 server may also expose other metrics derived from their aggregation 243 and having different levels of endpoint granularity, e.g. link 244 endpoints or session endpoints. The metric specifications may also 245 expose the utilized aggregation laws. 247 3. Cost Metric: OWDelay 249 Metric name: 251 One Way Delay 253 Metric Description: 255 To specify spatial and temporal aggregated delay of a stream of 256 packets exchanged between the specified source and destination or 257 the time that the packet spends to travel from source to 258 destination. The spatial aggregation level is specified in the 259 query context (e.g., PID to PID, or endpoint to endpoint). 261 Method of Measurement or Calculation: 263 See section 8.3 of [I-D.ietf-ippm-initial-registry] for 264 Measurement Method. 266 Units of Measurement: 268 See section 8.4.3 of [I-D.ietf-ippm-initial-registry] for 269 Measurement Unit. The unit is expressed in milliseconds in this 270 document. 272 Measurement Point(s) with Potential Measurement Domain: 274 See section 2.1, Data sources. 276 Measurement Timing: 278 See section 8.3.5 of [I-D.ietf-ippm-initial-registry] for 279 Measurement Timing. 281 Use and Applications: 283 The Metric value Type is a single 'JSONNumber' type value 284 containing a non-negative integer component that may be followed 285 by an exponent part. The Cost Mode is encoded as a US-ASCII 286 string. 288 This metric could be used as a cost metric constraint attribute 289 used either together with cost metric attribute 'routingcost' or 290 on its own or as a returned cost metric in the response. 292 Example 1: Delay value on source-destination endpoint pairs 294 POST /endpointcost/lookup HTTP/1.1 295 Host: alto.example.com 296 Content-Length: TBA 297 Content-Type: application/alto-endpointcostparams+json 298 Accept: application/alto-endpointcost+json,application/alto-error+json 300 { 301 "cost-type": {"cost-mode" : "numerical", 302 "cost-metric" : "owdelay"}, 303 "endpoints" : { 304 "srcs": [ "ipv4:192.0.2.2" ], 305 "dsts": [ 306 "ipv4:192.0.2.89", 307 "ipv4:198.51.100.34", 308 "ipv6:2000::1:2345:6789:abcd" 309 ] 310 } 311 } 312 HTTP/1.1 200 OK 313 Content-Length: TBA 314 Content-Type: application/alto-endpointcost+json 315 { 316 "meta" :{ 317 "cost-type": {"cost-mode" : "numerical", 318 "cost-metric" : "owdelay" 319 } 320 }, 321 "endpoint-cost-map" : { 322 "ipv4:192.0.2.2": { 323 "ipv4:192.0.2.89" : 10, 324 "ipv4:198.51.100.34" : 20, 325 "ipv6:2000::1:2345:6789:abcd" : 30, 326 } 327 } 328 } 330 4. Cost Metric: RTT 332 Metric name: 334 Round Trip Delay 336 Metric Description: 338 To specify spatial and temporal aggregated round trip delay 339 between the specified source and destination or the time that the 340 packet spends to travel from source to destination and then from 341 destination to source. The spatial aggregation level is specified 342 in the query context (e.g., PID to PID, or endpoint to endpoint). 344 Method of Measurement or Calculation: 346 See section 4.3 of [I-D.ietf-ippm-initial-registry] for 347 Measurement Method. 349 Units of Measurement: 351 See section 4.4.3 of [I-D.ietf-ippm-initial-registry] for 352 Measurement Unit. The unit is expressed in milliseconds in this 353 document. 355 Measurement Point(s) with Potential Measurement Domain: 357 See section 2.1, Data sources. 359 Measurement Timing: 361 See section 4.3.5 of [I-D.ietf-ippm-initial-registry] for 362 Measurement Timing. 364 Use and Applications: 366 See section 3 for use and application. 368 Example 2: Round Trip Delay value on source-destination endpoint pairs 370 POST /endpointcost/lookup HTTP/1.1 371 Host: alto.example.com 372 Content-Length: TBA 373 Content-Type: application/alto-endpointcostparams+json 374 Accept: application/alto-endpointcost+json,application/alto-error+json 376 { 377 "cost-type": {"cost-mode" : "numerical", 378 "cost-metric" : "rtt"}, 379 "endpoints" : { 380 "srcs": [ "ipv4:192.0.2.2" ], 381 "dsts": [ 382 "ipv4:192.0.2.89", 383 "ipv4:198.51.100.34", 384 "ipv6:2000::1:2345:6789:abcd" 385 ] 386 } 387 } 388 HTTP/1.1 200 OK 389 Content-Length: TBA 390 Content-Type: application/alto-endpointcost+json 391 { 392 "meta" :{ 393 "cost-type": {"cost-mode" : "numerical", 394 "cost-metric" : "rtt" 395 } 396 }, 397 "endpoint-cost-map" : { 398 "ipv4:192.0.2.2": { 399 "ipv4:192.0.2.89" : 4, 400 "ipv4:198.51.100.34" : 3, 401 "ipv6:2000::1:2345:6789:abcd" : 2, 402 } 403 } 404 } 406 5. Cost Metric: PDV 408 Metric name: 410 Packet Delay Variation 412 Metric Description: 414 To specify spatial and temporal aggregated jitter (packet delay 415 variation) with respect to the minimum delay observed on the 416 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 Method of Measurement or Calculation: 422 See section 5.3 of [I-D.ietf-ippm-initial-registry] for 423 Measurement Method. 425 Units of Measurement: 427 See section 5.4.4 of [I-D.ietf-ippm-initial-registry] for 428 Measurement Unit. The unit is expressed in milliseconds in this 429 document. 431 Measurement Point(s) with Potential Measurement Domain: 433 See section 2.1, Data sources. 435 Measurement Timing: 437 See section 5.3.5 of [I-D.ietf-ippm-initial-registry] for 438 Measurement Timing. 440 Use and Applications: 442 See section 3 for use and application. 444 Example 3: PDV value on source-destination endpoint pairs 446 POST /endpointcost/lookup HTTP/1.1 447 Host: alto.example.com 448 Content-Length: TBA 449 Content-Type: application/alto-endpointcostparams+json 450 Accept: application/alto-endpointcost+json,application/alto-error+json 452 { 453 "cost-type": {"cost-mode" : "numerical", 454 "cost-metric" : "pdv"}, 455 "endpoints" : { 456 "srcs": [ "ipv4:192.0.2.2" ], 457 "dsts": [ 458 "ipv4:192.0.2.89", 459 "ipv4:198.51.100.34", 460 "ipv6:2000::1:2345:6789:abcd" 461 ] 462 } 463 } 464 HTTP/1.1 200 OK 465 Content-Length: TBA 466 Content-Type: application/alto-endpointcost+json 467 { 468 "meta": { 469 "cost type": { 470 "cost-mode": "numerical", 471 "cost-metric":"delayjitter" 472 } 473 }, 474 "endpoint-cost-map": { 475 "ipv4:192.0.2.2": { 476 "ipv4:192.0.2.89" : 0 477 "ipv4:198.51.100.34" : 1 478 "ipv6:2000::1:2345:6789:abcd" : 5 479 } 480 } 481 } 483 6. Cost Metric: Hop Count 485 The metric hopcount is mentioned in [ALTO] as an example. This 486 section further clarifies its properties. 488 Metric name: 490 Hop count 492 Metric Description: 494 To specify the number of hops in the path between the source 495 endpoint and the destination endpoint. The hop count is a basic 496 measurement of distance in a network and can be exposed as Router 497 Hops, IP hops in direct relation to the routing protocols 498 originating this information. It might also result from the 499 aggregation of such information. 501 Method of Measurement or Calculation: 503 The hop count can and calculated based on the number of routers 504 from the source endpoint through which data must pass to reach the 505 destination endpoint. 507 Units of Measurement: 509 The unit is integer number. 511 Measurement Point(s) with Potential Measurement Domain: 513 The hop count can be measured at the source endpoint by 514 traceroute. 516 Measurement Timing: 518 Upon need, the traceroute can use UDP probe message or other 519 implementations that use ICMP and TCP to discover the hop counts 520 along the path from source endpoint to destination endpoint. 522 Use and Applications: 524 See section 3 for use and application. 526 Example 4: hopcount value on source-destination endpoint pairs 528 POST /endpointcost/lookup HTTP/1.1 529 Host: alto.example.com 530 Content-Length: TBA 531 Content-Type: application/alto-endpointcostparams+json 532 Accept: application/alto-endpointcost+json,application/alto-error+json 534 { 535 "cost-type": {"cost-mode" : "numerical", 536 "cost-metric" : "hopcount"}, 537 "endpoints" : { 538 "srcs": [ "ipv4:192.0.2.2" ], 539 "dsts": [ 540 "ipv4:192.0.2.89", 541 "ipv4:198.51.100.34", 542 "ipv6:2000::1:2345:6789:abcd" 543 ] 544 } 545 } 547 HTTP/1.1 200 OK 548 Content-Length: TBA 549 Content-Type: application/alto-endpointcost+json 550 { 551 "meta": { 552 "cost type": { 553 "cost-mode": "numerical", 554 "cost-metric":"hopcount"} 555 } 556 }, 557 "endpoint-cost-map": { 558 "ipv4:192.0.2.2": { 559 "ipv4:192.0.2.89" : 5, 560 "ipv4:198.51.100.34": 3, 561 "ipv6:2000::1:2345:6789:abcd" : 2, 562 } 563 } 564 } 566 7. Cost Metric: Packet Loss 568 Metric name: 570 Packet loss 572 Metric Description: 574 To specify spatial and temporal aggregated packet loss over the 575 specified source and destination. The spatial aggregation level 576 is specified in the query context (e.g., PID to PID, or endpoint 577 to endpoint). 579 Method of Measurement or Calculation: 581 See section 2.6 of [RFC7680] for Measurement Method. 583 Units of Measurement: 585 The unit is percentile. 587 Measurement Point(s) with Potential Measurement Domain: 589 See section 2.1, Data sources. 591 Measurement Timing: 593 See section 2 and section3 of [RFC7680] for Measurement Timing. 595 Use and Applications: 597 See section 3 for use and application. 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: application/alto-endpointcost+json,application/alto-error+json 607 { 608 "cost-type": {"cost-mode" : "numerical", 609 "cost-metric" : "pktloss"}, 610 "endpoints" : { 611 "srcs": [ "ipv4:192.0.2.2" ], 612 "dsts": [ 613 "ipv4:192.0.2.89", 614 "ipv4:198.51.100.34", 615 "ipv6:2000::1:2345:6789:abcd" 616 ] 617 } 618 } 620 HTTP/1.1 200 OK 621 Content-Length: TBA 622 Content-Type: application/alto-endpointcost+json 623 { 624 "meta": { 625 "cost type": { 626 "cost-mode": "numerical", 627 "cost-metric":"pktloss"} 628 } 629 }, 630 "endpoint-cost-map": { 631 "ipv4:192.0.2.2": { 632 "ipv4:192.0.2.89" : 0, 633 "ipv4:198.51.100.34": 0, 634 "ipv6:2000::1:2345:6789:abcd" : 0, 635 } 636 } 637 } 639 8. Cost Metric: Throughput 641 Metric name: 643 Throughput 645 Metric Description: 647 To specify spatial and temporal throughput over the specified 648 source and destination. The spatial aggregation level is 649 specified in the query context (e.g., PID to PID, or endpoint to 650 endpoint). 652 Method of Measurement or Calculation: 654 See section 3.3 of [RFC6349] for Measurement Method. 656 Units of Measurement: 658 The unit is Mbps. 660 Measurement Point(s) with Potential Measurement Domain: 662 See section 2.1, Data sources. 664 Measurement Timing: 666 Similar to RTT,See section 4.3.5 of [I-D.ietf-ippm-initial- 667 registry] for Measurement Timing. 669 Use and Applications: 671 See section 3 for use and application. 673 Example 5: throughtput value on source-destination endpoint pairs 675 POST /endpointcost/lookup HTTP/1.1 676 Host: alto.example.com 677 Content-Length: TBA 678 Content-Type: application/alto-endpointcostparams+json 679 Accept: application/alto-endpointcost+json,application/alto-error+json 681 { 682 "cost-type": {"cost-mode" : "numerical", 683 "cost-metric" : "throughput"}, 684 "endpoints" : { 685 "srcs": [ "ipv4:192.0.2.2" ], 686 "dsts": [ 687 "ipv4:192.0.2.89", 688 "ipv4:198.51.100.34", 689 "ipv6:2000::1:2345:6789:abcd" 690 ] 691 } 692 } 693 } 695 HTTP/1.1 200 OK 696 Content-Length: TBA 697 Content-Type: application/alto-endpointcost+json 698 { 699 "meta": { 700 "cost type": { 701 "cost-mode": "numerical", 702 "cost-metric":"throughput"} 703 } 704 }, 705 "endpoint-cost-map": { 706 "ipv4:192.0.2.2": { 707 "ipv4:192.0.2.89" : 25.6, 708 "ipv4:198.51.100.34": 12.8, 709 "ipv6:2000::1:2345:6789:abcd" : 42.8, 710 } 711 } 712 } 714 9. Traffic Engineering Performance Cost Metrics 716 This section introduces ALTO network performance metrics that may be 717 aggregated from network metrics measured on links and specified in 718 other documents. In particular, the bandwidth related metrics 719 specified in this section are only available through link level 720 measurements. For some of these metrics, the ALTO Server may further 721 expose aggregated values while specifying the aggregation laws. 723 9.1. Cost Metric: Link Maximum Reservable Bandwidth 725 Metric name: 727 Maximum Reservable Bandwidth 729 Metric Description: 731 To specify spatial and temporal maximum reservable bandwidth over 732 the specified source and destination. The value is corresponding 733 to the maximum bandwidth that can be reserved (motivated from RFC 734 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 735 the query context (e.g., PID to PID, or endpoint to endpoint). 737 Method of Measurement or Calculation: 739 Maximum Reserveable Bandwidth is the bandwidth measured between 740 two directly connected IS-IS neighbors or OSPF neighbors, See 741 section 3.5 of [RFC5305] for Measurement Method. 743 Units of Measurement: 745 The unit of measurement is byte per seconds. 747 Measurement Point(s) with Potential Measurement Domain: 749 See section 2.1, Data sources. 751 Measurement Timing: 753 See section 3.5 of [RFC5305] and section 5 of [RFC7810] for 754 Measurement Timing. 756 Use and Applications: 758 See section 3 for use and application. 760 Example 6: maxresbw value on source-destination endpoint pairs 762 POST/ endpointcost/lookup HTTP/1.1 763 Host: alto.example.com 764 Content-Length: TBA 765 Content-Type: application/alto-endpointcostparams+json 766 Accept: application/alto-endpointcost+json,application/alto-error+json 768 { 769 "cost-type" { "cost-mode": "numerical", 770 "cost-metric": "maxresbw"}, 771 "endpoints": { 772 "srcs": [ "ipv4 : 192.0.2.2" ], 773 "dsts": [ 774 "ipv4:192.0.2.89", 775 "ipv4:198.51.100.34", 776 "ipv6:2000::1:2345:6789:abcd" 777 ] 778 } 779 } 781 HTTP/1.1 200 OK 782 Content-Length: TBA 783 Content-Type: application/alto-endpointcost+json 784 { 785 "meta": { 786 "cost-type": { 787 "cost-mode": "numerical", 788 "cost-metric": "maxresbw" 789 } 790 }, 791 " endpoint-cost-map": { 792 "ipv4:192.0.2.2" { 793 "ipv4:192.0.2.89" : 0, 794 "ipv4:198.51.100.34": 2000, 795 "ipv6:2000::1:2345:6789:abcd": 5000, 796 } 797 } 798 } 800 9.2. Cost Metric: Link Residue Bandwidth 802 Metric name: 804 Residue Bandwidth 806 Metric Description: 808 To specify spatial and temporal residual bandwidth over the 809 specified source and destination. The value is calculated by 810 subtracting tunnel reservations from Maximum Bandwidth (motivated 811 from [RFC7810], Sec.4.5.). The spatial aggregation unit is 812 specified in the query context (e.g., PID to PID, or endpoint to 813 endpoint). 815 Method of Measurement or Calculation: 817 Residue Bandwidth is the Unidirectional Residue bandwidth measured 818 between two directly connected IS-IS neighbors or OSPF neighbors, 819 See section 4.5 of [RFC7810] for Measurement Method. 821 Units of Measurement: 823 The unit of measurement is byte per seconds. 825 Measurement Point(s) with Potential Measurement Domain: 827 See section 2.1, Data sources. 829 Measurement Timing: 831 See section 5 of [RFC7810] for Measurement Timing. 833 Use and Applications: 835 See section 3 for use and application. 837 Example 7: residbw value on source-destination endpoint pairs 839 POST/ endpointcost/lookup HTTP/1.1 840 Host: alto.example.com 841 Content-Length: TBA 842 Content-Type: application/alto-endpointcostparams+json 843 Accept: application/alto-endpointcost+json,application/alto-error+json 845 { 846 "cost-type": { "cost-mode": "numerical", 847 "cost-metric": "residubw"}, 848 "endpoints": { 849 "srcs": [ "ipv4 : 192.0.2.2" ], 850 "dsts": [ 851 "ipv4:192.0.2.89", 852 "ipv4:198.51.100.34", 853 "ipv6:2000::1:2345:6789:abcd" 854 ] 855 } 856 } 858 HTTP/1.1 200 OK 859 Content-Length: TBA 860 Content-Type: application/alto-endpointcost+json 861 { 862 "meta": { 863 "cost-type" { 864 "cost-mode": "numerical", 865 "cost-metric": "residbw" 866 } 867 }, 868 "endpoint-cost-map" { 869 "ipv4:192.0.2.2" { 870 "ipv4:192.0.2.89" : 0, 871 "ipv4:198.51.100.34": 2000, 872 "ipv6:2000::1:2345:6789:abcd": 5000, 873 } 874 } 875 } 877 10. Security Considerations 879 The properties defined in this document present no security 880 considerations beyond those in Section 15 of the base ALTO 881 specification [ALTO]. 883 However concerns addressed in Sections "15.1 Authenticity and 884 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 885 from Authenticated ALTO Information" and "15.3 Confidentiality of 886 ALTO Information" remain of utmost importance. Indeed, TE 887 performance is a highly sensitive ISP information, therefore, sharing 888 TE metric values in numerical mode requires full mutual confidence 889 between the entities managing the ALTO Server and Client. Numerical 890 TE performance information will most likely be distributed by ALTO 891 Servers to Clients under strict and formal mutual trust agreements. 892 On the other hand, ALTO Clients must be cognizant on the risks 893 attached to such information that they would have acquired outside 894 formal conditions of mutual trust. 896 11. IANA Considerations 898 IANA has created and now maintains the "ALTO Cost Metric Registry", 899 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 900 located at . This document requests to add the 902 following entries to "ALTO Cost Meric Registry". 904 +----------+------------+----------------------------------------------+ 905 |Namespace | Property | Reference | 906 +----------+------------+----------------------------------------------+ 907 | | owdelay | [thisdraft] Section 3,[RFC2679] Section 3.6 | 908 | | rtt | [thisdraft] Section 4,[RFC2681],Section 2.6 | 909 | | pdv | [thisdraft] Section 5,[RFC3393],Section 2.6 | 910 | | hopcount | [thisdraft] Section 6,[RFC7285] | 911 | | pktloss | [thisdraft] Section 7,[RFC7680],Section 2.6 | 912 | | throughput | [thisdraft],[RFC6349],Section3.3 | 913 | | maxresbw | [thisdraft] Section 8.1,[RFC5305],Section 3.5| 914 | | residbw | [thisdraft] Section 8.2,[RFC7810],Section 4.5| 915 +----------+------------+----------------------------------------------+ 917 12. References 919 12.1. Normative References 921 [I-D.ietf-idr-te-pm-bgp] 922 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 923 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 924 Performance Metric Extensions", draft-ietf-idr-te-pm- 925 bgp-14 (work in progress), October 2018. 927 [I-D.ietf-ippm-initial-registry] 928 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 929 "Initial Performance Metric Registry Entries", draft-ietf- 930 ippm-initial-registry-07 (work in progress), June 2018. 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", March 1997. 935 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 936 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 937 September 1999, . 939 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 940 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 941 September 1999, . 943 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 944 Metric for IP Performance Metrics (IPPM)", RFC 3393, 945 DOI 10.17487/RFC3393, November 2002, 946 . 948 [RFC4627] Crockford, D., "The application/json Media Type for 949 JavaScript Object Notation (JSON)", RFC 4627, 950 DOI 10.17487/RFC4627, July 2006, 951 . 953 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 954 Specifications: ABNF", STD 68, RFC 5234, 955 DOI 10.17487/RFC5234, January 2008, 956 . 958 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 959 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 960 2008, . 962 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 963 "Framework for TCP Throughput Testing", RFC 6349, 964 DOI 10.17487/RFC6349, August 2011, 965 . 967 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 968 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 969 "Application-Layer Traffic Optimization (ALTO) Protocol", 970 RFC 7285, DOI 10.17487/RFC7285, September 2014, 971 . 973 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 974 Previdi, "OSPF Traffic Engineering (TE) Metric 975 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 976 . 978 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 979 Ed., "A One-Way Delay Metric for IP Performance Metrics 980 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 981 2016, . 983 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 984 Ed., "A One-Way Loss Metric for IP Performance Metrics 985 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 986 2016, . 988 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 989 S. Ray, "North-Bound Distribution of Link-State and 990 Traffic Engineering (TE) Information Using BGP", RFC 7752, 991 DOI 10.17487/RFC7752, March 2016, 992 . 994 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 995 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 996 RFC 7810, DOI 10.17487/RFC7810, May 2016, 997 . 999 12.2. Informative References 1001 [I-D.ietf-alto-deployments] 1002 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1003 S. Previdi, "ALTO Deployment Considerations", draft-ietf- 1004 alto-deployments-16 (work in progress), July 2016. 1006 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 1007 Development", RFC 6390, July 2011. 1009 Authors' Addresses 1011 Qin Wu 1012 Huawei 1013 101 Software Avenue, Yuhua District 1014 Nanjing, Jiangsu 210012 1015 China 1017 Email: bill.wu@huawei.com 1018 Y. Richard Yang 1019 Yale University 1020 51 Prospect St 1021 New Haven, CT 06520 1022 USA 1024 Email: yry@cs.yale.edu 1026 Young Lee 1027 Huawei 1028 1700 Alma Drive, Suite 500 1029 Plano, TX 75075 1030 USA 1032 Email: leeyoung@huawei.com 1034 Dhruv Dhody 1035 Huawei 1036 Leela Palace 1037 Bangalore, Karnataka 560008 1038 INDIA 1040 Email: dhruv.ietf@gmail.com 1042 Sabine Randriamasy 1043 Nokia Bell Labs 1044 Route de Villejust 1045 Nozay 91460 1046 FRANCE 1048 Email: sabine.randriamasy@nokia-bell-labs.com