ALTO Working Group X. Shen Internet-Draft J. Zhang Intended status: Standards Track J. Wang Expires: October 23, 2016 Tongji University Q. Xiang Tongji/Yale University April 21, 2016 ALTO Extension: Endpoint Cost Service for Flows draft-wang-alto-ecs-flows-01 Abstract The Endpoint Cost Service (ECS) has limitations to illustrate the network condition and to work with the OpenFlow protocol. This document extends ECS to improve the Application-Layer Traffic Optimization (ALTO) protocol by (1) defining more types of endpoint address such as port number, protocol type, domain and etc; (2) adding flow constraints. 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 October 23, 2016. Copyright Notice Copyright (c) 2016 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 Shen, et al. Expires October 23, 2016 [Page 1] Internet-Draft ECS Flow April 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Changes Since Version -00 . . . . . . . . . . . . . . . . 3 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 6 3.1. Extend Endpoint Abstraction . . . . . . . . . . . . . . . 6 3.2. Strategy for Multi-Path . . . . . . . . . . . . . . . . . 7 3.3. Compatibility with Legacy Clients . . . . . . . . . . . . 8 3.4. Endpoint Cost Resources . . . . . . . . . . . . . . . . . 8 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Path Oblivious Principle . . . . . . . . . . . . . . . . 8 4.2. Full Relationship Principle . . . . . . . . . . . . . . . 9 5. Protocol Extension for Flow-Extended ECS . . . . . . . . . . 9 5.1. Endpoint Cost Service Extensions . . . . . . . . . . . . 9 5.1.1. Accepted Input Parameters . . . . . . . . . . . . . . 9 5.2. ALTO Address Type Registry Extensions . . . . . . . . . . 10 6. Interoperation and Exception Handling . . . . . . . . . . . . 10 6.1. Feedback when Multi-Path Detected . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Information Resource Directory . . . . . . . . . . . . . 11 7.2. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Endpoint Cost Service vs. Flow Cost Service . . . . . . . 14 8.2. The Same Purpose Principle . . . . . . . . . . . . . . . 14 8.3. Integration with Incremental Update . . . . . . . . . . . 14 8.4. Automatic Exploring Fine-Grained Path . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Privacy And Security Considerations . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction ECS is a basic service of the ALTO services defined in [RFC7285]. Based on the simple host model when defining endpoints, ECS defined in [RFC7285] may not work well in an emerging settings such as Software Defined Networking (SDN) based settings, where network routing decisions can be flow based. In this document, we present an extended ECS for such new settings. Shen, et al. Expires October 23, 2016 [Page 2] Internet-Draft ECS Flow April 2016 1.1. Terminology This document uses terms defined as follows: o {1.2.3}: References of this form are to sections in the ALTO protocol specification [RFC7285]. o And other terms defined in {8.2} of [RFC7285]. 1.2. 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]. 1.3. Changes Since Version -00 o Change the format of API for clients' request. This design is more concise and has better compatibility. It does not modify the IRD of ECS. Section 3.1 introduces a new abstraction for Endpoint which defines the ConnectionURI to represent an endpoint. And a specific flow can be determined by a pair of ConnectionURI. o Add some design principles in section 4. o Give two strategies to solve the multi-path problem and handle fine-grained path error in section 6. One option is to introduce feedback mechanism, the other option is to implement exploring. 2. Motivations Below is the acceptable input parameters of ECS in {11.5.1.3} of [RFC7285]. object { CostType cost-type; [JSONString constraints<0..*>;] EndpointFilter endpoints; } ReqEndpointCostMap; object { [TypedEndpointAddr srcs<0..*>;] [TypedEndpointAddr dsts<0..*>;] } EndpointFilter; Hence, the granularity is TypedEndpointAddr, which is defined in {10.4.1} of [RFC7285]. In particular, [RFC7285] defines two address Shen, et al. Expires October 23, 2016 [Page 3] Internet-Draft ECS Flow April 2016 types: ipv4 and ipv6. This, however, may limit the usage of ECS in multiple settings. Below we give some use cases. Use case 1: ECS is not compatible with virtual host technology, a popular on the Internet, which allows different hosts to share the same IP address. For example, a reverse proxy p1 hosts three sites shown in Figure 1. These sites share the same public network address: 202.180.1.11. Suppose the link in the private network from p1 to server s1 is busy, but the link to server s2 is free. It will cost client c1 more to access www.a.com than www.b.com. Suppose c1 wants to know the cost to www.a.com. Because ECS only supports IP addresses, it will query the DNS server to transfer the domain name to IP address. Therefore, c1 can only obtain the cost to p1. As a result, c1 will get the same result to three different domain names because ECS is only capable of measuring the cost between IP addresses. +---------------------------------+ | | | Private +-----------------+ | | Network | s1 | | | +--> www.a.com | | | | | 192.168.1.10 | | | | | | | | | +-----------------+ | | | | +-----------------+ +--------+--------+ | +-----------------+ | | c1 | | p1 | | | s2 | | | Web Browser +------> Reverse Proxy +-+--> www.b.com | | | 60.20.100.11 | | 202.180.1.11 | | | 192.168.1.11 | | | | | 192.168.1.20 | | | | | +-----------------+ +--------+--------+ | +-----------------+ | | | | | | +-----------------+ | | | | s3 | | | +--> www.c.com | | | | 192.168.1.12 | | | | | | | +-----------------+ | | | +---------------------------------+ Figure 1: Using reverse proxy to operate virtual hosts. Use case 2: Shen, et al. Expires October 23, 2016 [Page 4] Internet-Draft ECS Flow April 2016 ECS is not compatible with port-based or protocol-based routing systems. For example, the OpenFlow protocol can forward packets to different destinations by the port in TCP/IP protocols. A simple topology is shown in Figure 2, the link between switch sw1 and switch sw2 has a low speed but a low latency, while sw3 is a high speed but high latency switch. And there are two services running on host h2, SSH and FTP, using port 22 and port 20, respectively. An efficient flow configuration supported by OpenFlow, is to use a low latency link to transfer SSH packets and a high speed route to transfer files. So sw1 and sw2 will exchange the SSH flows with each other to achieve a lower latency and forward FTP flows to sw3 to achieve a higher bandwidth. In this case, the SDN network uses suitable links to transfer different packets, so the cost between IP addresses is protocol or port related. However, ECS cannot use this information to give a precise result. +-----------------+ +-----------------+ | h1 | | h2 | | SSH client | | SSH service: 22 | | FTP client | | FTP service: 20 | | | | | +-------^---------+ +---------^-------+ | | | | +--v---+ +---v--+ | | Low Speed | | | sw 1 <-----------------> sw 2 | | | Low Latency | | +--^---+ +---^--+ | | | | +--v-------------------------v--+ | sw 3 | | High Speed | | High Latency | +-------------------------------+ Figure 2: A simple example of protocol or port based routing. Use case 3: ECS is not compatible with other addresses such as MAC addresses or physical connectors. For example, some protocols such as ARP send packets by MAC addresses. ECS is unable to measure the cost between two NICs without IP addresses. The ALTO, as an information source, Shen, et al. Expires October 23, 2016 [Page 5] Internet-Draft ECS Flow April 2016 cannot compute the cost between two physic ports, either. These knowledge seems useless for the Internet users, but useful for ISPs. 3. Overview Of Approach This section contains the non-normative overview of the ECS extension for flows defined in this document. It assumes that the readers are familiar with the ALTO Protocol ([RFC7285]). 3.1. Extend Endpoint Abstraction The typed endpoint address used by ECS is defined in {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 transform the typed endpoint address to ConnectionURI 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 ConnectionURI may have one of the following form: "protocol:name-or-address:port" "protocol:name-or-address" And this ConnectionURI is defined in [OpenFlow1.5], 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 ConnectionURI, 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 hostname or IP address or domainnname or MAC address of the controller. If the hostname is locally configured, it is recommended that the URI uses the IP address. If the hostname is available via DNS the URI may use either, so long as it is consistent. Shen, et al. Expires October 23, 2016 [Page 6] Internet-Draft ECS Flow April 2016 port: This field is OPTIONAL. It is forbidden when the protocol is layer three or layer two protocol (like IPv4 and IPv6). 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 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"}, "ConnectionURI" : { "srcs": [ "ipv4:192.0.2.2:22" ], "dsts": [ "http:www.a.com:80", "ftp:01-23-45-67-89-AB", "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.2. Strategy for Multi-Path The multi-path problem refers to the case when given a flow-extended ECS request, more than one path are found and the ALTO server does not know to return which path's cost. Two reasons may cause the multi-path problem. First, the input of client is not fine-grained so that there are multiple paths matching a single input pair. Another reason is some requirements from clients like load balancing can make traffic choose one of several optional paths randomly. Section 6.1 gives a strategy for multi-path problem which is by returning a feedback when multi-path problem is detected in server to ask client for more details to select the specific result. Shen, et al. Expires October 23, 2016 [Page 7] Internet-Draft ECS Flow April 2016 3.3. Compatibility with Legacy Clients The extension defined in this document should be compatible with legacy implementations, which means clients and servers are not aware of this extension. A good way to achieve this goal is defining new media types for extended endpoint cost map. Based on the fact that the format of the extended address is similar as that of the original typed endpoint address, it would be a simpler way to implement a parser which can handle both typed endpoint addresses. Therefore, no new media type is defined in this document. Instead, this document extends the specifications of Information Resource Directory (IRD) in the ALTO protocol. Because the legacy ALTO clients MUST ignore unknown fields (see {8.3.7} of [RFC7285]), the legacy implementations will not use the extended typed endpoint address and are not aware of the existence of this extension. 3.4. Endpoint Cost Resources There is no need in this document to extend the endpoint cost service in IRD. So the legacy Endpoint Cost Resources is still useful. For example, an extended endpoint cost resource in IRD is shown below: "endpoint-cost" : { "uri" : "http://alto.example.com/endpointcost/lookup", "media-type" : "application/alto-endpointcost+json", "accepts" : "application/alto-endpointcostparams+json", "capabilities" : { "cost-constraints" : true, "cost-type-names" : [ "num-routing", "num-hop", "ord-routing", "ord-hop" ] } } 4. Design Principles In practice, there are several principles affecting the design of ECS extension. This section will talk about two major principles and why they are important. 4.1. Path Oblivious Principle The interfaces of ECS should not require or produce path related information. Practically, users do not care about the real path where the packets pass when they are sent between source and destination. Users only care about the cost between the endpoint Shen, et al. Expires October 23, 2016 [Page 8] Internet-Draft ECS Flow April 2016 pair. This principle requires the API design not to be related on the path information. Meanwhile, the ALTO server should not reveal the detailed path information to the clients, either. 4.2. Full Relationship Principle ECS MUST provide the costs for the full relationship. It means that the response map of ECS query MUST be the Cartesian Product between source and destination endpoint set. ECS assumes users are always asking for the full relationship. 5. Protocol Extension for Flow-Extended ECS 5.1. Endpoint Cost Service Extensions This document extends the Endpoint Cost Service, as defined in {11.5.1} of [RFC7285], by changing the format of EndpointFilter. The media type ({11.5.1.1} of [RFC7285]), HTTP method ({11.5.1.2} of [RFC7285]) and "uses" specifications ({11.5.1.5} of [RFC7285]) are unchanged. 5.1.1. Accepted Input Parameters The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended as follows: object { CostType cost-type; [JSONString constraints<0..*>;] EndpointFilter endpoints; } ReqEndpointCostMap; object { [ConnextionURI srcs<0..*>;] [ConnectionURI dsts<0..*>;] } EndpointFilter; With fields: cost-type, constraints: : As defined in {11.5.1.3} of [RFC7285]. endpoints: : Change the TypedEnpointAddress to ConnectionURI to get the fine-grained flow. Shen, et al. Expires October 23, 2016 [Page 9] Internet-Draft ECS Flow April 2016 5.2. ALTO Address Type Registry Extensions This document requests registration of the identifiers "mac" and "domainname" as shown in Table 1. +------------+----------+-----------+-------------------------------+ | Identifier | Address | Prefix | Mapping to/from IPv4/v6 | | | Encoding | Encoding | | +------------+----------+-----------+-------------------------------+ | mac | See | No | Mapping from IPv4 by | | | Section | compact | [RFC0826]. Mapping to IPv4 | | | 6.1.3 | encoding | by [RFC0903]. Mapping from | | | | is | IPv6 by [RFC4861]. Mapping | | | | available | to IPv6 by [RFC3122]. | | domainname | See | No | Mapping to/from IPv4 by | | | Section | compact | [RFC1034]. Mapping to/from | | | 6.1.3 | encoding | IPv6 by [RFC3596]. | | | | is | | | | | available | | +------------+----------+-----------+-------------------------------+ Table 1: New ALTO Address Types 6. Interoperation and Exception Handling 6.1. Feedback when Multi-Path Detected There may be several paths got by client's input, and our server did not know which to choose. When multi-Path problem is detected, there are two possible reasons. One is users' input is not fine-grained so that there are multiple paths matching a individual input pair. Another reason is some requirements like load balancing can make traffic choose one of several optional paths randomly. And if it is caused by the second reasons, we return all the results. And for the first reason, we return a special flag to represent the reason why a flow can not be returned the specific result. In flow extended ECS, we return "NR" in cost field to mean there is no specific path found by the ConnectionURI pair, and return "MU" in cost field to mean that there are multiple paths, and client should support more fine-grained information to get a path. The detailed example can be found in [section 7.2] of this document. In the last version of flow extended ECS, we regard the situation of multi-path problem as an error, so when multi-path problem is detected, server return an error to client, and extend some error information in the error response. The problem of the original design is that in that a query from client usually contains several Shen, et al. Expires October 23, 2016 [Page 10] Internet-Draft ECS Flow April 2016 flows, and other flows' result is not returned only due to a single flow's error. 7. Examples 7.1. Information Resource Directory Here is an example of an ALTO server's Information Resource Directory with an Endpoint Cost Service which supports the flow-based ECS extensions. 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-routing" : { "cost-mode" : "numerical", "cost-metric" : "routingcost" }, "num-hopcount" : { "cost-mode" : "numerical", "cost-metric" : "hopcount" }, } }, "resources" : { "my-default-network-map" : { "uri" : "http://alto.example.com/networkmap", "media-type" : "application/alto-networkmap+json" }, "numerical-routing-cost-map" : { "uri" : "http://alto.example.com/costmap/num-routing", "media-types" : [ "application/alto-costmap+json" ], "uses" : [ "my-default-network-map" ], "capabilities" : { "cost-type-names" : [ "num-routing" ] } }, "numerical-hopcount-cost-map" : { "uri" : "http://alto.example.com/costmap/num-hopcount", "media-types" : [ "application/alto-costmap+json" ], Shen, et al. Expires October 23, 2016 [Page 11] Internet-Draft ECS Flow April 2016 "uses" : [ "my-default-network-map" ], "capabilities" : { "cost-type-names" : [ "num-hopcount" ] } }, ......... And other information resources described in RFC7285 ......... "endpoint-multicost-map" : { "uri" : "http://alto.example.com/multi/endpointcost/lookup", "media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ], "uses" : [ "my-default-network-map" ], "capabilities" : { "cost-constraints" : true, "cost-type-names" : [ "num-routingcost", "num-hopcount" ], } } } } 7.2. Endpoint Cost Service This example uses multi-field typed endpoint addresses to query the "routingcost" for selected endpoints. And in the response, the "MU" means there are multiple paths from source to "http:www.a.com", so client should give more fine-grained information, but server did not provide other detail informations like what port client can replenish. And the response "NR" means there is no result, we can not find a path by this pair of ConnectionURI. Shen, et al. Expires October 23, 2016 [Page 12] Internet-Draft ECS Flow April 2016 POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 345 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json, application/alto-error+json { "cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost"}, "multi-field-endpoints" : { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "http:www.a.com", "ftp:01-23-45-67-89-AB", "ipv4:198.51.100.34", "telnet:198.51.100.34:23", "ipv6:fe80::ce3d:82ff:fe34:27e0/64" ] } } HTTP/1.1 200 OK Content-Length: 402 Content-Type: application/alto-endpointcost+json { "meta" : { "cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost" } }, "endpoint-cost-map" : { "ipv4:192.0.2.2": { "http:www.a.com" : "MU", "ftp:01-23-45-67-89-AB" : 1, "ipv4:198.51.100.34" : 2, "telnet:198.51.100.34:23" : "NR", "ipv6:fe80::ce3d:82ff:fe34:27e0/64" : 3 } } } 8. Discussion Shen, et al. Expires October 23, 2016 [Page 13] Internet-Draft ECS Flow April 2016 8.1. Endpoint Cost Service vs. Flow Cost Service There are two strategies on how to extend endpoint cost service for flows. The method used in this document is extending the legacy ECS, and the other way is defining a new service which we can call it Flow Cost Service (FCS). FCS is an isolated service which is unrelated to the ECS, and this service is incompatible with the legacy ECS. It calculates the cost for each specific flow. For better compatibility, this document chooses the first strategy, which is to extend the legacy ECS. 8.2. The Same Purpose Principle This document intents to indicate that another design principle is to ensure the same purpose. ECS SHOULD assume users submit only one objective in a single query. Traffic of every endpoint pairs in this query MUST have the same purpose. And if users want to query multiple objective traffic types, they MAY send multiple individual queries. But some people may think this principle is too strong and unnecessary. People can debate that ECS should be more flexible and be able to allow multiple purposes. A potential advantage of accepting multiple purposes may be less overhead. But it may also increase the complexity of handling queries. 8.3. Integration with Incremental Update The clients may want the result timely and efficiently, so we should make client able to obtain updates to ECS results, other than by periodically re-fetching them. To support this, we adopt the mechanism of sse. ALTO Server defines an Update Stream Services for ECS, Client establishes an HTTP stream to an Update Service, Updates are Server-Sent Events (SSEs), Server decides full replacement vs incremental update,Client can decline incremental updates.for more information, reference [draft-ietf-alto-incr-update-sse-00]. For ECS Flow, however, there are some cases that SSE does not supports well. For example, after updating, the situation of multi- path may occur. Then the client need query again with more fine- grained information. Hence the detail design of incremental update is not confirmed in this document. Shen, et al. Expires October 23, 2016 [Page 14] Internet-Draft ECS Flow April 2016 8.4. Automatic Exploring Fine-Grained Path When the query granularity are not fine-grained enough to get specific result, we want the ALTO server to explore fine-grained path automatically. The server can add more details by itself and explore specific path. And when the client give more details, the server can return the cost immediately. For example, clients may only request by IPAddress, but the server can calculate some costs by IPaddress and some common ports. 9. IANA Considerations This document does not define any new media type or introduce any new IANA consideration. 10. Privacy And Security Considerations This document does not introduce any privacy or security issue not already present in the ALTO protocol. 11. 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, . [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, . [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, DOI 10.17487/RFC3122, June 2001, . Shen, et al. Expires October 23, 2016 [Page 15] Internet-Draft ECS Flow April 2016 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", 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, . [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, . Authors' Addresses Xvdong Shelden Shen Tongji University 4800 Cao'an Road, Jiading District Shanghai China Email: shenxvdong1@gmail.com Jingxuan Jensen Zhang Tongji University 4800 Cao'an Road, Jiading District Shanghai China Email: jingxuan.n.zhang@gmail.com Junzhuo Austin Wang Tongji University 4800 Cao'an Road, Jiading District Shanghai China Email: wangjunzhuo200@gmail.com Shen, et al. Expires October 23, 2016 [Page 16] Internet-Draft ECS Flow April 2016 Qiao Xiang Tongji/Yale University 4800 Cao'an Road, Jiading District Shanghai China Email: xiangq27@gmail.com Shen, et al. Expires October 23, 2016 [Page 17]