ALTO WG K. Gao Internet-Draft Tsinghua University Intended status: Standards Track J. Zhang Expires: September 14, 2017 J. Wang Tongji University Q. Xiang Tongji/Yale University Y. Yang Yale University March 13, 2017 ALTO Extension: Flow-based Cost Query draft-gao-alto-fcs-01.txt Abstract The emergence of new networking datapath capabilities has substantially increased the flexibility of networking. For example, OpenFlow has emerged as a major southbound protocol for Software- Defined Networking, and OpenFlow allows flexible routing beyond simple destination-based routing. In this document, we define a new extention to ALTO, namely the Flow Cost Service, for ALTO clients in an OpenFlow-enabled network to query ALTO network information. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2017. Gao, et al. Expires September 14, 2017 [Page 1] Internet-Draft Flow Cost Service March 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes Since Version -00 . . . . . . . . . . . . . . . . . . 4 3. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 4 3.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 4 3.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 5 3.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Extend Endpoint Abstraction . . . . . . . . . . . . . . . 6 3.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 7 3.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 7 3.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. Flow-based Filtered Cost Map Service Example . . . . 10 3.4.3. Flow-based Endpoint Cost Service Example . . . . . . 11 4. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 12 4.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 12 4.1.3. Cost Confidence . . . . . . . . . . . . . . . . . . . 12 4.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 13 4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 15 4.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Advanced Flow-based Query Example . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 Gao, et al. Expires September 14, 2017 [Page 2] Internet-Draft Flow Cost Service March 2017 6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction ALTO is now being considered as a solution for more flexible network use cases. The legacy ALTO services defined in [RFC7285] just try to provide the cost information for peer selection. It is enough for the P2P domain. But the network is becoming more and more flexible nowadays. There are two major changes in the coming network evolution: o Some new network architectures such as SDN are adopting the logically central control solution. It makes the network optimization toward the higher-level view. The traffic optimizer can not only decide the source or the destination of the data transferring, but also make the flow-level traffic scheduling. To solve the flow-level scheduling problem, the cross-product query schema will be redundant. o With the emerging technologies in the data plane, where multiple header fields can be used to determine the forwarding path, networks are moving to more flexible routing mechanisms beyond the simple destination-based routing. As a consequence, the endpoint cost service (ECS), which depends on only source and destination IP addresses as currently defined, is no longer sufficient to provide accurate cost information. This document intents to address the following issues in providing fine-grained flow-based endpoint cost query services: 1. The compatibility with the legacy ALTO ECS service; 2. The support for emerging network architectures such as Software Defined Networking; 3. The trade-off between fine-grained queries and query/response redundancy. In this document, we consider the extensions of ALTO service which provide the flow-based cost query. The basic solution is to extend the legacy ALTO services to support flow-based query schema. Section 3 describes the extended schema on Filtered Cost Map (FCM) and Endpoint Cost Service (ECS) to support endpoint cost queries of flows defined by the 5-tuple of protocol, src/dst name/address and Gao, et al. Expires September 14, 2017 [Page 3] Internet-Draft Flow Cost Service March 2017 ports. For networks using a more generic flow concept such as Software-Defined Networks, Section 4 defines a novel ALTO service named the Flow Cost Service (FCS) with the flow-oriented query schema. It SHOULD support the query of any fine-grained routing cost to satisfy the growing demand of obtaining accurate costs in a network using flow-based routing. Section 5 and Section 6 discuss security and IANA considerations. 2. Changes Since Version -00 o Define the basic flow-based query extensions for Filtered Cost Map and Endpoint Cost service. The basic flow-based query is downward compatible with the legacy ALTO service. It does not introduce any new media types. o Move the service of media-type "application/alto-flowcost+json" to the advanced flow-based query extension. It will ask ALTO server to support the new media type. 3. ALTO Flow Cost Specification: Basic Flow-based Query This section describes a downward compatible extension for Filtered Cost Map and Endpoint Cost Service to support flow-based query. 3.1. Flow-based Filtered Cost Map 3.1.1. Capabilities The Filtered Cost Map capabilities are extended with two new members: o flow-based-filter o traffic-types The capability "flow-based-filter" indicates whether this resource supports flow-based query. The capability "traffic-type" list which traffic types are supported to be queried by this resource. The FilteredCostMapCapabilities object in Section 4.1.1 of [I-D.ietf-alto-multi-cost] is extended as follows: object { JSONString cost-type-names<1..*>; [JSONBool cost-constraints;] [JSONNumber max-cost-types;] [JSONString testable-cost-type-names<1..*>;] [JSONBool flow-based-filter<0..*>;] [JSONString traffic-type<0..*>;] } FilteredCostMapCapabilities; Gao, et al. Expires September 14, 2017 [Page 4] Internet-Draft Flow Cost Service March 2017 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 of [RFC7285]. max-cost-types and testable-cost-type-names: As defined in Section 4.1.1 of [I-D.ietf-alto-multi-cost]. flow-based-filter: If true, then the ALTO Server allows pid-flows to be queried in the requests. If not present, this field MUST be interpreted as if it is specified false. traffic-type: If present, the resource allows to query the specified traffic types but only on the traffic types in this array. 3.1.2. Accept Input Parameters The ReqFilteredCostMap object in Section 4.1.2 of [I-D.ietf-alto-multi-cost] is extended as follows: object { [CostType cost-type;] [CostType multi-cost-types<1..*>;] [CostType testable-cost-types<1..*>;] [JSONString constraints<0..*>;] [JSONString or-constraints<0..*><0..*>;] [JSONString traffic-types<0..*>;] [PIDFilter pids;] [PIDFlow pid-flows<0..*>;] } ReqFilteredCostMap; object { PIDName src; PIDName dst; } PIDFlow; cost-type, multi-cost-types, testable-cost-types, constraints, or- constraints: As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost]. traffic-types: A JSONArray of JSONStrings, where each string indicates a traffic type. If present, the ALTO server will only return the cost of the traffic with the specified types. pids: As defined in Section 11.3.2.3 of [RFC7285]. pid-flows: A list of PID src to PID dst for which path costs are to be returned. Gao, et al. Expires September 14, 2017 [Page 5] Internet-Draft Flow Cost Service March 2017 Additional requirement is that the Client MUST specify either "pids" or "pid-flows", but MUST NOT specify both. 3.1.3. Response The response is exactly as defined in Section 4.1.3 of [I-D.ietf-alto-multi-cost]. 3.2. Extend Endpoint Abstraction The typed endpoint address used by ECS is defined in Section 10.4 of [RFC7285]. That section only defines two address types: ipv4 and ipv6 to express IPv4 addresses and IPv6 addresses respectively. However, the flow-extended ECS may contain MAC addresses, domain names and port numbers to give a cost between hosts. Therefore, this document transforms the typed endpoint address to EndpointURI to measure the cost more precisely. This URI must conform to the syntax for URI defined in [@!RFC3986], in particular with respect to character encoding. The EndpointURI may have one of the following form: "protocol:name-or-address:port" "protocol:name-or-address" And this EndpointURI is defined in [OF15], and it is used to identify a controller connection. To extend endpoint abstraction, we use ConnectionURI to specify a flow with fields: protocol: The protocol field is REQUIRED. It contains many kinds of protocols, the protocol can be layer two protocols (like PPP, ARP) and layer three protocols (like IPv4, IPv6), it can also be upper- layer protocols (like UDP, TCP, HTTP, FTP). And for different kinds of protocols, there are some provisions. Firstly, if the protocol field is layer two or layer three protocol, client's query can not fill in the port field in EndpointURI, because the port is unnecessary. Secondly, when the protocol is upper-layer protocol, and if client do not indicate the port, for some special protocol, we will use the default port. name-or-address: This field is REQUIRED. The value can be an IP address, a domain name or a MAC address. port: This field is OPTIONAL. It is forbidden when the protocol is layer three (like IPv4 and IPv6) or layer two protocol (like MAC). And it is added for more fine-gained request when the protocol is upper-layer protocol. For some classic protocols, if the port is not Gao, et al. Expires September 14, 2017 [Page 6] Internet-Draft Flow Cost Service March 2017 indicated, we use the default port. For example, the default port of SSH is 22, and FTP is 21, HTTP is 80. A request to query the cost between hosts looks like this: { "cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost"}, "endpoints" : { "srcs": [ "ipv4:192.0.2.2:22" ], "dsts": [ "http:www.a.com", "ipv4:198.51.100.34", "telnet:198.51.100.34:23", "ipv6:2000::1:2345:6789:abcd" ] } } This design of API is fully compatible with ECS. TypedEndpointAddr of EndpointFilter in ECS have the format of "protocal:address", and the protocol only supports IPv4 and IPv6, so it can also be used in this design. 3.3. Flow-based Endpoint Cost Service 3.3.1. Capabilities The extensions to EndpointCostMapCpabilities are identically to FilteredCostMapCapabilities in Section 3.1.1. But for field "flow- based-filter", the true value means the ALTO server allows to get requests with "endpoint-flows" field. If not present, this field MUST be interpreted as if it is specified false. 3.3.2. Accept Input Parameters The ReqEndpointCostMap object in Section 4.2.2 of [I-D.ietf-alto-multi-cost] is extended as follows: Gao, et al. Expires September 14, 2017 [Page 7] Internet-Draft Flow Cost Service March 2017 object { [CostType cost-type;] [CostType multi-cost-types<1..*>;] [CostType testable-cost-types<1..*>;] [JSONString constraints<0..*>;] [JSONString or-constraints<0..*><0..*>;] [JSONString traffic-types<0..*>;] [EndpointFilter endpoints;] [EndpointFlow endpoint-flows<1..*>;] } ReqEndpointCostMap; object { EndpointURI srcs<0..*>; EndpointURI dsts<0..*>; } EndpointFilter; object { EndpointURI src; EndpointURI dst; } EndpointFlow; cost-type, multi-cost-types, testable-cost-types, constraints, or- constraints: As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost]. traffic-types: As defined in Section 3.1.2 of this document. endpoints: As defined in Section 11.5.1.3 of [RFC7285]. endpoint-flows: A list of source endpoint to destination endpoint for which path costs are to be returned. Additional requirement is that the Client MUST specify either "endpoints" or "endpoint-flows", but MUST NOT specify both. 3.3.3. Response The response is exactly as defined in Section 4.2.3 of [I-D.ietf-alto-multi-cost]. 3.4. Example 3.4.1. IRD Example GET /directory HTTP/1.1 Host: alto.example.com Accept: application/alto-directory+json,application/alto-error+json Gao, et al. Expires September 14, 2017 [Page 8] Internet-Draft Flow Cost Service March 2017 HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-directory+json { "meta" : { "default-alto-network-map" : "my-default-network-map", "cost-types" : { "num-routingcost" : { "cost-mode" : "numerial", "cost-metric" : "routingcost"}, "ord-routingcost" : { "cost-mode" : "ordinal", "cost-metric" : "routingcost"} }, ..... Other ALTO cost types as described in RFC7285 ..... }, "resources" : { "my-default-network-map" : { "uri" : "http://alto.example.com/networkmap", "media-type" : "application/alto-networkmap+json" }, "basic-flow-based-cost-map" : { "uri" : "http://alto.example.com/costmap/multi/filtered", "media-types" : [ "application/alto-costmap+json" ], "accepts" : [ "application/alto-costmapfilter+json" ], "uses" : [ "my-default-network-map" ], "capabilities" : { "flow-based-filter" : true, "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] } }, "endpoint-advanced-flow-based-cost-map" : { "uri" : "http://alto.example.com/endpointcost/lookup", "media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ], "uses" : [ "my-default-network-map" ], "capabilities" : { "flow-based-filter" : true, "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] } } } } Gao, et al. Expires September 14, 2017 [Page 9] Internet-Draft Flow Cost Service March 2017 3.4.2. Flow-based Filtered Cost Map Service Example POST /costmap/multi/filtered HTTP/1.1 Host: alto.example.com Accept: application/alto-costmap+json,application/alto-error+json Content-Length: [TBD] Content-Type: application/alto-costmapfilter+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "routingcost" }, "pid-flows": [ { "src": "PID1", "dst": "PID2" }, { "src": "PID1", "dst": "PID3" }, { "src": "PID3", "dst": "PID4" } ] } HTTP/1.1 200 OK Content-Length: [TBD] Content-Type: application/alto-costmap+json { "meta": { "dependent-vtags": [ { "resource-id": "my-default-network-map", "tag": "75ed013b3cb58f896e839582504f622838ce670f" }, ], "cost-type": { "cost-mode": "numerical", "cost-metric": "routingcost" } }, "cost-map": { "PID1": { "PID2": 100 }, "PID1": { "PID3": 20 }, "PID3": { "PID4": 80 } } } Gao, et al. Expires September 14, 2017 [Page 10] Internet-Draft Flow Cost Service March 2017 3.4.3. Flow-based Endpoint Cost Service Example POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Accept: application/alto-endpointcost+json,application/alto-error+json Content-Length: [TBD] Content-Type: application/alto-endpointcostparams+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "hopcount" }, "endpoint-flows": [ { "src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89" }, { "src": "ipv4:192.0.2.2", "dst": "http:cdn1.example.com" }, { "src": "tcp:203.0.113.45:54321", "dst": "http:cdn1.example.com" } ] } HTTP/1.1 200 OK Content-Length: [TBD] Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "hopcount" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 3, "http:cdn1.example.com": 6 }, "tcp:203.0.113.45:54321": { "http:cdn1.example.com": 10 } } } Gao, et al. Expires September 14, 2017 [Page 11] Internet-Draft Flow Cost Service March 2017 4. ALTO Flow Cost Specification: Advanced Flow-based Query The basic flow-based query extends the ECS service to support querying the cost of flows. However, it only supports the cost query of flows defined by the 5-tuple of protocol, source/dst address (hostname, IP address, domain name or MAC address) and ports. However, in the emerging software-defined networking, the concept of flow is not confined by this 5-tuple anymore. Instead, the OpenFlow 1.5 specifications has defined 38 header match fields that could define a flow. This document next introduces an advanced flow-based query to support the flow-based cost queries for such a generic context of flows. 4.1. Basic Data Types The flow cost service introduces some new basic data types, as defined below. 4.1.1. Flow ID A flow ID has the same format as a PIDName, as defined in [RFC7285] Section 10.1 [1]. It is used to uniquely identify a flow in a flow cost service request. 4.1.2. Typed Header Field A typed header field represents a particular field in a network protocol that can be obtained at the application layer. It is represented by the protocol name and the field name, concatenated by the colon (':', U+003A). The typed header fields are case insensitive. For example, "ipv4:source" and "IPv4:source" both represent the source address field used in IPv4 and "tcp:destination" represents the destination port for a TCP connection. See Table 2 for a list of proposed typed header fields. 4.1.3. Cost Confidence A cost confidence is defined as a JSON integer within the range of [0, 100]. It represents the ALTO servers' estimation on the accuracy of the returned costs. The larger the cost confidence is, the more accurate the path cost SHOULD be. If the cost value is very accurate, for example, a unique path can be identified for a flow with the provided information, the ALTO server SHOULD provide a cost confidence of 100. Gao, et al. Expires September 14, 2017 [Page 12] Internet-Draft Flow Cost Service March 2017 The cost confidence CAN be used as an evidence of ambiguous paths, which is often associated with insufficient information in a query. If an ALTO client finds that the associated cost confidence value is low, it can narrow down the flow header space in the query, e.g., by adding optional fields or use IP addresses instead of prefixes. The cost confidence value can be computed in several ways. For example, an ALTO server MAY use the following formula for some cost metrics: c = 100 * (1 - |deviation / mean|) 0 if c <= 0 confidence = round(c) if c > 0 where mean and deviation are computed from the cost values of all possible paths. 4.2. Flow Cost Service A flow cost service provides information about costs for each individual flow specified in a request. 4.2.1. Media Type The media type of the flow cost service is "application/alto- flowcost+json". 4.2.2. HTTP Method The flow cost service is requested using the HTTP POST method. 4.2.3. Accept Input Parameters The input parameters of the flow cost service MUST be encoded as a JSON object of type FlowCostRequest in the body of an HTTP POST request. The media type of the request MUST be "application/alto- flowcostparams+json". object { FlowFilterMap flows; } FlowCostRequest : MultiCostRequestBase; Gao, et al. Expires September 14, 2017 [Page 13] Internet-Draft Flow Cost Service March 2017 object { [CostType cost-type;] [CostType multi-cost-types<1..*>;] [CostType testable-cost-types<1..*>;] [JSONString constraints<0..*>;] [JSONString or-constraints<0..*><0..*>;] } MultiCostRequestBase; object-map { FlowId -> FlowFilter; } FlowFilterMap; object-map { TypedHeaderField -> JSONValue; } FlowFilter; flows: A map of flow filters for which path costs are to be returned. Each flow filter is identified by a unique FlowId, as defined in Section 4.1.1. The value types of a field is protocol- specific, see Table 3 for the value types associated with typed header fields in Table 2. cost-type: The same as defined in [I-D.ietf-alto-multi-cost] Section 4.2.2 [2]. multi-cost-types: The same as defined in [I-D.ietf-alto-multi-cost] Section 4.2.2 [3]. testable-cost-types, constraints, or-constraints: The same as defined in [I-D.ietf-alto-multi-cost] Section 4.2.2 [4]. 4.2.4. Capabilities The capabilities of the flow cost service is a JSON object of type FlowCostCapabilities: object { TypedHeaderField required<1..*>; [TypedHeaderField optional<1..*>;] } FlowCostCapabilities : FilteredCostMapCapabilities; with fields: required: A list of required typed header fields. These fields are essential to find the path cost for a given flow and MUST be provided in a flow filter. Gao, et al. Expires September 14, 2017 [Page 14] Internet-Draft Flow Cost Service March 2017 optional: A list of optional typed header fields. The ALTO server MAY leverage the values of the optional fields to find more accurate costs. 4.2.5. Response The "meta" field of a flow cost response MUST contain the same cost type information as defined in [I-D.ietf-alto-multi-cost] Section 4.2.3 [5]. The data component of a flow cost service is named "flow-cost-map", which is a JSON object of type FlowCostMap: object { FlowCostMap flow-cost-map; [FlowCostMap flow-cost-confidences;] } FlowCostResponse : ResponseEntityBase; object-map { FlowId -> JSONValue; } FlowCostMap; flow-cost-map: A dictionary map with each key (flow ID) representing a flow specified in the request. For each flow, the cost MUST follow the format defined in [I-D.ietf-alto-multi-cost] Section 4.2.3 [6]. flow-cost-confidences: A dictionary map with each key (flow ID) representing a flow specified in the request. For a single cost, the cost confidence for each flow MUST follow the specification in Section 4.1.3. If the query is using multiple costs where the costs are returned as a JSONArray, the cost confidence MUST also be a JSONArray where each element represents the cost confidence value computed for the corresponding cost type. 4.2.5.1. Ambiguous Paths Since new forwarding abstractions support fine-grained routing, for example, OpenFlow 1.5 [OF15] has defined 38 header match fields, it is possible that the ALTO server cannot determine the path using the provided header fields. The computation for costs with ambiguous paths is implementation-specific, the servers can choose to return an integrated result of all possible paths, or simply use the cost of a random path. The ALTO servers SHOULD provide cost confidences to justify the accuracy of the provided cost values. Gao, et al. Expires September 14, 2017 [Page 15] Internet-Draft Flow Cost Service March 2017 The ALTO server SHOULD be able to determine a unique path when all the optional typed header fields are provided without masks for a flow, however, the client SHOULD NOT assume this always holds. 4.2.6. Errors The ALTO servers can provide more information to the clients when requests have errors. The FlowCostErrorMap below can provide basic information about two most common errors for the flow cost service. The ALTO servers MAY include it as the data component of an ALTO error response. If multiple errors are identified, the ALTO server MUST return exactly one error code according to [RFC7285] Section 8.5.2 [7]. object-map { FlowId -> FlowCostError; } FlowCostErrorMap; object { [TypedHeaderField conflicts<2..*>;] [TypedHeadreField missing<2..*>;] [TypedHeaderField unsupported<1..*>;] } FlowFilterError; conflicts: A list of conflicting typed header fields. See Section 4.2.6.1 for details. missing: A list of missing typed header fields. See Section 4.2.6.2 for details. unsupported: A list of unsupported typed header fields. See Section 4.2.6.3 for details. 4.2.6.1. Conflicts 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. Gao, et al. Expires September 14, 2017 [Page 16] Internet-Draft Flow Cost Service March 2017 4.2.6.2. Missing Fields The "E_MISSING_FIELD" error code is originally designed to report the absence of required JSON fields. In the flow cost service, the required typed header fields are implementation-specific and the ALTO servers MUST declare the required fields in the capabilities. If any required header field is missing, the ALTO server MUST return an ALTO error response, with the error code "E_MISSING_FIELD". The ALTO server CAN follow the steps defined in [RFC7285] Section 8.5.2 [9] to indicate the location of the missing field. An alternative approach which is also recommended, is that the server provide the missing typed header fields in the "missing" field of the FlowFilterError associated with the corresponding flow ID. 4.2.6.3. Unsupported Fields If a query contains unsupported typed header fields, e.g., those not in the "required" nor the "optional" capabilities, the ALTO server MUST return an ALTO error response, with the error code "E_INVALID_FIELD_VALUE". Like how the conflicting header fields are handled in Section 4.2.6.1, the ALTO servers CAN report unsupported typed header fields in the "unsupported" field associated with the corresponding flow ID. 4.3. Advanced Flow-based Query Example Gao, et al. Expires September 14, 2017 [Page 17] Internet-Draft Flow Cost Service March 2017 POST /flowcost/lookup HTTP/1.1 HOST: alto.example.com Content-Length: 521 Content-Type: application/alto-flowcostparams+json Accept: application/alto-flowcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "routingcost" }, "flows": { "l3-flow": { "ipv4:source": "192.168.1.1", "ipv4:destination": "192.168.1.2" }, "optional-l2-flow": { "ethernet:source": "12:34:56:78:00:01", "ethernet:destination": "12:34:56:78:00:02" }, "l3-flow-aggr": { "ipv4:source": "192.168.1.0/24", "ipv4:destination": "192.168.2.0/24" } } } Gao, et al. Expires September 14, 2017 [Page 18] Internet-Draft Flow Cost Service March 2017 HTTP/1.1 200 OK Content-Length: 312 Content-Type: application/alto-flowcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "routingcost" }, }, "flow-cost-map": { "l3-flow": 10, "l3-flow-aggr": 50 "optional-l3-flow": 5, }, "flow-cost-confidences": { "l3-flow": 70, "l3-flow-aggr": 40, "optional-l2-flow": 90 } } 5. Security Considerations This document has not conducted its security analysis. 6. IANA Considerations This document defines two new entries to be registered to application/alto-* media types. 6.1. Media Types This document registers two media types, listed in Table 1. +--------------+--------------------------+----------------+ | Type | Subtype | Specification | +--------------+--------------------------+----------------+ | application | alto-flowcost+json | Section 3.1.3 | | application | alto-flowcostparam+json | Section 3.3.2 | +--------------+--------------------------+----------------+ Table 1: ALTO FCS Media Types Type name: application Gao, et al. Expires September 14, 2017 [Page 19] Internet-Draft Flow Cost Service March 2017 Subtype name: This document registers two subtypes, as listed in Table 1. Required parameters: n/a Optional parameters: n/a Encoding considerations: Encoding considerations are identical to those specified for the "applicatoin/json" media type. See [RFC7159]. Security considerations: Security considerations are identical to those specified in [RFC7285] Section 15 [10]. Interoperability considerations: n/a Published specification: This document is the specification for these media types. See Table 1 for the section documenting each media type. Applications that use this media type: ALTO servers and ALTO clients with the extension to support the flow cost service, either standalone or embedded within other applications. Additional information: n/a Person & email address to contact for further information: See Authors' Addresses. Intended usage: COMMON Restrictions on usage: n/a Author: See Authors' Addresses. 6.2. Header Field TBD: Create the "ALTO Header Field Name Registry". 7. Acknowledgement The authors would like to thank Dawn Chen, Haizhou Du, Sabine Randriamasy and Wendy Roome for fruitful discussions and feedback on this document. Shawn Lin provided substantial review feedback and suggestions to the protocol design. Gao, et al. Expires September 14, 2017 [Page 20] Internet-Draft Flow Cost Service March 2017 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.ietf-alto-multi-cost] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost ALTO", draft-ietf-alto-multi-cost-05 (work in progress), February 2017. [I-D.wang-alto-ecs-flows] Shen, X., Zhang, J., Wang, J., and Q. Xiang, "ALTO Extension: Endpoint Cost Service for Flows", draft-wang- alto-ecs-flows-01 (work in progress), April 2016. [OF15] Foundation, O., "Openflow switch specification v1. 5.0", 2014, . [openflow] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and J. Turner, "Openflow: enabling innovation in campus networks", 2008. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . 8.3. URIs [1] https://tools.ietf.org/html/rfc7285#section-10.1 [2] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 Gao, et al. Expires September 14, 2017 [Page 21] Internet-Draft Flow Cost Service March 2017 [3] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 [4] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.2 [5] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.3 [6] https://tools.ietf.org/html/draft-ietf-alto-multi-cost-02#4.2.3 [7] https://tools.ietf.org/html/rfc7285#section-8.5.2 [8] https://tools.ietf.org/html/rfc7285#section-8.5.2 [9] https://tools.ietf.org/html/rfc7285#section-8.5.2 [10] ttps://tools.ietf.org/html/rfc7285#section-15 Appendix A. Tables +------------+--------------+------------------------------+ | Protocol | Field Name | Description | +------------+--------------+------------------------------+ | Ethernet | source | The source MAC address | | | destination | The destination MAC address | | | vlan-id | VLAN-ID from 802.1Q header | | IPv4 | source | IPv4 source address | | | destination | IPv4 destination address | | IPv6 | source | IPv6 source address | | | destination | IPv6 destination address | | TCP | source | TCP source port | | | destination | TCP destination port | | UDP | source | UDP source port | | | destination | UDP destination port | +------------+--------------+------------------------------+ Table 2: Protocols and Field Names. Gao, et al. Expires September 14, 2017 [Page 22] Internet-Draft Flow Cost Service March 2017 +-----------------------+-------------------------------------------+ | Typed Header Field | Acceptable Value Type | +-----------------------+-------------------------------------------+ | ethernet:source | JSONString as MAC address | | ethernet:destination | | | ethernet:vlan-id | JSONNumber in the range of [1, 4094] | | ipv4:source | JSONString as IPv4 address or IPv4 prefix | | ipv4:destination | | | ipv6:source | JSONString as IPv6 address or IPv6 prefix | | ipv6:destination | | | tcp:source | JSONNumber in the range of [0, 65535] | | tcp:destination | 0 serves as a wildcard value | | udp:source | | | udp:destination | | +-----------------------+-------------------------------------------+ Table 3: Value Types for Typed Header Fields Authors' Addresses Kai Gao Tsinghua University 30 Shuangqinglu Street Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Jingxuan Jensen Zhang Tongji University 4800 Cao'an Hwy Shanghai 201804 China Email: jingxuan.n.zhang@gmail.com Junzhuo Austin Wang Tongji University 4800 Cao'an Hwy, Jiading District Shanghai China Email: wangjunzhuo200@gmail.com Gao, et al. Expires September 14, 2017 [Page 23] Internet-Draft Flow Cost Service March 2017 Qiao Xiang Tongji/Yale University 51 Prospect Street New Haven, CT USA Email: qiao.xiang@cs.yale.edu Y. Richard Yang Yale University 51 Prospect St New Haven CT USA Email: yry@cs.yale.edu Gao, et al. Expires September 14, 2017 [Page 24]