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