Internet DRAFT - draft-wang-alto-ecs-flows
draft-wang-alto-ecs-flows
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,
<http://www.rfc-editor.org/info/rfc826>.
[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,
<http://www.rfc-editor.org/info/rfc903>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122,
DOI 10.17487/RFC3122, June 2001,
<http://www.rfc-editor.org/info/rfc3122>.
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,
<http://www.rfc-editor.org/info/rfc3596>.
[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,
<http://www.rfc-editor.org/info/rfc3986>.
[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,
<http://www.rfc-editor.org/info/rfc4861>.
[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,
<http://www.rfc-editor.org/info/rfc7285>.
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]
