[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/