idnits 2.17.1 draft-ietf-alto-performance-metrics-04.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 (June 16, 2018) is 2141 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 824, but not defined == Missing Reference: 'ALTO-DEPLOYMENT' is mentioned on line 192, but not defined == Missing Reference: 'RFC3630' is mentioned on line 195, but not defined == Missing Reference: 'RFC3784' is mentioned on line 195, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'BGP-PM' is mentioned on line 196, but not defined == Unused Reference: 'I-D.ietf-idr-te-pm-bgp' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 943, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-10 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-06 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 6 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: December 18, 2018 Yale University 6 Y. Lee 7 D. Dhody 8 Huawei 9 S. Randriamasy 10 Nokia Bell Labs 11 June 16, 2018 13 ALTO Performance Cost Metrics 14 draft-ietf-alto-performance-metrics-04 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 December 18, 2018. 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: POWDelay . . . . . . . . . . . . . . . . . . . . 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. Traffic Engineering Performance Cost Metrics . . . . . . . . 16 92 8.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 17 93 8.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 18 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 98 11.2. Informative References . . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 Cost Metric is a basic concept in Application-Layer Traffic 104 Optimization (ALTO). It is used in both the Cost Map Service and the 105 Endpoint Cost Service. In particular, applications may benefit from 106 knowing network performance measured on several Cost Metrics. For 107 example, a more delay-sensitive application may focus on latency, and 108 a more bandwidth-sensitive application may focus on available 109 bandwidth. 111 This document introduces a set of new cost metrics, listed in 112 Table 1, to support the aforementioned applications and allow them to 113 determine "where" to connect based on network performance criteria. 114 Hence, this document extends the base ALTO protocol [ALTO], which 115 defines only a single cost metric, i.e., the generic "routingcost" 116 metric (Sec. 14.2 of ALTO base specification [ALTO]). 118 +----------+--------------+----------------------------------------+ 119 |Namespace | Property | Reference | 120 +----------+--------------+----------------------------------------+ 121 | | owdelay | See Section 3,[RFC2679] Section 3.6 | 122 | | rtt | See Section 4,[RFC2681] Section 2.6 | 123 | | pdv | See Section 5,[RFC3393] Section 2.6 | 124 | | hopcount | See Section 6,[RFC7285] | 125 | | pktloss | See Section 7,[RFC7680] Section 2.6 | 126 | | maxresbw | See Section 8.1,[RFC5305] Section 3.5 | 127 | | residbw | See Section 8.2,[RFC7810] Section 4.5 | 128 +----------+--------------+----------------------------------------+ 129 Table 1. 131 The purpose of this draft is to list the metrics likely to be exposed 132 to ALTO Clients, including those already specified in other 133 standardization groups and as such it does not claim novelty on all 134 the specified metrics. Some metrics may have values produced by 135 standard measurement methods such as those specified in IPPM, some 136 may be ISP dependent such as those registered in ISIS or OSPF-TE. In 137 this case, this document will refer to the relevant specifications. 139 An ALTO server may provide a subset of the cost metrics described in 140 this document. These cost metrics can be retrieved and aggregated 141 from routing protocols or other traffic measurement management tools 142 (See Figure 1). Note that these cost metrics are optional and not 143 all them need to be exposed to applications. For example, those that 144 are subject to privacy concerns should not be provided to 145 unauthorized ALTO clients. 147 +--------+ +--------+ +--------+ 148 | Client | | Client | | Client | 149 +----^---+ +---^----+ +---^----+ 150 | | | 151 +-----------|-----------+ 152 NBI |ALTO protocol 153 | 154 | 155 +--+-----+ retrieval +---------+ 156 | ALTO |<----------------| Routing | 157 | Server | and aggregation| | 158 | |<-------------+ | Protocol| 159 +--------+ | +---------+ 160 | 161 | +---------+ 162 | |Management 163 ---| | 164 | Tool | 165 +---------+ 166 Figure 1.End-to-End Path Cost Metrics Exposing 168 When an ALTO server supports a cost metric defined in this document, 169 it MUST announce this metric in its IRD. 171 Additionally, future versions of this document may define network 172 metric values that stem from both measurements and provider policies 173 such as many metrics related to end-to-end path bandwidth. 175 As for the reliability and trust in the exposed metric values, 176 applications SHOULD rapidly give up using ALTO-based guidance if they 177 feel the exposed information does not preserve their performance 178 level or even degrades it. 180 Following the ALTO base protocol, this document uses JSON to specify 181 the value type of each defined metric. See [RFC4627] for JSON data 182 type specification. 184 2. Challenges on data sources and computation of ALTO performance 185 metrics 187 2.1. Data sources Challenge 189 An ALTO server needs data sources to compute the cost metrics 190 described in this document. This document does not define the exact 191 data sources. For example, the ALTO server may use log servers or 192 the OAM system as its data source [ALTO-DEPLOYMENT]. In particular, 193 the cost metrics defined in this document can be computed using 194 routing systems as the data sources. Mechanisms defined in 195 [RFC2681],[RFC3393],[RFC7679],[RFC7680],[RFC3630], [RFC3784], 196 [RFC7471], [RFC7810], [RFC7752] and [BGP-PM] that allow an ALTO 197 Server to retrieve and derive the necessary information to compute 198 the metrics that we describe in this document. 200 One challenge lies in the data sources originating the ALTO metric 201 values. The very important purpose of ALTO is to guide application 202 traffic with provider network centric information that may be exposed 203 to ALTO Clients in the form of network performance metric values. 204 Not all of these metrics have values produced by standardized 205 measurement methods or routing protocols. Some of them involve 206 provider-centric policy considerations. Some of them may describe 207 wireless or cellular networks. To reliably guide users and 208 applications while preserving provider privacy, ALTO performance 209 metric values may also add abstraction to measurements or provide 210 unitless performance scores. 212 2.2. ALTO performance metrics Computation Challenges 214 The metric values exposed by an ALTO server may result from 215 additional processing on measurements from data sources to compute 216 exposed metrics. This may involve data processing tasks such as 217 aggregating the results across multiple systems, removing outliers, 218 and creating additional statistics. There are two challenges on 219 computation of ALTO performance metrics. 221 2.2.1. Configuration Parameters Challenge 223 Performance metrics often depend on configuration parameters. For 224 example, the value of packet loss rate depends on the measurement 225 interval and varies over time. To handle this issue, an ALTO server 226 may collect data on time periods covering the previous and current 227 time or only collect data on present time. The ALTO server may 228 further aggregate these data to provide an abstract and unified view 229 that can be more useful to applications. To make the ALTO client 230 better understand how to use these performance data, the ALTO server 231 may provide the client with the validity period of the exposed metric 232 values. 234 2.2.2. Availability of end to end path values Challenge 236 Applications value information relating to bandwidth availability 237 where as bandwidth related metrics can often be only measured at the 238 link level. This document specifies a set of link-level bandwidth 239 related values that may be exposed as such by an ALTO server. The 240 server may also expose other metrics derived from their aggregation 241 and having different levels of endpoint granularity, e.g. link 242 endpoints or session endpoints. The metric specifications may also 243 expose the utilized aggregation laws. 245 3. Cost Metric: POWDelay 247 Metric name: 249 Periodic One Way Delay 251 Metric Description: 253 To specify spatial and temporal aggregated delay of a stream of 254 packets exchanged between the specified source and destination or 255 the time that the packet spends to travel from source to 256 destination. The spatial aggregation level is specified in the 257 query context (e.g., PID to PID, or endpoint to endpoint). 259 Method of Measurement or Calculation: 261 See section 8.3 of [I-D.ietf-ippm-initial-registry] for 262 Measurement Method. 264 Units of Measurement: 266 See section 8.4.3 of [I-D.ietf-ippm-initial-registry] for 267 Measurement Unit. The unit is expressed in milliseconds in this 268 document. 270 Measurement Point(s) with Potential Measurement Domain: 272 See section 2.1, Data sources. 274 Measurement Timing: 276 See section 8.3.5 of [I-D.ietf-ippm-initial-registry] for 277 Measurement Timing. 279 Use and Applications: 281 The Metric value Type is a single 'JSONNumber' type value 282 containing a non-negative integer component that may be followed 283 by an exponent part. The Cost Mode is encoded as a US-ASCII 284 string. 286 This metric could be used as a cost metric constraint attribute 287 used either together with cost metric attribute 'routingcost' or 288 on its own or as a returned cost metric in the response. 290 Example 1: Delay value on source-destination endpoint pairs 292 POST /endpointcost/lookup HTTP/1.1 293 Host: alto.example.com 294 Content-Length: TBA 295 Content-Type: application/alto-endpointcostparams+json 296 Accept: application/alto-endpointcost+json,application/alto-error+json 298 { 299 "cost-type": {"cost-mode" : "numerical", 300 "cost-metric" : "powdelay"}, 301 "endpoints" : { 302 "srcs": [ "ipv4:192.0.2.2" ], 303 "dsts": [ 304 "ipv4:192.0.2.89", 305 "ipv4:198.51.100.34", 306 "ipv6:2000::1:2345:6789:abcd" 307 ] 308 } 309 } 310 HTTP/1.1 200 OK 311 Content-Length: TBA 312 Content-Type: application/alto-endpointcost+json 313 { 314 "meta" :{ 315 "cost-type": {"cost-mode" : "numerical", 316 "cost-metric" : "powdelay" 317 } 318 }, 319 "endpoint-cost-map" : { 320 "ipv4:192.0.2.2": { 321 "ipv4:192.0.2.89" : 10, 322 "ipv4:198.51.100.34" : 20, 323 "ipv6:2000::1:2345:6789:abcd" : 30, 324 } 325 } 326 } 328 4. Cost Metric: RTT 330 Metric name: 332 Round Trip Delay 334 Metric Description: 336 To specify spatial and temporal aggregated round trip delay 337 between the specified source and destination or the time that the 338 packet spends to travel from source to destination and then from 339 destination to source. The spatial aggregation level is specified 340 in the query context (e.g., PID to PID, or endpoint to endpoint). 342 Method of Measurement or Calculation: 344 See section 4.3 of [I-D.ietf-ippm-initial-registry] for 345 Measurement Method. 347 Units of Measurement: 349 See section 4.4.3 of [I-D.ietf-ippm-initial-registry] for 350 Measurement Unit. The unit is expressed in milliseconds in this 351 document. 353 Measurement Point(s) with Potential Measurement Domain: 355 See section 2.1, Data sources. 357 Measurement Timing: 359 See section 4.3.5 of [I-D.ietf-ippm-initial-registry] for 360 Measurement Timing. 362 Use and Applications: 364 See section 3 for use and application. 366 Example 2: Round Trip Delay value on source-destination endpoint pairs 368 POST /endpointcost/lookup HTTP/1.1 369 Host: alto.example.com 370 Content-Length: TBA 371 Content-Type: application/alto-endpointcostparams+json 372 Accept: application/alto-endpointcost+json,application/alto-error+json 374 { 375 "cost-type": {"cost-mode" : "numerical", 376 "cost-metric" : "rtt"}, 377 "endpoints" : { 378 "srcs": [ "ipv4:192.0.2.2" ], 379 "dsts": [ 380 "ipv4:192.0.2.89", 381 "ipv4:198.51.100.34", 382 "ipv6:2000::1:2345:6789:abcd" 383 ] 384 } 385 } 386 HTTP/1.1 200 OK 387 Content-Length: TBA 388 Content-Type: application/alto-endpointcost+json 389 { 390 "meta" :{ 391 "cost-type": {"cost-mode" : "numerical", 392 "cost-metric" : "rtt" 393 } 394 }, 395 "endpoint-cost-map" : { 396 "ipv4:192.0.2.2": { 397 "ipv4:192.0.2.89" : 4, 398 "ipv4:198.51.100.34" : 3, 399 "ipv6:2000::1:2345:6789:abcd" : 2, 400 } 401 } 402 } 404 5. Cost Metric: PDV 406 Metric name: 408 Packet Delay Variation 410 Metric Description: 412 To specify spatial and temporal aggregated jitter (packet delay 413 variation) with respect to the minimum delay observed on the 414 stream over the specified source and destination. The spatial 415 aggregation level is specified in the query context (e.g., PID to 416 PID, or endpoint to endpoint). 418 Method of Measurement or Calculation: 420 See section 5.3 of [I-D.ietf-ippm-initial-registry] for 421 Measurement Method. 423 Units of Measurement: 425 See section 5.4.4 of [I-D.ietf-ippm-initial-registry] for 426 Measurement Unit. The unit is expressed in milliseconds in this 427 document. 429 Measurement Point(s) with Potential Measurement Domain: 431 See section 2.1, Data sources. 433 Measurement Timing: 435 See section 5.3.5 of [I-D.ietf-ippm-initial-registry] for 436 Measurement Timing. 438 Use and Applications: 440 See section 3 for use and application. 442 Example 3: Delay jitter value on source-destination endpoint pairs 444 POST /endpointcost/lookup HTTP/1.1 445 Host: alto.example.com 446 Content-Length: TBA 447 Content-Type: application/alto-endpointcostparams+json 448 Accept: application/alto-endpointcost+json,application/alto-error+json 450 { 451 "cost-type": {"cost-mode" : "numerical", 452 "cost-metric" : "delayjitter"}, 453 "endpoints" : { 454 "srcs": [ "ipv4:192.0.2.2" ], 455 "dsts": [ 456 "ipv4:192.0.2.89", 457 "ipv4:198.51.100.34", 458 "ipv6:2000::1:2345:6789:abcd" 459 ] 460 } 461 } 462 Example 3: Delay jitter value on source-destination endpoint pairs 464 POST /endpointcost/lookup HTTP/1.1 465 Host: alto.example.com 466 Content-Length: TBA 467 Content-Type: application/alto-endpointcostparams+json 468 Accept: application/alto-endpointcost+json,application/alto-error+json 470 { 471 "cost-type": {"cost-mode" : "numerical", 472 "cost-metric" : "delayjitter"}, 473 "endpoints" : { 474 "srcs": [ "ipv4:192.0.2.2" ], 475 "dsts": [ 476 "ipv4:192.0.2.89", 477 "ipv4:198.51.100.34", 478 "ipv6:2000::1:2345:6789:abcd" 479 ] 480 } 481 } 482 HTTP/1.1 200 OK 483 Content-Length: TBA 484 Content-Type: application/alto-endpointcost+json 485 { 486 "meta": { 487 "cost type": { 488 "cost-mode": "numerical", 489 "cost-metric":"delayjitter" 490 } 491 }, 492 "endpoint-cost-map": { 493 "ipv4:192.0.2.2": { 494 "ipv4:192.0.2.89" : 0 495 "ipv4:198.51.100.34" : 1 496 "ipv6:2000::1:2345:6789:abcd" : 5 497 } 498 } 499 } 501 6. Cost Metric: Hop Count 503 The metric hopcount is mentioned in [ALTO] as an example. This 504 section further clarifies its properties. 506 Metric name: 508 Hop count 510 Metric Description: 512 To specify the number of hops in the path between the source 513 endpoint and the destination endpoint. The hop count is a basic 514 measurement of distance in a network and can be exposed as Router 515 Hops, IP hops in direct relation to the routing protocols 516 originating this information. It might also result from the 517 aggregation of such information. 519 Method of Measurement or Calculation: 521 The hop count can and calculated based on the number of routers 522 from the source endpoint through which data must pass to reach the 523 destination endpoint. 525 Units of Measurement: 527 The unit is integer number. 529 Measurement Point(s) with Potential Measurement Domain: 531 The hop count can be measured at the source endpoint by 532 traceroute. 534 Measurement Timing: 536 Upon need, the traceroute can use UDP probe message or other 537 implementations that use ICMP and TCP to discover the hop counts 538 along the path from source endpoint to destination endpoint. 540 Use and Applications: 542 See section 3 for use and application. 544 Example 4: hopcount value on source-destination endpoint pairs 546 POST /endpointcost/lookup HTTP/1.1 547 Host: alto.example.com 548 Content-Length: TBA 549 Content-Type: application/alto-endpointcostparams+json 550 Accept: application/alto-endpointcost+json,application/alto-error+json 552 { 553 "cost-type": {"cost-mode" : "numerical", 554 "cost-metric" : "hopcount"}, 555 "endpoints" : { 556 "srcs": [ "ipv4:192.0.2.2" ], 557 "dsts": [ 558 "ipv4:192.0.2.89", 559 "ipv4:198.51.100.34", 560 "ipv6:2000::1:2345:6789:abcd" 561 ] 562 } 563 } 565 HTTP/1.1 200 OK 566 Content-Length: TBA 567 Content-Type: application/alto-endpointcost+json 568 { 569 "meta": { 570 "cost type": { 571 "cost-mode": "numerical", 572 "cost-metric":"hopcount"} 573 } 574 }, 575 "endpoint-cost-map": { 576 "ipv4:192.0.2.2": { 577 "ipv4:192.0.2.89" : 5, 578 "ipv4:198.51.100.34": 3, 579 "ipv6:2000::1:2345:6789:abcd" : 2, 580 } 581 } 582 } 584 7. Cost Metric: Packet Loss 586 Metric name: 588 Packet loss 590 Metric Description: 592 To specify spatial and temporal aggregated packet loss over the 593 specified source and destination. The spatial aggregation level 594 is specified in the query context (e.g., PID to PID, or endpoint 595 to endpoint). 597 Method of Measurement or Calculation: 599 See section 2.6 of [RFC7680] for Measurement Method. 601 Units of Measurement: 603 The unit is percentile. 605 Measurement Point(s) with Potential Measurement Domain: 607 See section 2.1, Data sources. 609 Measurement Timing: 611 See section 2 and section3 of [RFC7680] for Measurement Timing. 613 Use and Applications: 615 See section 3 for use and application. 617 Example 5: pktloss value on source-destination endpoint pairs 619 POST /endpointcost/lookup HTTP/1.1 620 Host: alto.example.com 621 Content-Length: TBA 622 Content-Type: application/alto-endpointcostparams+json 623 Accept: application/alto-endpointcost+json,application/alto-error+json 625 { 626 "cost-type": {"cost-mode" : "numerical", 627 "cost-metric" : "pktloss"}, 628 "endpoints" : { 629 "srcs": [ "ipv4:192.0.2.2" ], 630 "dsts": [ 631 "ipv4:192.0.2.89", 632 "ipv4:198.51.100.34", 633 "ipv6:2000::1:2345:6789:abcd" 634 ] 635 } 636 } 638 HTTP/1.1 200 OK 639 Content-Length: TBA 640 Content-Type: application/alto-endpointcost+json 641 { 642 "meta": { 643 "cost type": { 644 "cost-mode": "numerical", 645 "cost-metric":"pktloss"} 646 } 647 }, 648 "endpoint-cost-map": { 649 "ipv4:192.0.2.2": { 650 "ipv4:192.0.2.89" : 0, 651 "ipv4:198.51.100.34": 0, 652 "ipv6:2000::1:2345:6789:abcd" : 0, 653 } 654 } 655 } 657 8. Traffic Engineering Performance Cost Metrics 659 This section introduces ALTO network performance metrics that may be 660 aggregated from network metrics measured on links and specified in 661 other documents. In particular, the bandwidth related metrics 662 specified in this section are only available through link level 663 measurements. For some of these metrics, the ALTO Server may further 664 expose aggregated values while specifying the aggregation laws. 666 8.1. Cost Metric: Link Maximum Reservable Bandwidth 668 Metric name: 670 Maximum Reservable Bandwidth 672 Metric Description: 674 To specify spatial and temporal maximum reservable bandwidth over 675 the specified source and destination. The value is corresponding 676 to the maximum bandwidth that can be reserved (motivated from RFC 677 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 678 the query context (e.g., PID to PID, or endpoint to endpoint). 680 Method of Measurement or Calculation: 682 Maximum Reserveable Bandwidth is the bandwidth measured between 683 two directly connected IS-IS neighbors or OSPF neighbors, See 684 section 3.5 of [RFC5305] for Measurement Method. 686 Units of Measurement: 688 The unit of measurement is byte per seconds. 690 Measurement Point(s) with Potential Measurement Domain: 692 See section 2.1, Data sources. 694 Measurement Timing: 696 See section 3.5 of [RFC5305] and section 5 of [RFC7810] for 697 Measurement Timing. 699 Use and Applications: 701 See section 3 for use and application. 703 Example 6: maxresbw value on source-destination endpoint pairs 705 POST/ endpointcost/lookup HTTP/1.1 706 Host: alto.example.com 707 Content-Length: TBA 708 Content-Type: application/alto-endpointcostparams+json 709 Accept: application/alto-endpointcost+json,application/alto-error+json 711 { 712 "cost-type" { "cost-mode": "numerical", 713 "cost-metric": "maxresbw"}, 714 "endpoints": { 715 "srcs": [ "ipv4 : 192.0.2.2" ], 716 "dsts": [ 717 "ipv4:192.0.2.89", 718 "ipv4:198.51.100.34", 719 "ipv6:2000::1:2345:6789:abcd" 720 ] 721 } 722 } 724 HTTP/1.1 200 OK 725 Content-Length: TBA 726 Content-Type: application/alto-endpointcost+json 727 { 728 "meta": { 729 "cost-type": { 730 "cost-mode": "numerical", 731 "cost-metric": "maxresbw" 732 } 733 }, 734 " endpoint-cost-map": { 735 "ipv4:192.0.2.2" { 736 "ipv4:192.0.2.89" : 0, 737 "ipv4:198.51.100.34": 2000, 738 "ipv6:2000::1:2345:6789:abcd": 5000, 739 } 740 } 741 } 743 8.2. Cost Metric: Link Residue Bandwidth 745 Metric name: 747 Residue Bandwidth 749 Metric Description: 751 To specify spatial and temporal residual bandwidth over the 752 specified source and destination. The value is calculated by 753 subtracting tunnel reservations from Maximum Bandwidth (motivated 754 from [RFC7810], Sec.4.5.). The spatial aggregation unit is 755 specified in the query context (e.g., PID to PID, or endpoint to 756 endpoint). 758 Method of Measurement or Calculation: 760 Residue Bandwidth is the Unidirectional Residue bandwidth measured 761 between two directly connected IS-IS neighbors or OSPF neighbors, 762 See section 4.5 of [RFC7810] for Measurement Method. 764 Units of Measurement: 766 The unit of measurement is byte per seconds. 768 Measurement Point(s) with Potential Measurement Domain: 770 See section 2.1, Data sources. 772 Measurement Timing: 774 See section 5 of [RFC7810] for Measurement Timing. 776 Use and Applications: 778 See section 3 for use and application. 780 Example 7: residuebw value on source-destination endpoint pairs 782 POST/ endpointcost/lookup HTTP/1.1 783 Host: alto.example.com 784 Content-Length: TBA 785 Content-Type: application/alto-endpointcostparams+json 786 Accept: application/alto-endpointcost+json,application/alto-error+json 788 { 789 "cost-type": { "cost-mode": "numerical", 790 "cost-metric": "residubw"}, 791 "endpoints": { 792 "srcs": [ "ipv4 : 192.0.2.2" ], 793 "dsts": [ 794 "ipv4:192.0.2.89", 795 "ipv4:198.51.100.34", 796 "ipv6:2000::1:2345:6789:abcd" 797 ] 798 } 799 } 801 HTTP/1.1 200 OK 802 Content-Length: TBA 803 Content-Type: application/alto-endpointcost+json 804 { 805 "meta": { 806 "cost-type" { 807 "cost-mode": "numerical", 808 "cost-metric": "residubw" 809 } 810 }, 811 "endpoint-cost-map" { 812 "ipv4:192.0.2.2" { 813 "ipv4:192.0.2.89" : 0, 814 "ipv4:198.51.100.34": 2000, 815 "ipv6:2000::1:2345:6789:abcd": 5000, 816 } 817 } 818 } 820 9. Security Considerations 822 The properties defined in this document present no security 823 considerations beyond those in Section 15 of the base ALTO 824 specification [ALTO]. 826 However concerns addressed in Sections "15.1 Authenticity and 827 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 828 from Authenticated ALTO Information" and "15.3 Confidentiality of 829 ALTO Information" remain of utmost importance. Indeed, TE 830 performance is a highly sensitive ISP information, therefore, sharing 831 TE metric values in numerical mode requires full mutual confidence 832 between the entities managing the ALTO Server and Client. Numerical 833 TE performance information will most likely be distributed by ALTO 834 Servers to Clients under strict and formal mutual trust agreements. 835 On the other hand, ALTO Clients must be cognizant on the risks 836 attached to such information that they would have acquired outside 837 formal conditions of mutual trust. 839 10. IANA Considerations 841 IANA has created and now maintains the "ALTO Cost Metric Registry", 842 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 843 located at . This document requests to add the 845 following entries to "ALTO Cost Meric Registry". 847 +----------+------------+----------------------------------------------+ 848 |Namespace | Property | Reference | 849 +----------+------------+----------------------------------------------+ 850 | | owdelay | [thisdraft] Section 3,[RFC2679] Section 3.6 | 851 | | rtt | [thisdraft] Section 4,[RFC2681],Section 2.6 | 852 | | pdv | [thisdraft] Section 5,[RFC3393],Section 2.6 | 853 | | hopcount | [thisdraft] Section 6,[RFC7285] | 854 | | pktloss | [thisdraft] Section 7,[RFC7680],Section 2.6 | 855 | | maxresbw | [thisdraft] Section 8.1,[RFC5305],Section 3.5| 856 | | residbw | [thisdraft] Section 8.2,[RFC7810],Section 4.5| 857 +----------+------------+----------------------------------------------+ 859 11. References 861 11.1. Normative References 863 [I-D.ietf-idr-te-pm-bgp] 864 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 865 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 866 Performance Metric Extensions", draft-ietf-idr-te-pm- 867 bgp-10 (work in progress), March 2018. 869 [I-D.ietf-ippm-initial-registry] 870 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 871 "Initial Performance Metric Registry Entries", draft-ietf- 872 ippm-initial-registry-06 (work in progress), March 2018. 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", March 1997. 877 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 878 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 879 September 1999, . 881 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 882 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 883 September 1999, . 885 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 886 Metric for IP Performance Metrics (IPPM)", RFC 3393, 887 DOI 10.17487/RFC3393, November 2002, 888 . 890 [RFC4627] Crockford, D., "The application/json Media Type for 891 JavaScript Object Notation (JSON)", RFC 4627, 892 DOI 10.17487/RFC4627, July 2006, 893 . 895 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 896 Specifications: ABNF", STD 68, RFC 5234, 897 DOI 10.17487/RFC5234, January 2008, 898 . 900 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 901 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 902 2008, . 904 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 905 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 906 "Application-Layer Traffic Optimization (ALTO) Protocol", 907 RFC 7285, DOI 10.17487/RFC7285, September 2014, 908 . 910 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 911 Previdi, "OSPF Traffic Engineering (TE) Metric 912 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 913 . 915 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 916 Ed., "A One-Way Delay Metric for IP Performance Metrics 917 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 918 2016, . 920 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 921 Ed., "A One-Way Loss Metric for IP Performance Metrics 922 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 923 2016, . 925 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 926 S. Ray, "North-Bound Distribution of Link-State and 927 Traffic Engineering (TE) Information Using BGP", RFC 7752, 928 DOI 10.17487/RFC7752, March 2016, 929 . 931 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 932 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 933 RFC 7810, DOI 10.17487/RFC7810, May 2016, 934 . 936 11.2. Informative References 938 [I-D.ietf-alto-deployments] 939 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 940 S. Previdi, "ALTO Deployment Considerations", draft-ietf- 941 alto-deployments-16 (work in progress), July 2016. 943 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 944 Development", RFC 6390, July 2011. 946 Authors' Addresses 948 Qin Wu 949 Huawei 950 101 Software Avenue, Yuhua District 951 Nanjing, Jiangsu 210012 952 China 954 Email: bill.wu@huawei.com 956 Y. Richard Yang 957 Yale University 958 51 Prospect St 959 New Haven, CT 06520 960 USA 962 Email: yry@cs.yale.edu 964 Young Lee 965 Huawei 966 1700 Alma Drive, Suite 500 967 Plano, TX 75075 968 USA 970 Email: leeyoung@huawei.com 971 Dhruv Dhody 972 Huawei 973 Leela Palace 974 Bangalore, Karnataka 560008 975 INDIA 977 Email: dhruv.ietf@gmail.com 979 Sabine Randriamasy 980 Nokia Bell Labs 981 Route de Villejust 982 Nozay 91460 983 FRANCE 985 Email: sabine.randriamasy@nokia-bell-labs.com