ALTO WG J. Zhang Internet-Draft Tongji University Intended status: Standards Track K. Gao Expires: September 6, 2018 Tsinghua University J. Wang Tongji University Q. Xiang Tongji/Yale University Y. Yang Yale University March 5, 2018 ALTO Extension: Flow-based Cost Query draft-gao-alto-fcs-05.txt Abstract ALTO cost maps and endpoint cost services map a source-destination pair into a cost value. However, current filter specifications, which define the set of source-destination pairs in an ALTO query, have two limitations: 1) Only very limited address types are supported (IPv4 and IPv6), which is not sufficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks. 2) The base ALTO protocol only defines filters enumerating all sources and all destinations, leading to redundant information in the response. To address these two issues, this document extends the base ALTO protocol with a more fine-grained filter type which allows ALTO clients to select only the concerned source-destination pairs, and a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses. 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/. Zhang, et al. Expires September 6, 2018 [Page 1] Internet-Draft Flow Cost Service March 2018 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 6, 2018. Copyright Notice Copyright (c) 2018 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 4 3.1. Extended Endpoint Address . . . . . . . . . . . . . . . . 5 3.2. Flow-based Filter . . . . . . . . . . . . . . . . . . . . 5 4. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 5 5. Extended Endpoint Address . . . . . . . . . . . . . . . . . . 6 5.1. Address Type . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Endpoint Address . . . . . . . . . . . . . . . . . . . . 7 5.2.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 7 5.2.2. Domain Name . . . . . . . . . . . . . . . . . . . . . 8 5.2.3. IPv4 Socket Address . . . . . . . . . . . . . . . . . 8 5.2.4. IPv6 Socket Address . . . . . . . . . . . . . . . . . 8 5.3. Address Type Compatibility . . . . . . . . . . . . . . . 8 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Extended Cost Query Filters . . . . . . . . . . . . . . . . . 9 6.1. Filtered Cost Map Extension . . . . . . . . . . . . . . . 9 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 9 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 10 6.2. Endpoint Cost Service Extension . . . . . . . . . . . . . 10 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 11 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhang, et al. Expires September 6, 2018 [Page 2] Internet-Draft Flow Cost Service March 2018 6.3.1. Information Resource Directory . . . . . . . . . . . 12 6.3.2. Flow-based Filtered Cost Map Service . . . . . . . . 13 6.3.3. Flow-based Endpoint Cost Service Example . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 16 8.2. ALTO Address Type Compatibility Registry . . . . . . . . 16 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction ALTO cost query services (Filtered Cost Map and Endpoint Cost Service) can be regarded as functions transforming a given subset of a specific query space into a network view abstract. However, the current specification has some limitations. First, in the base ALTO protocol [RFC7285], the endpoint cost filter only contains the source and destination IP addresses. In practice, both Internet Service Providers (ISP) and local network administrators MAY conduct policy-based routing, e.g., P2P traffic may be constrained and has a smaller bandwidth than HTTP traffic. Also, web services with different QoS requirements may be hosted on the same machine and have the same IP address but different paths with different QoS metrics. Second, in the base ALTO protocol [RFC7285], the query space is defined by the lists of sources and destinations. For a query with N sources and M destinations, the response contains NM entries. While such a query schema is well suited for peer-to-peer (P2P) applications where files of the same seed are stored on all hosts, it may lead to a lot of redundancy in use cases such as modern data analytics systems where replicas of the same dataset are stored on only a small subset of servers. Consider a system where the number of replicas is 3 (the default in HDFS), jointly scheduling N concurrent transfers only needs a maximum of 3N entries but the base ALTO protocol MAY return up to N^2 entries. Thus, we can conclude that the following additional requirements (AR) MUST be satisfied to allow ALTO clients make more accurate and efficient cost queries. AR-1: ALTO clients SHOULD be able to specify accurate query space in cost query services. Zhang, et al. Expires September 6, 2018 [Page 3] Internet-Draft Flow Cost Service March 2018 The base ALTO protocol only includes IPv4 and IPv6 addresses as endpoint address types, which may not be sufficient to accurately identify an endpoint with emerging flow-based routing mechanisms. ALTO clients MAY suffer from suboptimal decisions because of such inaccuracy. Thus, the ALTO protocol SHOULD be extended so that clients CAN be able to specify accurate query space, i.e., with more fine-grained endpoint address types. AR-2: ALTO clients SHOULD be able to specify only the essential query space in cost query services. Existing PIDFilter (see Sec 11.3.2.3 in [RFC7285]) and EndpointFilter (see Sec 11.5.1.3 in [RFC7285]) represent the cross-product of sources and destinations, and can introduce a lot of redundancy in certain use cases. This limitation CAN greatly harm the scalability of the ALTO protocol. Thus, the ALTO protocol SHOULD be extended so that ALTO clients CAN specify only the essential cost query space, i.e., the concerned source- destination pairs. In this document, we describe an ALTO extension specifying flow-based cost queries. The rest of this document is organized as follows. Section 5 introduces several new address types that extend the query space of ALTO cost services. Section 6 describes the extended schema on Filtered Cost Map (FCM) and Endpoint Cost Service (ECS) to support cost queries of arbitrary source-destination combinations. Section 7 and Section 8 discuss security and IANA considerations. 2. Terminology This document uses the same terms as defined in [RFC7285] and [RFC8189] with the following additional term: 2.1. Flow In this document, a flow refers to all communications between two endpoints. A flow is valid if and only if there CAN be valid communications between the two endpoints, which oftentimes requires that that two endpoint addresses have compatible address types. 3. Overview of Approaches This section presents a non-normative overview of the extension to support flow-based cost query. It assumes the readers are familiar with Filtered Cost Map and Endpoint Cost Service defined in [RFC7285] and their extensions defined in [RFC8189]. Zhang, et al. Expires September 6, 2018 [Page 4] Internet-Draft Flow Cost Service March 2018 3.1. Extended Endpoint Address To allow ALTO clients specify accurate query space in cost query services (AR-1), this document defines several new endpoint address types. An endpoint address with a new type is referred to as an extended endpoint address. Since the address types of both the source and the destination correspond to the same network flow, they MUST NOT conflict. This document defines an address type conflict table to indicate conflicts. If some source and destination address types in a query conflict with each others, ALTO servers SHOULD return the corresponding error. 3.2. Flow-based Filter To allow ALTO clients specify only the essential query space in cost query services (AR-2), both PIDFilter and EndpointFilter in the base protocol MUST be extended. The extended filters are referred to as flow-based filters. A straight-forward way of satisfying AR-1 is to have an ALTO client list all its concerned flows. Despite its simplicity, it MAY be too large in size, especially when many flows have common sources or common destinations in the query. Also from the implementation's perspective, it cannot reuse the functionality to parse a PIDFilter/ EndpointFilter. Thus, the flow-based filters defined in this document allow ALTO clients to include multiple PIDFilter/EndpointFilter objects in the same query. Apparently, if we replace each PIDFilter/EndpointFilter of N sources and M destinations with NM filters that have exactly one source and destination, the two representations refer to the same set of flows. As a result, one can aggregate flows with common sources or destinations in one PIDFilter/EndpointFilter object without introducing redundant flows. From the implementation's perspective, one MAY reuse an ALTO library which parses PIDFilter/EndpointFilter and/or converts them into a set of source-destination pairs. 4. Changes Since Version -01 Note to Editor: Please remove this section prior to publication. This section records the change logs of the draft updates. Changes since -04 revision: Zhang, et al. Expires September 6, 2018 [Page 5] Internet-Draft Flow Cost Service March 2018 o Improve the clarity of the document by explicitly stating the problems. o Keep only flow in the terminology section. o Move section 6 Advanced Flow-based Query out of this document. o Change ALTO Address Type Conflicts Registry to ALTO Address Type Compatibility Registry. Changes since older versions: Since -03 revision: o Remove some irrelevant content from the draft. o Improve the description of the new endpoint address type identifier registry. And add a new registry to declare the conflicting address type identifiers. Since -02 revision: o Change "EndpointURI" to "AddressType::EndpointAddr" for consistency. o Replace Cost Confidence by Cost Statistics for compatibility. Since -01 revision: 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. Since -00 revision: o Change the schema of pid-flows and endpoint-flows fields from pair list to pair mesh list. 5. Extended Endpoint Address This document registers new address types and defines the corresponding formats for endpoint addresses of each new address type. Zhang, et al. Expires September 6, 2018 [Page 6] Internet-Draft Flow Cost Service March 2018 5.1. Address Type The new AddressType identifiers defined in this document are as follows: eth: An endpoint address with type eth is the address of an Ethernet interface. It is used to uniquely identify an endpoint in the data link layer. domain: An endpoint address with type domain is the domain name of a web service. It is used to uniquely identify a web service which MAY be translated to one or more IPv4 address(es). domain6: An endpoint address with type domain6 is the domain name of a web service. It is used to uniquely identify a web service which MAY be translated to one or more IPv6 address(es). tcp: An endpoint address with type tcp is the address of a TCP socket. It is used to uniquely identify an IPv4 TCP socket in the transport layer. tcp6: An endpoint address with type tcp6 is the address of a TCP socket. It is used to uniquely identify an IPv6 TCP socket in the transport layer. udp: An endpoint address with type udp is the address of a UDP socket. It is used to uniquely identify an IPv4 UDP socket in the transport layer. udp6: An endpoint address with type udp6 is the address of a UDP socket. It is used to uniquely identify an IPv6 UDP socket in the transport layer. 5.2. Endpoint Address This document defines EndpointAddr when AddressType is in Section 8.1. 5.2.1. MAC Address An Endpoint Address of type eth is encoded as a MAC address, whose format is encoded as specified by either format EUI-48 in [EUI48] or EUI-64 in [EUI64]. Zhang, et al. Expires September 6, 2018 [Page 7] Internet-Draft Flow Cost Service March 2018 5.2.2. Domain Name An Endpoint Address of type domain or domain6 is encoded as a domain name, as specified in Section 11 of [RFC2181]. It MUST have at least one corresponding A (domain) or AAAA (domain6) record in the DNS. 5.2.3. IPv4 Socket Address An Endpoint Address of type tcp or udp is encoded as an IPv4 socket address. It is encoded as a string of the format Host:Port with the : character as a separator. The Host component of an IPv4 socket address is encoded as specified by either an IPv4 address (see Section 10.4.3.1 of [RFC7285]) or an IPv4-compatible domain name (see Section 5.2.2). The Port component of an IPv4 socket address is encoded as an integer between 1 and 65535. 5.2.4. IPv6 Socket Address An Endpoint Address of type tcp6 or udp6 is encoded as an IPv6 socket address. It is also encoded as a string of the format Host:Port with the : character as a separator. The Host component of an IPv6 socket address is encoded as specified by either an IPv6 address (see Section 10.4.3.2 of [RFC7285]) enclosed in the [" and "] characters or an IPv6-compatible domain name (see Section 5.2.2). The Port component of IPv6 socket address is encoded as an integer between 1 and 65535. 5.3. Address Type Compatibility In practice, a flow with endpoint addresses with different types MAY NOT be valid. For example, a source endpoint with an IPv4 address CANNOT establish a network connection with a destination endpoint with an IPv6 address. Neither can a source with a TCP socket address and a destination with a UDP socket address. Thus, to explicitly define the compatibility between AddressType identifiers, every ALTO AddressType identifier MUST provide a list of AddressType identifiers that are compatible with it in the ALTO Address Type Compatibility Registry Section 8.2. For all sources and destinations in a PIDFilter/EndpointFilter, if the AddressType identifiers of a given pair DO NOT appear in the ALTO Address Type Compatibility Registry, an ALTO server MUST return an ALTO error response with the error code "E_INVALID_FIELD_VALUE" with optional information to help diagnose the incompatibility. Zhang, et al. Expires September 6, 2018 [Page 8] Internet-Draft Flow Cost Service March 2018 5.4. Examples Some valid endpoint addresses are demonstrated as follows: "eth:98-e0-d9-9c-df-81" "domain:www.example.com" "tcp:198.51.100.34:5123" "udp6:[2000::1:2345:6789:abcd]:8080" 6. Extended Cost Query Filters This section describes extensions to [RFC7285] and [RFC8189] to support flow-based cost queries. This document uses the notation rules specified in Section 8.2 of [RFC7285] and also the notation rule for optional fields in Section 4 of [RFC8189]. 6.1. Filtered Cost Map Extension This document extends the Filtered Cost Map as defined in Section 11.3.2 of [RFC7285] and Section 4.1 of [RFC8189], by adding a new capability and input parameters. The media type, HTTP method, and uses specifications (described in Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively) are unchanged. The response is the same as defined in Section 4.1.3 of [RFC8189]. 6.1.1. Capabilities The Filtered Cost Map capabilities are extended with a new member: o flow-based-filter The capability flow-based-filter indicates whether this resource supports flow-based cost queries. The FilteredCostMapCapabilities object in Section 4.1.1 of [RFC8189] 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;] } FilteredCostMapCapabilities; Zhang, et al. Expires September 6, 2018 [Page 9] Internet-Draft Flow Cost Service March 2018 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 [RFC8189]. flow-based-filter: If true, an ALTO Server allows a field pid-flows to be included in the requests. If not present, this field MUST be interpreted as if it is false. 6.1.2. Accept Input Parameters The ReqFilteredCostMap object in Section 4.1.2 of [RFC8189] is extended as follows: object { [CostType cost-type;] [CostType multi-cost-types<1..*>;] [CostType testable-cost-types<1..*>;] [JSONString constraints<0..*>;] [JSONString or-constraints<1..*><1..*>;] [PIDFilter pids;] [PIDFilter pid-flows<1..*>;] } ReqFilteredCostMap; cost-type, multi-cost-types, testable-cost-types, constraints, or- constraints: As defined in Section 4.1.2 of [RFC8189]. pids: As defined in Section 11.3.2.3 of [RFC7285]. pid-flows: Defined as a list of PIDFilter objects. The ALTO server MUST interpret PID pairs appearing in multiple PIDFilter objects as if they appeared only once. An ALTO client MUST include either pids or pid-flows in a query but MUST NOT include both at the same time. 6.2. Endpoint Cost Service Extension This document extends the Endpoint Cost Service as defined in Section 11.5.1 of [RFC7285] and Section 4.2 of [RFC8189], by adding a new capability and input parameters. The media type, HTTP method, and uses specifications (described in Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) are unchanged. The response is the same as defined in Section 4.2.3 of [RFC8189]. Zhang, et al. Expires September 6, 2018 [Page 10] Internet-Draft Flow Cost Service March 2018 6.2.1. Capabilities The extension to EndpointCostCapabilities includes two new members: o address-types o flow-based-filter Only if the capability "flow-based-filter" is present and its value is "true", the ALTO server supports the flow-based extension for this endpoint cost service. The capability "address-types" indicates which endpoint address types are supported by this resource, it MUST NOT be included if "flow-based-filter" is absent or the value is false. object { [JSONString address-types<0..*>;] [JSONBool flow-based-filter;] } EndpointCostCapabilities : FilteredCostMapCapabilities; flow-based-filter: If true, an ALTO Server MUST accept field "endpoint-flows" in the requests. If not present, this field MUST be interpreted as if it is specified false. address-types: Defines a list of AddressType identifiers encoded as a JSONArray of JSONString. All AddressType identifiers MUST be registered in the "ALTO Address Type Registry" (see Section 14.4 of [RFC7285]). An ALTO server SHOULD NOT claim "ipv4" and "ipv6" in this field explicitly, because they are supported by default. If not present, this field MUST be interpreted as if it is an empty array, i.e., the ALTO server only supports the default "ipv4" and "ipv6" address types. 6.2.2. Accept Input Parameters The ReqEndpointCostMap object in Section 4.2.2 of [RFC8189] is extended as follows: object { [CostType cost-type;] [CostType multi-cost-types<1..*>;] [CostType testable-cost-types<1..*>;] [JSONString constraints<0..*>;] [JSONString or-constraints<1..*><1..*>;] [EndpointFilter endpoints;] [EndpointFilter endpoint-flows<1..*>;] } ReqEndpointCostMap; Zhang, et al. Expires September 6, 2018 [Page 11] Internet-Draft Flow Cost Service March 2018 cost-type, multi-cost-types, testable-cost-types, constraints, or- constraints: As defined in Section 4.1.2 of [RFC8189]. endpoints: As defined in Section 11.5.1.3 of [RFC7285]. endpoint-flows: Defined as a list of EndpointFilter objects. The ALTO server MUST interpret endpoint pairs appearing in multiple EndpointFilter objects as if they appeared only once. If the AddressType of the source and destination in the same EndpointFilter do NOT conform the compatibility rule defined in Table 1 of Section 8.1, an ALTO server MUST return an ALTO error response with the error code "E_INVALID_FIELD_VALUE". An ALTO client MUST specify either "endpoints" or "endpoint-flows", but MUST NOT specify both in the same query. 6.3. Examples 6.3.1. Information Resource Directory GET /directory HTTP/1.1 Host: alto.example.com Accept: application/alto-directory+json,application/alto-error+json 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" Zhang, et al. Expires September 6, 2018 [Page 12] Internet-Draft Flow Cost Service March 2018 }, "basic-flow-based-cost-map" : { "uri" : "http://alto.example.com/costmap/multi/filtered", "media-type" : "application/alto-costmap+json", "accepts" : "application/alto-costmapfilter+json", "uses" : [ "my-default-network-map" ], "capabilities" : { "max-cost-types" : 2, "flow-based-filter" : true, "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] } }, "basic-flow-based-endpoint-cost" : { "uri" : "http://alto.example.com/endpointcost/lookup", "media-type" : "application/alto-endpointcost+json", "accepts" : "application/alto-endpointcostparams+json", "capabilities" : { "protocols": ["tcp", "http"], "flow-based-filter" : true, "cost-type-names" : [ "ord-routingcost" , "num-routingcost" ] } }, "flow-cost-map": { "uri" : "http://alto.example.com/flowcost/lookup", "media-type" : "application/alto-flowcost+json", "accepts" : "application/alto-flowcostparams+json", "capabilities" : { "or-required" : [ [ "ethernet:destination" ], [ "ipv4:destination" ] ], "optional" : [ "ethernet:source", "ethernet:destination", "ipv4:source", "ipv4:destination", "tcp:source", "tcp:destination"] } } } } 6.3.2. Flow-based Filtered Cost Map Service Zhang, et al. Expires September 6, 2018 [Page 13] Internet-Draft Flow Cost Service March 2018 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": [ { "srcs": ["PID1"], "dsts": ["PID2", "PID3"] }, { "srcs": ["PID3"], "dsts": ["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 } } } 6.3.3. Flow-based Endpoint Cost Service Example Zhang, et al. Expires September 6, 2018 [Page 14] Internet-Draft Flow Cost Service March 2018 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": [ { "srcs": ["ipv4:192.0.2.2"], "dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] }, { "srcs": ["tcp:203.0.113.45:54321"], "dsts": ["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 } } } 7. Security Considerations As discussed in Section 15.4 of [RFC7285], an ALTO server or a third party who is able to intercept the flow-based cost query messages MAY store and process the obtained information in order to analyze user behaviors and communication patterns. Since flow-based cost queries Zhang, et al. Expires September 6, 2018 [Page 15] Internet-Draft Flow Cost Service March 2018 MAY potentially provide more accurate information, an ALTO client should be cognizant about the trade-off between redundancy and privacy. 8. IANA Considerations This document defines new address types to be registered to an existing ALTO registry, and a new registry for their compatible address types. 8.1. ALTO Address Type Registry This document defines several new address types to be registered to ALTO Address Type Registry, listed in Table 1. +------------+--------------------+-------------+-------------------+ | Identifier | Address Encoding | Prefix | Mapping to/from | | | | Encoding | IPv4/v6 | +------------+--------------------+-------------+-------------------+ | eth | See Section 5.2.1 | None | Mapping to/from | | | | | IPv4 by [RFC0903] | | | | | and [RFC0826]; | | | | | Mapping to/from | | | | | IPv6 by [RFC3122] | | | | | and [RFC4861] | | domain | See Section 5.2.2 | None | Mapping to/from | | | | | IPv4 by [RFC1034] | | domain6 | See Section 5.2.2 | None | Mapping to/from | | | | | IPv6 by [RFC3596] | | tcp | See Section 5.2.3 | None | No mapping | | tcp6 | See Section 5.2.4 | None | No mapping | | upd | See Section 5.2.3 | None | No mapping | | udp6 | See Section 5.2.4 | None | No mapping | +------------+--------------------+-------------+-------------------+ Table 1: ALTO Address Type Registry 8.2. ALTO Address Type Compatibility Registry This document proposes to create a new registry called ALTO Address Type Compatibility Registry, whose purpose is stated in Section 5.3. The compatible address type identifiers of the ones registered in the ALTO Address Type Registry are listed in Table 2. Zhang, et al. Expires September 6, 2018 [Page 16] Internet-Draft Flow Cost Service March 2018 +-------------+-------------------------+ | Identifier | Compatible Identifiers | +-------------+-------------------------+ | eth | ipv4, ipv6 | | domain | eth, ipv4 | | domain6 | eth, ipv6 | | tcp | eth, ipv4, domain | | tcp6 | eth, ipv6, domain6 | | udp | eth, ipv4, domain | | udp6 | eth, ipv6, domain6 | +-------------+-------------------------+ Table 2: ALTO Address Type Compatibility Registry The entry of an address type identifier SHOULD only include the identifiers registered before it. The compatibility between address types are bidirectional. For example, although "eth" does not register "tcp" as its compatible identifier, an ALTO server MUST recognize them as compatible because eth is registered as a compatible identifier of "tcp". Any new ALTO address type identifier registered after this document MUST register their compatible identifiers in this registry simultaneously. 9. Acknowledgment The authors would like to thank Dawn Chen, Haizhou Du, Sabine Randriamasy and Wendy Roome for their fruitful discussions and feedback on this document. Shawn Lin also gave substantial review feedback and suggestions on the protocol design. 10. References 10.1. Normative References [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, . [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, DOI 10.17487/RFC0903, June 1984, . Zhang, et al. Expires September 6, 2018 [Page 17] Internet-Draft Flow Cost Service March 2018 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, DOI 10.17487/RFC2732, December 1999, . [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, DOI 10.17487/RFC3122, June 2001, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . 10.2. Informative References [EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48)", 2012, . [EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique Identifier (EUI-64)", November 2012, . Zhang, et al. Expires September 6, 2018 [Page 18] Internet-Draft Flow Cost Service March 2018 [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, . [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost Application-Layer Traffic Optimization (ALTO)", RFC 8189, DOI 10.17487/RFC8189, October 2017, . Authors' Addresses Jingxuan Jensen Zhang Tongji University 4800 Cao'an Hwy Shanghai 201804 China Email: jingxuan.n.zhang@gmail.com Kai Gao Tsinghua University 30 Shuangqinglu Street Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Zhang, et al. Expires September 6, 2018 [Page 19] Internet-Draft Flow Cost Service March 2018 Junzhuo Austin Wang Tongji University 4800 Cao'an Hwy, Jiading District Shanghai China Email: wangjunzhuo200@gmail.com 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 Zhang, et al. Expires September 6, 2018 [Page 20]