idnits 2.17.1 draft-ietf-alto-performance-metrics-03.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 (December 22, 2017) is 2310 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 989, but not defined == Missing Reference: 'ALTO-DEPLOYMENT' is mentioned on line 197, but not defined == Missing Reference: 'RFC3630' is mentioned on line 200, but not defined == Missing Reference: 'RFC3784' is mentioned on line 200, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'OSPF-TE' is mentioned on line 200, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 200, but not defined == Missing Reference: 'BGP-LS' is mentioned on line 200, but not defined == Missing Reference: 'BGP-PM' is mentioned on line 200, but not defined == Missing Reference: 'XXXX' is mentioned on line 855, but not defined -- Looks like a reference, but probably isn't: '6' on line 903 -- Looks like a reference, but probably isn't: '5' on line 903 -- Looks like a reference, but probably isn't: '7' on line 903 -- Looks like a reference, but probably isn't: '8' on line 903 -- Looks like a reference, but probably isn't: '4' on line 902 -- Looks like a reference, but probably isn't: '10' on line 901 -- Looks like a reference, but probably isn't: '9' on line 903 == Unused Reference: 'I-D.ietf-idr-te-pm-bgp' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC7471' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1106, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-08 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-05 ** 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: June 25, 2018 Yale University 6 Y. Lee 7 D. Dhody 8 Huawei 9 S. Randriamasy 10 Nokia Bell Labs 11 December 22, 2017 13 ALTO Performance Cost Metrics 14 draft-ietf-alto-performance-metrics-03 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 June 25, 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 (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 8.3. Cost Metric: Link Available Bandwidth . . . . . . . . . . 20 95 8.4. Cost Metric: Link Utilized Bandwidth . . . . . . . . . . 23 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 100 11.2. Informative References . . . . . . . . . . . . . . . . . 27 101 Appendix A. Open Issue List . . . . . . . . . . . . . . . . . . 28 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 104 1. Introduction 106 Cost Metric is a basic concept in Application-Layer Traffic 107 Optimization (ALTO). It is used in both the Cost Map Service and the 108 Endpoint Cost Service. In particular, applications may benefit from 109 knowing network performance measured on several Cost Metrics. For 110 example, a more delay-sensitive application may focus on latency, and 111 a more bandwidth-sensitive application may focus on available 112 bandwidth. 114 This document introduces a set of new cost metrics, listed in 115 Table 1, to support the aforementioned applications and allow them to 116 determine "where" to connect based on network performance criteria. 117 Hence, this document extends the base ALTO protocol [ALTO], which 118 defines only a single cost metric, i.e., the generic "routingcost" 119 metric (Sec. 14.2 of ALTO base specification [ALTO]). 121 +----------+--------------+---------------------------------------------+ 122 |Namespace | Property | Reference | 123 +----------+--------------+---------------------------------------------+ 124 | | owdelay | See Section 3,[RFC2679] Section 3.6 | 125 | | rtt | See Section 4,[RFC2681] Section 2.6 | 126 | | pdv | See Section 5,[RFC3393] Section 2.6 | 127 | | hopcount | See Section 6,[RFC7285] | 128 | | pktloss | See Section 7,[RFC7680] Section 2.6 | 129 | | maxresbw | See Section 8.1,[RFC5305] Section 3.5 | 130 | | residbw | See Section 8.2,[RFC7810] Section 4.5 | 131 | | availbw | See Section 8.3,[RFC7810] Section 4.6 | 132 | | utilbw | See Section 8.4,[RFC7810] Section 4.7 | 133 +----------+--------------+---------------------------------------------+ 134 Table 1. 136 The purpose of this draft is to list the metrics likely to be exposed 137 to ALTO Clients, including those already specified in other 138 standardization groups and as such it does not claim novelty on all 139 the specified metrics. Some metrics may have values produced by 140 standard measurement methods such as those specified in IPPM, some 141 may be ISP dependent such as those registered in ISIS or OSPF-TE. In 142 this case, this document will refer to the relevant specifications. 144 An ALTO server may provide a subset of the cost metrics described in 145 this document. These cost metrics can be retrieved and aggregated 146 from routing protocols or other traffic measurement management tools 147 (See Figure 1). Note that these cost metrics are optional and not 148 all them need to be exposed to applications. For example, those that 149 are subject to privacy concerns should not be provided to 150 unauthorized ALTO clients. 152 +--------+ +--------+ +--------+ 153 | Client | | Client | | Client | 154 +----^---+ +---^----+ +---^----+ 155 | | | 156 +-----------|-----------+ 157 NBI |ALTO protocol 158 | 159 | 160 +--+-----+ retrieval +---------+ 161 | ALTO |<----------------| Routing | 162 | Server | and aggregation| | 163 | |<-------------+ | Protocol| 164 +--------+ | +---------+ 165 | 166 | +---------+ 167 | |Management 168 ---| | 169 | Tool | 170 +---------+ 171 Figure 1.End-to-End Path Cost Metrics Exposing 173 When an ALTO server supports a cost metric defined in this document, 174 it MUST announce this metric in its IRD. 176 Additionally, future versions of this document may define network 177 metric values that stem from both measurements and provider policies 178 such as many metrics related to end-to-end path bandwidth. 180 As for the reliability and trust in the exposed metric values, 181 applications SHOULD rapidly give up using ALTO-based guidance if they 182 feel the exposed information does not preserve their performance 183 level or even degrades it. 185 Following the ALTO base protocol, this document uses JSON to specify 186 the value type of each defined metric. See [RFC4627] for JSON data 187 type specification. 189 2. Challenges on data sources and computation of ALTO performance 190 metrics 192 2.1. Data sources Challenge 194 An ALTO server needs data sources to compute the cost metrics 195 described in this document. This document does not define the exact 196 data sources. For example, the ALTO server may use log servers or 197 the OAM system as its data source [ALTO-DEPLOYMENT]. In particular, 198 the cost metrics defined in this document can be computed using 199 routing systems as the data sources. Mechanisms defined in 200 [RFC3630], [RFC3784], [OSPF-TE], [ISIS-TE], [BGP-LS] and [BGP-PM] 201 that allow an ALTO Server to retrieve and derive the necessary 202 information to compute the metrics that we describe in this document. 204 One challenge lies in the data sources originating the ALTO metric 205 values. The very important purpose of ALTO is to guide application 206 traffic with provider network centric information that may be exposed 207 to ALTO Clients in the form of network performance metric values. 208 Not all of these metrics have values produced by standardized 209 measurement methods or routing protocols. Some of them involve 210 provider-centric policy considerations. Some of them may describe 211 wireless or cellular networks. To reliably guide users and 212 applications while preserving provider privacy, ALTO performance 213 metric values may also add abstraction to measurements or provide 214 unitless performance scores. 216 2.2. ALTO performance metrics Computation Challenges 218 The metric values exposed by an ALTO server may result from 219 additional processing on measurements from data sources to compute 220 exposed metrics. This may involve data processing tasks such as 221 aggregating the results across multiple systems, removing outliers, 222 and creating additional statistics. There are two challenges on 223 computation of ALTO performance metrics. 225 2.2.1. Configuration Parameters Challenge 227 Performance metrics often depend on configuration parameters. For 228 example, the value of packet loss rate depends on the measurement 229 interval and varies over time. To handle this issue, an ALTO server 230 may collect data on time periods covering the previous and current 231 time or only collect data on present time. The ALTO server may 232 further aggregate these data to provide an abstract and unified view 233 that can be more useful to applications. To make the ALTO client 234 better understand how to use these performance data, the ALTO server 235 may provide the client with the validity period of the exposed metric 236 values. 238 2.2.2. Availability of end to end path values Challenge 240 Applications value information relating to bandwidth availability 241 where as bandwidth related metrics can often be only measured at the 242 link level. This document specifies a set of link-level bandwidth 243 related values that may be exposed as such by an ALTO server. The 244 server may also expose other metrics derived from their aggregation 245 and having different levels of endpoint granularity, e.g. link 246 endpoints or session endpoints. The metric specifications may also 247 expose the utilized aggregation laws. 249 3. Cost Metric: POWDelay 251 Metric name: 253 Periodic One Way Delay 255 Metric Description: 257 To specify spatial and temporal aggregated delay of a stream of 258 packets exchanged between the specified source and destination or 259 the time that the packet spends to travel from source to 260 destination. The spatial aggregation level is specified in the 261 query context (e.g., PID to PID, or endpoint to endpoint). 263 Method of Measurement or Calculation: 265 See section 8.3 of [I-D.ietf-ippm-initial-registry] for 266 Measurement Method. 268 Units of Measurement: 270 See section 8.4.3 of [I-D.ietf-ippm-initial-registry] for 271 Measurement Unit. The unit is expressed in seconds. 273 Measurement Point(s) with Potential Measurement Domain: 275 See section 2.1, Data sources. 277 Measurement Timing: 279 See section 8.3.5 of [I-D.ietf-ippm-initial-registry] for 280 Measurement Timing. 282 Use and Applications: 284 The Metric value Type is a single 'JSONNumber' type value 285 containing a non-negative integer component that may be followed 286 by an exponent part. The Cost Mode is encoded as a US-ASCII 287 string. 289 This metric could be used as a cost metric constraint attribute 290 used either together with cost metric attribute 'routingcost' or 291 on its own or as a returned cost metric in the response. 293 Example 1: Delay value on source-destination endpoint pairs 295 POST /endpointcost/lookup HTTP/1.1 296 Host: alto.example.com 297 Content-Length: TBA 298 Content-Type: application/alto-endpointcostparams+json 299 Accept: application/alto-endpointcost+json,application/alto-error+json 301 { 302 "cost-type": {"cost-mode" : "numerical", 303 "cost-metric" : "powdelay"}, 304 "endpoints" : { 305 "srcs": [ "ipv4:192.0.2.2" ], 306 "dsts": [ 307 "ipv4:192.0.2.89", 308 "ipv4:198.51.100.34", 309 "ipv6:2000::1:2345:6789:abcd" 310 ] 311 } 312 } 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 2: Round Trip Delay value on source-destination endpoint pairs 370 POST /endpointcost/lookup HTTP/1.1 371 Host: alto.example.com 372 Content-Length: TBA 373 Content-Type: application/alto-endpointcostparams+json 374 Accept: application/alto-endpointcost+json,application/alto-error+json 376 { 377 "cost-type": {"cost-mode" : "numerical", 378 "cost-metric" : "rtt"}, 379 "endpoints" : { 380 "srcs": [ "ipv4:192.0.2.2" ], 381 "dsts": [ 382 "ipv4:192.0.2.89", 383 "ipv4:198.51.100.34", 384 "ipv6:2000::1:2345:6789:abcd" 385 ] 386 } 387 } 388 HTTP/1.1 200 OK 389 Content-Length: TBA 390 Content-Type: application/alto-endpointcost+json 391 { 392 "meta" :{ 393 "cost-type": {"cost-mode" : "numerical", 394 "cost-metric" : "rtt" 395 } 396 }, 397 "endpoint-cost-map" : { 398 "ipv4:192.0.2.2": { 399 "ipv4:192.0.2.89" : 4, 400 "ipv4:198.51.100.34" : 3, 401 "ipv6:2000::1:2345:6789:abcd" : 2, 402 } 403 } 404 } 406 5. Cost Metric: PDV 408 Metric name: 410 Packet Delay Variation 412 Metric Description: 414 To specify spatial and temporal aggregated jitter (packet delay 415 variation) with respect to the minimum delay observed on the 416 stream over the specified source and destination. The spatial 417 aggregation level is specified in the query context (e.g., PID to 418 PID, or endpoint to endpoint). 420 Method of Measurement or Calculation: 422 See section 5.3 of [I-D.ietf-ippm-initial-registry] for 423 Measurement Method. 425 Units of Measurement: 427 See section 5.4.4 of [I-D.ietf-ippm-initial-registry] for 428 Measurement Unit. The unit is expressed in seconds. 430 Measurement Point(s) with Potential Measurement Domain: 432 See section 2.1, Data sources. 434 Measurement Timing: 436 See section 5.3.5 of [I-D.ietf-ippm-initial-registry] for 437 Measurement Timing. 439 Use and Applications: 441 See section 3 for use and application. 443 Example 3: Delay jitter value on source-destination endpoint pairs 445 POST /endpointcost/lookup HTTP/1.1 446 Host: alto.example.com 447 Content-Length: TBA 448 Content-Type: application/alto-endpointcostparams+json 449 Accept: application/alto-endpointcost+json,application/alto-error+json 451 { 452 "cost-type": {"cost-mode" : "numerical", 453 "cost-metric" : "delayjitter"}, 454 "endpoints" : { 455 "srcs": [ "ipv4:192.0.2.2" ], 456 "dsts": [ 457 "ipv4:192.0.2.89", 458 "ipv4:198.51.100.34", 459 "ipv6:2000::1:2345:6789:abcd" 460 ] 461 } 462 } 463 Example 3: Delay jitter value on source-destination endpoint pairs 465 POST /endpointcost/lookup HTTP/1.1 466 Host: alto.example.com 467 Content-Length: TBA 468 Content-Type: application/alto-endpointcostparams+json 469 Accept: application/alto-endpointcost+json,application/alto-error+json 471 { 472 "cost-type": {"cost-mode" : "numerical", 473 "cost-metric" : "delayjitter"}, 474 "endpoints" : { 475 "srcs": [ "ipv4:192.0.2.2" ], 476 "dsts": [ 477 "ipv4:192.0.2.89", 478 "ipv4:198.51.100.34", 479 "ipv6:2000::1:2345:6789:abcd" 480 ] 481 } 482 } 483 HTTP/1.1 200 OK 484 Content-Length: TBA 485 Content-Type: application/alto-endpointcost+json 486 { 487 "meta": { 488 "cost type": { 489 "cost-mode": "numerical", 490 "cost-metric":"delayjitter" 491 } 492 }, 493 "endpoint-cost-map": { 494 "ipv4:192.0.2.2": { 495 "ipv4:192.0.2.89" : 0 496 "ipv4:198.51.100.34" : 1 497 "ipv6:2000::1:2345:6789:abcd" : 5 498 } 499 } 500 } 502 6. Cost Metric: Hop Count 504 The metric hopcount is mentioned in [ALTO] as an example. This 505 section further clarifies its properties. 507 Metric name: 509 Hop count 511 Metric Description: 513 To specify the number of hops in the path between the source 514 endpoint and the destination endpoint. The hop count is a basic 515 measurement of distance in a network and can be exposed as Router 516 Hops, IP hops or other hops in direct relation to the routing 517 protocols originating this information. It might also result from 518 the aggregation of such information. 520 Method of Measurement or Calculation: 522 See section 2.2, Computation of metrics. 524 Units of Measurement: 526 The unit is integer number. 528 Measurement Point(s) with Potential Measurement Domain: 530 See section 2.1, Data sources. 532 Measurement Timing: 534 See section 2.1, second paragraph for Measurement Timing. 536 Use and Applications: 538 See section 3 for use and application. 540 Example 4: hopcount value on source-destination endpoint pairs 542 POST /endpointcost/lookup HTTP/1.1 543 Host: alto.example.com 544 Content-Length: TBA 545 Content-Type: application/alto-endpointcostparams+json 546 Accept: application/alto-endpointcost+json,application/alto-error+json 548 { 549 "cost-type": {"cost-mode" : "numerical", 550 "cost-metric" : "hopcount"}, 551 "endpoints" : { 552 "srcs": [ "ipv4:192.0.2.2" ], 553 "dsts": [ 554 "ipv4:192.0.2.89", 555 "ipv4:198.51.100.34", 556 "ipv6:2000::1:2345:6789:abcd" 557 ] 558 } 559 } 561 HTTP/1.1 200 OK 562 Content-Length: TBA 563 Content-Type: application/alto-endpointcost+json 564 { 565 "meta": { 566 "cost type": { 567 "cost-mode": "numerical", 568 "cost-metric":"hopcount"} 569 } 570 }, 571 "endpoint-cost-map": { 572 "ipv4:192.0.2.2": { 573 "ipv4:192.0.2.89" : 5, 574 "ipv4:198.51.100.34": 3, 575 "ipv6:2000::1:2345:6789:abcd" : 2, 576 } 577 } 578 } 580 7. Cost Metric: Packet Loss 582 Metric name: 584 Packet loss 586 Metric Description: 588 To specify spatial and temporal aggregated packet loss over the 589 specified source and destination. The spatial aggregation level 590 is specified in the query context (e.g., PID to PID, or endpoint 591 to endpoint). 593 Method of Measurement or Calculation: 595 See section 2.6 of [RFC7680] for Measurement Method. 597 Units of Measurement: 599 The unit is percentile. 601 Measurement Point(s) with Potential Measurement Domain: 603 See section 2.1, Data sources. 605 Measurement Timing: 607 See section 2 and section3 of [RFC7680] for Measurement Timing. 609 Use and Applications: 611 See section 3 for use and application. 613 Example 5: pktloss value on source-destination endpoint pairs 615 POST /endpointcost/lookup HTTP/1.1 616 Host: alto.example.com 617 Content-Length: TBA 618 Content-Type: application/alto-endpointcostparams+json 619 Accept: application/alto-endpointcost+json,application/alto-error+json 621 { 622 "cost-type": {"cost-mode" : "numerical", 623 "cost-metric" : "pktloss"}, 624 "endpoints" : { 625 "srcs": [ "ipv4:192.0.2.2" ], 626 "dsts": [ 627 "ipv4:192.0.2.89", 628 "ipv4:198.51.100.34", 629 "ipv6:2000::1:2345:6789:abcd" 630 ] 631 } 632 } 634 HTTP/1.1 200 OK 635 Content-Length: TBA 636 Content-Type: application/alto-endpointcost+json 637 { 638 "meta": { 639 "cost type": { 640 "cost-mode": "numerical", 641 "cost-metric":"pktloss"} 642 } 643 }, 644 "endpoint-cost-map": { 645 "ipv4:192.0.2.2": { 646 "ipv4:192.0.2.89" : 0, 647 "ipv4:198.51.100.34": 1, 648 "ipv6:2000::1:2345:6789:abcd" : 2, 649 } 650 } 651 } 653 8. Traffic Engineering Performance Cost Metrics 655 This section introduces ALTO network performance metrics that may be 656 aggregated from network metrics measured on links and specified in 657 other documents. In particular, the bandwidth related metrics 658 specified in this section are only available through link level 659 measurements. For some of these metrics, the ALTO Server may further 660 expose aggregated values while specifying the aggregation laws. 662 8.1. Cost Metric: Link Maximum Reservable Bandwidth 664 Metric name: 666 Maximum Reservable Bandwidth 668 Metric Description: 670 To specify spatial and temporal maximum reservable bandwidth over 671 the specified source and destination. The value is corresponding 672 to the maximum bandwidth that can be reserved (motivated from RFC 673 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 674 the query context (e.g., PID to PID, or endpoint to endpoint). 676 Method of Measurement or Calculation: 678 Maximum Reserveable Bandwidth is the bandwidth measured between 679 two directly connected IS-IS neighbors or OSPF neighbors, See 680 section 3.5 of [RFC5305] for Measurement Method. 682 Units of Measurement: 684 The unit of measurement is byte per seconds. 686 Measurement Point(s) with Potential Measurement Domain: 688 See section 2.1, Data sources. 690 Measurement Timing: 692 See section 3.5 of [RFC5305] and section 5 of [RFC7810] for 693 Measurement Timing. 695 Use and Applications: 697 See section 3 for use and application. 699 Example 6: maxresbw value on source-destination endpoint pairs 701 POST/ endpointcost/lookup HTTP/1.1 702 Host: alto.example.com 703 Content-Length: TBA 704 Content-Type: application/alto-endpointcostparams+json 705 Accept: application/alto-endpointcost+json,application/alto-error+json 707 { 708 "cost-type" { "cost-mode": "numerical", 709 "cost-metric": "maxresbw"}, 710 "endpoints": { 711 "srcs": [ "ipv4 : 192.0.2.2" ], 712 "dsts": [ 713 "ipv4:192.0.2.89", 714 "ipv4:198.51.100.34", 715 "ipv6:2000::1:2345:6789:abcd" 716 ] 717 } 718 } 720 HTTP/1.1 200 OK 721 Content-Length: TBA 722 Content-Type: application/alto-endpointcost+json 723 { 724 "meta": { 725 "cost-type": { 726 "cost-mode": "numerical", 727 "cost-metric": "maxresbw" 728 } 729 }, 730 " endpoint-cost-map": { 731 "ipv4:192.0.2.2" { 732 "ipv4:192.0.2.89" : 0, 733 "ipv4:198.51.100.34": 2000, 734 "ipv6:2000::1:2345:6789:abcd": 5000, 735 } 736 } 737 } 739 8.2. Cost Metric: Link Residue Bandwidth 741 Metric name: 743 Residue Bandwidth 745 Metric Description: 747 To specify spatial and temporal residual bandwidth over the 748 specified source and destination. The value is calculated by 749 subtracting tunnel reservations from Maximum Bandwidth (motivated 750 from [RFC7810], Sec.4.5.). The spatial aggregation unit is 751 specified in the query context (e.g., PID to PID, or endpoint to 752 endpoint). 754 Method of Measurement or Calculation: 756 Residue Bandwidth is the Unidirectional Residue bandwidth measured 757 between two directly connected IS-IS neighbors or OSPF neighbors, 758 See section 4.5 of [RFC7810] for Measurement Method. 760 Units of Measurement: 762 The unit of measurement is byte per seconds. 764 Measurement Point(s) with Potential Measurement Domain: 766 See section 2.1, Data sources. 768 Measurement Timing: 770 See section 5 of [RFC7810] for Measurement Timing. 772 Use and Applications: 774 See section 3 for use and application. 776 Example 7: residuebw value on source-destination endpoint pairs 778 POST/ endpointcost/lookup HTTP/1.1 779 Host: alto.example.com 780 Content-Length: TBA 781 Content-Type: application/alto-endpointcostparams+json 782 Accept: application/alto-endpointcost+json,application/alto-error+json 784 { 785 "cost-type": { "cost-mode": "numerical", 786 "cost-metric": "residubw"}, 787 "endpoints": { 788 "srcs": [ "ipv4 : 192.0.2.2" ], 789 "dsts": [ 790 "ipv4:192.0.2.89", 791 "ipv4:198.51.100.34", 792 "ipv6:2000::1:2345:6789:abcd" 793 ] 794 } 795 } 797 HTTP/1.1 200 OK 798 Content-Length: TBA 799 Content-Type: application/alto-endpointcost+json 800 { 801 "meta": { 802 "cost-type" { 803 "cost-mode": "numerical", 804 "cost-metric": "residubw" 805 } 806 }, 807 "endpoint-cost-map" { 808 "ipv4:192.0.2.2" { 809 "ipv4:192.0.2.89" : 0, 810 "ipv4:198.51.100.34": 2000, 811 "ipv6:2000::1:2345:6789:abcd": 5000, 812 } 813 } 814 } 816 8.3. Cost Metric: Link Available Bandwidth 818 Metric name: 820 Available Bandwidth 822 Metric Description: 824 To specify spatial and temporal availaible bandwidth over the 825 specified source and destination. The value is calculated by 826 subtracting the measured bandwidth used for the actual forwarding 827 of best effort traffic from Residue Bandwidth (motivated from 828 [RFC7810], Sec.4.6.). The spatial aggregation level is specified 829 in the query context (e.g., PID to PID, or endpoint to endpoint). 831 Method of Measurement or Calculation: 833 Available bandwidth is the Unidirectional Available bandwidth 834 measured between two directly connected IS-IS neighbors or OSPF 835 neighbors, See section 4.6 of [RFC7810] for Measurement Method. 837 Units of Measurement: 839 The unit of measurement is byte per seconds. 841 Measurement Point(s) with Potential Measurement Domain: 843 See section 2.1, Data sources. 845 Measurement Timing: 847 See section 5 of [RFC7810] for Measurement Timing. 849 Use and Applications: 851 See section 3 for use and application. Besides, knowledge about 852 available bandwidth is essential for applications to distribute or 853 schedule their transmissions. The example below illustrates how 854 this metric is provided in the form of an ALTO calendar, as 855 specified in [XXXX] to help deciding "where" and "when" to 856 transmit. 858 Example 8: availbw value on source-destination endpoint pairs 860 This example assumes that the ALTO Server provides the values for 861 metric "availbw" in the form of an ALTO calendar and declares it 862 in its IRD. 864 POST /endpointcost/lookup HTTP/1.1 865 Host: alto.example.com 866 Content-Length: TBA 867 Content-Type: application/alto-endpointcostparams+json 868 Accept: application/alto-endpointcost+json,application/alto-error+json 870 { 871 "cost-type": { "cost-mode": "numerical", 872 "cost-metric": "availbw"}, 873 "calendared" : [true], 874 "endpoints": { 875 "srcs": [ "ipv4 : 192.0.2.2" ], 876 "dsts": [ 877 "ipv4:192.0.2.89", 878 "ipv4:198.51.100.34", 879 "ipv6:2000::1:2345:6789:abcd" 880 ] 881 } 882 } 884 HTTP/1.1 200 OK 885 Content-Length: TBA 886 Content-Type: application/alto-endpointcost+json 887 { 888 "meta": { 889 "cost-type": { 890 "cost-mode": "numerical", "cost-metric": "availbw" 891 } 892 "calendar-response-attributes" : [ 893 "calendar-start-time" : Tue, 1 Mar 2017 13:00:00 GMT, 894 "time-interval-size" : "1 hour", 895 "numb-intervals" : 8 896 ] 897 }, 899 "endpoint-cost-map": { 900 "ipv4:192.0.2.2" { 901 "ipv4:192.0.2.89" : [6,5,7,8,4,10,7,6], 902 "ipv4:198.51.100.34" : [7,4,6,8,5,9,6,7], 903 "ipv6:2000::1:2345:6789:abcd" : [7,6,8,5,7,9,6,8], 904 } 905 } 906 } 908 8.4. Cost Metric: Link Utilized Bandwidth 910 Metric name: 912 Utilized Bandwidth 914 Metric Description: 916 To specify spatial and temporal utilized bandwidth over the 917 specified source and destination. The value is corresponding to 918 the actual measured bandwidth used for all traffic (motivated from 919 [RFC7810], Sec.4.7.). The spatial aggregation level is specified 920 in the query context (e.g., PID to PID, or endpoint to endpoint). 922 Method of Measurement or Calculation: 924 Link Utilizated bandwidth is Unidirectional utilization bandwidth 925 measured between two directly connected IS-IS neighbors or OSPF 926 neighbors, See section 4.7 of [RFC7810] for Measurement Method. 928 Units of Measurement: 930 The unit of measurement is byte per seconds. 932 Measurement Point(s) with Potential Measurement Domain: 934 See section 2.1, Data sources. 936 Measurement Timing: 938 Link Utilized bandwidth is Unidirectional utilization bandwidth 939 measured between two directly connected IS-IS neighbors or OSPF 940 neighbors, See section 5 of [RFC7810] for Measurement Timing. 942 Use and Applications: 944 See section 3 for use and application. 946 Example 9: utilbw value on source-destination endpoint pairs 948 POST /endpointcost/lookup HTTP/1.1 949 Host: alto.example.com 950 Content-Length: TBA 951 Content-Type: application/alto-endpointcostparams+json 952 Accept: application/alto-endpointcost+json,application/alto-error+json 954 { 955 "cost-type": {"cost-mode" : "numerical", 956 "cost-metric" : "utilbw"}, 957 "endpoints": { 958 "srcs" : [ "ipv4 : 192.0.2.2" ], 959 "dsts" : [ 960 "ipv4:192.0.2.89", 961 "ipv4:198.51.100.34", 962 "ipv6:2000::1:2345:6789:abcd" 963 ] 964 } 965 } 966 HTTP/1.1 200 OK 967 Content-Length: TBA 968 Content-Type: application/alto-endpointcost+json 969 { 970 "meta": { 971 "cost type": { 972 "cost-mode": "numerical", 973 "cost-metric": "utilbw" 974 } 975 }, 976 "endpoint-cost-map": { 977 "ipv4:192.0.2.2" { 978 "ipv4:192.0.2.89" : 0, 979 "ipv4:198.51.100.34" : 2000, 980 "ipv6:2000::1:2345:6789:abcd" : 5000, 981 } 982 } 983 } 985 9. Security Considerations 987 The properties defined in this document present no security 988 considerations beyond those in Section 15 of the base ALTO 989 specification [ALTO]. 991 However concerns addressed in Sections "15.1 Authenticity and 992 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 993 from Authenticated ALTO Information" and "15.3 Confidentiality of 994 ALTO Information" remain of utmost importance. Indeed, TE 995 performance is a highly sensitive ISP information, therefore, sharing 996 TE metric values in numerical mode requires full mutual confidence 997 between the entities managing the ALTO Server and Client. Numerical 998 TE performance information will most likely be distributed by ALTO 999 Servers to Clients under strict and formal mutual trust agreements. 1000 On the other hand, ALTO Clients must be cognizant on the risks 1001 attached to such information that they would have acquired outside 1002 formal conditions of mutual trust. 1004 10. IANA Considerations 1006 IANA has created and now maintains the "ALTO Cost Metric Registry", 1007 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1008 located at . This document requests to add the 1010 following entries to "ALTO Cost Meric Registry". 1012 +----------+--------------+----------------------------------------------+ 1013 |Namespace | Property | Reference | 1014 +----------+--------------+----------------------------------------------+ 1015 | | owdelay | [thisdraft] Section 3,[RFC2679] Section 3.6 | 1016 | | rtt | [thisdraft] Section 4,[RFC2681],Section 2.6 | 1017 | | pdv | [thisdraft] Section 5,[RFC3393],Section 2.6 | 1018 | | hopcount | [thisdraft] Section 6,[RFC7285] | 1019 | | pktloss | [thisdraft] Section 7,[RFC7680],Section 2.6 | 1020 | | maxresbw | [thisdraft] Section 8.1,[RFC5305],Section 3.5| 1021 | | residbw | [thisdraft] Section 8.2,[RFC7810],Section 4.5| 1022 | | availbw | [thisdraft] Section 8.3,[RFC7810],Section 4.6| 1023 | | utilbw | [thisdraft] Section 8.4,[RFC7810,Section4.7] | 1024 +----------+--------------+----------------------------------------------+ 1026 11. References 1028 11.1. Normative References 1030 [I-D.ietf-idr-te-pm-bgp] 1031 Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., 1032 Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of 1033 IGP Traffic Engineering Performance Metric Extensions", 1034 draft-ietf-idr-te-pm-bgp-08 (work in progress), August 1035 2017. 1037 [I-D.ietf-ippm-initial-registry] 1038 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 1039 "Initial Performance Metric Registry Entries", draft-ietf- 1040 ippm-initial-registry-05 (work in progress), October 2017. 1042 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1043 Requirement Levels", March 1997. 1045 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1046 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1047 September 1999, . 1049 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1050 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1051 September 1999, . 1053 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1054 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1055 DOI 10.17487/RFC3393, November 2002, 1056 . 1058 [RFC4627] Crockford, D., "The application/json Media Type for 1059 JavaScript Object Notation (JSON)", RFC 4627, 1060 DOI 10.17487/RFC4627, July 2006, 1061 . 1063 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1064 Specifications: ABNF", STD 68, RFC 5234, 1065 DOI 10.17487/RFC5234, January 2008, 1066 . 1068 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1069 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1070 2008, . 1072 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1073 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1074 "Application-Layer Traffic Optimization (ALTO) Protocol", 1075 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1076 . 1078 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1079 Previdi, "OSPF Traffic Engineering (TE) Metric 1080 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1081 . 1083 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1084 Ed., "A One-Way Loss Metric for IP Performance Metrics 1085 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1086 2016, . 1088 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1089 S. Ray, "North-Bound Distribution of Link-State and 1090 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1091 DOI 10.17487/RFC7752, March 2016, 1092 . 1094 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1095 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1096 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1097 . 1099 11.2. Informative References 1101 [I-D.ietf-alto-deployments] 1102 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1103 S. Previdi, "ALTO Deployment Considerations", draft-ietf- 1104 alto-deployments-16 (work in progress), July 2016. 1106 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 1107 Development", RFC 6390, July 2011. 1109 Appendix A. Open Issue List 1111 We need to consider to add Cellular endpoint format support in the 1112 example, the Cellular endpoint format is specified in draft- 1113 randriamasy-alto-cellular-adresses. 1115 Authors' Addresses 1117 Qin Wu 1118 Huawei 1119 101 Software Avenue, Yuhua District 1120 Nanjing, Jiangsu 210012 1121 China 1123 Email: bill.wu@huawei.com 1125 Y. Richard Yang 1126 Yale University 1127 51 Prospect St 1128 New Haven, CT 06520 1129 USA 1131 Email: yry@cs.yale.edu 1133 Young Lee 1134 Huawei 1135 1700 Alma Drive, Suite 500 1136 Plano, TX 75075 1137 USA 1139 Email: leeyoung@huawei.com 1141 Dhruv Dhody 1142 Huawei 1143 Leela Palace 1144 Bangalore, Karnataka 560008 1145 INDIA 1147 Email: dhruv.ietf@gmail.com 1148 Sabine Randriamasy 1149 Nokia Bell Labs 1150 Route de Villejust 1151 Nozay 91460 1152 FRANCE 1154 Email: sabine.randriamasy@nokia-bell-labs.com