idnits 2.17.1 draft-wu-alto-json-te-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ALTO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 504 has weird spacing: '...inkName link-...' == Line 515 has weird spacing: '...inkName link-...' == Line 526 has weird spacing: '...inkName link-...' == Line 542 has weird spacing: '...inkName link-...' == Line 556 has weird spacing: '...inkName link-...' == (2 more instances...) -- The document date (October 21, 2013) is 3832 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: 'RFC3630' is mentioned on line 563, but not defined == Missing Reference: 'RFC3784' is mentioned on line 563, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'TBD' is mentioned on line 575, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 692, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 720, but not defined == Missing Reference: 'IEEE.754.2008' is mentioned on line 829, but not defined == Unused Reference: 'RFC6390' is defined on line 757, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-16 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-03 == Outdated reference: A later version (-03) exists of draft-wu-idr-te-pm-bgp-02 == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-01 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-te-metric-extensions-04 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 3 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Q. Wu 3 Internet-Draft Y. Lee 4 Intended status: Standards Track D. Dhody 5 Expires: April 24, 2014 Huawei 6 October 21, 2013 8 ALTO Extensions for Traffic Engineering (TE) performance metrics in JSON 9 format 10 draft-wu-alto-json-te-02 12 Abstract 14 Cost metric is a basic concept in Application-Layer Traffic 15 Optimization (ALTO). It is used in both the Cost Map Service and the 16 Endpoint Cost Service. However the base protocol defines only a 17 single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 18 of ALTO base specification [ALTO]). In practice, applications may 19 request network information on other cost (including performance) 20 metrics. 22 In this document, we define five new base metrics which are delay, 23 jitter, pktloss (packet loss), bandwidth and hopcount. These base 24 metrics are further extended with these nine new metrics linkdelay, 25 linkjitter, linkloss, maxbw (Maximum Bandwidth), maxreservbw (Maximum 26 Reserved Bandwdith), unreservbw (Unreserved Bandwidth), residuebw 27 (Residual Bandwidth), availbw (Available Bandwidth), and utilbw 28 (Utilized Bandwidth). Also a new parameter anomalousstate is added. 29 These fourteen cost metrics are derived from OSPF-TE and ISIS-TE and 30 can be either used as constraint attribute associated with 31 'routingcost' cost metric attribute or used as returned Cost metrics 32 in the response, or both and hence provide a relatively comprehensive 33 set of cost metrics for ALTO. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 24, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions used in this document . . . . . . . . . . . . . . 5 70 3. Cost Metric Extensions: Cost Metrics . . . . . . . . . . . . . 6 71 3.1. Cost Metric: delay . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Cost Metric: jitter . . . . . . . . . . . . . . . . . . . 8 73 3.3. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . . 9 74 3.4. Cost Metric: Bandwidth . . . . . . . . . . . . . . . . . . 11 75 3.5. Cost Metric: Hopcount . . . . . . . . . . . . . . . . . . 13 76 3.6. Delay Cost Metric Extension: linkdelay . . . . . . . . . . 13 77 3.7. Jitter Cost Metric Extension: linkjitter . . . . . . . . . 13 78 3.8. Packet Loss Cost Metric Extension: linkloss . . . . . . . 14 79 3.9. Bandwidth Cost Metric Extension . . . . . . . . . . . . . 14 80 3.9.1. Maximum Bandwidth: maxbw . . . . . . . . . . . . . . . 14 81 3.9.2. Maximum Reserved Bandwdith: maxreservbw . . . . . . . 14 82 3.9.3. Unreserved Bandwidth: unreservbw . . . . . . . . . . . 14 83 3.9.4. Residual Bandwidth: residuebw . . . . . . . . . . . . 15 84 3.9.5. Available Bandwidth: availbw . . . . . . . . . . . . . 15 85 3.9.6. Utilized Bandwidth: utilbw . . . . . . . . . . . . . . 15 86 4. Cost Metric Extensions: Parameters . . . . . . . . . . . . . . 17 87 4.1. Parameter: anomalousstate . . . . . . . . . . . . . . . . 17 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 93 Appendix A. Filtering constraint Extensions . . . . . . . . . . . 22 94 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . . 24 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Introduction 99 The ALTO protocol [ALTO] uses a REST-ful design , and encodes its 100 requests and responses using JSON [RFC4627] . In ALTO architecture 101 [ALTO], the ALTO server allows alto information to be gathered from 102 multiple systems(e.g., routing protocol). [OSPF-TE], [ISIS-TE], 103 [BGP-LS] and [BGP-PM]describes extensions to routing protocol, that 104 can be used to distribute network performance information (such as 105 link delay, delay variation, packet loss, residual bandwidth, and 106 available bandwidth). The mechanism defined in [OSPF-TE], [ISIS-TE], 107 [BGP-LS], and [BGP-PM]can be used by an ALTO Server to retrieve the 108 necessary performance information supplementing the prefix and 109 network topology data gathered from other sources (such as Path 110 Computation Element (PCE)) in the underlying network. 112 Cost metric is a basic concept in ALTO. It is used in both the Cost 113 Map Service and the Endpoint Cost Service. However the base protocol 114 defines only a single cost metric, i.e., the generic "routingcost" 115 metric (Sec. 14.2 of [ALTO]). In practice, applications may request 116 network information on other cost (such as performance) metrics. In 117 this document, we define five new base metrics which are delay, 118 jitter, pktloss (packet loss), bandwidth and hopcount. These base 119 metrics are further extended with these nine new metrics linkdelay, 120 linkjitter, linkloss, maxbw (Maximum Bandwidth), maxreservbw (Maximum 121 Reserved Bandwdith), unreservbw (Unreserved Bandwidth), residuebw 122 (Residual Bandwidth), availbw (Available Bandwidth), and utilbw 123 (Utilized Bandwidth). Also a new parameter anomalousstate is added. 124 These fourteen cost metrics are derived from [OSPF-TE] and [ISIS-TE] 125 and can be either used as constraint attribute associated with 126 'routingcost' cost metric attribute or used as returned Cost metrics 127 in the response, or both and hence provide a relatively comprehensive 128 set of cost metrics for ALTO. 130 The introduction of a set of cost metrics allows us to extend the 131 flexibility of ALTO services. In particular, both the Cost Map 132 Service and the Endpoint Cost Service allow filtering. However, 133 these two services as defined in the base protocol are limited in 134 that the output information metric and the filtering (constraint) 135 metric must be the same. However, applications may request a 136 filtered "routingcost" Cost Map only for locations where the delay is 137 below a threshold. This is not feasible in the ALTO base protocol. 138 We discuss the overhead of implementing the aforementioned use case 139 using the current base protocol, and propose a simple but effective 140 extension to the "constraint" syntax to ALTO. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC2119 [RFC2119]. 148 Syntax specifications shown here use the augmented Backus-Naur Form 149 (ABNF) as described in [RFC5234], and are specified as in the base 150 JSON specification [RFC4627]. 152 3. Cost Metric Extensions: Cost Metrics 154 3.1. Cost Metric: delay 156 Cost Metric name: delay 158 Metric Description: To specify the average delay over a configurable 159 interval for each source/destination pair between two 160 endpoints (network locations) in the network. It could be 161 either end to end delay or the delay associated with the 162 link (linkdelay). The unit is microseconds. 164 Cost Metric Value type: 165 A single 'JSONNumber' type value containing an integer 166 component that may be prefixed with an optional minus 167 sign, which may be followed by a fraction part and/or 168 an exponent part. 170 Purpose: This is intended to be a new cost metric. It could be 171 used as a cost metric constraint attribute used together with cost 172 metric attribute 'routingcost' or on its own or as a returned cost 173 metric in the response. 175 Cost mode: A Cost Mode is encoded as a US-ASCII string. 176 The string MUST either have the value 'numerical' or 'ordinal'. 178 Measurement timing: Gather and update at the configurable interval 179 if it is link attribute. See [OSPF-TE] for configurable 180 interval. The configurable interval for end to end delay could 181 be same as link. 183 Measurement points with Potential Measurement Domain: 184 The measurement point could be at any endpoint between 185 source and destination in the network. 187 Examples 1: 188 POST /endpointcost/lookup HTTP/1.1 189 Host: alto.example.com 190 Content-Length: 195 191 Content-Type: application/alto-endpointcostparams+json 192 Accept: application/alto-endpointcost+json,application/alto-error+json 194 { 195 "cost-type": {"cost-mode" : "numerical", 196 "cost-metric" : "delay"}, 197 "endpoints" : { 198 "srcs": [ "ipv4:192.0.2.2" ], 199 "dsts": [ 200 "ipv4:192.0.2.89", 201 "ipv4:198.51.100.34", 202 "ipv4:203.0.113.45" 203 ] 204 } 205 } 207 HTTP/1.1 200 OK 208 Content-Length: 231 209 Content-Type: application/alto-endpointcost+json 211 { 212 "meta" : {}, 213 "data" : { 214 "cost-type": {"cost-mode" : "numerical", 215 "cost-metric" : "delay"}, 216 "map" : { 217 "ipv4:192.0.2.2": { 218 "ipv4:192.0.2.89" : 10, 219 "ipv4:198.51.100.34" : 20, 220 "ipv4:203.0.113.45" : 30, 221 } 222 } 223 } 224 } 226 //Note that these are end to end delay values in microseconds. 228 Example 2: 229 POST /endpointcost/lookup HTTP/1.1 230 Host: alto.example.com 231 Content-Length: 195 232 Content-Type: application/alto-endpointcostparams+json 233 Accept: application/alto-endpointcost+json,application/alto-error+json 235 { 236 "cost-type": {"cost-mode" : "numerical", 237 "cost-metric" : "routingcost"}, 238 "constraints" : {"delay ls 15"}, 239 "endpoints" : { 240 "srcs": [ "ipv4:192.0.2.2" ], 241 "dsts": [ 242 "ipv4:192.0.2.89", 243 "ipv4:198.51.100.34", 244 "ipv4:203.0.113.45" 245 ] 246 } 247 } 248 HTTP/1.1 200 OK 249 Content-Length: 231 250 Content-Type: application/alto-endpointcost+json 252 "data": { 253 "cost type": { 254 "cost-mode": "numerical", 255 "cost-metric":"routingcost"}, 256 "constraints" : {"delay ls 15"}, 257 "map": { 258 "ipv4:192.0.2.2": { 259 "ipv4:192.0.2.89": 0 ["delay eq 0"], 260 "ipv4:198.51.100.34": 15 ["delay eq 3"], 261 "ipv4:203.0.113.45": 1 ["delay eq 12"], 262 } 263 } 265 //Note that these are end to end routing cost and delay . 267 3.2. Cost Metric: jitter 269 Cost Metric name: jitter 271 Metric Description: To specify the average delay variation over 272 a configurable interval for each source/destination pair 273 between two endpoints(network locations)in the network. 274 It could be either end to end jitter or the jitter 275 associated with a link (linkjitter). The unit is 276 microseconds. 278 Cost Metric Value type: 279 A single 'JSONumber' type value containing an integer 280 component that may be prefixed with an optional minus 281 sign, which may be followed by a fraction part and/or 282 an exponent part. 284 Purpose: This is intended to be a constraint attribute value 285 It could be used as a cost metric constraint attribute used 286 together with cost metric attribute 'routingcost' or on its 287 own or as a returned cost metric in the response. 289 Cost mode: A Cost Mode is encoded as a US-ASCII string. 290 The string MUST either have the value 'numerical' or 'ordinal'. 292 Measurement timing: Gather and update at the configurable interval 293 if it is link attribute. See [OSPF-TE] for configurable 294 interval. The configurable interval for end to end jitter could 295 be same as link. 297 Measurement points with Potential Measurement Domain: 298 The measurement point could be at any endpoint between 299 source and destination in the network. 301 Examples: 302 POST /endpointcost/lookup HTTP/1.1 303 Host: alto.example.com 304 Content-Length: 195 305 Content-Type: application/alto-endpointcostparams+json 306 Accept: application/alto-endpointcost+json,application/alto-error+json 308 { 309 "cost-type": {"cost-mode" : "numerical", 310 "cost-metric" : "routingcost"}, 311 "constraints" : {"delay ls 15","jitter ls 8"}, 312 "endpoints" : { 313 "srcs": [ "ipv4:192.0.2.2" ], 314 "dsts": [ 315 "ipv4:192.0.2.89", 316 "ipv4:198.51.100.34", 317 "ipv4:203.0.113.45" 318 ] 319 } 320 } 321 HTTP/1.1 200 OK 322 Content-Length: 231 323 Content-Type: application/alto-endpointcost+json 324 "data": { 325 "cost type": { 326 "cost-mode": "numerical", 327 "cost-metric":"routingcost"}, 328 "constraints" : {"delay ls 15","jitter ls 8"}, 329 "map": { 330 "ipv4:192.0.2.2": { 331 "ipv4:192.0.2.89": 0 ["delay eq 0", "jitter eq 0"], 332 "ipv4:198.51.100.34": 5 ["delay eq 3", "jitter eq 1"], 333 "ipv4:203.0.113.45":2 ["delay eq 12", "jitter eq 5"], 334 } 336 3.3. Cost Metric: Packet Loss 338 Cost Metric name: pktloss 340 Metric Description: To specify a percentage of the total traffic 341 sent over a configurable interval for each 342 source/destination pair between two endpoints(network 343 locations) in the network. It could be either end to 344 end packet loss or the packet loss associated with a link 345 (linkloss). 347 Cost Metric Value type: 348 A single number value containing an integer component that 349 may be prefixed with an optional minus sign, which may 350 be followed by a fraction part and/or an exponent part. 352 Purpose: This is intended to be a constraint attribute value 353 It could be used as a cost metric constraint attribute used 354 together with cost metric attribute 'routingcost' or on its 355 own or as a returned cost metric in the response. 357 Cost mode: A Cost Mode is encoded as a US-ASCII string. 358 The string MUST either have the value 'numerical' or 'ordinal'. 360 Measurement timing: Gather and update at the configurable interval 361 if it is link attribute. See [OSPF-TE] for configurable 362 interval. The configurable interval for end to end packet loss 363 could be same as link. 365 Measurement points with Potential Measurement Domain: 366 The measurement point could be at any endpoint between 367 source and destination in the network. 369 Examples: 370 POST /endpointcost/lookup HTTP/1.1 371 Host: alto.example.com 372 Content-Length: 195 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" : "routingcost"}, 379 "constraints" : {"pktloss le 0.3"}, 380 "endpoints" : { 381 "srcs": [ "ipv4:192.0.2.2" ], 382 "dsts": [ 383 "ipv4:192.0.2.89", 384 "ipv4:198.51.100.34", 385 "ipv4:203.0.113.45" 386 ] 387 } 388 } 389 HTTP/1.1 200 OK 390 Content-Length: 231 391 Content-Type: application/alto-endpointcost+json 392 "data": { 393 "cost type": { 394 "cost-mode": "numerical", 395 "cost-metric":"routingcost"}, 396 "constraints" : {"pktloss le 0.3"}, 397 "map": { 398 "ipv4:192.0.2.2": { 399 "ipv4:192.0.2.89": 0 ["pktloss eq 0.0"], 400 "ipv4:198.51.100.34": 1 ["pktloss eq 0.0001"], 401 "ipv4:203.0.113.45": 0 ["pktloss eq 0.0"], 402 } 403 } 404 [Editor Note: We have to be clear when the new metrics are part of 405 response and when it is not?] 407 3.4. Cost Metric: Bandwidth 409 Cost Metric name: bandwidth 411 Metric Description: To specify Bandwidth over a configurable 412 interval for each source/destination pair between 413 two endpoints (network locations)in the network. 414 It could be either aggregated bandwidth for end to end 415 path or the bandwidth associated with a link. The units 416 are bytes per second. 418 Cost Metric Value type: 419 A single 'JSONNumber' type value containing an integer 420 component that may be prefixed with an optional minus 421 sign, which may be followed by a fraction part and/or 422 an exponent part. 424 Purpose: This is intended to be a constraint attribute value 425 It could be used as a cost metric constraint attribute used 426 together with cost metric attribute 'routingcost' or on its 427 own or as a returned cost metric in the response. 429 Cost mode: A Cost Mode is encoded as a US-ASCII string. 430 The string MUST either have the value 'numerical' or 'ordinal'. 432 This is just a definition of the costtype 'bandwidth'. The use of 433 this cost is always in conjunction with what it represents, which 434 could be Max Bandwidth (maxbw), Residual Bandwidth (residuebw) etc. 436 Examples: (based on Residual Bandwidth (residuebw)) 438 POST /endpointcost/lookup HTTP/1.1 439 Host: alto.example.com 440 Content-Length: 195 441 Content-Type: application/alto-endpointcostparams+json 442 Accept: application/alto-endpointcost+json,application/alto-error+json 444 { 445 "cost-type": {"cost-mode" : "numerical", 446 "cost-metric" : "routingcost"}, 447 "constraints" : {"residuebw gt 1500"}, 448 "endpoints" : { 449 "srcs": [ "ipv4:192.0.2.2" ], 450 "dsts": [ 451 "ipv4:192.0.2.89", 452 "ipv4:198.51.100.34", 453 "ipv4:203.0.113.45" 454 ] 455 } 456 } 457 HTTP/1.1 200 OK 458 Content-Length: 231 459 Content-Type: application/alto-endpointcost+json 461 "data": { 462 "cost type": { 463 "cost-mode": "numerical", 464 "cost-metric":"routingcost"}, 465 "constraints" : {"residuebw gt 1500"}, 466 "map": { 467 "ipv4:192.0.2.2": { 468 "ipv4:192.0.2.89": 0 ["residuebw eq 0"], 469 "ipv4:198.51.100.34": 5 ["residuebw eq 2000"], 470 "ipv4:203.0.113.45":2 ["residuebw eq 5000"], 471 } 472 } 474 3.5. Cost Metric: Hopcount 476 Cost Metric name: hopcount 478 Metric Description: To specify the number of hops in the path 479 between the source endpoint and the destination 480 endpoint. 482 Editor Note: Need to specify which layer (IP perhaps), details TBD for 483 multiple-layer aspect. 485 Cost Metric Value type: 486 A single 'JSONNumber' type value containing an 487 integer component that may be prefixed with an 488 optional minus sign. 490 Purpose: This is intended to be a constraint attribute value 491 It could be used as a cost metric constraint attribute used 492 together with cost metric attribute 'routingcost' or on its 493 own or as a returned cost metric in the response. 495 Cost mode: A Cost Mode is encoded as a US-ASCII string. 496 string MUST either have the value 'numerical' or 'ordinal'. 498 3.6. Delay Cost Metric Extension: linkdelay 500 A linkdelay is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It 501 is extended from Delay Cost metric and defined as: 503 Object { 504 LinkName link-name; 505 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 506 delay dl; 507 }linkdelay; 509 3.7. Jitter Cost Metric Extension: linkjitter 511 A linkjitter is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It 512 is extended from Jitter Cost metric and defined as: 514 Object { 515 LinkName link-name; 516 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 517 jitter jt; 518 }linkjitter; 520 3.8. Packet Loss Cost Metric Extension: linkloss 522 A linkloss is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It is 523 extended from Packet loss cost metric and defined as: 525 Object { 526 LinkName link-name; 527 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 528 pktloss l; 529 }linkloss; 531 3.9. Bandwidth Cost Metric Extension 533 3.9.1. Maximum Bandwidth: maxbw 535 A maxbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It could 536 be either maximum bandwidth for end to end path or the bandwidth 537 associated with a link. It is extended from Bandwidth Cost metric 538 and defined as: 540 Object { 541 BWType max; 542 [LinkName link-name;] 543 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 544 Bandwidth bw; 545 }maxbw; 547 3.9.2. Maximum Reserved Bandwdith: maxreservbw 549 A maxreservbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It 550 could be either maximum reserved bandwidth for end to end path or the 551 bandwidth associated with a link. It is extended from Bandwidth Cost 552 metric and defined as: 554 Object { 555 BWType maxreserved; 556 [LinkName link-name;] 557 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 558 Bandwidth bw; 559 }maxreservbw; 561 3.9.3. Unreserved Bandwidth: unreservbw 563 A unreservbw is gathered using [RFC3630], [RFC3784] or [BGP-LS]. It 564 could be either unreserved bandwidth for end to end path or the 565 bandwidth associated with a link. It is extended from Bandwidth Cost 566 metric and defined as: 568 Object { 569 BWType unreserved; 570 [LinkName link-name;] 571 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 572 Bandwidth bw<1,8> 573 }unreservbw; 575 //This bandwidth is per priority [TBD]. 577 3.9.4. Residual Bandwidth: residuebw 579 A residuebw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It 580 could be either residual bandwidth for end to end path or the 581 bandwidth associated with a link. It is extended from Bandwidth Cost 582 metric and defined as: 584 Object { 585 BWType Residue; 586 [LinkName link-name;] 587 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 588 Bandwidth bw; 589 }rediduebw; 591 3.9.5. Available Bandwidth: availbw 593 A availbw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It 594 could be either available bandwidth for end to end path or the 595 bandwidth associated with a link. It is extended from Bandwidth Cost 596 metric and defined as: 598 Object { 599 BWType Available; 600 [LinkName link-name;] 601 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 602 Bandwidth bw; 603 }availbw; 605 3.9.6. Utilized Bandwidth: utilbw 607 A utilbw is gathered using [OSPF-TE], [ISIS-TE] or [BGP-PM]. It 608 could be either utilized bandwidth for end to end path or the 609 bandwidth associated with a link. It is extended from Bandwidth Cost 610 metric and defined as: 612 Object { 613 BWType Utilized; 614 [LinkName link-name;] 615 [JSONBool linkstate;] //TRUE = not steady; FALSE = steady; 616 Bandwidth bw; 617 }utilbw; 619 4. Cost Metric Extensions: Parameters 621 The following sections define Parameters used within cost metrics 622 specified in the section 3. 624 4.1. Parameter: anomalousstate 626 Parameter name: anomalousstate 628 Purpose: Optinally used in a prefixed cost metric to 629 indicate whether it is steady state 630 of the performance metric. 632 Description: This state can be used to notify to the ALTO 633 client if the performance metric associated is in a 634 steady state. The ALTO client may use this to perform 635 some action. The anomalousstate 636 is set when the measured value of this parameter exceeds 637 its configured maximum threshold. The anomalousstate is 638 cleared when the measured value falls below its 639 configured threshold. Anomalousstate should be used 640 together with Cost metric we defined in the 641 section 3. Cost Metrics prefixed with 'a:' are 642 reserved for cost metric that does not have steady state 643 network performance. Cost Metrics without prefix 'a:' 644 indicate the cost metric has steady state network 645 performance. 647 Examples: 649 POST /endpointcost/lookup HTTP/1.1 650 Host: alto.example.com 651 Content-Length: 195 652 Content-Type: application/alto-endpointcostparams+json 653 Accept: application/alto-endpointcost+json,application/alto-error+json 655 { 656 "cost-type": {"cost-mode" : "numerical", 657 "cost-metric" : "routingcost"}, 658 "constraints" : {"delay ls 15"}, 659 "endpoints" : { 660 "srcs": [ "ipv4:192.0.2.2" ], 661 "dsts": [ 662 "ipv4:192.0.2.89", 663 "ipv4:198.51.100.34", 664 "ipv4:203.0.113.45" 665 ] 666 } 667 } 668 HTTP/1.1 200 OK 669 Content-Length: 231 670 Content-Type: application/alto-endpointcost+json 672 "data": { 673 "cost type":{ 674 "cost-mode": "numerical", 675 "cost-metric":"routingcost"} 676 "constraints": {"delay ls 15"}, 677 "map": { 678 "ipv4:192.0.2.2": { 679 "ipv4:192.0.2.89": 0 ["a:delay eq 10"], 680 } 681 } 683 5. Security Considerations 685 The properties defined in this document present no security 686 considerations beyond those in Section 14 of the base ALTO 687 specification [ALTO]. 689 6. IANA Considerations 691 IANA has added the following entries to the ALTO cost map Properties 692 registry, defined in Section 3 of [RFCXXX]. 694 +-----------+--------------+------------------------+ 695 | Namespace | Property | Reference | 696 +-----------+--------------+------------------------+ 697 | | delay | [RFCxxxx], Section 3.1 | 698 | | jitter | [RFCxxxx], Section 3.2 | 699 | | pktloss | [RFCxxxx], Section 3.3 | 700 | | linkdelay | [RFCxxxx], Section 3.6 | 701 | | linkjitter | [RFCxxxx], Section 3.7 | 702 | | linkloss | [RFCxxxx], Section 3.8 | 703 | | bandwidth | [RFCxxxx], Section 3.4 | 704 | | hopcount | [RFCxxxx], Section 3.5 | 705 | | maxbw |[RFCxxxx], Section 3.9.1| 706 | | maxresbw |[RFCxxxx], Section 3.9.2| 707 | | unresdbw |[RFCxxxx], Section 3.9.3| 708 | | residbw |[RFCxxxx], Section 3.9.4| 709 | | availbw |[RFCxxxx], Section 3.9.5| 710 | | utilbw |[RFCxxxx], Section 3.9.6| 711 +-----------+--------------+------------------------+ 713 IANA has added the following entries to the " ALTO cost map 714 Parameters" registry, defined in [RFCxxxx] Section 4.1. 716 +-------+------------------------+------------------------+ 717 | Name- | | | 718 | space | Parameter | Reference | 719 +-------+------------------------+------------------------+ 720 | | anomalousstate | [RFCxxxx], Section 4.1 | 721 +-------+------------------------+------------------------+ 723 7. References 725 7.1. Normative References 727 [ALTO] Alimi, R., "ALTO Protocol", 728 ID draft-ietf-alto-protocol-16, May 2013. 730 [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and 731 TE Information using BGP", 732 ID draft-ietf-idr-ls-distribution-03, May 2013. 734 [BGP-PM] Wu, Q., "BGP attribute for North-Bound Distribution of 735 Traffic Engineering (TE) performance Metrics", 736 ID draft-wu-idr-te-pm-bgp-02, October 2013. 738 [ISIS-TE] Giacalone, S., "ISIS Traffic Engineering (TE) Metric 739 Extensions", ID draft-ietf-isis-te-metric-extensions-01, 740 October 2013. 742 [OSPF-TE] Giacalone, S., "OSPF Traffic Engineering (TE) Metric 743 Extensions", ID draft-ietf-ospf-te-metric-extensions-04, 744 June 2013. 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", March 1997. 749 [RFC4627] Crockford, D., "The application/json Media Type for 750 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 752 [RFC5234] Crocker, D., "Augmented BNF for Syntax Specifications: 753 ABNF", RFC 5234, January 2008. 755 7.2. Informative References 757 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 758 Development", RFC 6390, July 2011. 760 Appendix A. Filtering constraint Extensions 762 Section 10.2.2.3 of "ALTO: Application Layer Traffic Optimization 763 Protocol" [I.D-ietf-alto-protocol] states: 764 " 765 object { 766 CostType cost-type; 767 [JSONString constraints<0..*>;] 768 [PIDFilter pids;] 769 } ReqFilteredCostMap; 771 object { 772 PIDName srcs<0..*>; 773 PIDName dsts<0..*>; 774 } PIDFilter; 776 with members: 778 cost-type The CostType (Section 9.7) for the returned costs. The 779 cost-metric and cost-mode fields MUST match one of the supported 780 Cost Types indicated in this resource's capabilities 781 (Section 10.2.2.4). The ALTO Client SHOULD omit the description 782 field, and if present, the ALTO Server MUST ignore the description 783 field. 785 constraints Defines a list of additional constraints on which 786 elements of the Cost Map are returned. This parameter MUST NOT be 787 specified if this resource's capabilities ( Section 10.2.2.4) 788 indicate that constraint support is not available. A constraint 789 contains two entities separated by whitespace: (1) an operator, 790 'gt' for greater than, 'lt' for less than, 'ge' for greater than 791 or equal to, 'le' for less than or equal to, or 'eq' for equal to; 792 (2) a target cost value. The cost value is a number that MUST be 793 defined in the same units as the Cost Metric indicated by the 794 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754 795 double-precision floating point [IEEE.754.2008] to store the cost 796 value, and SHOULD perform internal computations using double- 797 precision floating-point arithmetic. If multiple 'constraint' 798 parameters are specified, they are interpreted as being related to 799 each other with a logical AND. 800 " 802 In the JSON Object of type ReqFilteredCostMap, the constraint 803 attribute is expressed as: 805 " 806 [gt | lt | ge | le | eq ] 807 " 808 In this specification, the constraint attribute is changed to 810 " 811 [gt | lt | ge | le | eq ] 812 " 814 Accordingly, the constraints definition is changed to: 816 " 817 constraints Defines a list of additional constraints on which 818 elements of the Cost Map are returned. This parameter MUST NOT be 819 specified if this resource's capabilities ( Section 10.2.2.4) 820 indicate that constraint support is not available. A constraint 821 contains three entities separated by whitespace: (1)an cost type 822 is by default cost-type in the JSON Object of type ReqFilteredCostMap. 823 In addition, it could be another cost-type used for the returned cost 824 (2) an operator, 'gt' for greater than, 'lt' for less than, 'ge' for 825 greater than or equal to, 'le' for less than or equal to, or 'eq' for 826 equal to; (3) a target cost value. The cost value is a number that 827 MUST be defined in the same units as the Cost Metric indicated by the 828 cost-metric parameter. ALTO Servers SHOULD use at least IEEE 754 829 double-precision floating point [IEEE.754.2008] to store the cost 830 value, and SHOULD perform internal computations using double- 831 precision floating-point arithmetic. If multiple 'constraint' 832 parameters are specified, they are interpreted as being related to 833 each other with a logical AND. 834 " 836 Editor-Notes: Filtering constraint extension should move to another 837 document defining multi-metrics filtering in the future. 839 Appendix B. Contributor Addresses 841 Y. Richard Yang 842 Yale University 843 51 Prospect St 844 New Haven CT 845 USA 847 Email: yry@cs.yale.edu 849 Roni Even 850 Gesher Erove Ltd 851 14 David Hamelech 852 Tel Aviv 64953 853 Israel 855 Email: ron.even.tlv@gmail.com 857 Liang Xia 858 Huawei 859 101 Software Avenue, Yuhua District 860 Nanjing, Jiangsu 210012 861 China 863 Email: frank.xialiang@huawei.com 865 Authors' Addresses 867 Qin Wu 868 Huawei 869 101 Software Avenue, Yuhua District 870 Nanjing, Jiangsu 210012 871 China 873 Email: sunseawq@huawei.com 875 Young Lee 876 Huawei 877 1700 Alma Drive, Suite 500 878 Plano, TX 75075 879 USA 881 Email: leeyoung@huawei.com 883 Dhruv Dhody 884 Huawei 885 Leela Palace 886 Bangalore, Karnataka 560008 887 INDIA 889 Email: dhruv.ietf@gmail.com