ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications
draft-lee-alto-app-net-info-exchange-03

ALTO Working Group                                            Young Lee
                                                            Dhruv Dhody
                                                                 Qin Wu
Internet Draft                                                   Huawei
Intended status: standard                                Greg Bernstein
                                                      Grotto Networking
                                                          Tae Sang Choi
                                                                   ETRI

                                                       October 17, 2013

        ALTO Extensions to Support Application and Network Resource
           Information Exchange for High Bandwidth Applications

                draft-lee-alto-app-net-info-exchange-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 17, 2014.

Copyright Notice

Lee, et al.             Expires April 17, 2014                 [Page 1]
Internet-Draft Application and Network Information Exchange October 2013

   Copyright (c) 2013 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.

Abstract

This draft proposes ALTO information model and protocol extensions to
support application and network resource information exchange for high
bandwidth applications in partially controlled and controlled
environments as part of the infrastructure to application information
exposure (i2aex) initiative.

Table of Contents

    1. Introduction..................................................3
   2. Problem Statement..............................................5
   3. ALTO Constraints Filtering Extension Model.....................8
      3.1. ALTO Query from Application Stratum to Network Stratum....8
      3.2. ALTO Response from Network Stratum to Application Stratum10
      3.3. Information Model of ALTO Query from Application Stratum to
      Network Stratum...............................................10
      3.4. Information Model of ALTO Response from Network Stratum to
      Application Stratum...........................................10
      3.5. ALTO Protocol Extension for Constraints Filtering Mechanism
      ..............................................................11
      3.6. Multiple Service Class...................................13
         3.6.1. Gold Service........................................13
         3.6.2. Silver Service......................................14
         3.6.3. Bronze Service......................................16
   4. ALTO Protocol Extension for Graph Representation Mechanism....18
   5. Summary and Conclusion........................................18
   6. Security Considerations.......................................18
   7. IANA Considerations...........................................18
   8. References....................................................18
      8.1. Informative References...................................18
   Author's Addresses...............................................19
   Intellectual Property Statement..................................19
   Disclaimer of Validity...........................................20

   Lee et al.     Expires April 17, 2014  [Page 2]
Internet-Draft Application and Network Information Exchange October 2013

1. Introduction

   This draft proposes ALTO information model and protocol extensions
   to support application and network resource information exchange for
   high bandwidth applications in partially controlled and controlled
   environments as part of the infrastructure to application
   information exposure (i2aex) initiative. The Controlled and
   partially controlled ALTO environments referred to here are those
   where general access to a specific ALTO server may be restricted to
   a qualified list of clients.

   This draft is build upon the previously introduced High Bandwidth
   Use Cases [HighBW]. In [HighBW], we have discussed two generic use
   cases that motivate the usefulness of general interfaces for cross
   stratum optimization in the network core. In our first use case,
   network resource usage became significant due to the aggregation of
   many individually unique client demands. In the second use case
   where data centers are sending large amount of data with each other,
   bandwidth usage was already significant enough to warrant the use of
   traffic engineered "express lanes" (e.g., private line service). We
   introduce third use case where inter-CDN providers may want to
   expose controlled network resource usage information so that CDN
   applications (e.g., request routing server) can utilize such
   information when appropriate decisions (e.g., request routing
   redirection) are needed.

   These use cases result in optimization problems that trade off
   computational versus network costs and constraints. Both featured
   use cases show the usefulness of an ALTO interface between the
   application and network strata in optimizing the networked
   applications.

   In particular, this draft introduces: (i) enhanced constraints
   filtering extensions to the ALTO protocol to reduce extraneous
   information transfer and enhance information hiding from the
   network's perspective; (ii) constrained cost graph mechanism
   encoding that enables enhanced application traffic optimization that
   was introduced by [HighBW].

   In controlled and partially controlled environments in which
   operators are willing to share additional network stratum resource
   information such as bandwidth constraints or additional cost types
   of topology (e.g., graph or summary), it can be useful to reduce the

   Lee et al.     Expires April 17, 2014  [Page 3]
Internet-Draft Application and Network Information Exchange October 2013

   amount of information transferred from the ALTO server to the ALTO
   client.

   In considering information exchange between the application stratum
   and the network stratum, especially from the network stratum to the
   application stratum, the degree of information details is one of the
   key concerns from the network providers' standpoint. On the one
   hand, the network information has to be useful to the application;
   on the other hand, the provided network information should hide
   details about the network. In order to achieve these desired goals,
   a simple enhancement to ALTO protocol would help significantly both
   in reducing/filtering the amount of information and in increasing
   the usefulness of the information from network to application.

   Figure 1 shows ALTO Client-Server Architecture for Application-
   Network information Exchange. Figure 1 shows that ALTO Client in the
   application stratum can interface with ALTO Server in the network
   stratum. With this architecture, a simple ALTO query mechanism from
   application (via ALTO client) to network (via ALTO server) can be
   implemented. According to this architecture, ALTO Client is assumed
   to interact with the Application Orchestrator that has the knowledge
   of the end-user (i.e., source) application requirement, Data Center
   locations (i.e., destinations) and their resource information.

                             +--------------+
           Resource Request  | Application  |
                -----------> | Orchestrator |
                             +--------------+
                             |  ALTO Client |
                             +--------------+
                                |       /|\
                   ALTO Query   |        |  ALTO Response
                                |        |
                                |        |
                                |        |
                               \|/       |
                             +--------------+
                             |  ALTO Server |
                             +--------------+
                             |   Network    |
                             | Orchestrator |
                             +--------------+

   Lee et al.     Expires April 17, 2014  [Page 4]
Internet-Draft Application and Network Information Exchange October 2013

     Figure 1 ALTO Client-Server Architecture for Application-Network
                           information Exchange

   The Application Orchestration functions depicted in Figure 1
   interfacing data centers and end-users are out of the scope of this
   document. For simplicity purpose, Figure 1 doesn't depict the
   detailed relationship between ALTO client and server.  In fact, both
   client and server don't need to be in the same administration
   boundary.  It can be inter-operator and one to many relationships.
   For example, in the cases of inter-CDN environment or generic multi-
   domain environment, ALTO client represents a request routing server
   of upstream CDN operator and it interacts with multiple downstream
   CDN operators for their network resource information to make
   efficient decisions for desired quality CDN services.  Interaction
   methods can either iterative or recursive.  That is, ALTO client can
   interact with multiple ALTO servers directly or ALTO client can
   interact with one representative ALTO server and subsequent
   interaction is done by the representative one to rest of ALTO
   servers.

   The organization of this document is as follows. Section 2 discusses
   the ALTO architecture in the context of the application and network
   strata interaction. Section 3 provides ALTO Information model and
   protocol extension to support ALTO Constraints Filtering Mechanism.
   Section 4 provides ALTO information model and the protocol extension
   to support ALTO Constrained Cost Graph Mechanism.

2. Problem Statement

   One critical issue in Application-Network information exchange in
   ALTO is the amount of information exchanged between the application
   and network strata. The information provided by network providers
   can be not so useful to the application stratum unless such
   information is abstracted into an appropriate level the that
   application stratum can understand.

   In partially controlled and controlled environments, network
   providers can furnish appropriately abstracted and pruned
   information to the application stratum with the cooperation of the
   application stratum that can indicate some level of filtering and
   pruning in its query.

   To reduce extraneous information this draft allows for "filtering"
   (or "pruning") of the following information in query/response of the
   ALTO pull model:

   Lee et al.     Expires April 17, 2014  [Page 5]
Internet-Draft Application and Network Information Exchange October 2013

      . Topology Filtering - reduction of the results to only those
         specified set of source(s) and destination(s) instead of the
         entire network cost map. Note that this mechanism is not new
         in the current ALTO protocol. In the context of application-
         network information exchange, this topology filtering can be
         of a tremendous help in reducing the amount of data exchanged
         between application and network.
      . Multiple Service Class: ALTO server may provide multiple class
         of service (Gold, Silver, or Bronze) and allow application to
         request them accordingly.
      . Multiple Cost: Alto server should be able to provide multiple
         cost for a end to end path or abstract links in the graph.
      . Optimization Criteria: The optimization criteria that the ALTO
         server may use. For ex least number of hops, least amount of
         delay (latency), etc.
      . Constraint Filtering on paths or graphs (e.g., bandwidth,
         latency, hop count, packet loss, etc.) - reduction of results
         to only those that meet ALTO client specified cost bounds.

   As discussed in [HighBW], in a controlled environment optimization
   is significantly enhanced by sharing data related to bandwidth
   constraints and additional cost measures [MultiCost], [TE-cost].
   Such information may be considered sensitive to the network provider
   just as application data, e.g., usage, demand, etc., may be
   considered sensitive to an application provider. Section 3 provides
   ALTO information model and protocol extensions to support topology,
   multiple service class, constraints filtering mechanism.

   Multiple Service Class supports gold, silver and bronze services and
   is defined as follow:

     . Gold Service

   The customer (say an Enterprise Private DC) pay Top-Dollor to setup
   network based on the actual demand. The Path (maybe a TE LSP) would
   not be used by any other customer / application giving guarantee of
   service and best QoE to the application.

     . Silver Service

   The customer (say a Gaming) which will pay flat subscription fees
   only. In this case during the setup phase a flat full mesh of
   tunnels are established between the User regions and the Data
   Centers.

   Lee et al.     Expires April 17, 2014  [Page 6]
Internet-Draft Application and Network Information Exchange October 2013

   The Application gaming load balncer would handle the end user by
   allocating him to a particular DC (gaming server). The reserved
   resources during admin setup are allocated to multiple end user
   requests.

     . Bronze Service

   The customer (say a Video service) pays nothing. Best effort
   service, use IP best effort path instead of reserved path. The
   application (global load balancer) could get the network abstract
   topology and would further handle the end user request by allocating
   them to a particular DC or CDN. The ALTO message exchange for these
   multiple class of service are further described in Sec 3.6.

   While it is important to reduce and filter the information amount
   from network to application, for some applications that require
   stringent QoS objectives (e.g., bandwidth and latency), simple
   summary source-destination network resource information (i.e.,
   summary form of topology) may not provide sufficient details to the
   application stratum. For example, suppose that a multiple number of
   large concurrent flows need to be scheduled from application to
   network. In such a case, a summary form of network topology that
   only shows source-destination bandwidth availability may not show
   the bottleneck links over which more than one flow may compete for
   the link bandwidth resource. This problem was indicated by [HighBW].
   The following are the excerpts from [HighBW].

   Consider the network shown in Figure 2, where DC indicates a
   datacenter, ER an end user region (as in the end user aggregation
   use case), N a switching node of some sort, and L a link. The link
   capacities and costs are also shown on the figure as well as a cost
   map between [ER1, ER2] and [DC1, DC2, DC3]. Since the network has a
   tree structure (very unusual but easier to draw in ASCII art), the
   cost map is unique.

   As an illustration, assume that the maximum available capacity
   between any individual end region and a data center is 5 units(i.e.,
   L1=L2=L5=L6=5). However, link L3 (capacity 8 units) represents a
   bottle neck to all the data centers (L3 is on all the paths to DC1,
   DC2, or DC3 from all end regions, ER1 and ER2).

   ALTO Cost Map is shown in the lower right corner of Figure 2. This
   summary cost map does not provide enough details on the bottle
   necks. The lower left corner shows Link Capacity Cost, from which
   the bottle necks can be shown such that multi-flow commodity
   scheduling can be made possible to avoid such bottle necks.

   Lee et al.     Expires April 17, 2014  [Page 7]
Internet-Draft Application and Network Information Exchange October 2013

    ,---.    L1                                  +----+
   ( ER1 )`-.                              L5  .'|DC1 |
    `---'    `-._ ,-.                         /  +----+
                 ( N1)    L3             ,-..'
               .-'`-' `-.__         L4--(N3 )
    ,---.    .'          `-.  ,-..--''   `-'`.   +----+
   ( ER2 ).-'L2              (N2 )         L6 `-.|DC2 |
    `---'                     `-'`-._            +----+
                                     `-.
           Link Capacity Cost            `-._L7
           L1    5                         `-.
           L2    5                            `-._
           L3    8                               `-.
           L4    6           ALTO Cost Map          `-.+----+
           L5    5           DC1  DC2  DC3 _           |DC3 |
           L6    5       ER1  5    5    8              +----+
           L7    10      ER2  6    6    9

               Figure 2. Example network illustrating bottlenecks

   With the current ALTO cost map structure, the least cost path from
   ER1 would be either to DC1 or DC2. However, with the proposed
   capacitated cost map, the connection from ER1 to DC3 could be a
   better choice than the rest depending on the relative cost of
   network resources to data center resources.

   A more general and relatively efficient alternative is to provide
   the requestor with a capacitated and multiply weighted graph that
   approximates and abstracts the capabilities of the network as seen
   by the source and destination location sets. This document provides
   ALTO information model and protocol extensions to support the graph
   model in Section 4.

3. ALTO Constraints Filtering Extension Model

3.1. ALTO Query from Application Stratum to Network Stratum

   In order for the network stratum to provide its resource
   information, the application stratum needs to provide the End Point
   Cost Map to the network stratum. The End Point Cost Map should
   include the following information at a minimum:

   Lee et al.     Expires April 17, 2014  [Page 8]
Internet-Draft Application and Network Information Exchange October 2013

     . End Point Source Address(es) /* these are the respective
        addresses of the nearest PE's to the user/client location */

     . End Point Destination Address(es) /* these are the respective
        addresses of the nearest PE's to a set of the candidate Data
        Center locations that can provide service to the user request.
        */

   Note that how ALTO client derives the End Point Source/Destination
   addresses in terms of the nearest PE's is beyond the scope of this
   document.

     . Service-Class:= {gold, silver, bronze} /*the service class as
        described in this document*/

     . Cost Type:= 'routingcost' as defined by base specification.
        Additional cost (ex. latency, hopcount) are defined in
        [MultiCost] and [TE-cost].

     . Cost Mode :={summary, graph} /* the cost map can be either a
        summary form or a graph form */

          o Cost Mode: summary

             This cost mode is indicated by string 'summary'. This mode
             indicates that the returned costs contain end-to-end
             values which can be used by application stratum for better
             selection of resources.

          o Cost Mode: gragh

             This cost mode is indicated by string 'gragh' in which
             case an abstract topology is returned to the application.

     . Constraints /* a set of constraints that apply to the requested
        path summary or graph for filtering. For instance, constraints
        can be like bandwidth greater than 'x', latency less than 'y',
        hopcount less than 'z', packetloss less than 'a' etc. */

     . Objective-function (or Optimization Criteria): The summary or
        the graph should be computed based on optimizing which
        parameter - IGP cost, latency, residual bandwidth, etc. This is
        for future use.

   Lee et al.     Expires April 17, 2014  [Page 9]
Internet-Draft Application and Network Information Exchange October 2013

3.2. ALTO Response from Network Stratum to Application Stratum

   In response to the ALTO Query from the Application Stratum, the
   Network Stratum needs to provide the filtered Cost Map Data of the
   feasible path found. The Filtered End Cost Map Data should include
   the following information at a minimum:

     . The list of feasible Source-Destination pair and its Cost Type

     . For each feasible S-D pair, indicate the following:

     . Constraints Values /* indicate the actual values of each
        constraint requested */

   Note that in case of Graph, each S-D pair is the source of the
   abstract link and the destination of the abstract link.

3.3. Information Model of ALTO Query from Application Stratum to
   Network Stratum

   Alto query:

   Object{
     TypedEndpointAddr   Src<1...*>; /*atleast one source*/
     TypedEndpointAddr   Dsts<2...*>; /*atleast two destinations*/
   }EndpointList;

   Object{
     ServiceClass      service-class;
     CostMode         cost-mode;
     CostType           cost-type;
     [JSONString        constraints<0...*>; ]
     [JSONString        ObjectiveFunction]
     EndpointList      endpoints;
   }EndpointCostMapReq;

3.4. Information Model of ALTO Response from Network Stratum to
   Application Stratum

   Alto response:

   Object-map{

   Lee et al.     Expires April 17, 2014  [Page 10]
Internet-Draft Application and Network Information Exchange October 2013

       JSONString        costparam;
   } EndpointCostParam ;

   Object-map{
    TypedEndpointAddr -> EndpointCostParam<1...*>;
   } EndpointCosts ;

   Object-map{
    TypedEndpointAddr -> EndpointCosts;
   } EndpointCostMapData ;

   Object{
        ServiceClass              service-class;
        CostMode                  cost-mode;
        CostType                     cost-type;
       [EndpointCostMapData      map;]
   }EndpointCostMapRsp;

   The Alto response consist of map (EndpointCostMapData) which is map
   containing the S-D pairs information. For each destination, its
   parameters (rank, cost etc) is included using EndpointCostParam.

3.5. ALTO Protocol Extension for Constraints Filtering Mechanism

   This section provides the ALTO protocol extensions based on the
   information model discussed in Sections 3.3. and 3.4. The scenario
   provided in this section is that the ALTO client in the Application
   Stratum requests the summary cost map from the network with one
   source and three destinations.

   In this particular example, the ALTO client requests the filtered
   summary of the network path subject to:  bandwidth >= 20, latency <
   10, hop count < 5 and packet loss < 0.03.

   The ALTO server provides the resulted network paths in summary.

   POST /endpointcost/lookup HTTP/1.1
     Host: alto.example.com
     Content-Length: [TODO]

   Lee et al.     Expires April 17, 2014  [Page 11]
Internet-Draft Application and Network Information Exchange October 2013

     Content-Type: application/alto-csoendpointcostparams+json
     Accept: application/alto-csoendpointsummary+json,application/alto-
   error+json
     {
       "service-class" : "silver",
       "cost-mode" : "summary",
       "cost-type" : "routingcost",
       "constraints": ["bw gt 20", "delay lt 10", "hopcount lt 5",
   "pktloss lt 0.03"],
       "endpoints" : {
         "srcs": [ "ipv4:192.0.2.2" ],
         "dsts": [
           "ipv4:192.0.2.89",
           "ipv4:198.51.100.34",
           "ipv4:203.0.113.45"
         ]
       }
     }

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-csoendpointsummary+json
     {
       "meta" : {},
       "data" : {
         "service-class" : "silver",
         "cost-mode" : "summary",
         "cost-type" : "routingcost",
         "map" : {
           "ipv4:192.0.2.2": {
           "ipv4:192.0.2.89"    : [ "delay eq 5",
                            "hopcount eq 8", "pktloss eq 0.01", cost eq
   100" ],
           "ipv4:18.51.100.34"  : [ "delay eq 9",
                            "hopcount eq 10", "pktloss eq 0.02", cost
   eq 120" ],
           "ipv4:203.0.113.45"  : [ "delay eq 40",
                            "hopcount eq 12", "pktloss eq 0.02", cost
   eq 50" ]
           }
         }
       }

   Lee et al.     Expires April 17, 2014  [Page 12]
Internet-Draft Application and Network Information Exchange October 2013

     }
3.6.  Multiple Service Class

3.6.1. Gold Service

   In case of gold service, the application may like to find out the
   ranking of the destinations (DC) from the network point of view. It
   may further set the filtering constraints for bandwidth (bw), delay
   etc.

   Alto Request:
   POST /endpointcost/lookup HTTP/1.1
        Host: alto.example.com
        Content-Length: [TODO]
        Content-Type: application/alto-csoendpointcostparams+json
        Accept: application/alto-
   csoendpointsummary+json,application/alto-
      error+json
        {
          "service-class" : "gold",
          "cost-mode" : "summary",
          "cost-type" : "routingcost",
          "constraints": ["bw gt 20", "delay lt 10",
                         "pktloss lt 0.03", "jitter lt 10", "hopcount
   lt 5" ],
          "endpoints" : {
          "srcs": [ "ipv4:192.0.2.2" ],
            "dsts": [
              "ipv4:192.0.2.89",
              "ipv4:198.51.100.34",
              "ipv4:203.0.113.45"
            ]
          }
     }
   ALTO server would factor in the filtering constraints and provide
   only the ranking information to the application.

   Alto Response:

   HTTP/1.1 200 OK
   Content-Length: [TODO]
   Content-Type: application/alto-csoendpointsummary+json

   Lee et al.     Expires April 17, 2014  [Page 13]
Internet-Draft Application and Network Information Exchange October 2013

     {
       "meta" : {},
       "data" : {
         "service-class" : "gold",
         "cost-mode" : "summary",
         "cost-type" : "routingcost",
         "map" : {
           "ipv4:192.0.2.2": {
           "ipv4:192.0.2.89"    : [ "rank eq 3" ],
           "ipv4:198.51.100.34"  : [ "rank eq 1" ],
           "ipv4:203.0.113.45"  : [ "rank eq 2" ]
           }
         }
       }
     }

3.6.2. Silver Service

   In case of the silver service, application may want to setup a flat
   full mesh of connection between the source(s) and destination(s)
   meeting some basic constraints.

   Alto Request:

   POST /endpointcost/lookup HTTP/1.1

     Host: alto.example.com
     Content-Length: [TODO]
     Content-Type: application/alto-csoendpointcostparams+json
     Accept: application/alto-csoendpointsummary+json,application/alto-
   error+json
     {
       "service-class" : "silver",
       "cost-mode" : "summary",
       "cost-type" : "routingcost",
       "constraints": ["bw gt 20", "delay lt 10",
                         "pktloss lt 0.03", "jitter lt 10", "hopcount
   lt 5" ],

       "endpoints" : {
         "srcs": [
           "ipv4:192.0.2.2",
           "ipv4:192.0.2.10"

   Lee et al.     Expires April 17, 2014  [Page 14]
Internet-Draft Application and Network Information Exchange October 2013

         ],
         "dsts": [
           "ipv4:192.0.2.89",
           "ipv4:198.51.100.34",
           "ipv4:203.0.113.45"
         ]
       }
     }
   ALTO server would factor in the filtering constraints and provide
   the end to end cost parameters to the application.

   Alto Response:
    HTTP/1.1 200 OK
      Content-Length: [TODO]
      Content-Type: application/alto-csoendpointsummary+json
        {
          "meta" : {},
          "data" : {
            "service-class" : "silver",
            "cost-mode" : "summary",
            "cost-type" : "routingcost",
            "map" : {
              "ipv4:192.0.2.2": {
              "ipv4:192.0.2.89"    : [ "delay eq 5", "jitter eq 5",
                               "pktloss eq 0.01", "hopcount eq 8",
   "cost eq 100" ],
              "ipv4:198.51.100.34"  : [ "delay eq 9", "jitter eq 3",
                               "pktloss eq 0.02", "hopcount eq 10",
   "cost eq 500" ],
              "ipv4:203.0.113.45"  : [ "delay eq 4", "jitter eq 4",
                               "pktloss eq 0.02", "hopcount eq 12",
   "cost eq 200" ]
              }

              "ipv4:192.0.2.10": {
              "ipv4:192.0.2.89"    : [ "delay eq 4", "jitter eq 4",
                               "pktloss eq 0.03", "hopcount eq 6",
   "cost eq 300" ],
              "ipv4:203.0.113.45"  : [ "delay eq 6", "jitter eq 6",

   Lee et al.     Expires April 17, 2014  [Page 15]
Internet-Draft Application and Network Information Exchange October 2013

                               "pktloss eq 0.04", "hopcount eq 8",
   "cost eq 400"]
              }
            }
          }
        }

3.6.3. Bronze Service

   In case of the bronze service, application may rely on the basic IP
   best effort but would like to know the abstract topology that could
   be used by the application to find out bottleneck etc. Note that no
   constraints are passed in this example and graph is requested.

   Alto Request:
    POST /endpointcost/lookup HTTP/1.1
        Host: alto.example.com
        Content-Length: [TODO]
        Content-Type: application/alto-csoendpointcostparams+json
        Accept: application/alto-
   csoendpointsummary+json,application/alto-
      error+json
        {
          "service-class" : "bronze",
          "cost-mode" : "graph",
          "cost-type" : "routingcost",
           "endpoints" : {
            "srcs": [
              "ipv4:192.0.2.2",
              "ipv4:192.0.2.10"         ],
            "dsts": [
              "ipv4:192.0.2.89",
              "ipv4:198.51.100.34",
              "ipv4:203.0.113.45"
            ]
          }
        }
   ALTO server would prepare an abstract network graph based on the
   source(s) and destination(s). The graph may also include some
   internal (maybe abstract) nodes (ex 192.0.2.20 and 192.0.2.30).
   Alto Response:
      HTTP/1.1 200 OK
      Content-Length: [TODO]

   Lee et al.     Expires April 17, 2014  [Page 16]
Internet-Draft Application and Network Information Exchange October 2013

      Content-Type: application/alto-csoendpointsummary+json
        {
          "meta" : {},
          "data" : {
            "service-class" : "bronze",
            "cost-mode" : "graph",
            "cost-type" : "routingcost",
            "map": {
              "ipv4:192.0.2.2": {
              "ipv4:192.0.2.20"    : [ "delay eq 9",  "jitter eq 2",
                               "pktloss eq 0.04", "bw eq 20", "cost eq
   100" ]
              }

              "ipv4:192.0.2.20": {
              "ipv4:192.0.2.89"    : [ "delay eq 5", "jitter eq 2",
                               "pktloss eq 0.02", "bw eq 30", "cost eq
   100" ],
              "ipv4:198.51.100.34"    : [ "delay eq 3", "jitter eq 2",
                               "pktloss eq 0.01", "bw eq 50", "cost eq
   400" ]
              }

              "ipv4:192.0.2.10": {
              "ipv4:192.0.2.30"    : [ "delay eq 4", "jitter eq 2",
                               "pktloss eq 0.01", "bw eq 60", "cost eq
   300" ]
              }

              "ipv4:192.0.2.30": {
              "ipv4:203.0.113.45"    : [ "delay eq 2", "jitter eq 2",
                               "pktloss eq 0.03", "bw eq 10", "cost eq
   200" ]
              }
            }
          }
        }
   Note that the EndpointCostMapData can be used for both the Graph
   representation as well as the end to end path.

   Lee et al.     Expires April 17, 2014  [Page 17]
Internet-Draft Application and Network Information Exchange October 2013

4. ALTO Protocol Extension for Graph Representation Mechanism

   The encoding details for graph representation mechanism are shown in
   Section 3.6.3 where Bronze service is described.

5. Summary and Conclusion

   TBD

6. Security Considerations

   TBD

7. IANA Considerations

   TBD

8. References

8.1. Informative References

   [HighBW] G. Bernstein and Y. Lee, "Use Cases for High Bandwidth
             Query and Control of Core Networks," draft-bernstein-alto-
             large-bandwidth-cases, work in progress.

   [MultiCost] S. Randriamasy, Ed., "Multi-Cost ALTO," draft-
             randriamasy-alto-multi-cost, work in progress.

   [TE-cost] Q. Wu, et. al. "JSON Format Extensions for Traffic
             Engineering (TE) performance metrics in the ALTO
             Information Resource Directory, draft-wu-alto-json-te,
             work in progress.

   Lee et al.     Expires April 17, 2014  [Page 18]
Internet-Draft Application and Network Information Exchange October 2013

Author's Addresses

   Young Lee
   Huawei Technologies
   1700 Alma Drive, Suite 500
   Plano, TX 75075
   USA
   Phone: (972) 509-5599
   Email: leeyoung@huawei.com

   Dhruv Dhody
   Huawei Technologies, India
   Email: dhruv.dhody@huawei.com

   Qin Wu
   Huawei Technologies, China
   Email: bill.wu@huawei.com

   Greg M. Bernstein
   Grotto Networking
   Fremont California, USA
   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com

   Tae-Sang Choi
   ETRI
   161 Gajong-Dong, Yusong-Gu
   Daejon, Republic of Korea
   Phone: (8242) 860-5628
   Email: choits@etri.re.kr

Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or

   Lee et al.     Expires April 17, 2014  [Page 19]
Internet-Draft Application and Network Information Exchange October 2013

   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line
   IPR repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
   HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

   Lee et al.     Expires April 17, 2014  [Page 20]