idnits 2.17.1 draft-ietf-alto-performance-metrics-02.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 : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 (July 2, 2017) is 2490 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 968, but not defined == Missing Reference: 'ALTO-DEPLOYMENT' is mentioned on line 200, but not defined == Missing Reference: 'RFC3630' is mentioned on line 203, but not defined == Missing Reference: 'RFC3784' is mentioned on line 203, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'OSPF-TE' is mentioned on line 203, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 203, but not defined == Missing Reference: 'BGP-LS' is mentioned on line 203, but not defined == Missing Reference: 'BGP-PM' is mentioned on line 203, but not defined == Missing Reference: 'XXXX' is mentioned on line 833, but not defined -- Looks like a reference, but probably isn't: '6' on line 881 -- Looks like a reference, but probably isn't: '5' on line 881 -- Looks like a reference, but probably isn't: '7' on line 881 -- Looks like a reference, but probably isn't: '8' on line 881 -- Looks like a reference, but probably isn't: '4' on line 880 -- Looks like a reference, but probably isn't: '10' on line 879 -- Looks like a reference, but probably isn't: '9' on line 881 == Unused Reference: 'I-D.ietf-idr-te-pm-bgp' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'RFC7471' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1085, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-06 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-04 ** 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: 7 errors (**), 0 flaws (~~), 21 warnings (==), 9 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 3, 2018 Yale University 6 Y. Lee 7 D. Dhody 8 Huawei 9 S. Randriamasy 10 Nokia Bell Labs 11 July 2, 2017 13 ALTO Performance Cost Metrics 14 draft-ietf-alto-performance-metrics-02 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 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 3, 2018. 62 Copyright Notice 64 Copyright (c) 2017 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. Challenges on data sources and computation of ALTO 81 performance metrics . . . . . . . . . . . . . . . . . . . . . 5 82 2.1. Data sources . . . . . . . . . . . . . . . . . . . . . . 5 83 2.2. Computation of ALTO performance metrics . . . . . . . . . 5 84 3. Cost Metric: POWDelay . . . . . . . . . . . . . . . . . . . . 6 85 4. Cost Metric: RTT . . . . . . . . . . . . . . . . . . . . . . 8 86 5. Cost Metric: PDV . . . . . . . . . . . . . . . . . . . . . . 10 87 6. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . . . 12 88 7. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . . . 14 89 8. Traffic Engineering Performance Cost Metrics . . . . . . . . 16 90 8.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 17 91 8.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 18 92 8.3. Cost Metric: Link Available Bandwidth . . . . . . . . . . 20 93 8.4. Cost Metric: Link Utilized Bandwidth . . . . . . . . . . 22 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 11.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Appendix A. Open Issue List . . . . . . . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 | | maxresbw | See Section 8.1,[RFC5305] Section 3.5 | 128 | | residbw | See Section 8.2,[RFC7810] Section 4.5 | 129 | | availbw | See Section 8.3,[RFC7810] Section 4.6 | 130 | | utilbw | See Section 8.4,[RFC7810 Section 4.7 | 131 +----------+--------------+---------------------------------------------+ 132 Table 1. 134 The purpose of this draft is to list the metrics likely to be exposed 135 to ALTO Clients, including those already specified in other 136 standardization groups and as such it does not claim novelty on all 137 the specified metrics. Some metrics may have values produced by 138 explicitly specified measurement methods such as those specified in 139 IPPM, some may be ISP dependent such as those registered in ISIS or 140 OSPF-TE. In this case, this document will refer to the relevant 141 specifications. 143 An ALTO server may provide a subset of the cost metrics described in 144 this document. These cost metrics can be retrieved and aggregated 145 from routing protocols or other traffic measurement management tools 146 (See Figure 1). Note that these cost metrics are optional and not 147 all them need to be exposed to applications. If some are subject to 148 privacy concerns, the ALTO server should not provide them to the 149 client. 151 +--------+ +--------+ +--------+ 152 | Client | | Client | | Client | 153 +----^---+ +---^----+ +---^----+ 154 | | | 155 +-----------|-----------+ 156 NBI |ALTO protocol 157 | 158 | 159 +--+-----+ retrieve +---------+ 160 | ALTO |<----------------| Routing | 161 | Server | and aggregation| | 162 | |<-------------+ | Protocol| 163 +--------+ | +---------+ 164 | 165 | +---------+ 166 | |Management 167 ---| | 168 | Tool | 169 +---------+ 170 Figure 1.End-to-End Path Cost Metrics Exposing 172 When an ALTO server supports a cost metric defined in this document, 173 it SHOULD announce this metric in its IRD. 175 Additionally, further versions of this document may define network 176 metric values that stem from both measurements and provider policies 177 as for example, many end-to-end path bandwidth related ALTO metrics. 178 ALTO may convey such information, not available via 3rd party 179 measurement tools. Besides, IPPM informational RFC 5136 points the 180 difficulty to have a unified nomenclature for network capacity 181 related measurements. 183 As for the reliability and trust in the exposed metric values, 184 applications will rapidly give up using ALTO-based guidance if they 185 feel the exposed information does not preserve their performance 186 level or even degrades it. 188 Following the ALTO base protocol, this document uses JSON to specify 189 the value type of each defined metric. See [RFC4627] for JSON data 190 type specification. 192 2. Challenges on data sources and computation of ALTO performance 193 metrics 195 2.1. Data sources 197 An ALTO server needs data sources to compute the cost metrics 198 described in this document. This document does not define the exact 199 data sources. For example, the ALTO server may use log servers or 200 the OAM system as its data source [ALTO-DEPLOYMENT]. In particular, 201 the cost metrics defined in this document can be computed using 202 routing systems as the data sources. Mechanisms defined in 203 [RFC3630], [RFC3784], [OSPF-TE], [ISIS-TE], [BGP-LS] and [BGP-PM] 204 that allow an ALTO Server to retrieve and derive the necessary 205 information to compute the metrics that we describe in this document. 207 One challenge lies in the data sources originating the ALTO metric 208 values. The very purpose of ALTO is to guide application traffic 209 with provider network centric information that may be exposed to ALTO 210 Clients in the form of network performance metric values. Not all of 211 these metrics have values produced by standardized measurement 212 methods or routing protocols. Some of them involve provider-centric 213 policy considerations. Some of them may describe wireless or 214 cellular networks. To reliably guide users and applications while 215 preserving provider privacy, ALTO performance metric values may also 216 add abstraction to measurements or provide unitless performance 217 scores. 219 2.2. Computation of ALTO performance metrics 221 The metric values exposed by an ALTO server may result from 222 additional processing on measurements from data sources to compute 223 exposed metrics. This may involve data processing tasks such as 224 aggregating the results across multiple systems, removing outliers, 225 and creating additional statistics. 227 One challenge in describing the metrics is that performance metrics 228 often depend on configuration parameters. For example, the value of 229 packet loss rate depends on the measurement interval and varies over 230 time. To handle this issue, an ALTO server may collect data on time 231 periods covering the previous and current time or only collect data 232 on present time. The ALTO server may further aggregate these data to 233 provide an abstract and unified view that can be more useful to 234 applications. To make the ALTO client better understand how to use 235 these performance data, the ALTO server may provide the client with 236 the validity period of the exposed metric values. 238 Another challenge relates to the availability of end-to-end path 239 values for certain metrics. Applications value information relating 240 to bandwidth availability where as bandwidth related metrics can 241 often be only measured at the link level. This document specifies a 242 set of link-level bandwidth related values that may be exposed as 243 such by an ALTO server. The server may also expose other metrics 244 derived from their aggregation and having different levels of 245 endpoint granularity, e.g. link endpoints or session endpoints. The 246 metric specifications may also expose the utilised aggregation laws. 248 3. Cost Metric: POWDelay 250 Metric name: 252 Periodic One Way Delay 254 Metric Description: 256 To specify spatial and temporal aggregated delay of a stream of 257 packets exchanged between the specified source and destination or 258 the time that the packet spends to travel from source to 259 destination. The spatial aggregation level is specified in the 260 query context (e.g., PID to PID, or endpoint to endpoint). 262 Method of Measurement or Calculation: 264 See section 8.3 of [I-D.ietf-ippm-initial-registry] for 265 Measurement Method. 267 Units of Measurement: 269 See section 8.4.3 of [I-D.ietf-ippm-initial-registry] for 270 Measurement Unit. The unit is expressed in seconds. 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" : "powdelay"}, 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 } 313 HTTP/1.1 200 OK 314 Content-Length: TBA 315 Content-Type: application/alto-endpointcost+json 316 { 317 "meta" :{ 318 "cost-type": {"cost-mode" : "numerical", 319 "cost-metric" : "powdelay" 320 } 321 }, 322 "endpoint-cost-map" : { 323 "ipv4:192.0.2.2": { 324 "ipv4:192.0.2.89" : 10, 325 "ipv4:198.51.100.34" : 20, 326 "ipv6:2000::1:2345:6789:abcd" : 30, 327 } 328 } 329 } 331 4. Cost Metric: RTT 333 Metric name: 335 Round Trip Delay 337 Metric Description: 339 To specify spatial and temporal aggregated round trip delay 340 between the specified source and destination or the time that the 341 packet spends to travel from source to destination and then from 342 destination to source. The spatial aggregation level is specified 343 in the query context (e.g., PID to PID, or endpoint to endpoint). 345 Method of Measurement or Calculation: 347 See section 4.3 of [I-D.ietf-ippm-initial-registry] for 348 Measurement Method. 350 Units of Measurement: 352 See section 4.4.3 of [I-D.ietf-ippm-initial-registry] for 353 Measurement Unit. The unit is expressed in seconds. 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 7: 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 } 389 HTTP/1.1 200 OK 390 Content-Length: TBA 391 Content-Type: application/alto-endpointcost+json 392 { 393 "meta" :{ 394 "cost-type": {"cost-mode" : "numerical", 395 "cost-metric" : "rtt" 396 } 397 }, 398 "endpoint-cost-map" : { 399 "ipv4:192.0.2.2": { 400 "ipv4:192.0.2.89" : 4, 401 "ipv4:198.51.100.34" : 3, 402 "ipv6:2000::1:2345:6789:abcd" : 2, 403 } 404 } 405 } 407 5. Cost Metric: PDV 409 Metric name: 411 Packet Delay Variation 413 Metric Description: 415 To specify spatial and temporal aggregated jitter (packet delay 416 variation) with respect to the minimum delay observed on the 417 stream over the specified source and destination. The spatial 418 aggregation level is specified in the query context (e.g., PID to 419 PID, or endpoint to endpoint). 421 Method of Measurement or Calculation: 423 See section 5.3 of [I-D.ietf-ippm-initial-registry] for 424 Measurement Method. 426 Units of Measurement: 428 See section 5.4.4 of [I-D.ietf-ippm-initial-registry] for 429 Measurement Unit. The unit is expressed in seconds. 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 2: Delay jitter 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" : "delayjitter"}, 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 or other hops in direct relation to the routing 498 protocols originating this information. It might also result from 499 the aggregation of such information. 501 Method of Measurement or Calculation: 503 See section 2.2, Computation of metrics. 505 Units of Measurement: 507 The unit is integer number. 509 Measurement Point(s) with Potential Measurement Domain: 511 See section 2.1, Data sources. 513 Measurement Timing: 515 See section 2.1, second paragraph for Measurement Timing. 517 Use and Applications: 519 See section 3 for use and application. 521 Example 4: hopcount value on source-destination endpoint pairs 523 POST /endpointcost/lookup HTTP/1.1 524 Host: alto.example.com 525 Content-Length: TBA 526 Content-Type: application/alto-endpointcostparams+json 527 Accept: application/alto-endpointcost+json,application/alto-error+json 529 { 530 "cost-type": {"cost-mode" : "numerical", 531 "cost-metric" : "hopcount"}, 532 "endpoints" : { 533 "srcs": [ "ipv4:192.0.2.2" ], 534 "dsts": [ 535 "ipv4:192.0.2.89", 536 "ipv4:198.51.100.34", 537 "ipv6:2000::1:2345:6789:abcd" 538 ] 539 } 540 } 541 HTTP/1.1 200 OK 542 Content-Length: TBA 543 Content-Type: application/alto-endpointcost+json 544 { 545 "meta": { 546 "cost type": { 547 "cost-mode": "numerical", 548 "cost-metric":"hopcount"} 549 } 550 }, 551 "endpoint-cost-map": { 552 "ipv4:192.0.2.2": { 553 "ipv4:192.0.2.89" : 5, 554 "ipv4:198.51.100.34": 3, 555 "ipv6:2000::1:2345:6789:abcd" : 2, 556 } 557 } 558 } 560 7. Cost Metric: Packet Loss 562 Metric name: 564 Packet loss 566 Metric Description: 568 To specify spatial and temporal aggregated packet loss over the 569 specified source and destination. The spatial aggregation level 570 is specified in the query context (e.g., PID to PID, or endpoint 571 to endpoint). 573 Method of Measurement or Calculation: 575 See section 2.6 of [RFC7680] for Measurement Method. 577 Units of Measurement: 579 The unit is percentile. 581 Measurement Point(s) with Potential Measurement Domain: 583 See section 2.1, Data sources. 585 Measurement Timing: 587 See section 2 and section3 of [RFC7680] for Measurement Timing. 589 Use and Applications: 591 See section 3 for use and application. 593 Example 3: pktloss value on source-destination endpoint pairs 595 POST /endpointcost/lookup HTTP/1.1 596 Host: alto.example.com 597 Content-Length: TBA 598 Content-Type: application/alto-endpointcostparams+json 599 Accept: application/alto-endpointcost+json,application/alto-error+json 601 { 602 "cost-type": {"cost-mode" : "numerical", 603 "cost-metric" : "pktloss"}, 604 "endpoints" : { 605 "srcs": [ "ipv4:192.0.2.2" ], 606 "dsts": [ 607 "ipv4:192.0.2.89", 608 "ipv4:198.51.100.34", 609 "ipv6:2000::1:2345:6789:abcd" 610 ] 611 } 612 } 613 HTTP/1.1 200 OK 614 Content-Length: TBA 615 Content-Type: application/alto-endpointcost+json 616 { 617 "meta": { 618 "cost type": { 619 "cost-mode": "numerical", 620 "cost-metric":"pktloss"} 621 } 622 }, 623 "endpoint-cost-map": { 624 "ipv4:192.0.2.2": { 625 "ipv4:192.0.2.89" : 0, 626 "ipv4:198.51.100.34": 1, 627 "ipv6:2000::1:2345:6789:abcd" : 2, 628 } 629 } 630 } 632 8. Traffic Engineering Performance Cost Metrics 634 This section introduces ALTO network performance metrics that may be 635 aggregated from network metrics measured on links and specified in 636 other documents. In particular, the bandwidth related metrics 637 specified in this section are only available through link level 638 measurements. For some of these metrics, the ALTO Server may further 639 expose aggregated values while specifying the aggregation laws. 641 8.1. Cost Metric: Link Maximum Reservable Bandwidth 643 Metric name: 645 Maximum Reservable Bandwidth 647 Metric Description: 649 To specify spatial and temporal maximum reservable bandwidth over 650 the specified source and destination. The value is corresponding 651 to the maximum bandwidth that can be reserved (motivated from RFC 652 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 653 the query context (e.g., PID to PID, or endpoint to endpoint). 655 Method of Measurement or Calculation: 657 Maximum Reserveable Bandwidth is the bandwidth measured between 658 two directly connected IS-IS neighbors or OSPF neighbors, See 659 section 3.5 of [RFC5305] for Measurement Method. 661 Units of Measurement: 663 The unit of measurement is byte per seconds. 665 Measurement Point(s) with Potential Measurement Domain: 667 See section 2.1, Data sources. 669 Measurement Timing: 671 See section 3.5 of [RFC5305] and section 5 of [RFC7810] for 672 Measurement Timing. 674 Use and Applications: 676 See section 3 for use and application. 678 Example 6: maxresbw value on source-destination endpoint pairs 680 POST/ endpointcost/lookup HTTP/1.1 681 Host: alto.example.com 682 Content-Length: TBA 683 Content-Type: application/alto-endpointcostparams+json 684 Accept: application/alto-endpointcost+json,application/alto-error+json 686 { 687 "cost-type" { "cost-mode": "numerical", 688 "cost-metric": "maxresbw"}, 689 "endpoints": { 690 "srcs": [ "ipv4 : 192.0.2.2" ], 691 "dsts": [ 692 "ipv4:192.0.2.89", 693 "ipv4:198.51.100.34", 694 "ipv6:2000::1:2345:6789:abcd" 695 ] 696 } 697 } 698 HTTP/1.1 200 OK 699 Content-Length: TBA 700 Content-Type: application/alto-endpointcost+json 701 { 702 "meta": { 703 "cost-type": { 704 "cost-mode": "numerical", 705 "cost-metric": "maxresbw" 706 } 707 }, 708 " endpoint-cost-map": { 709 "ipv4:192.0.2.2" { 710 "ipv4:192.0.2.89" : 0, 711 "ipv4:198.51.100.34": 2000, 712 "ipv6:2000::1:2345:6789:abcd": 5000, 713 } 714 } 715 } 717 8.2. Cost Metric: Link Residue Bandwidth 719 Metric name: 721 Residue Bandwidth 723 Metric Description: 725 To specify spatial and temporal residual bandwidth over the 726 specified source and destination. The value is calculated by 727 subtracting tunnel reservations from Maximum Bandwidth (motivated 728 from [RFC7810], Sec.4.5.). The spatial aggregation unit is 729 specified in the query context (e.g., PID to PID, or endpoint to 730 endpoint). 732 Method of Measurement or Calculation: 734 Residue Bandwidth is the Unidirectional Residue bandwidth measured 735 between two directly connected IS-IS neighbors or OSPF neighbors, 736 See section 4.5 of [RFC7810] for Measurement Method. 738 Units of Measurement: 740 The unit of measurement is byte per seconds. 742 Measurement Point(s) with Potential Measurement Domain: 744 See section 2.1, Data sources. 746 Measurement Timing: 748 See section 5 of [RFC7810] for Measurement Timing. 750 Use and Applications: 752 See section 3 for use and application. 754 Example 8: residuebw value on source-destination endpoint pairs 756 POST/ endpointcost/lookup HTTP/1.1 757 Host: alto.example.com 758 Content-Length: TBA 759 Content-Type: application/alto-endpointcostparams+json 760 Accept: application/alto-endpointcost+json,application/alto-error+json 762 { 763 "cost-type": { "cost-mode": "numerical", 764 "cost-metric": "residubw"}, 765 "endpoints": { 766 "srcs": [ "ipv4 : 192.0.2.2" ], 767 "dsts": [ 768 "ipv4:192.0.2.89", 769 "ipv4:198.51.100.34", 770 "ipv6:2000::1:2345:6789:abcd" 771 ] 772 } 773 } 775 HTTP/1.1 200 OK 776 Content-Length: TBA 777 Content-Type: application/alto-endpointcost+json 778 { 779 "meta": { 780 "cost-type" { 781 "cost-mode": "numerical", 782 "cost-metric": "residubw" 783 } 784 }, 785 "endpoint-cost-map" { 786 "ipv4:192.0.2.2" { 787 "ipv4:192.0.2.89" : 0, 788 "ipv4:198.51.100.34": 2000, 789 "ipv6:2000::1:2345:6789:abcd": 5000, 790 } 791 } 792 } 794 8.3. Cost Metric: Link Available Bandwidth 796 Metric name: 798 Available Bandwidth 800 Metric Description: 802 To specify spatial and temporal availaible bandwidth over the 803 specified source and destination. The value is calculated by 804 subtracting the measured bandwidth used for the actual forwarding 805 of best effort traffic from Residue Bandwidth (motivated from 806 [RFC7810], Sec.4.6.). The spatial aggregation level is specified 807 in the query context (e.g., PID to PID, or endpoint to endpoint). 809 Method of Measurement or Calculation: 811 Available bandwidth is the Unidirectional Available bandwidth 812 measured between two directly connected IS-IS neighbors or OSPF 813 neighbors, See section 4.6 of [RFC7810] for Measurement Method. 815 Units of Measurement: 817 The unit of measurement is byte per seconds. 819 Measurement Point(s) with Potential Measurement Domain: 821 See section 2.1, Data sources. 823 Measurement Timing: 825 See section 5 of [RFC7810] for Measurement Timing. 827 Use and Applications: 829 See section 3 for use and application. Besides, knowledge about 830 available bandwidth is essential for applications to distribute or 831 schedule their transmissions. The example below illustrates how 832 this metric is provided in the form of an ALTO calendar, as 833 specified in [XXXX] to help deciding "where" and "when" to 834 transmit. 836 Example 9: availbw value on source-destination endpoint pairs 838 This example assumes that the ALTO Server provides the values for 839 metric "availbw" in the form of an ALTO calendar and declares it 840 in its IRD. 842 POST /endpointcost/lookup HTTP/1.1 843 Host: alto.example.com 844 Content-Length: TBA 845 Content-Type: application/alto-endpointcostparams+json 846 Accept: application/alto-endpointcost+json,application/alto-error+json 848 { 849 "cost-type": { "cost-mode": "numerical", 850 "cost-metric": "availbw"}, 851 "calendared" : [true], 852 "endpoints": { 853 "srcs": [ "ipv4 : 192.0.2.2" ], 854 "dsts": [ 855 "ipv4:192.0.2.89", 856 "ipv4:198.51.100.34", 857 "ipv6:2000::1:2345:6789:abcd" 858 ] 859 } 860 } 862 HTTP/1.1 200 OK 863 Content-Length: TBA 864 Content-Type: application/alto-endpointcost+json 865 { 866 "meta": { 867 "cost-type": { 868 "cost-mode": "numerical", "cost-metric": "availbw" 869 } 870 "calendar-response-attributes" : [ 871 "calendar-start-time" : Tue, 1 Mar 2017 13:00:00 GMT, 872 "time-interval-size" : "1 hour", 873 "numb-intervals" : 8 874 ] 875 }, 877 "endpoint-cost-map": { 878 "ipv4:192.0.2.2" { 879 "ipv4:192.0.2.89" : [6,5,7,8,4,10,7,6], 880 "ipv4:198.51.100.34" : [7,4,6,8,5,9,6,7], 881 "ipv6:2000::1:2345:6789:abcd" : [7,6,8,5,7,9,6,8], 882 } 883 } 884 } 886 8.4. Cost Metric: Link Utilized Bandwidth 888 Metric name: 890 Utilized Bandwidth 892 Metric Description: 894 To specify spatial and temporal utilized bandwidth over the 895 specified source and destination. The value is corresponding to 896 the actual measured bandwidth used for all traffic (motivated from 897 [RFC7810], Sec.4.7.). The spatial aggregation level is specified 898 in the query context (e.g., PID to PID, or endpoint to endpoint). 900 Method of Measurement or Calculation: 902 Link Utilizated bandwidth is Unidirectional utilization bandwidth 903 measured between two directly connected IS-IS neighbors or OSPF 904 neighbors, See section 4.7 of [RFC7810] for Measurement Method. 906 Units of Measurement: 908 The unit of measurement is byte per seconds. 910 Measurement Point(s) with Potential Measurement Domain: 912 See section 2.1, Data sources. 914 Measurement Timing: 916 Link Utilized bandwidth is Unidirectional utilization bandwidth 917 measured between two directly connected IS-IS neighbors or OSPF 918 neighbors, See section 5 of [RFC7810] for Measurement Timing. 920 Use and Applications: 922 See section 3 for use and application. 924 Example 10: utilbw value on source-destination endpoint pairs 926 POST /endpointcost/lookup HTTP/1.1 927 Host: alto.example.com 928 Content-Length: TBA 929 Content-Type: application/alto-endpointcostparams+json 930 Accept: application/alto-endpointcost+json,application/alto-error+json 932 { 933 "cost-type": {"cost-mode" : "numerical", 934 "cost-metric" : "utilbw"}, 935 "endpoints": { 936 "srcs" : [ "ipv4 : 192.0.2.2" ], 937 "dsts" : [ 938 "ipv4:192.0.2.89", 939 "ipv4:198.51.100.34", 940 "ipv6:2000::1:2345:6789:abcd" 941 ] 942 } 943 } 945 HTTP/1.1 200 OK 946 Content-Length: TBA 947 Content-Type: application/alto-endpointcost+json 948 { 949 "meta": { 950 "cost type": { 951 "cost-mode": "numerical", 952 "cost-metric": "utilbw" 953 } 954 }, 955 "endpoint-cost-map": { 956 "ipv4:192.0.2.2" { 957 "ipv4:192.0.2.89" : 0, 958 "ipv4:198.51.100.34" : 2000, 959 "ipv6:2000::1:2345:6789:abcd" : 5000, 960 } 961 } 962 } 964 9. Security Considerations 966 The properties defined in this document present no security 967 considerations beyond those in Section 15 of the base ALTO 968 specification [ALTO]. 970 However concerns addressed in Sections "15.1 Authenticity and 971 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 972 from Authenticated ALTO Information" and "15.3 Confidentiality of 973 ALTO Information" remain of utmost importance. Indeed, TE 974 performance is a highly sensitive ISP information, therefore, sharing 975 TE metric values in numerical mode requires full mutual confidence 976 between the entities managing the ALTO Server and Client. Numerical 977 TE performance information will most likely be distributed by ALTO 978 Servers to Clients under strict and formal mutual trust agreements. 979 On the other hand, ALTO Clients must be cognizant on the risks 980 attached to such information that they would have acquired outside 981 formal conditions of mutual trust. 983 10. IANA Considerations 985 IANA has created and now maintains the "ALTO Cost Metric Registry", 986 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 987 located at . This document requests to add the 989 following entries to "ALTO Cost Meric Registry". 991 +----------+--------------+---------------------------------------------+ 992 |Namespace | Property | Reference | 993 +----------+--------------+---------------------------------------------+ 994 | | owdelay | [thisdraft] Section 3,[RFC2679] Section 3.6 | 995 | | rtt | [thisdraft] Section 4,[RFC2681],Section 2.6 | 996 | | pdv | [thisdraft] Section 5,[RFC3393],Section 2.6 | 997 | | hopcount | [thisdraft] Section 6,[RFC7285] | 998 | | pktloss | [thisdraft] Section 7,[RFC7680],Section 2.6 | 999 | | maxresbw | [thisdraft] Section 8.1,[RFC5305],Section 3.5| 1000 | | residbw | [thisdraft] Section 8.2,[RFC7810],Section 4.5| 1001 | | availbw | [thisdraft] Section 8.3,[RFC7810],Section 4.6| 1002 | | utilbw | [thisdraft] Section 8.4,[RFC7810,Section4.7] | 1003 +----------+--------------+---------------------------------------------+ 1005 11. References 1007 11.1. Normative References 1009 [I-D.ietf-idr-te-pm-bgp] 1010 Previdi, S., Wu, Q., Gredler, H., Ray, S., 1011 jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg, 1012 "BGP-LS Advertisement of IGP Traffic Engineering 1013 Performance Metric Extensions", draft-ietf-idr-te-pm- 1014 bgp-06 (work in progress), June 2017. 1016 [I-D.ietf-ippm-initial-registry] 1017 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 1018 "Initial Performance Metric Registry Entries", draft-ietf- 1019 ippm-initial-registry-04 (work in progress), June 2017. 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", March 1997. 1024 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1025 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1026 September 1999, . 1028 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1029 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1030 September 1999, . 1032 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1033 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1034 DOI 10.17487/RFC3393, November 2002, 1035 . 1037 [RFC4627] Crockford, D., "The application/json Media Type for 1038 JavaScript Object Notation (JSON)", RFC 4627, 1039 DOI 10.17487/RFC4627, July 2006, 1040 . 1042 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1043 Specifications: ABNF", STD 68, RFC 5234, 1044 DOI 10.17487/RFC5234, January 2008, 1045 . 1047 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1048 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1049 2008, . 1051 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1052 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1053 "Application-Layer Traffic Optimization (ALTO) Protocol", 1054 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1055 . 1057 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1058 Previdi, "OSPF Traffic Engineering (TE) Metric 1059 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1060 . 1062 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1063 Ed., "A One-Way Loss Metric for IP Performance Metrics 1064 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1065 2016, . 1067 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1068 S. Ray, "North-Bound Distribution of Link-State and 1069 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1070 DOI 10.17487/RFC7752, March 2016, 1071 . 1073 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1074 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1075 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1076 . 1078 11.2. Informative References 1080 [I-D.ietf-alto-deployments] 1081 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1082 S. Previdi, "ALTO Deployment Considerations", draft-ietf- 1083 alto-deployments-16 (work in progress), July 2016. 1085 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 1086 Development", RFC 6390, July 2011. 1088 Appendix A. Open Issue List 1090 We need to consider to add Cellular endpoint format support in the 1091 example, the Cellular endpoint format is specified in draft- 1092 randriamasy-alto-cellular-adresses. 1094 Authors' Addresses 1096 Qin Wu 1097 Huawei 1098 101 Software Avenue, Yuhua District 1099 Nanjing, Jiangsu 210012 1100 China 1102 Email: bill.wu@huawei.com 1104 Y. Richard Yang 1105 Yale University 1106 51 Prospect St 1107 New Haven, CT 06520 1108 USA 1110 Email: yry@cs.yale.edu 1111 Young Lee 1112 Huawei 1113 1700 Alma Drive, Suite 500 1114 Plano, TX 75075 1115 USA 1117 Email: leeyoung@huawei.com 1119 Dhruv Dhody 1120 Huawei 1121 Leela Palace 1122 Bangalore, Karnataka 560008 1123 INDIA 1125 Email: dhruv.ietf@gmail.com 1127 Sabine Randriamasy 1128 Nokia Bell Labs 1129 Route de Villejust 1130 Nozay 91460 1131 FRANCE 1133 Email: sabine.randriamasy@nokia-bell-labs.com