idnits 2.17.1 draft-gao-alto-fcs-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 220 has weird spacing: '...DFilter pids;...' == Line 221 has weird spacing: '...DFilter pid-f...' == Line 317 has weird spacing: '...NString proto...' == Line 318 has weird spacing: '...SONBool flo...' == Line 639 has weird spacing: '...erField requi...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Some header fields may have conflicts. For example, IPv4 fields and IPv6 fields can never appear in the same packet, nor can TCP and UDP ports. These header fields MUST not be included in the same flow filter, otherwise the ALTO server MUST return an ALTO error response, with the error code "E_INVALID_FIELD_VALUE". As specified in Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field" and the "value" in the "meta" field. In this case, the ALTO server MUST use the flow ID as the "field" and the flow filter as the "value". However, the recommended approach is to use the FlowCostErrorMap, where the server CAN provide the conflicting typed header fields in the "conflicts" field of the FlowFilterError associated with the corresponding flow ID. -- The document date (June 25, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 379, but not defined == Missing Reference: 'TBD' is mentioned on line 491, but not defined -- Looks like a reference, but probably isn't: '0' on line 968 -- Looks like a reference, but probably isn't: '100' on line 552 -- Looks like a reference, but probably isn't: '1' on line 963 -- Looks like a reference, but probably isn't: '4094' on line 963 -- Looks like a reference, but probably isn't: '65535' on line 968 == Unused Reference: 'I-D.wang-alto-ecs-flows' is defined on line 912, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) == Outdated reference: A later version (-10) exists of draft-ietf-alto-multi-cost-05 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG K. Gao 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track J. Zhang 5 Expires: December 27, 2017 J. Wang 6 Tongji University 7 Q. Xiang 8 Tongji/Yale University 9 Y. Yang 10 Yale University 11 June 25, 2017 13 ALTO Extension: Flow-based Cost Query 14 draft-gao-alto-fcs-02.txt 16 Abstract 18 The emergence of new networking datapath capabilities has 19 substantially increased the flexibility of networking. For example, 20 OpenFlow has emerged as a major southbound protocol for Software- 21 Defined Networking, and OpenFlow allows flexible routing beyond 22 simple destination-based routing. In this document, we define a new 23 extention to ALTO, namely the Flow Cost Service, for ALTO clients in 24 an OpenFlow-enabled network to query ALTO network information. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 27, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 4 68 3. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 4 69 3.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 4 70 3.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 4 71 3.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 5 72 3.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Extend Endpoint Encoding . . . . . . . . . . . . . . . . 6 74 3.2.1. Protocol . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.2. EndpointName . . . . . . . . . . . . . . . . . . . . 6 76 3.2.3. Port . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.2.4. EndpointURI Example . . . . . . . . . . . . . . . . . 7 78 3.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 7 79 3.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 7 80 3.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 8 81 3.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 82 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 9 84 3.4.2. Flow-based Filtered Cost Map Service Example . . . . 10 85 3.4.3. Flow-based Endpoint Cost Service Example . . . . . . 11 86 4. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 12 87 4.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 12 88 4.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 12 89 4.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 12 90 4.1.3. Cost Confidence . . . . . . . . . . . . . . . . . . . 12 91 4.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 13 92 4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 93 4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13 94 4.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 13 95 4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 96 4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 15 97 4.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 16 98 4.3. Advanced Flow-based Query Example . . . . . . . . . . . . 17 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 101 6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19 102 6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . 20 103 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 106 8.2. Informative References . . . . . . . . . . . . . . . . . 21 107 Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 22 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 110 1. Introduction 112 ALTO is now being considered as a solution for more flexible network 113 scenario. The legacy ALTO services defined in [RFC7285] only provide 114 the cost information for peer selection. It is enough for the P2P 115 application. However, the network is becoming more and more flexible 116 nowadays. There are two major changes in the coming network 117 evolution: 119 o Some new network architectures, such as Software Defined 120 Networking (SDN), are adopting the logically central control 121 solution, which makes the network optimization toward the higher- 122 level view. The traffic optimizer can not only decide the source 123 or the destination of the data transferring, but also make the 124 flow-level traffic scheduling. To solve the flow-level scheduling 125 problem, the cross-product query schema will be redundant. 127 o With the emerging technologies in the data plane, where multiple 128 header fields can be used to determine the forwarding path, 129 networks are moving to more flexible routing mechanisms beyond the 130 simple destination-based routing. As a consequence, the endpoint 131 cost service (ECS), which depends on only source and destination 132 IP addresses as currently defined, is no longer sufficient to 133 provide accurate cost information. 135 This document addresses the following issues in providing fine- 136 grained flow-based endpoint cost query services: 1) The compatibility 137 with the legacy ALTO ECS service; 2) The support for emerging network 138 architectures such as Software Defined Networking; 3) The trade-off 139 between fine-grained queries and query/response redundancy. 141 In this document, we consider the extensions of ALTO service which 142 provide the flow-based cost query. The basic solution is to extend 143 the legacy ALTO services to support flow-based query schema. 144 Section 3 describes the extended schema on Filtered Cost Map (FCM) 145 and Endpoint Cost Service (ECS) to support endpoint cost queries of 146 flows defined by the 5-tuple of protocol, src/dst name/address and 147 ports. For networks using a more generic flow concept such as 148 Software-Defined Networks, Section 4 defines a novel ALTO service 149 named the Flow Cost Service (FCS) with the flow-oriented query 150 schema. It SHOULD support the query of any fine-grained routing cost 151 to satisfy the growing demand of obtaining accurate costs in a 152 network using flow-based routing. Section 5 and Section 6 discuss 153 security and IANA considerations. 155 2. Changes Since Version -01 157 Note to Editor: Please remove this section prior to publication. 159 This section records the change log of the draft updates. 161 o Change the schema of "pid-flows" and "endpoint-flows" fields from 162 pair list to pair mesh list. 164 Changes since older versions: 166 o Define the basic flow-based query extensions for Filtered Cost Map 167 and Endpoint Cost service. The basic flow-based query is downward 168 compatible with the legacy ALTO service. It does not introduce 169 any new media types. 171 o Move the service of media-type "application/alto-flowcost+json" to 172 the advanced flow-based query extension. It will ask ALTO server 173 to support the new media type. 175 3. ALTO Flow Cost Specification: Basic Flow-based Query 177 This section describes a downward compatible extension for Filtered 178 Cost Map and Endpoint Cost Service to support flow-based query. 180 3.1. Flow-based Filtered Cost Map 182 3.1.1. Capabilities 184 The Filtered Cost Map capabilities are extended with a new member: 185 flow-based-filter. 187 The capability "flow-based-filter" indicates whether this resource 188 supports flow-based query. The FilteredCostMapCapabilities object in 189 Section 4.1.1 of [I-D.ietf-alto-multi-cost] is extended as follows: 191 object { 192 JSONString cost-type-names<1..*>; 193 [JSONBool cost-constraints;] 194 [JSONNumber max-cost-types;] 195 [JSONString testable-cost-type-names<1..*>;] 196 [JSONBool flow-based-filter;] 197 } FilteredCostMapCapabilities; 199 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 200 of [RFC7285]. 202 max-cost-types and testable-cost-type-names: As defined in 203 Section 4.1.1 of [I-D.ietf-alto-multi-cost]. 205 flow-based-filter: If true, then the ALTO Server allows pid-flows to 206 be queried in the requests. If not present, this field MUST be 207 interpreted as if it is specified false. 209 3.1.2. Accept Input Parameters 211 The ReqFilteredCostMap object in Section 4.1.2 of 212 [I-D.ietf-alto-multi-cost] is extended as follows: 214 object { 215 [CostType cost-type;] 216 [CostType multi-cost-types<1..*>;] 217 [CostType testable-cost-types<1..*>;] 218 [JSONString constraints<0..*>;] 219 [JSONString or-constraints<0..*><0..*>;] 220 [PIDFilter pids;] 221 [PIDFilter pid-flows<1..*>;] 222 } ReqFilteredCostMap; 224 cost-type, multi-cost-types, testable-cost-types, constraints, or- 225 constraints: As defined in Section 4.1.2 of 226 [I-D.ietf-alto-multi-cost]. 228 pids: As defined in Section 11.3.2.3 of [RFC7285]. 230 pid-flows: Defined as a list of PIDFilter objects in which each 231 object is as defined in Section 11.3.2.3 of [RFC7285]. The ALTO 232 server MUST interpret PID pairs appearing in all objects multiple 233 times as if they appeared only once. If the "pids" field is 234 present, the "pid-flows" field MUST NOT be specified. 236 3.1.3. Response 238 The response is exactly as defined in Section 4.1.3 of 239 [I-D.ietf-alto-multi-cost]. 241 3.2. Extend Endpoint Encoding 243 The legacy endpoint encoding is TypedEndpointAddr, which is defined 244 in Section 10.4 of [RFC7285]. This encoding only defines two address 245 types: ipv4 and ipv6 to express IPv4 addresses and IPv6 addresses 246 respectively. However, the flow-extended ECS may contain MAC 247 addresses, domain names and port numbers to give a cost between 248 hosts. 250 Therefore, this document extends the endpoint encoding from 251 TypedEndpointAddr to EndpointURI to measure the cost more precisely. 252 The syntax of EndpointURI SHOULD be compatible with the definition of 253 URI in [RFC3986]. The string encoded as type EndpointURI MUST be one 254 of the following format: 256 Protocol:EndpointName 257 Protocol:EndpointName:Port 259 This definition is downward compatible with the definition of 260 TypedEndpointAddr . When the Protocol field only supports "ipv4" and 261 "ipv6", EndpointURI is equivalent to TypedEndpointAddr. 263 3.2.1. Protocol 265 The Protocol field is REQUIRED. The available values contain 266 different protocols including layer two protocols (e.g. "eth") and 267 layer three protocols (e.g. "ipv4", "ipv6"). It can also be 268 specified upper-layer protocols (e.g. "udp", "tcp", "ssh", "http" and 269 "ftp"). The source and destination protocols MUST NOT be conflict. 270 In every EndpointFilter object of either "endpoints" field or 271 "endpoint-flows" field, if the source protocol is conflict with the 272 destination protocol, this endpoint pair is invalid. For different 273 protocols, some additional constraints are defined in Section 3.2.3. 275 3.2.2. EndpointName 277 The EndpointName field is REQUIRED. The value can be a MAC address, 278 an IP address or a host/domain name. If the IP address type is 279 "ipv6" and the Port field is specified, the address MUST be enclosed 280 in "[" and "]" characters, as recommended in [RFC2732]. 282 3.2.3. Port 284 The Port field is OPTIONAL. It is introduced for more fine-gained 285 requests when the protocol is upper-layer. It MUST be forbidden when 286 the Protocol field is specified layer three (like "ipv4" and "ipv6") 287 or layer two protocol (like "eth"). For some classic application- 288 layer protocols, if the port is not specified, the ALTO server will 289 use the default port. For example, the default port of "ssh" is 22, 290 "ftp" is 21 and "http" is 80. 292 3.2.4. EndpointURI Example 294 Some valid EndpointURI values look like follows: 296 "eth:98:e0:d9:9c:df:81" 297 "http:www.example.com" 298 "ipv4:198.51.100.34" 299 "telnet:198.51.100.34:23" 300 "tcp:[2000::1:2345:6789:abcd]:8080" 302 3.3. Flow-based Endpoint Cost Service 304 3.3.1. Capabilities 306 The extensions of EndpointCostCapabilities are based on 307 FilteredCostMapCapabilities in Section 3.1.1 but with a new member: 308 protocols. 310 The capability "protocols" indicates which protocols are supported to 311 be queried by this resource. For the capability "flow-based-filter", 312 the true value means the ALTO server allows requests to have 313 "endpoint-flows" field. If not present, this field MUST be 314 interpreted as if it is specified false. 316 object { 317 [JSONString protocols<0..*>;] 318 [JSONBool flow-based-filter;] 319 } EndpointCostCapabilities : FilteredCostMapCapabilities; 321 protocols: Defines a list of JSONString indicating the supported 322 Protocol values of the EndpointURI in the request. The ALTO 323 server does not have to claim "ipv4" and "ipv6" in this field 324 explictly, because they are supported by default. If not present, 325 this field MUST be interpreted as if it is specified the default 326 supported protocols "ipv4" and "ipv6". 328 flow-based-filter: If true, then the ALTO Server allows endpoint- 329 flows to be queried in the requests. If not present, this field 330 MUST be interpreted as if it is specified false. 332 3.3.2. Accept Input Parameters 334 The ReqEndpointCostMap object in Section 4.2.2 of 335 [I-D.ietf-alto-multi-cost] is extended as follows: 337 object { 338 [CostType cost-type;] 339 [CostType multi-cost-types<1..*>;] 340 [CostType testable-cost-types<1..*>;] 341 [JSONString constraints<0..*>;] 342 [JSONString or-constraints<0..*><0..*>;] 343 [EndpointFilter endpoints;] 344 [EndpointFilter endpoint-flows<1..*>;] 345 } ReqEndpointCostMap; 347 object { 348 EndpointURI srcs<0..*>; 349 EndpointURI dsts<0..*>; 350 } EndpointFilter; 352 cost-type, multi-cost-types, testable-cost-types, constraints, or- 353 constraints: 354 As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost]. 356 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 358 endpoint-flows: Defined as a list of EndpointFilter objects in which 359 each object is as defined in Section 11.5.1.3 of [RFC7285]. The 360 ALTO server MUST interpret endpoint pairs appearing multiple times 361 in all EndpointFilter objects as if they appeared only once. 363 The additional requirement is that the ALTO client MUST specify 364 either "endpoints" or "endpoint-flows", but MUST NOT specify both. 366 3.3.3. Response 368 The response is exactly as defined in Section 4.2.3 of 369 [I-D.ietf-alto-multi-cost]. 371 3.4. Example 372 3.4.1. IRD Example 374 GET /directory HTTP/1.1 375 Host: alto.example.com 376 Accept: application/alto-directory+json,application/alto-error+json 378 HTTP/1.1 200 OK 379 Content-Length: [TODO] 380 Content-Type: application/alto-directory+json 381 { 382 "meta" : { 383 "default-alto-network-map" : "my-default-network-map", 384 "cost-types" : { 385 "num-routingcost" : { 386 "cost-mode" : "numerial", 387 "cost-metric" : "routingcost"}, 388 "ord-routingcost" : { 389 "cost-mode" : "ordinal", 390 "cost-metric" : "routingcost"} 391 }, 392 ..... 393 Other ALTO cost types as described in RFC7285 394 ..... 395 }, 396 "resources" : { 397 "my-default-network-map" : { 398 "uri" : "http://alto.example.com/networkmap", 399 "media-type" : "application/alto-networkmap+json" 400 }, 401 "basic-flow-based-cost-map" : { 402 "uri" : "http://alto.example.com/costmap/multi/filtered", 403 "media-types" : [ "application/alto-costmap+json" ], 404 "accepts" : [ "application/alto-costmapfilter+json" ], 405 "uses" : [ "my-default-network-map" ], 406 "capabilities" : { 407 "flow-based-filter" : true, 408 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 409 } 410 }, 411 "basic-flow-based-endpoint-cost" : { 412 "uri" : "http://alto.example.com/endpointcost/lookup", 413 "media-types" : [ "application/alto-endpointcost+json" ], 414 "accepts" : [ "application/alto-endpointcostparams+json" ], 415 "uses" : [ "my-default-network-map" ], 416 "capabilities" : { 417 "protocols": ["tcp", "http"], 418 "flow-based-filter" : true, 419 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 421 } 422 } 423 } 424 } 426 3.4.2. Flow-based Filtered Cost Map Service Example 428 POST /costmap/multi/filtered HTTP/1.1 429 Host: alto.example.com 430 Accept: application/alto-costmap+json,application/alto-error+json 431 Content-Length: [TBD] 432 Content-Type: application/alto-costmapfilter+json 434 { 435 "cost-type": { 436 "cost-mode": "numerical", 437 "cost-metric": "routingcost" 438 }, 439 "pid-flows": [ 440 { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, 441 { "srcs": ["PID3"], "dsts": ["PID4"] } 442 ] 443 } 445 HTTP/1.1 200 OK 446 Content-Length: [TBD] 447 Content-Type: application/alto-costmap+json 449 { 450 "meta": { 451 "dependent-vtags": [ 452 { 453 "resource-id": "my-default-network-map", 454 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 455 }, 456 ], 457 "cost-type": { 458 "cost-mode": "numerical", 459 "cost-metric": "routingcost" 460 } 461 }, 462 "cost-map": { 463 "PID1": { "PID2": 100 }, 464 "PID1": { "PID3": 20 }, 465 "PID3": { "PID4": 80 } 466 } 467 } 469 3.4.3. Flow-based Endpoint Cost Service Example 471 POST /endpointcost/lookup HTTP/1.1 472 Host: alto.example.com 473 Accept: application/alto-endpointcost+json,application/alto-error+json 474 Content-Length: [TBD] 475 Content-Type: application/alto-endpointcostparams+json 477 { 478 "cost-type": { 479 "cost-mode": "numerical", 480 "cost-metric": "hopcount" 481 }, 482 "endpoint-flows": [ 483 { "srcs": ["ipv4:192.0.2.2"], 484 "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] }, 485 { "srcs": ["tcp:203.0.113.45:54321"], 486 "dsts": ["http:cdn1.example.com"] } 487 ] 488 } 490 HTTP/1.1 200 OK 491 Content-Length: [TBD] 492 Content-Type: application/alto-endpointcost+json 494 { 495 "meta": { 496 "cost-type": { 497 "cost-mode": "numerical", 498 "cost-metric": "hopcount" 499 } 500 }, 501 "endpoint-cost-map": { 502 "ipv4:192.0.2.2": { 503 "ipv4:192.0.2.89": 3, 504 "http:cdn1.example.com": 6 505 }, 506 "tcp:203.0.113.45:54321": { 507 "http:cdn1.example.com": 10 508 } 509 } 510 } 512 4. ALTO Flow Cost Specification: Advanced Flow-based Query 514 The basic flow-based query extends the ECS service to support 515 querying the cost of flows. However, it only supports the cost query 516 of flows defined by the 5-tuple of protocol, source/destination 517 address (hostname, IP address, domain name or MAC address) and ports. 518 However, in the emerging software-defined networking, the concept of 519 flow is not confined by this 5-tuple anymore. Instead, [OF15] has 520 defined 38 header match fields that could define a flow. This 521 document next introduces an advanced flow-based query to support the 522 flow-based cost queries for such a generic context of flows. 524 4.1. Basic Data Types 526 The flow cost service introduces some new basic data types, as 527 defined below. 529 4.1.1. Flow ID 531 A flow ID has the same format as a PIDName, as defined in 532 Section 10.1 of [RFC7285]. It is used to uniquely identify a flow in 533 a flow cost service request. 535 4.1.2. Typed Header Field 537 A typed header field represents a particular field in a network 538 protocol that can be obtained at the application layer. It is 539 represented by the protocol name and the field name, concatenated by 540 the colon (':', U+003A). The typed header fields are case 541 insensitive. 543 For example, "ipv4:source" and "IPv4:source" both represent the 544 source address field used in IPv4 and "tcp:destination" represents 545 the destination port for a TCP connection. 547 See Table 2 for a list of proposed typed header fields. 549 4.1.3. Cost Confidence 551 A cost confidence is defined as a JSON integer within the range of 552 [0, 100]. It represents the ALTO servers' estimation on the accuracy 553 of the returned costs. The larger the cost confidence is, the more 554 accurate the path cost SHOULD be. If the cost value is very 555 accurate, for example, a unique path can be identified for a flow 556 with the provided information, the ALTO server SHOULD provide a cost 557 confidence of 100. 559 The cost confidence CAN be used as an evidence of ambiguous paths, 560 which is often associated with insufficient information in a query. 561 If an ALTO client finds that the associated cost confidence value is 562 low, it can narrow down the flow header space in the query, e.g., by 563 adding optional fields or use IP addresses instead of prefixes. 565 The cost confidence value can be computed in several ways. For 566 example, an ALTO server MAY use the following formula for some cost 567 metrics: 569 c = 100 * (1 - |deviation / mean|) 571 0 if c <= 0 572 confidence = 573 round(c) if c > 0 575 where mean and deviation are computed from the cost values of all 576 possible paths. 578 4.2. Flow Cost Service 580 A flow cost service provides information about costs for each 581 individual flow specified in a request. 583 4.2.1. Media Type 585 The media type of the flow cost service is "application/alto- 586 flowcost+json". 588 4.2.2. HTTP Method 590 The flow cost service is requested using the HTTP POST method. 592 4.2.3. Accept Input Parameters 594 The input parameters of the flow cost service MUST be encoded as a 595 JSON object of type FlowCostRequest in the body of an HTTP POST 596 request. The media type of the request MUST be "application/alto- 597 flowcostparams+json". 599 object { 600 FlowFilterMap flows; 601 } FlowCostRequest : MultiCostRequestBase; 602 object { 603 [CostType cost-type;] 604 [CostType multi-cost-types<1..*>;] 605 [CostType testable-cost-types<1..*>;] 606 [JSONString constraints<0..*>;] 607 [JSONString or-constraints<0..*><0..*>;] 608 } MultiCostRequestBase; 610 object-map { 611 FlowId -> FlowFilter; 612 } FlowFilterMap; 614 object-map { 615 TypedHeaderField -> JSONValue; 616 } FlowFilter; 618 flows: A map of flow filters for which path costs are to be 619 returned. Each flow filter is identified by a unique FlowId, as 620 defined in Section 4.1.1. The value types of a field is protocol- 621 specific, see Table 3 for the value types associated with typed 622 header fields in Table 2. 624 cost-type: The same as defined in Section 4.2.2 of 625 [I-D.ietf-alto-multi-cost]. 627 multi-cost-types: The same as defined in Section 4.2.2 of 628 [I-D.ietf-alto-multi-cost]. 630 testable-cost-types, constraints, or-constraints: The same as 631 defined in Section 4.2.2 of [I-D.ietf-alto-multi-cost]. 633 4.2.4. Capabilities 635 The capabilities of the flow cost service is a JSON object of type 636 FlowCostCapabilities: 638 object { 639 TypedHeaderField required<1..*>; 640 [TypedHeaderField optional<1..*>;] 641 } FlowCostCapabilities : FilteredCostMapCapabilities; 643 with fields: 645 required: A list of required typed header fields. These fields are 646 essential to find the path cost for a given flow and MUST be 647 provided in a flow filter. 649 optional: A list of optional typed header fields. The ALTO server 650 MAY leverage the values of the optional fields to find more 651 accurate costs. 653 4.2.5. Response 655 The "meta" field of a flow cost response MUST contain the same cost 656 type information as defined in Section 4.2.3 of 657 [I-D.ietf-alto-multi-cost]. 659 The data component of a flow cost service is named "flow-cost-map", 660 which is a JSON object of type FlowCostMap: 662 object { 663 FlowCostMap flow-cost-map; 664 [FlowCostMap flow-cost-confidences;] 665 } FlowCostResponse : ResponseEntityBase; 667 object-map { 668 FlowId -> JSONValue; 669 } FlowCostMap; 671 flow-cost-map: A dictionary map with each key (flow ID) representing 672 a flow specified in the request. For each flow, the cost MUST 673 follow the format defined in Section 4.2.3 of 674 [I-D.ietf-alto-multi-cost]. 676 flow-cost-confidences: A dictionary map with each key (flow ID) 677 representing a flow specified in the request. For a single cost, 678 the cost confidence for each flow MUST follow the specification in 679 Section 4.1.3. If the query is using multiple costs where the 680 costs are returned as a JSONArray, the cost confidence MUST also 681 be a JSONArray where each element represents the cost confidence 682 value computed for the corresponding cost type. 684 4.2.5.1. Ambiguous Paths 686 Since new forwarding abstractions support fine-grained routing, for 687 example, OpenFlow 1.5 [OF15] has defined 38 header match fields, it 688 is possible that the ALTO server cannot determine the path using the 689 provided header fields. The computation for costs with ambiguous 690 paths is implementation-specific, the servers can choose to return an 691 integrated result of all possible paths, or simply use the cost of a 692 random path. The ALTO servers SHOULD provide cost confidences to 693 justify the accuracy of the provided cost values. 695 The ALTO server SHOULD be able to determine a unique path when all 696 the optional typed header fields are provided without masks for a 697 flow, however, the client SHOULD NOT assume this always holds. 699 4.2.6. Errors 701 The ALTO servers can provide more information to the clients when 702 requests have errors. The FlowCostErrorMap below can provide basic 703 information about two most common errors for the flow cost service. 704 The ALTO servers MAY include it as the data component of an ALTO 705 error response. If multiple errors are identified, the ALTO server 706 MUST return exactly one error code according to Section 8.5.2 of 707 [RFC7285] . 709 object-map { 710 FlowId -> FlowCostError; 711 } FlowCostErrorMap; 713 object { 714 [TypedHeaderField conflicts<2..*>;] 715 [TypedHeadreField missing<2..*>;] 716 [TypedHeaderField unsupported<1..*>;] 717 } FlowFilterError; 719 conflicts: A list of conflicting typed header fields. See 720 Section 4.2.6.1 for details. 722 missing: A list of missing typed header fields. See Section 4.2.6.2 723 for details. 725 unsupported: A list of unsupported typed header fields. See 726 Section 4.2.6.3 for details. 728 4.2.6.1. Conflicts 730 Some header fields may have conflicts. For example, IPv4 fields and 731 IPv6 fields can never appear in the same packet, nor can TCP and UDP 732 ports. These header fields MUST not be included in the same flow 733 filter, otherwise the ALTO server MUST return an ALTO error response, 734 with the error code "E_INVALID_FIELD_VALUE". As specified in 735 Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field" 736 and the "value" in the "meta" field. In this case, the ALTO server 737 MUST use the flow ID as the "field" and the flow filter as the 738 "value". However, the recommended approach is to use the 739 FlowCostErrorMap, where the server CAN provide the conflicting typed 740 header fields in the "conflicts" field of the FlowFilterError 741 associated with the corresponding flow ID. 743 4.2.6.2. Missing Fields 745 The "E_MISSING_FIELD" error code is originally designed to report the 746 absence of required JSON fields. In the flow cost service, the 747 required typed header fields are implementation-specific and the ALTO 748 servers MUST declare the required fields in the capabilities. If any 749 required header field is missing, the ALTO server MUST return an ALTO 750 error response, with the error code "E_MISSING_FIELD". The ALTO 751 server CAN follow the steps defined in Section 8.5.2 of [RFC7285] to 752 indicate the location of the missing field. An alternative approach 753 which is also recommended, is that the server provide the missing 754 typed header fields in the "missing" field of the FlowFilterError 755 associated with the corresponding flow ID. 757 4.2.6.3. Unsupported Fields 759 If a query contains unsupported typed header fields, e.g., those not 760 in the "required" nor the "optional" capabilities, the ALTO server 761 MUST return an ALTO error response, with the error code 762 "E_INVALID_FIELD_VALUE". Like how the conflicting header fields are 763 handled in Section 4.2.6.1, the ALTO servers CAN report unsupported 764 typed header fields in the "unsupported" field associated with the 765 corresponding flow ID. 767 4.3. Advanced Flow-based Query Example 768 POST /flowcost/lookup HTTP/1.1 769 HOST: alto.example.com 770 Content-Length: 521 771 Content-Type: application/alto-flowcostparams+json 772 Accept: application/alto-flowcost+json,application/alto-error+json 774 { 775 "cost-type": { 776 "cost-mode": "numerical", 777 "cost-metric": "routingcost" 778 }, 779 "flows": { 780 "l3-flow": { 781 "ipv4:source": "192.168.1.1", 782 "ipv4:destination": "192.168.1.2" 783 }, 784 "optional-l2-flow": { 785 "ethernet:source": "12:34:56:78:00:01", 786 "ethernet:destination": "12:34:56:78:00:02" 787 }, 788 "l3-flow-aggr": { 789 "ipv4:source": "192.168.1.0/24", 790 "ipv4:destination": "192.168.2.0/24" 791 } 792 } 793 } 794 HTTP/1.1 200 OK 795 Content-Length: 312 796 Content-Type: application/alto-flowcost+json 798 { 799 "meta": { 800 "cost-type": { 801 "cost-mode": "numerical", 802 "cost-metric": "routingcost" 803 }, 804 }, 805 "flow-cost-map": { 806 "l3-flow": 10, 807 "l3-flow-aggr": 50 808 "optional-l3-flow": 5, 809 }, 810 "flow-cost-confidences": { 811 "l3-flow": 70, 812 "l3-flow-aggr": 40, 813 "optional-l2-flow": 90 814 } 815 } 817 5. Security Considerations 819 This document has not conducted its security analysis. 821 6. IANA Considerations 823 This document defines two new entries to be registered to 824 application/alto-* media types. 826 6.1. Media Types 828 This document registers two media types listed in Table 1. 830 +--------------+--------------------------+----------------+ 831 | Type | Subtype | Specification | 832 +--------------+--------------------------+----------------+ 833 | application | alto-flowcost+json | Section 3.1.3 | 834 | application | alto-flowcostparam+json | Section 3.3.2 | 835 +--------------+--------------------------+----------------+ 837 Table 1: ALTO FCS Media Types 839 Type name: application 840 Subtype name: This document registers two subtypes, as listed in 841 Table 1. 843 Required parameters: n/a 845 Optional parameters: n/a 847 Encoding considerations: Encoding considerations are identical to 848 those specified for the "applicatoin/json" media type. See 849 [RFC7159]. 851 Security considerations: Security considerations are identical to 852 those specified in Section 15 of [RFC7285] . 854 Interoperability considerations: n/a 856 Published specification: This document is the specification for 857 these media types. See Table 1 for the section documenting each 858 media type. 860 Applications that use this media type: ALTO servers and ALTO clients 861 with the extension to support the flow cost service, either 862 standalone or embedded within other applications. 864 Additional information: n/a 866 Person & email address to contact for further information: See 867 Authors' Addresses. 869 Intended usage: COMMON 871 Restrictions on usage: n/a 873 Author: See Authors' Addresses. 875 6.2. Header Field 877 TBD: Create the "ALTO Header Field Name Registry". 879 7. Acknowledgement 881 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 882 Randriamasy and Wendy Roome for fruitful discussions and feedback on 883 this document. Shawn Lin provided substantial review feedback and 884 suggestions to the protocol design. 886 8. References 888 8.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, 892 DOI 10.17487/RFC2119, March 1997, 893 . 895 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 896 Literal IPv6 Addresses in URL's", RFC 2732, 897 DOI 10.17487/RFC2732, December 1999, 898 . 900 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 901 Resource Identifier (URI): Generic Syntax", STD 66, 902 RFC 3986, DOI 10.17487/RFC3986, January 2005, 903 . 905 8.2. Informative References 907 [I-D.ietf-alto-multi-cost] 908 Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 909 ALTO", draft-ietf-alto-multi-cost-05 (work in progress), 910 February 2017. 912 [I-D.wang-alto-ecs-flows] 913 Shen, X., Zhang, J., Wang, J., and Q. Xiang, "ALTO 914 Extension: Endpoint Cost Service for Flows", draft-wang- 915 alto-ecs-flows-01 (work in progress), April 2016. 917 [OF15] Foundation, O., "Openflow switch specification v1. 5.0", 918 2014, 919 . 923 [openflow] 924 McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 925 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 926 "Openflow: enabling innovation in campus networks", 2008. 928 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 929 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 930 2014, . 932 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 933 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 934 "Application-Layer Traffic Optimization (ALTO) Protocol", 935 RFC 7285, DOI 10.17487/RFC7285, September 2014, 936 . 938 Appendix A. Tables 940 +------------+--------------+------------------------------+ 941 | Protocol | Field Name | Description | 942 +------------+--------------+------------------------------+ 943 | Ethernet | source | The source MAC address | 944 | | destination | The destination MAC address | 945 | | vlan-id | VLAN-ID from 802.1Q header | 946 | IPv4 | source | IPv4 source address | 947 | | destination | IPv4 destination address | 948 | IPv6 | source | IPv6 source address | 949 | | destination | IPv6 destination address | 950 | TCP | source | TCP source port | 951 | | destination | TCP destination port | 952 | UDP | source | UDP source port | 953 | | destination | UDP destination port | 954 +------------+--------------+------------------------------+ 956 Table 2: Protocols and Field Names. 958 +-----------------------+-------------------------------------------+ 959 | Typed Header Field | Acceptable Value Type | 960 +-----------------------+-------------------------------------------+ 961 | ethernet:source | JSONString as MAC address | 962 | ethernet:destination | | 963 | ethernet:vlan-id | JSONNumber in the range of [1, 4094] | 964 | ipv4:source | JSONString as IPv4 address or IPv4 prefix | 965 | ipv4:destination | | 966 | ipv6:source | JSONString as IPv6 address or IPv6 prefix | 967 | ipv6:destination | | 968 | tcp:source | JSONNumber in the range of [0, 65535] | 969 | tcp:destination | 0 serves as a wildcard value | 970 | udp:source | | 971 | udp:destination | | 972 +-----------------------+-------------------------------------------+ 974 Table 3: Value Types for Typed Header Fields 976 Authors' Addresses 978 Kai Gao 979 Tsinghua University 980 30 Shuangqinglu Street 981 Beijing 100084 982 China 984 Email: gaok12@mails.tsinghua.edu.cn 986 Jingxuan Jensen Zhang 987 Tongji University 988 4800 Cao'an Hwy 989 Shanghai 201804 990 China 992 Email: jingxuan.n.zhang@gmail.com 994 Junzhuo Austin Wang 995 Tongji University 996 4800 Cao'an Hwy, Jiading District 997 Shanghai 998 China 1000 Email: wangjunzhuo200@gmail.com 1002 Qiao Xiang 1003 Tongji/Yale University 1004 51 Prospect Street 1005 New Haven, CT 1006 USA 1008 Email: qiao.xiang@cs.yale.edu 1010 Y. Richard Yang 1011 Yale University 1012 51 Prospect St 1013 New Haven CT 1014 USA 1016 Email: yry@cs.yale.edu