idnits 2.17.1 draft-gao-alto-fcs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 219 has weird spacing: '...DFilter pids;...' == Line 220 has weird spacing: '...PIDFlow pid...' == Line 637 has weird spacing: '...erField requi...' == Line 662 has weird spacing: '...CostMap flo...' == 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 [RFC7285] Section 8.5.2 [8], 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 (March 13, 2017) is 2598 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 375, but not defined == Missing Reference: 'TBD' is mentioned on line 488, but not defined -- Looks like a reference, but probably isn't: '1' on line 973 -- Looks like a reference, but probably isn't: '0' on line 978 -- Looks like a reference, but probably isn't: '100' on line 550 -- Looks like a reference, but probably isn't: '2' on line 930 -- Looks like a reference, but probably isn't: '3' on line 932 -- Looks like a reference, but probably isn't: '4' on line 934 -- Looks like a reference, but probably isn't: '5' on line 936 -- Looks like a reference, but probably isn't: '6' on line 938 -- Looks like a reference, but probably isn't: '7' on line 940 -- Looks like a reference, but probably isn't: '8' on line 942 -- Looks like a reference, but probably isn't: '9' on line 944 -- Looks like a reference, but probably isn't: '10' on line 946 -- Looks like a reference, but probably isn't: '4094' on line 973 -- Looks like a reference, but probably isn't: '65535' on line 978 == Unused Reference: 'I-D.wang-alto-ecs-flows' is defined on line 900, but no explicit reference was found in the text == 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: 0 errors (**), 0 flaws (~~), 10 warnings (==), 16 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: September 14, 2017 J. Wang 6 Tongji University 7 Q. Xiang 8 Tongji/Yale University 9 Y. Yang 10 Yale University 11 March 13, 2017 13 ALTO Extension: Flow-based Cost Query 14 draft-gao-alto-fcs-01.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 September 14, 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 -00 . . . . . . . . . . . . . . . . . . 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 Abstraction . . . . . . . . . . . . . . . 6 74 3.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 7 75 3.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 7 76 3.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 7 77 3.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 78 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 8 80 3.4.2. Flow-based Filtered Cost Map Service Example . . . . 10 81 3.4.3. Flow-based Endpoint Cost Service Example . . . . . . 11 82 4. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 12 83 4.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 12 84 4.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 12 86 4.1.3. Cost Confidence . . . . . . . . . . . . . . . . . . . 12 87 4.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 13 88 4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 89 4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13 90 4.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 13 91 4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 92 4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 15 93 4.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.3. Advanced Flow-based Query Example . . . . . . . . . . . . 17 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19 98 6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . 20 99 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 102 8.2. Informative References . . . . . . . . . . . . . . . . . 21 103 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 107 1. Introduction 109 ALTO is now being considered as a solution for more flexible network 110 use cases. The legacy ALTO services defined in [RFC7285] just try to 111 provide the cost information for peer selection. It is enough for 112 the P2P domain. But the network is becoming more and more flexible 113 nowadays. There are two major changes in the coming network 114 evolution: 116 o Some new network architectures such as SDN are adopting the 117 logically central control solution. It makes the network 118 optimization toward the higher-level view. The traffic optimizer 119 can not only decide the source or the destination of the data 120 transferring, but also make the flow-level traffic scheduling. To 121 solve the flow-level scheduling problem, the cross-product query 122 schema will be redundant. 124 o With the emerging technologies in the data plane, where multiple 125 header fields can be used to determine the forwarding path, 126 networks are moving to more flexible routing mechanisms beyond the 127 simple destination-based routing. As a consequence, the endpoint 128 cost service (ECS), which depends on only source and destination 129 IP addresses as currently defined, is no longer sufficient to 130 provide accurate cost information. 132 This document intents to address the following issues in providing 133 fine-grained flow-based endpoint cost query services: 1. The 134 compatibility with the legacy ALTO ECS service; 2. The support for 135 emerging network architectures such as Software Defined Networking; 136 3. The trade-off between fine-grained queries and query/response 137 redundancy. 139 In this document, we consider the extensions of ALTO service which 140 provide the flow-based cost query. The basic solution is to extend 141 the legacy ALTO services to support flow-based query schema. 142 Section 3 describes the extended schema on Filtered Cost Map (FCM) 143 and Endpoint Cost Service (ECS) to support endpoint cost queries of 144 flows defined by the 5-tuple of protocol, src/dst name/address and 145 ports. For networks using a more generic flow concept such as 146 Software-Defined Networks, Section 4 defines a novel ALTO service 147 named the Flow Cost Service (FCS) with the flow-oriented query 148 schema. It SHOULD support the query of any fine-grained routing cost 149 to satisfy the growing demand of obtaining accurate costs in a 150 network using flow-based routing. Section 5 and Section 6 discuss 151 security and IANA considerations. 153 2. Changes Since Version -00 155 o Define the basic flow-based query extensions for Filtered Cost Map 156 and Endpoint Cost service. The basic flow-based query is downward 157 compatible with the legacy ALTO service. It does not introduce 158 any new media types. 160 o Move the service of media-type "application/alto-flowcost+json" to 161 the advanced flow-based query extension. It will ask ALTO server 162 to support the new media type. 164 3. ALTO Flow Cost Specification: Basic Flow-based Query 166 This section describes a downward compatible extension for Filtered 167 Cost Map and Endpoint Cost Service to support flow-based query. 169 3.1. Flow-based Filtered Cost Map 171 3.1.1. Capabilities 173 The Filtered Cost Map capabilities are extended with two new members: 175 o flow-based-filter 177 o traffic-types 179 The capability "flow-based-filter" indicates whether this resource 180 supports flow-based query. The capability "traffic-type" list which 181 traffic types are supported to be queried by this resource. The 182 FilteredCostMapCapabilities object in Section 4.1.1 of 183 [I-D.ietf-alto-multi-cost] is extended as follows: 185 object { 186 JSONString cost-type-names<1..*>; 187 [JSONBool cost-constraints;] 188 [JSONNumber max-cost-types;] 189 [JSONString testable-cost-type-names<1..*>;] 190 [JSONBool flow-based-filter<0..*>;] 191 [JSONString traffic-type<0..*>;] 192 } FilteredCostMapCapabilities; 194 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 195 of [RFC7285]. 197 max-cost-types and testable-cost-type-names: As defined in 198 Section 4.1.1 of [I-D.ietf-alto-multi-cost]. 200 flow-based-filter: If true, then the ALTO Server allows pid-flows to 201 be queried in the requests. If not present, this field MUST be 202 interpreted as if it is specified false. 204 traffic-type: If present, the resource allows to query the specified 205 traffic types but only on the traffic types in this array. 207 3.1.2. Accept Input Parameters 209 The ReqFilteredCostMap object in Section 4.1.2 of 210 [I-D.ietf-alto-multi-cost] is extended as follows: 212 object { 213 [CostType cost-type;] 214 [CostType multi-cost-types<1..*>;] 215 [CostType testable-cost-types<1..*>;] 216 [JSONString constraints<0..*>;] 217 [JSONString or-constraints<0..*><0..*>;] 218 [JSONString traffic-types<0..*>;] 219 [PIDFilter pids;] 220 [PIDFlow pid-flows<0..*>;] 221 } ReqFilteredCostMap; 223 object { 224 PIDName src; 225 PIDName dst; 226 } PIDFlow; 228 cost-type, multi-cost-types, testable-cost-types, constraints, or- 229 constraints: As defined in Section 4.1.2 of 230 [I-D.ietf-alto-multi-cost]. 232 traffic-types: A JSONArray of JSONStrings, where each string 233 indicates a traffic type. If present, the ALTO server will only 234 return the cost of the traffic with the specified types. 236 pids: As defined in Section 11.3.2.3 of [RFC7285]. 238 pid-flows: A list of PID src to PID dst for which path costs are to 239 be returned. 241 Additional requirement is that the Client MUST specify either "pids" 242 or "pid-flows", but MUST NOT specify both. 244 3.1.3. Response 246 The response is exactly as defined in Section 4.1.3 of 247 [I-D.ietf-alto-multi-cost]. 249 3.2. Extend Endpoint Abstraction 251 The typed endpoint address used by ECS is defined in Section 10.4 of 252 [RFC7285]. That section only defines two address types: ipv4 and 253 ipv6 to express IPv4 addresses and IPv6 addresses respectively. 254 However, the flow-extended ECS may contain MAC addresses, domain 255 names and port numbers to give a cost between hosts. 257 Therefore, this document transforms the typed endpoint address to 258 EndpointURI to measure the cost more precisely. This URI must 259 conform to the syntax for URI defined in [@!RFC3986], in particular 260 with respect to character encoding. The EndpointURI may have one of 261 the following form: 263 "protocol:name-or-address:port" 264 "protocol:name-or-address" 266 And this EndpointURI is defined in [OF15], and it is used to identify 267 a controller connection. To extend endpoint abstraction, we use 268 ConnectionURI to specify a flow with fields: 270 protocol: The protocol field is REQUIRED. It contains many kinds of 271 protocols, the protocol can be layer two protocols (like PPP, ARP) 272 and layer three protocols (like IPv4, IPv6), it can also be upper- 273 layer protocols (like UDP, TCP, HTTP, FTP). And for different kinds 274 of protocols, there are some provisions. Firstly, if the protocol 275 field is layer two or layer three protocol, client's query can not 276 fill in the port field in EndpointURI, because the port is 277 unnecessary. Secondly, when the protocol is upper-layer protocol, 278 and if client do not indicate the port, for some special protocol, we 279 will use the default port. 281 name-or-address: This field is REQUIRED. The value can be an IP 282 address, a domain name or a MAC address. 284 port: This field is OPTIONAL. It is forbidden when the protocol is 285 layer three (like IPv4 and IPv6) or layer two protocol (like MAC). 286 And it is added for more fine-gained request when the protocol is 287 upper-layer protocol. For some classic protocols, if the port is not 288 indicated, we use the default port. For example, the default port of 289 SSH is 22, and FTP is 21, HTTP is 80. 291 A request to query the cost between hosts looks like this: 293 { 294 "cost-type": {"cost-mode" : "ordinal", 295 "cost-metric" : "routingcost"}, 296 "endpoints" : { 297 "srcs": [ "ipv4:192.0.2.2:22" ], 298 "dsts": [ 299 "http:www.a.com", 300 "ipv4:198.51.100.34", 301 "telnet:198.51.100.34:23", 302 "ipv6:2000::1:2345:6789:abcd" 303 ] 304 } 305 } 307 This design of API is fully compatible with ECS. TypedEndpointAddr 308 of EndpointFilter in ECS have the format of "protocal:address", and 309 the protocol only supports IPv4 and IPv6, so it can also be used in 310 this design. 312 3.3. Flow-based Endpoint Cost Service 314 3.3.1. Capabilities 316 The extensions to EndpointCostMapCpabilities are identically to 317 FilteredCostMapCapabilities in Section 3.1.1. But for field "flow- 318 based-filter", the true value means the ALTO server allows to get 319 requests with "endpoint-flows" field. If not present, this field 320 MUST be interpreted as if it is specified false. 322 3.3.2. Accept Input Parameters 324 The ReqEndpointCostMap object in Section 4.2.2 of 325 [I-D.ietf-alto-multi-cost] is extended as follows: 327 object { 328 [CostType cost-type;] 329 [CostType multi-cost-types<1..*>;] 330 [CostType testable-cost-types<1..*>;] 331 [JSONString constraints<0..*>;] 332 [JSONString or-constraints<0..*><0..*>;] 333 [JSONString traffic-types<0..*>;] 334 [EndpointFilter endpoints;] 335 [EndpointFlow endpoint-flows<1..*>;] 336 } ReqEndpointCostMap; 338 object { 339 EndpointURI srcs<0..*>; 340 EndpointURI dsts<0..*>; 341 } EndpointFilter; 343 object { 344 EndpointURI src; 345 EndpointURI dst; 346 } EndpointFlow; 348 cost-type, multi-cost-types, testable-cost-types, constraints, or- 349 constraints: As defined in Section 4.1.2 of 350 [I-D.ietf-alto-multi-cost]. 352 traffic-types: As defined in Section 3.1.2 of this document. 354 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 356 endpoint-flows: A list of source endpoint to destination endpoint for 357 which path costs are to be returned. 359 Additional requirement is that the Client MUST specify either 360 "endpoints" or "endpoint-flows", but MUST NOT specify both. 362 3.3.3. Response 364 The response is exactly as defined in Section 4.2.3 of 365 [I-D.ietf-alto-multi-cost]. 367 3.4. Example 369 3.4.1. IRD Example 371 GET /directory HTTP/1.1 372 Host: alto.example.com 373 Accept: application/alto-directory+json,application/alto-error+json 374 HTTP/1.1 200 OK 375 Content-Length: [TODO] 376 Content-Type: application/alto-directory+json 377 { 378 "meta" : { 379 "default-alto-network-map" : "my-default-network-map", 380 "cost-types" : { 381 "num-routingcost" : { 382 "cost-mode" : "numerial", 383 "cost-metric" : "routingcost"}, 384 "ord-routingcost" : { 385 "cost-mode" : "ordinal", 386 "cost-metric" : "routingcost"} 387 }, 388 ..... 389 Other ALTO cost types as described in RFC7285 390 ..... 391 }, 392 "resources" : { 393 "my-default-network-map" : { 394 "uri" : "http://alto.example.com/networkmap", 395 "media-type" : "application/alto-networkmap+json" 396 }, 397 "basic-flow-based-cost-map" : { 398 "uri" : "http://alto.example.com/costmap/multi/filtered", 399 "media-types" : [ "application/alto-costmap+json" ], 400 "accepts" : [ "application/alto-costmapfilter+json" ], 401 "uses" : [ "my-default-network-map" ], 402 "capabilities" : { 403 "flow-based-filter" : true, 404 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 405 } 406 }, 407 "endpoint-advanced-flow-based-cost-map" : { 408 "uri" : "http://alto.example.com/endpointcost/lookup", 409 "media-types" : [ "application/alto-endpointcost+json" ], 410 "accepts" : [ "application/alto-endpointcostparams+json" ], 411 "uses" : [ "my-default-network-map" ], 412 "capabilities" : { 413 "flow-based-filter" : true, 414 "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] 415 } 416 } 417 } 418 } 420 3.4.2. Flow-based Filtered Cost Map Service Example 422 POST /costmap/multi/filtered HTTP/1.1 423 Host: alto.example.com 424 Accept: application/alto-costmap+json,application/alto-error+json 425 Content-Length: [TBD] 426 Content-Type: application/alto-costmapfilter+json 428 { 429 "cost-type": { 430 "cost-mode": "numerical", 431 "cost-metric": "routingcost" 432 }, 433 "pid-flows": [ 434 { "src": "PID1", "dst": "PID2" }, 435 { "src": "PID1", "dst": "PID3" }, 436 { "src": "PID3", "dst": "PID4" } 437 ] 438 } 440 HTTP/1.1 200 OK 441 Content-Length: [TBD] 442 Content-Type: application/alto-costmap+json 444 { 445 "meta": { 446 "dependent-vtags": [ 447 { 448 "resource-id": "my-default-network-map", 449 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 450 }, 451 ], 452 "cost-type": { 453 "cost-mode": "numerical", 454 "cost-metric": "routingcost" 455 } 456 }, 457 "cost-map": { 458 "PID1": { "PID2": 100 }, 459 "PID1": { "PID3": 20 }, 460 "PID3": { "PID4": 80 } 461 } 462 } 464 3.4.3. Flow-based Endpoint Cost Service Example 466 POST /endpointcost/lookup HTTP/1.1 467 Host: alto.example.com 468 Accept: application/alto-endpointcost+json,application/alto-error+json 469 Content-Length: [TBD] 470 Content-Type: application/alto-endpointcostparams+json 472 { 473 "cost-type": { 474 "cost-mode": "numerical", 475 "cost-metric": "hopcount" 476 }, 477 "endpoint-flows": [ 478 { "src": "ipv4:192.0.2.2", 479 "dst": "ipv4:192.0.2.89" }, 480 { "src": "ipv4:192.0.2.2", 481 "dst": "http:cdn1.example.com" }, 482 { "src": "tcp:203.0.113.45:54321", 483 "dst": "http:cdn1.example.com" } 484 ] 485 } 487 HTTP/1.1 200 OK 488 Content-Length: [TBD] 489 Content-Type: application/alto-endpointcost+json 491 { 492 "meta": { 493 "cost-type": { 494 "cost-mode": "numerical", 495 "cost-metric": "hopcount" 496 } 497 }, 498 "endpoint-cost-map": { 499 "ipv4:192.0.2.2": { 500 "ipv4:192.0.2.89": 3, 501 "http:cdn1.example.com": 6 502 }, 503 "tcp:203.0.113.45:54321": { 504 "http:cdn1.example.com": 10 505 } 506 } 507 } 509 4. ALTO Flow Cost Specification: Advanced Flow-based Query 511 The basic flow-based query extends the ECS service to support 512 querying the cost of flows. However, it only supports the cost query 513 of flows defined by the 5-tuple of protocol, source/dst address 514 (hostname, IP address, domain name or MAC address) and ports. 515 However, in the emerging software-defined networking, the concept of 516 flow is not confined by this 5-tuple anymore. Instead, the OpenFlow 517 1.5 specifications has defined 38 header match fields that could 518 define a flow. This document next introduces an advanced flow-based 519 query to support the flow-based cost queries for such a generic 520 context of flows. 522 4.1. Basic Data Types 524 The flow cost service introduces some new basic data types, as 525 defined below. 527 4.1.1. Flow ID 529 A flow ID has the same format as a PIDName, as defined in [RFC7285] 530 Section 10.1 [1]. It is used to uniquely identify a flow in a flow 531 cost service request. 533 4.1.2. Typed Header Field 535 A typed header field represents a particular field in a network 536 protocol that can be obtained at the application layer. It is 537 represented by the protocol name and the field name, concatenated by 538 the colon (':', U+003A). The typed header fields are case 539 insensitive. 541 For example, "ipv4:source" and "IPv4:source" both represent the 542 source address field used in IPv4 and "tcp:destination" represents 543 the destination port for a TCP connection. 545 See Table 2 for a list of proposed typed header fields. 547 4.1.3. Cost Confidence 549 A cost confidence is defined as a JSON integer within the range of 550 [0, 100]. It represents the ALTO servers' estimation on the accuracy 551 of the returned costs. The larger the cost confidence is, the more 552 accurate the path cost SHOULD be. If the cost value is very 553 accurate, for example, a unique path can be identified for a flow 554 with the provided information, the ALTO server SHOULD provide a cost 555 confidence of 100. 557 The cost confidence CAN be used as an evidence of ambiguous paths, 558 which is often associated with insufficient information in a query. 559 If an ALTO client finds that the associated cost confidence value is 560 low, it can narrow down the flow header space in the query, e.g., by 561 adding optional fields or use IP addresses instead of prefixes. 563 The cost confidence value can be computed in several ways. For 564 example, an ALTO server MAY use the following formula for some cost 565 metrics: 567 c = 100 * (1 - |deviation / mean|) 569 0 if c <= 0 570 confidence = 571 round(c) if c > 0 573 where mean and deviation are computed from the cost values of all 574 possible paths. 576 4.2. Flow Cost Service 578 A flow cost service provides information about costs for each 579 individual flow specified in a request. 581 4.2.1. Media Type 583 The media type of the flow cost service is "application/alto- 584 flowcost+json". 586 4.2.2. HTTP Method 588 The flow cost service is requested using the HTTP POST method. 590 4.2.3. Accept Input Parameters 592 The input parameters of the flow cost service MUST be encoded as a 593 JSON object of type FlowCostRequest in the body of an HTTP POST 594 request. The media type of the request MUST be "application/alto- 595 flowcostparams+json". 597 object { 598 FlowFilterMap flows; 599 } FlowCostRequest : MultiCostRequestBase; 600 object { 601 [CostType cost-type;] 602 [CostType multi-cost-types<1..*>;] 603 [CostType testable-cost-types<1..*>;] 604 [JSONString constraints<0..*>;] 605 [JSONString or-constraints<0..*><0..*>;] 606 } MultiCostRequestBase; 608 object-map { 609 FlowId -> FlowFilter; 610 } FlowFilterMap; 612 object-map { 613 TypedHeaderField -> JSONValue; 614 } FlowFilter; 616 flows: A map of flow filters for which path costs are to be 617 returned. Each flow filter is identified by a unique FlowId, as 618 defined in Section 4.1.1. The value types of a field is protocol- 619 specific, see Table 3 for the value types associated with typed 620 header fields in Table 2. 622 cost-type: The same as defined in [I-D.ietf-alto-multi-cost] 623 Section 4.2.2 [2]. 625 multi-cost-types: The same as defined in [I-D.ietf-alto-multi-cost] 626 Section 4.2.2 [3]. 628 testable-cost-types, constraints, or-constraints: The same as 629 defined in [I-D.ietf-alto-multi-cost] Section 4.2.2 [4]. 631 4.2.4. Capabilities 633 The capabilities of the flow cost service is a JSON object of type 634 FlowCostCapabilities: 636 object { 637 TypedHeaderField required<1..*>; 638 [TypedHeaderField optional<1..*>;] 639 } FlowCostCapabilities : FilteredCostMapCapabilities; 641 with fields: 643 required: A list of required typed header fields. These fields are 644 essential to find the path cost for a given flow and MUST be 645 provided in a flow filter. 647 optional: A list of optional typed header fields. The ALTO server 648 MAY leverage the values of the optional fields to find more 649 accurate costs. 651 4.2.5. Response 653 The "meta" field of a flow cost response MUST contain the same cost 654 type information as defined in [I-D.ietf-alto-multi-cost] 655 Section 4.2.3 [5]. 657 The data component of a flow cost service is named "flow-cost-map", 658 which is a JSON object of type FlowCostMap: 660 object { 661 FlowCostMap flow-cost-map; 662 [FlowCostMap flow-cost-confidences;] 663 } FlowCostResponse : ResponseEntityBase; 665 object-map { 666 FlowId -> JSONValue; 667 } FlowCostMap; 669 flow-cost-map: A dictionary map with each key (flow ID) representing 670 a flow specified in the request. For each flow, the cost MUST 671 follow the format defined in [I-D.ietf-alto-multi-cost] 672 Section 4.2.3 [6]. 674 flow-cost-confidences: A dictionary map with each key (flow ID) 675 representing a flow specified in the request. For a single cost, 676 the cost confidence for each flow MUST follow the specification in 677 Section 4.1.3. If the query is using multiple costs where the 678 costs are returned as a JSONArray, the cost confidence MUST also 679 be a JSONArray where each element represents the cost confidence 680 value computed for the corresponding cost type. 682 4.2.5.1. Ambiguous Paths 684 Since new forwarding abstractions support fine-grained routing, for 685 example, OpenFlow 1.5 [OF15] has defined 38 header match fields, it 686 is possible that the ALTO server cannot determine the path using the 687 provided header fields. The computation for costs with ambiguous 688 paths is implementation-specific, the servers can choose to return an 689 integrated result of all possible paths, or simply use the cost of a 690 random path. The ALTO servers SHOULD provide cost confidences to 691 justify the accuracy of the provided cost values. 693 The ALTO server SHOULD be able to determine a unique path when all 694 the optional typed header fields are provided without masks for a 695 flow, however, the client SHOULD NOT assume this always holds. 697 4.2.6. Errors 699 The ALTO servers can provide more information to the clients when 700 requests have errors. The FlowCostErrorMap below can provide basic 701 information about two most common errors for the flow cost service. 702 The ALTO servers MAY include it as the data component of an ALTO 703 error response. If multiple errors are identified, the ALTO server 704 MUST return exactly one error code according to [RFC7285] 705 Section 8.5.2 [7]. 707 object-map { 708 FlowId -> FlowCostError; 709 } FlowCostErrorMap; 711 object { 712 [TypedHeaderField conflicts<2..*>;] 713 [TypedHeadreField missing<2..*>;] 714 [TypedHeaderField unsupported<1..*>;] 715 } FlowFilterError; 717 conflicts: A list of conflicting typed header fields. See 718 Section 4.2.6.1 for details. 720 missing: A list of missing typed header fields. See Section 4.2.6.2 721 for details. 723 unsupported: A list of unsupported typed header fields. See 724 Section 4.2.6.3 for details. 726 4.2.6.1. Conflicts 728 Some header fields may have conflicts. For example, IPv4 fields and 729 IPv6 fields can never appear in the same packet, nor can TCP and UDP 730 ports. These header fields MUST not be included in the same flow 731 filter, otherwise the ALTO server MUST return an ALTO error response, 732 with the error code "E_INVALID_FIELD_VALUE". As specified in 733 [RFC7285] Section 8.5.2 [8], the ALTO server MAY include the "field" 734 and the "value" in the "meta" field. In this case, the ALTO server 735 MUST use the flow ID as the "field" and the flow filter as the 736 "value". However, the recommended approach is to use the 737 FlowCostErrorMap, where the server CAN provide the conflicting typed 738 header fields in the "conflicts" field of the FlowFilterError 739 associated with the corresponding flow ID. 741 4.2.6.2. Missing Fields 743 The "E_MISSING_FIELD" error code is originally designed to report the 744 absence of required JSON fields. In the flow cost service, the 745 required typed header fields are implementation-specific and the ALTO 746 servers MUST declare the required fields in the capabilities. If any 747 required header field is missing, the ALTO server MUST return an ALTO 748 error response, with the error code "E_MISSING_FIELD". The ALTO 749 server CAN follow the steps defined in [RFC7285] Section 8.5.2 [9] to 750 indicate the location of the missing field. An alternative approach 751 which is also recommended, is that the server provide the missing 752 typed header fields in the "missing" field of the FlowFilterError 753 associated with the corresponding flow ID. 755 4.2.6.3. Unsupported Fields 757 If a query contains unsupported typed header fields, e.g., those not 758 in the "required" nor the "optional" capabilities, the ALTO server 759 MUST return an ALTO error response, with the error code 760 "E_INVALID_FIELD_VALUE". Like how the conflicting header fields are 761 handled in Section 4.2.6.1, the ALTO servers CAN report unsupported 762 typed header fields in the "unsupported" field associated with the 763 corresponding flow ID. 765 4.3. Advanced Flow-based Query Example 766 POST /flowcost/lookup HTTP/1.1 767 HOST: alto.example.com 768 Content-Length: 521 769 Content-Type: application/alto-flowcostparams+json 770 Accept: application/alto-flowcost+json,application/alto-error+json 772 { 773 "cost-type": { 774 "cost-mode": "numerical", 775 "cost-metric": "routingcost" 776 }, 777 "flows": { 778 "l3-flow": { 779 "ipv4:source": "192.168.1.1", 780 "ipv4:destination": "192.168.1.2" 781 }, 782 "optional-l2-flow": { 783 "ethernet:source": "12:34:56:78:00:01", 784 "ethernet:destination": "12:34:56:78:00:02" 785 }, 786 "l3-flow-aggr": { 787 "ipv4:source": "192.168.1.0/24", 788 "ipv4:destination": "192.168.2.0/24" 789 } 790 } 791 } 792 HTTP/1.1 200 OK 793 Content-Length: 312 794 Content-Type: application/alto-flowcost+json 796 { 797 "meta": { 798 "cost-type": { 799 "cost-mode": "numerical", 800 "cost-metric": "routingcost" 801 }, 802 }, 803 "flow-cost-map": { 804 "l3-flow": 10, 805 "l3-flow-aggr": 50 806 "optional-l3-flow": 5, 807 }, 808 "flow-cost-confidences": { 809 "l3-flow": 70, 810 "l3-flow-aggr": 40, 811 "optional-l2-flow": 90 812 } 813 } 815 5. Security Considerations 817 This document has not conducted its security analysis. 819 6. IANA Considerations 821 This document defines two new entries to be registered to 822 application/alto-* media types. 824 6.1. Media Types 826 This document registers two media types, listed in Table 1. 828 +--------------+--------------------------+----------------+ 829 | Type | Subtype | Specification | 830 +--------------+--------------------------+----------------+ 831 | application | alto-flowcost+json | Section 3.1.3 | 832 | application | alto-flowcostparam+json | Section 3.3.2 | 833 +--------------+--------------------------+----------------+ 835 Table 1: ALTO FCS Media Types 837 Type name: application 838 Subtype name: This document registers two subtypes, as listed in 839 Table 1. 841 Required parameters: n/a 843 Optional parameters: n/a 845 Encoding considerations: Encoding considerations are identical to 846 those specified for the "applicatoin/json" media type. See 847 [RFC7159]. 849 Security considerations: Security considerations are identical to 850 those specified in [RFC7285] Section 15 [10]. 852 Interoperability considerations: n/a 854 Published specification: This document is the specification for 855 these media types. See Table 1 for the section documenting each 856 media type. 858 Applications that use this media type: ALTO servers and ALTO clients 859 with the extension to support the flow cost service, either 860 standalone or embedded within other applications. 862 Additional information: n/a 864 Person & email address to contact for further information: See 865 Authors' Addresses. 867 Intended usage: COMMON 869 Restrictions on usage: n/a 871 Author: See Authors' Addresses. 873 6.2. Header Field 875 TBD: Create the "ALTO Header Field Name Registry". 877 7. Acknowledgement 879 The authors would like to thank Dawn Chen, Haizhou Du, Sabine 880 Randriamasy and Wendy Roome for fruitful discussions and feedback on 881 this document. Shawn Lin provided substantial review feedback and 882 suggestions to the protocol design. 884 8. References 886 8.1. Normative References 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 8.2. Informative References 895 [I-D.ietf-alto-multi-cost] 896 Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 897 ALTO", draft-ietf-alto-multi-cost-05 (work in progress), 898 February 2017. 900 [I-D.wang-alto-ecs-flows] 901 Shen, X., Zhang, J., Wang, J., and Q. Xiang, "ALTO 902 Extension: Endpoint Cost Service for Flows", draft-wang- 903 alto-ecs-flows-01 (work in progress), April 2016. 905 [OF15] Foundation, O., "Openflow switch specification v1. 5.0", 906 2014, 907 . 911 [openflow] 912 McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 913 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 914 "Openflow: enabling innovation in campus networks", 2008. 916 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 917 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 918 2014, . 920 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 921 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 922 "Application-Layer Traffic Optimization (ALTO) Protocol", 923 RFC 7285, DOI 10.17487/RFC7285, September 2014, 924 . 926 8.3. URIs 928 [1] https://tools.ietf.org/html/rfc7285#section-10.1 930 [2] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 932 [3] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 934 [4] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 936 [5] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.3 938 [6] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.3 940 [7] https://tools.ietf.org/html/rfc7285#section-8.5.2 942 [8] https://tools.ietf.org/html/rfc7285#section-8.5.2 944 [9] https://tools.ietf.org/html/rfc7285#section-8.5.2 946 [10] ttps://tools.ietf.org/html/rfc7285#section-15 948 Appendix A. Tables 950 +------------+--------------+------------------------------+ 951 | Protocol | Field Name | Description | 952 +------------+--------------+------------------------------+ 953 | Ethernet | source | The source MAC address | 954 | | destination | The destination MAC address | 955 | | vlan-id | VLAN-ID from 802.1Q header | 956 | IPv4 | source | IPv4 source address | 957 | | destination | IPv4 destination address | 958 | IPv6 | source | IPv6 source address | 959 | | destination | IPv6 destination address | 960 | TCP | source | TCP source port | 961 | | destination | TCP destination port | 962 | UDP | source | UDP source port | 963 | | destination | UDP destination port | 964 +------------+--------------+------------------------------+ 966 Table 2: Protocols and Field Names. 968 +-----------------------+-------------------------------------------+ 969 | Typed Header Field | Acceptable Value Type | 970 +-----------------------+-------------------------------------------+ 971 | ethernet:source | JSONString as MAC address | 972 | ethernet:destination | | 973 | ethernet:vlan-id | JSONNumber in the range of [1, 4094] | 974 | ipv4:source | JSONString as IPv4 address or IPv4 prefix | 975 | ipv4:destination | | 976 | ipv6:source | JSONString as IPv6 address or IPv6 prefix | 977 | ipv6:destination | | 978 | tcp:source | JSONNumber in the range of [0, 65535] | 979 | tcp:destination | 0 serves as a wildcard value | 980 | udp:source | | 981 | udp:destination | | 982 +-----------------------+-------------------------------------------+ 984 Table 3: Value Types for Typed Header Fields 986 Authors' Addresses 988 Kai Gao 989 Tsinghua University 990 30 Shuangqinglu Street 991 Beijing 100084 992 China 994 Email: gaok12@mails.tsinghua.edu.cn 996 Jingxuan Jensen Zhang 997 Tongji University 998 4800 Cao'an Hwy 999 Shanghai 201804 1000 China 1002 Email: jingxuan.n.zhang@gmail.com 1004 Junzhuo Austin Wang 1005 Tongji University 1006 4800 Cao'an Hwy, Jiading District 1007 Shanghai 1008 China 1010 Email: wangjunzhuo200@gmail.com 1011 Qiao Xiang 1012 Tongji/Yale University 1013 51 Prospect Street 1014 New Haven, CT 1015 USA 1017 Email: qiao.xiang@cs.yale.edu 1019 Y. Richard Yang 1020 Yale University 1021 51 Prospect St 1022 New Haven CT 1023 USA 1025 Email: yry@cs.yale.edu