Network Working Group                                S. Randriamasy, Ed.
Internet-Draft                                                 N. Schwan
Intended status: Experimental                   Alcatel-Lucent Bell Labs
Expires: May 3, 2012                                    October 31, 2011


                            Multi-Cost ALTO
                  draft-randriamasy-alto-multi-cost-05

Abstract

   IETF is designing a new service called ALTO (Application Layer
   traffic Optimization) that includes a "Network Map Service", an
   "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and
   thus incentives for application clients to connect to ISP preferred
   Endpoints.  These services provide a view of the Network Provider
   (NP) topology to overlay clients.

   The present draft proposes a light way to extend the information
   provided by the current ALTO protocol.  The purpose is to broaden the
   possibilities of the Application Clients in two ways.  Firstly it
   proposes to include information on multiple cost types in a single
   ALTO transaction, providing a better mapping of the Selected
   Endpoints to needs of the growing diversity of Content Networking
   Applications and to the network conditions.  Secondly it proposes new
   cost types, that are an abstraction of time-sensitive network
   information as viewed by the Network Provider.  All this also helps
   producing a more robust choice when multiple Endpoints must be
   selected.

   There are 2 parts in this draft: the first part initiates protocol
   extensions to support requests on multiple Cost Types in one single
   transaction.  These first extensions also integrate the discussions
   within the ALTO Working Group.  The second part proposes use cases
   motivating further definitions of additional CostTypes and Cost
   related attributes and capabilities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

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




Randriamasy & Schwan       Expires May 3, 2012                  [Page 1]


Internet-Draft               Multi-Cost ALTO                October 2011


   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 May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

























Randriamasy & Schwan       Expires May 3, 2012                  [Page 2]


Internet-Draft               Multi-Cost ALTO                October 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Proposed ALTO protocol updates for multi-cost transactions . .  7
     4.1.  Information Resources Directory  . . . . . . . . . . . . .  8
       4.1.1.  Example Multi-Cost specific resources  . . . . . . . .  8
     4.2.  Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Media Type . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.2.  HTTP Method  . . . . . . . . . . . . . . . . . . . . . 10
       4.2.3.  Input Parameters . . . . . . . . . . . . . . . . . . . 10
       4.2.4.  Capabilities . . . . . . . . . . . . . . . . . . . . . 10
       4.2.5.  Response . . . . . . . . . . . . . . . . . . . . . . . 11
       4.2.6.  Example  . . . . . . . . . . . . . . . . . . . . . . . 13
     4.3.  Filtered Multi-Cost  Map . . . . . . . . . . . . . . . . . 13
       4.3.1.  Media Type . . . . . . . . . . . . . . . . . . . . . . 14
       4.3.2.  HTTP Method  . . . . . . . . . . . . . . . . . . . . . 14
       4.3.3.  Input Parameters . . . . . . . . . . . . . . . . . . . 14
       4.3.4.  Capabilities . . . . . . . . . . . . . . . . . . . . . 16
       4.3.5.  Response . . . . . . . . . . . . . . . . . . . . . . . 16
       4.3.6.  Example  . . . . . . . . . . . . . . . . . . . . . . . 16
     4.4.  Endpoint Multi-Cost Service  . . . . . . . . . . . . . . . 17
       4.4.1.  Endpoint Multi-Cost  . . . . . . . . . . . . . . . . . 18
       4.4.2.  Media Type . . . . . . . . . . . . . . . . . . . . . . 18
       4.4.3.  HTTP Method  . . . . . . . . . . . . . . . . . . . . . 18
       4.4.4.  Input Parameters . . . . . . . . . . . . . . . . . . . 18
       4.4.5.  Capabilities . . . . . . . . . . . . . . . . . . . . . 19
       4.4.6.  Response . . . . . . . . . . . . . . . . . . . . . . . 19
       4.4.7.  Example  . . . . . . . . . . . . . . . . . . . . . . . 20
     4.5.  ALTO Status Codes for Multi-Cost ALTO  . . . . . . . . . . 21
   5.  Use cases for further Cost Types and Endpoint Properties . . . 22
     5.1.  Delay Sensitive Overlay Applications . . . . . . . . . . . 22
     5.2.  CDN Surrogate Selection  . . . . . . . . . . . . . . . . . 23
     5.3.  Bulk Data Transfer scheduling  . . . . . . . . . . . . . . 24
   6.  Proposed additional Properties and Costs . . . . . . . . . . . 25
     6.1.  For further extensions: dynamic Costs  . . . . . . . . . . 25
       6.1.1.  Path Occupation Cost and Endpointoccupationcost  . . . 26
       6.1.2.  Dynamic Cost  Attributes . . . . . . . . . . . . . . . 26
         6.1.2.1.  The dynamic Cost Mode  . . . . . . . . . . . . . . 26
       6.1.3.  Proposed  dynamic Cost Scope capability  . . . . . . . 27
         6.1.3.1.  Example of time scope for a dynamic cost . . . . . 27
       6.1.4.  Example of dynamic information resources in the IRD  . 27
         6.1.4.1.  Example of response with a "dynamic" cost  . . . . 28
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
     7.1.  Information for IANA on proposed Cost Types  . . . . . . . 30
     7.2.  Information for IANA on proposed Endpoint Propeeries . . . 30
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30



Randriamasy & Schwan       Expires May 3, 2012                  [Page 3]


Internet-Draft               Multi-Cost ALTO                October 2011


   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31















































Randriamasy & Schwan       Expires May 3, 2012                  [Page 4]


Internet-Draft               Multi-Cost ALTO                October 2011


1.  Introduction

   IETF is designing a new service called ALTO that provides guidance to
   P2P applications, which have to select one or several hosts from a
   set of candidates that are able to provide a desired resource.  This
   guidance shall be based on parameters that affect performance and
   efficiency of the data transmission between the hosts, e.g., the
   topological distance.  The ultimate goal is to improve Quality of
   Experience (QoE) in the application while reducing resource
   consumption in the underlying network infrastructure.  The ALTO
   protocol conveys the Internet View from the perspective of a Provider
   Network region that spans from a region to one or more Autonomous
   System (AS).  Together with this Network Map, it provides the
   Provider determined Cost Map between locations of the Network Map.
   Last, it provides the Ranking of Endpoints w.r.t. their routing cost.

   The term Network Provider in this document includes both ISPs, who
   provide means to transport the data and Content Delivery Network
   (CDN) operators who care for the dissemination, persistent storage
   and possibly identification of the best/closest content copy.

   The last ALTO protocol draft see [ID-alto-protocol], gives the
   possibility to query multiple Endpoint properties at once.  On the
   other hand, the Endpoint Cost service in its input specification
   allows only one Cost Type and Cost mode per request.  The ALTO
   requirements draft, see [ID-ALTO-Requirements7] states in REQ.
   ARv05-14: "The ALTO client protocol MUST support the usage of several
   different rating criteria types".  In the current protocol draft,
   there is no specified way to get values for several Cost Types
   simultaneously.  Currently, the costs are provided in a scalar form,
   one by one.  So that an ALTO Client wanting information for several
   Cost Types must request and receive a response as many times as
   desired Cost Types.

   Getting all costs in one single query/response transaction saves time
   and ALTO traffic load, thus ressources, thus energy.  Besides, vector
   costs provide a robust and natural input to multi-variate path
   computation as well as robust multi-variate selection multiple
   Endpoints.  Other savings in resources can be obtained by gathering
   multiple Cost Types in the Cost map and Filtered Cost Map services.
   Indeed, one Cost Map reporting on N Cost Types is less bulky than N
   Cost Maps containing one Cost Type each.  This is valuable for both
   the storage of these maps and their transfer.  Last, as it is most
   likely that nowadays applications need information on several cost
   types, having them gathered in one map will save time.

   The ALTO Problem Statement, see [RFC5693] and the ALTO requirements
   draft, see [RFC5693] stress that: "information that can change very



Randriamasy & Schwan       Expires May 3, 2012                  [Page 5]


Internet-Draft               Multi-Cost ALTO                October 2011


   rapidly, such as transport-layer congestion, is out of scope for an
   ALTO service.  Such information is better suited to be transferred
   through an in-band technique at the transport layer instead", as
   "ALTO is not an admission control system "and does not necessarily
   know about the instant load of endpoints and links.  However, non-
   real time abstraction of performance oriented information is useful
   for a reliable choice of candidate endpoints.  In addition, given the
   QoE requirements of nowadays and future Internet applications, more
   and more NPs compute and store such information to optimize their
   traffic.  Besides specific ALTO servers can be specified for small
   networks including mobile core networks, which have a smaller scale
   and can afford and take advantage of using small time-scale network
   information.  Adding QoE-enabling metrics to the Network Provider
   established routing cost could meet the interests of both the end
   users and the Providers.


2.  Scope

   This draft generalizes the case of a P2P client to include the case
   of a CDN client, a GRID application client and any Client having the
   choice in several connection points for data or resource exchange.
   To do so, it uses the term "Application Client" (AC).

   This draft focuses on the use case where the ALTO client is embedded
   in the Application Client or in some Application Endpoint tracker in
   the network, such as a P2P tracker, a CDN location tracker or a cloud
   computing orchestration system implemented in a logically centralized
   management system.

   It is assumed that Applications likely to use the ALTO service have a
   choice in connection endpoints as it is the case for most of them.
   The ALTO service is managed by the Network Provider and reflects its
   preferences for the choice of endpoints.  The NP defines in
   particular the network map, the routing cost among Network Locations,
   and which ALTO services are available at a given ALTO server.


3.  Terminology

   Endpoint (EP): can be a Peer, a CDN storage location, a Party in a
   resource sharing swarm such as a computation Grid or an online multi-
   party game.

   Endpoint Discovery (EP Discovery) : this term covers the different
   types of processes used to discover different types of endpoints.

   Network Service Provider (NSP): includes both ISPs, who provide means



Randriamasy & Schwan       Expires May 3, 2012                  [Page 6]


Internet-Draft               Multi-Cost ALTO                October 2011


   to transport the data and Content Delivery Network (CDN) who care for
   the dissemination, persistent storage and possibly identification of
   the best/closest content copy.

   ALTO transaction: a request/response exchange between an ALTO Client
   and an ALTO Server.

   Application Client (AC): this term generalizes the case of a P2P
   client to include the case of a CDN client and of any Client having
   the choice in several connection points for data or resource
   exchange.


4.  Proposed ALTO protocol updates for multi-cost transactions

   This section proposes updates of the ALTO protocol to support Multi
   Cost ALTO Services or provide additional ALTO information.  It
   integrates discussions on the ALTO mailing list.

   If an ALTO client desires several Cost Types, instead of placing as
   many requests as costs, it may request and receive all the desired
   cost types in one single transaction.

   The ALTO server then, provided it supports the requested Cost Types,
   and provided it supports multi-cost ALTO transactions, sends one
   single response where for each {source, destination} pair, the cost
   values are arranged in a vector, where each component corresponds to
   a specified Cost Type.  The correspondence between the components and
   the cost types MUST be indicated either in the ALTO response or
   available via the resource directory.

   The following ALTO services get corresponding services with Multi-
   Cost extensions:

   o  Information Resources Directory: extended with multi-cost related
      URIs and associated capabilities.

   o  Cost Map Service: extended with the Multi-Cost Map Service,

   o  Cost Map Filtering Service: extended with the Multi-Cost Map
      Filtering Service,

   o  Endpoint Cost Lookup Service: extended with the Endpoint Multi-
      Cost Lookup Service.







Randriamasy & Schwan       Expires May 3, 2012                  [Page 7]


Internet-Draft               Multi-Cost ALTO                October 2011


4.1.  Information Resources Directory

   When the ALTO server supports the provision of information on
   multiple costs in a single transactions, the Information Resources
   will list the corresponding resources.  The media type and encoding
   specificarions remain the same as in the current ALTO protocol.

4.1.1.  Example Multi-Cost specific resources

   The following is an example Information Resource Directory returned
   by an ALTO Server and containing Multi-Cost specific services: the
   Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint
   Multi-Cost Service.  It is assumed that the IRD contains usual ALTO
   Services as described in the example IRD of the current ALTO
   protocol.  In this example, the ALTO Server provides additional
   Multi-Cost Services in a specific folder of "alto.example.com" called
   "multi".  This folder contains the Multi-Cost Maps, Filtered Multi-
   Cost Maps as well as the Endpoint Multi-Cost Service.

































Randriamasy & Schwan       Expires May 3, 2012                  [Page 8]


Internet-Draft               Multi-Cost ALTO                October 2011


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

   {
     "resources" : [
       {
         .....
         Usual ALTO "single-cost" Services as described in ALTO Protocol
         .....
       }, {
         "uri" : "http://alto.example.com/multi/maps",
         "media-types" : ["application/alto-multicostmap+json"],
         "accepts" : ["application/alto-multicostmapfilter+json"],
         "capabilities" : {
           "cost-constraints" : true,
           "cost-types" : [ "routingcost", "hopcount" ],
           "cost-modes" : [ "numerical", "numerical" ]
         }
       }, {
         "uri" : "http://alto.example.com/multi/endpointmulticost/lookup",
         "media-types" : [ "application/alto-endpointmulticost+json" ],
         "accepts" : [ "application/alto-endpointmulticostparams+json" ],
         "capabilities" : {
           "cost-constraints" : true,
           "cost-types" : [ "routingcost", "hopcount" ],
           "cost-modes" : [ "numerical", "numerical" ]
         }
       }, {
         "uri" : "http://custom.alto.example.com/multi/endpointmulticost/lookup",
         "media-types" : [ "application/alto-endpointmulticost+json" ],
         "accepts" : [ "application/alto-endpointmulticostparams+json" ],
       }
     ]
   }









Randriamasy & Schwan       Expires May 3, 2012                  [Page 9]


Internet-Draft               Multi-Cost ALTO                October 2011


4.2.  Multi-Cost Map Service

   This section introduces a new media-type for the Multi-Cost map.  For
   each source/destination pair of PIDs, it provides the value of the
   different Cost Type supported for the Multi-cost map, in the same
   order as in the list of cost-types specified in the capabilities.

   A Multi-Cost Map MAY be provided by an ALTO Server.

   This resource MUST be provided for at least the 'routingcost' Cost
   Type with the 'numerical' Cost Mode.  It is assumed that an ALTO
   Server supporting multi-cost maps supports the 'numerical' Cost Mode
   for all Cost Types encoded in the 'JSONnumber' type.

   Note that the capabilities specify implicitly the order in which the
   different Cost Type values will be listed in the Cost Map.

   The Cost Type values in the responses are encoded in with a JSONArray
   of cost values for the different required cost types.

   Note also that contrary to the Cost Map service, the returned Multi
   Cost Map is not required to include the required Path Costs for each
   pair of Source and Destination PID known to the ALTO Server.  The
   reason is that for a given source/destination pair, the ALTO Server
   may not have the information on certain Cost Types.  As a
   consequence, contrary to the Cost Map service, the Multi-Cost Map
   service introduces a particular value that unambiguously indicates
   that the information is not available.  This way, the order in which
   the cost values are provided for a source/destination pair is
   unambiguous.

4.2.1.  Media Type

   The media type is "application/alto-multicostmap+json".

4.2.2.  HTTP Method

   This resource is requested using the HTTP GET method.

4.2.3.  Input Parameters

   None.

4.2.4.  Capabilities

   This resource may be defined for multiple Cost Types and Cost Modes.
   The capabilities of an ALTO Server URI providing this resource are
   defined by a JSON Object of type MultiCostMapCapability:



Randriamasy & Schwan       Expires May 3, 2012                 [Page 10]


Internet-Draft               Multi-Cost ALTO                October 2011


   object {
        CostType cost-types<1..*>;
        CostMode cost-modes<0..*>;
      } MultiCostMapCapability;

   with members

   cost-types  The Cost Types ( Section 5.1.1) supported by the
         corresponding URI. This member MUST at least include the
         type 'routingcost'. The order in which the Cost Type values
         for a source/destination pair will be listed in the Multi-Cost
         Map provided to an ALTO Client MUST be the order in which these
         Cost Types are listed in this member.

   cost-modes  The Cost Mode ( Section 5.1.2) supported for each of
         the supported Cost Types listed in the "cost-types".
         For Cost types encoded with the 'JSONnumber' type, the
         Cost Mode MUST be numerical. It will be interpreted as such
         if this member is not present.


   An ALTO Server MUST support all of the Cost Types listed here for
   each of the listed Cost Modes.  Note that an ALTO Server may provide
   multiple Cost Map Information Resources, each with different
   capabilities.

   An ALTO Server supporting the Multi-Cost Map service, MUST support
   the Cost mode 'numerical' for all supported Cost Types encoded with
   the 'JSONnumber' type.  It also MUST list the Cost Type values
   associated to a source/destination pair in the same order as in the
   "cost-types" member of the capabilities specified the Multi-Cost Map
   resource.

4.2.5.  Response

   The returned InfoResourceEntity object has "data" member of type
   InfoResourceMultiCostMap:














Randriamasy & Schwan       Expires May 3, 2012                 [Page 11]


Internet-Draft               Multi-Cost ALTO                October 2011


object DstMultiCosts {
     JSONArray [PIDName];
     ...
   };

   object {
     DstMultiCosts [PIDName]<0..*>;
     ...
   } MultiCostMapData;

   object {
     CostType    cost-type<1..*>;
     CostMode    cost-mode<1..*>;
     JSONString  map-vtag;
     MultiCostMapData map;
   } InfoResourceMultiCostMap;

with members:

   cost-mode  Cost Mode (Section 5.1.2) used in the Cost Map where each
        member of the cost-mode list is the Cost Mode provided for the
        Cost Type at the same place in the list.

   cost-type  Cost Type (Section 5.1.1) used in the Multi Cost Map.

   map-vtag  The Version Tag (Section 5.3) of the Network Map used to
       generate the Cost Map.

   map  The Multi Cost Map data itself.

   MultiCostMapData    is a JSON object with each member representing a single
       Source PID; the name for a member is the PIDName string identifying
       the corresponding Source PID.  For each Source PID, a DstMultiCosts
       object denotes the associated multiple costs to a set of destination
       PIDs (Section 5.2); the name for each member in the object is the PIDName
       string identifying the corresponding Destination PID. DstMultiCosts are
       listed in the same order as in the 'cost-type' array.


   The returned Cost Map MUST include the required Path Costs for each
   pair of Source and Destination PID for which this information is
   available.

   The members cost-mode and cost-type MUST be arrays with the same
   number of elements.

   Note also that the Multi-Cost Map service needs a particular value
   that unambiguously indicates that the information is not available.



Randriamasy & Schwan       Expires May 3, 2012                 [Page 12]


Internet-Draft               Multi-Cost ALTO                October 2011


   As an example this value is referred here to as NAv for "Not
   available".  Note that the type of NAv still needs to be specified:
   preferably a numerical value for numerical costs that unambiguously
   means: "not available" and can distiguished from "infinite" or
   "invalid something" or any "pathological" value.

4.2.6.  Example

   This example illustrates a 'static' multi-cost' ALTO trasaction,
   where the utilized cost-types all have 'static' values.  We assume
   here that the Cost Types available at the ALTO Server are
   "routingcost" and "hopcount" and the 'numerical' mode is available
   for both of them.  The "routingcost" may be based on monetary
   considerations where as the "hopcount" is used to account on the path
   delay.

GET /multicostmap/num HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-multicostmap+json,application/alto-error+json

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

   {
     "meta" : {},
     "data" : {
       "cost-mode" : ["numerical", "numerical"]
       "cost-type" : ["routingcost", "hopcount"]
       "map-vtag"  : "1266506139",
       "map" : {
         "PID1": { "PID1": [1,6],  "PID2": [5,23],  "PID3": [10,5] },
         "PID2": { "PID1": [5,5],  "PID2": [1,11],  "PID3": [15,9] },
         "PID3": { "PID1": [20,12], "PID2": [15,1], "PID3": [1,18]  }
       }
     }
   }


4.3.  Filtered Multi-Cost  Map

   A Multi-Cost Map may reach a huge volume and also, an Application
   Client assisted by the ALTO Client does not necessarily need
   information on all the Cost Types for all the source/destination
   pairs of PIDs.

   Therefore, applications may more likely use Cost Map information
   filtered w.r.t. the Cost types as well as the source/destination



Randriamasy & Schwan       Expires May 3, 2012                 [Page 13]


Internet-Draft               Multi-Cost ALTO                October 2011


   pairs of PIDs.  This section specifies filtered Multi-Cost Maps.

   A Filtered Cost Map is a Cost Map Information Resource (Section
   7.7.2.2) for which an ALTO Client may supply additional parameters
   limiting the scope of the resulting Cost Map. A Filtered Cost Map MAY
   be provided by an ALTO Server.

4.3.1.  Media Type

   The media type is "application/alto-multicostmap+json", see Section
   4.2.1 of this draft.

4.3.2.  HTTP Method

   This resource is requested using the HTTP POST method

4.3.3.  Input Parameters

   Input parameters are supplied in the entity body of the POST request.
   This document specifies the input parameters with a data format
   indicated by the media type "application/
   alto-multicostmapfilter+json", which is a JSON Object of type
   ReqFilteredCostMap, where:




























Randriamasy & Schwan       Expires May 3, 2012                 [Page 14]


Internet-Draft               Multi-Cost ALTO                October 2011


object {
     PIDName srcs<0..*>;
     PIDName dsts<0..*>;
   } PIDFilter;

   object {
     CostType    cost-type<0..*>;
     CostMode    cost-mode<0..*>;
     JSONString constraints<0..*>;   [OPTIONAL]
     PIDFilter  pids;                [OPTIONAL]
   } ReqFilteredMultiCostMap;


   with members:

   cost-type  The Cost Type ( Section 5.1.1) for the returned costs.
      Each listed cost-type MUST be one of the supported Cost Types indicated
      in this resource's capabilities ( Section 7.7.3.2.4).

   cost-mode  The Cost Mode ( Section 5.1.2) for each of the returned cost-types.
      For Cost types encoded with the 'JSONnumber' type, the
      Cost Mode MUST be numerical. It will be interpreted as such
      if this member is not present.

   constraints  Defines a list of additional constraints on which
      elements of the Cost Map are returned.  This parameter MUST NOT be
      specified if this resource's capabilities ( Section 7.7.3.2.4)
      indicate that constraint support is not available.  A constraint
      contains two entities separated by whitespace: (1) an operator
      either 'gt' for greater than or 'lt' for less than (2) a target
      numerical cost.  The numerical cost is a number that MUST be
      defined in the same units as the Cost Type indicated by the cost-
      type parameter.  ALTO Servers SHOULD use at least IEEE 754 double-
      precision floating point [IEEE.754.2008] to store the numerical
      cost, and SHOULD perform internal computations using double-
      precision floating-point arithmetic.  If multiple 'constraint'
      parameters are specified, they are interpreted as being related to
      each other with a logical AND.

   pids  A list of Source PIDs and a list of Destination PIDs for which
      Path Costs are to be returned.  If a list is empty, the ALTO
      Server MUST interpret it as the full set of currently-defined
      PIDs.  The ALTO Server MUST interpret entries appearing in a list
      multiple times as if they appeared only once.  If the "pids"
      member is not present, both lists MUST be interpreted by the ALTO
      Server as containing the full set of currently-defined PIDs.





Randriamasy & Schwan       Expires May 3, 2012                 [Page 15]


Internet-Draft               Multi-Cost ALTO                October 2011


4.3.4.  Capabilities

   The URI providing this resource supports all capabilities documented
   in Section 7.7.2.2.4 (with identical semantics), plus additional
   capabilities.  In particular, the capabilities are defined by a JSON
   object of type FilteredMultiCostMapCapability:

object {
     CostMode cost-modes<0..*>;
     CostType cost-types<0..*>;
     JSONBool cost-constraints;
   } FilteredMultiCostMapCapability;


   with members:

   cost-modes  See Section 4.2.5 of this MC draft

   cost-types  See Section 4.2.5 of this MC draft

   cost-constraints  If true, then the ALTO Server allows cost
      constraints to be included in requests to the corresponding URI.
      If not present, this member MUST be interpreted as if it specified
      false.


4.3.5.  Response

   See Section of this draft for the format.  The returned Cost Map MUST
   NOT contain any source/destination pair that was not indicated
   (implicitly or explicitly) in the input parameters.  If the input
   parameters contain a PID name that is not currently defined by the
   ALTO Server, the ALTO Server MUST behave as if the PID did not appear
   in the input parameters.  If any constraints are specified, Source/
   Destination pairs that do for which the Path Costs do not meet the
   constraints MUST NOT be included in the returned Cost Map. If no
   constraints were specified, then all Path Costs are assumed to meet
   the constraints.

4.3.6.  Example











Randriamasy & Schwan       Expires May 3, 2012                 [Page 16]


Internet-Draft               Multi-Cost ALTO                October 2011


POST multi/multicostmap/filtered HTTP/1.1
   Host: alto.example.com
   Content-Type: application/alto-multicostmapfilter+json
   Accept: application/alto-multicostmap+json,application/alto-error+json

   {
     "cost-mode" : "numerical", "numerical"],
     "cost-type" : "routingcost", "hopcount"],
     "pids" : {
       "srcs" : [ "PID1" ],
       "dsts" : [ "PID1", "PID2", "PID3" ]
     }
   }


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

   {
     "meta" : {},
     "data" : {
       "cost-mode" : ["numerical", "numerical"],
       "cost-type" : ["routingcost", "hopcount"],
       "map-vtag" : "1266506139",
       "map" : {
         "PID1": { "PID1": [1,6],  "PID2": [5,23],  "PID3": [10,5] }
       }
     }
   }


4.4.  Endpoint Multi-Cost Service

   The Endpoint Multi-Cost Service provides information about several
   costs between individual Endpoints.

   This service does not allow lists of Endpoint prefixes (and
   addresses, as a special case) to be ranked (ordered) by an ALTO
   Server, as firstly the costs encoded with the JSONnumber 'type' are
   provided in the numerical Mode and secondly the choice among various
   existing methods to rank Endpoints upon multiple costs (criteria) is
   out of scope of this protocol and in the responsability of the
   Application Client using the ALTO Endpoint Multi-Cost information.

   However common sense lead to warn that a necessary condition for
   methods that rank vectors to be reliable is that the components
   (costs) of the processed vectors be numerical Cost Mode.



Randriamasy & Schwan       Expires May 3, 2012                 [Page 17]


Internet-Draft               Multi-Cost ALTO                October 2011


   This Service introduces a new media type to define the service and
   the input parameters.

4.4.1.  Endpoint Multi-Cost

   The Endpoint Multi-Cost resource provides information about multiple
   costs between individual endpoints.

   This service MAY be provided by an ALTO Server.  If it is provided.
   It is important to note that although this resource allows an ALTO
   Server to reveal costs between individual endpoints, an ALTO Server
   is not required to do so.  A simple alternative would be to compute
   the cost between two endpoints as the cost between the PIDs
   corresponding to the endpoints +++ if this service is available for
   the requested Cost Types +++ .  See Section 12.1 for additional
   details.

4.4.2.  Media Type

   The media type is "application/alto-endpointmulticost+json".

4.4.3.  HTTP Method

   This resource is requested using the HTTP POST method

4.4.4.  Input Parameters

   Input parameters are supplied in the entity body of the POST request.
   This document specifies input parameters with a data format indicated
   by media type "application/alto-endpointmulticostparams+json", which
   is a JSON Object of type ReqEndpointMultiCostMap:

   object {
           TypedEndpointAddr srcs<0..*>; [OPTIONAL]
           TypedEndpointAddr dsts<1..*>;
    } EndpointFilter;

    object{
          CostType cost-type<0..*>;
          CostMode cost-mode<0..*>;
          JSONString constraints; [OPTIONAL]
          EndpointFilter endpoints;
    } ReqEndpointMultiCostMap;


   with members:





Randriamasy & Schwan       Expires May 3, 2012                 [Page 18]


Internet-Draft               Multi-Cost ALTO                October 2011


cost-mode The Cost Mode ( Section 5.1.2) to use for returne costs that
     are encoded with the 'JSONnumber' type.  For Multi-Cost requests
     this Cost Mode MUST be numerical for any Cost Type encoded with
     the 'JSONnumber' type, provided that the Cost Mode 'numerical'
     is available for this Cost Type.  Remember (Section 5.1.2) that
     ALTO Clients SHOULD be cognizant of operations applicable to different
     Cost Modes.

cost-type The Cost Type ( Section 5.1.1) to use for returned costs.
     All the listed the Cost Types MUST be indicated in this
     resource's capabilities ( Section 7.7.5.1.4).

constraints Defined equivalently to the "constraints" input parameter
     of a Filtered Multi Cost Map (see Section 7.7.3.2).

endpoints A list of Source Endpoints and Destination Endpoints for
     which Path Costs are to be returned.  If the list of Source Endpoints
     is empty (or not included), the ALTO Server MUST interpret it as if
     it contained the Endpoint Address corresponding to the client IP
     address from the incoming connection (see Section 10.3 for discussion
     and considerations regarding this mode).  The list of destination
     Endpoints MUST NOT be empty.  The ALTO Server MUST interpret entries
     appearing multiple times in a list as if they appeared only once.


4.4.5.  Capabilities

   See section 4.3.4 of this draft.

4.4.6.  Response

   The returned InfoResourceEntity object has "data" member equal to
   InfoResourceEndpointMultiCostMap, where:


















Randriamasy & Schwan       Expires May 3, 2012                 [Page 19]


Internet-Draft               Multi-Cost ALTO                October 2011


object EndpointDstMultiCosts {
     JSONArray [TypedEndpointAddr];
     ...
   };

   object {
     EndpointDstMultiCosts [TypedEndpointAddr]<0..*>;
     ...
   } EndpointMultiCostMapData;

   object {
     CostMode            cost-mode<0..*>;
     CostType            cost-type<0..*>;
     EndpointMultiCostMapData map;
   } InfoResourceEndpointMultiCostMap;


   InfoResourceEndpointMultiCostMap has members:

   cost-type<0..*>  The Cost Types used in the returned Cost Map.

   cost-mode<0..*>  The Cost Mode for each of the Cost Types used in the returned Cost Map.

   map  The Endpoint Multi-Cost Map data itself.

   EndpointMultiCostMapData is a JSON object with each member representing a
        single Source Endpoint specified in the input parameters; the name
        for a member is the TypedEndpointAddr string identifying the
        corresponding Source Endpoint.  For each Source Endpoint, a
        EndpointDstMultiCosts object denotes the cost vector associated to each
        Destination Endpoint specified in the input parameters; the name for
        each member in the object is the TypedEndpointAddr string identifying
        the corresponding Destination Endpoint.


4.4.7.  Example















Randriamasy & Schwan       Expires May 3, 2012                 [Page 20]


Internet-Draft               Multi-Cost ALTO                October 2011


POST /endpointcost/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: [TODO]
  Content-Type: application/alto-endpointmulticostparams+json
  Accept: application/alto-endpointmulticost+json,application/alto-error+json

  {
    "cost-type" : ["routingcost", "hopcount"],
    "cost-mode" : ["numerical", "numerical"],
    "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-endpointmulticost+json

  {
    "meta" : {},
    "data" : {
      "cost-type" : ["routingcost", "hopcount"],
      "cost-mode" : ["numerical", "numerical"],
      "map" : {
        "ipv4:192.0.2.2": {
          "ipv4:192.0.2.89"    : [1, 7],
          "ipv4:198.51.100.34" : [2, 4],
          "ipv4:203.0.113.45"  : [3, 2]
        }
      }
    }
  }



4.5.  ALTO Status Codes for Multi-Cost ALTO

   If the Multi-cost Service is not supported for either the Cost Map or
   the Endpoint Service, then the ALTO server sends an ALTO status code
   7 corresponding to HTTP status code 501 indicating "Invalid cost
   structure".  The ALTO client may then needs to place as many requests
   as needed Cost Types, and the ALTO server sends as many cost maps or



Randriamasy & Schwan       Expires May 3, 2012                 [Page 21]


Internet-Draft               Multi-Cost ALTO                October 2011


   EP cost as needed.

   To the attribute Cost Mode in S.5.1 should be associated a rule
   stipulating that when multiple cost types are requested, then the
   requested Cost Mode SHOULD be numerical.


5.  Use cases for further Cost Types and Endpoint Properties

   The current ALTO protocol [ID-alto-protocol] specification requests
   the creation of two registries maintained by IANA.  The ALTO Cost
   Type registry ensures that the Cost Types that are represented by an
   ALTO Cost Map are unique identifiers, and it further contains
   references to the semantics of the Cost Type.  The current
   specification registers 'routingcost' as a generic measure for
   routing traffic from a source to a destination.  In a similar way the
   ALTO Endpoint Property Registry ensures uniqueness of ALTO Endpoint
   Property identifiers and provides references to particular semantics
   of the allocated Enpoint Properties.  Currently the 'pid' identifier
   is registered, which serves as an identifier that allows aggregation
   of network endpoints into network regions.  Both registries accept
   new entries after Expert Review [[ID-alto-protocol]].  New entries
   are requested to be conform to the respective syntactical
   requirements, and must include information about the new identifier,
   the intended semantics as well as security considerations.

   The current protocol specification concentrates on the basic use case
   of optimizing routing costs in NSPs networks.  Upcoming use cases
   however will require both, new Cost Types and new Endpoint
   Properties.  The goal of this section is to describe further forward
   looking use case scenarios that are likely to benefit from ALTO, and,
   in future iterations, to convey new Cost Types and Endpoint
   Properties that are likely to be beneficial for ALTO clients in these
   scenarios.

5.1.  Delay Sensitive Overlay Applications

   The ALTO working group has been created to allow P2P applications and
   NSPs a mutual cooperation, in particular because P2P bulk file-
   transfer applications have created a huge amount of intra-domain and
   congestion on low-speed uplink traffic.  By aligning overlay
   topologies according to the 'routingcost' of the underlying network
   both layers are expected to benefit in terms of reduced costs and
   improved Quality-of-Experience.

   However other types of overlay applications might benefit from a
   different set of path metrics.  In particular for real-time sensitive
   applications, such as gaming, interactive video conferencing or



Randriamasy & Schwan       Expires May 3, 2012                 [Page 22]


Internet-Draft               Multi-Cost ALTO                October 2011


   medical services, creating an overlay topology with respect to a
   minimized delay is preferable.  However it is very hard for a NSP to
   give accurate guidance for this kind of realtime information, instead
   probing through end-to-end measurements on the application layer has
   proven to be the superior mechanism.  Still, a NSP might give some
   guidance to the overlay application, for example by providing
   statistically preferable paths with respect to the time of a day.
   Also static information like hopcount can be seen as an indicator for
   the delay that can be expected.  In the following iterations this
   draft will thus analyse which metrics can realistically be provided
   through ALTO to give delay sensitive applications guidance for peer
   selection.

5.2.  CDN Surrogate Selection

   A second use case is motivated through draft
   [draft-jenkins-alto-cdn-use-cases-01].  The request router in today's
   CDNs makes a decision about to which surrogate or cache node a
   content request should be forwarded to.  Typically this decision is
   based on locality aspects, i.e. the surrogate node which is closest
   to the client is preferred by the request router.  An ALTO server
   hereby is one promising option to allow NSPs to give guidance to the
   CDN about which cache node would be preferable according to the view
   of the network by the 'routingcost' Cost Type.  Providing this kind
   of information is in particular important as one trend is to place
   cache nodes deeper into the network (i.e., closer to the end user),
   which results in the need for finer grained information.

   While distance today is the predominant metric used for routing
   decisions, other metrics might allow sophisticated request routing
   strategies.  For example the load a cache node sees in terms of CPU
   utilization, memory usage or bandwidth utilization might influence
   routing decisions for load-balancing reasons.  There exist numerous
   ways of gathering and feeding this kind of information into the
   request routing mechanism.

   Typically, information reporting on the occupation of a cache could
   be based on:

   o  an Endpoint Property called : "EPCapacity" and reflecting the
      nominal capacity of this endpoint.  This capacity could be
      splitted in:

      *  EP Nominal Memory : denoting the nominal storage capacity

      *  EP Nominal Bandwidth: denoting the computation resources of the
         Endpoint.




Randriamasy & Schwan       Expires May 3, 2012                 [Page 23]


Internet-Draft               Multi-Cost ALTO                October 2011


   o  an Endpoint Cost called: "EP occupied Capacity" and reflecting the
      currently available resources wrt their nominal capacity and
      splitted in the same way as for the EP Capacity:

      *  EP Occupied Memory: denoting the remaining storage capacity,

      *  EP Occupied Bandwidth: denoting the remaining computation
         resources.

   As ALTO is likely to become a standardized interface to provide
   network topology information, for simplicity other information that
   is used by a request router could be provided by the ALTO server as
   well.  In the next iterations of this draft we will analyse which of
   these metrics is suitable to be provided as Cost Type or Endpoint
   Property for the use case of CDN Surrogate Selection and propose to
   register them in the respective registries.

5.3.  Bulk Data Transfer scheduling

   Applications like Facebook or YouTube rely on data replication across
   multiple sites for several reasons, such as offloading the core
   network or increasing user experience through short latency.

   As content is generated constantly data also needs to be replicated
   across the various locations of a CDN provider, leading to bulk data
   transfers between datacenters.  Scheduling these data transfers is a
   non-trivial task as the transfer should not infer with the user peak
   demand to avoid degradation of user experience and to decrease
   billing costs for the datacenter operator by leveraging off-peak
   hours for the transfer.  This peak demand typically follows a diurnal
   pattern according to the geographic region of the datacenter.  One
   precondition to schedule transfers however is to have a good
   knowledge about the demand and link utilization patterns between the
   different datacenters and networks.  Provisioning this data gets
   increasingly complex with the number of CDN nodes and in particular
   the number of datacenter operators that are involved.  ALTO can
   provide time sensitive utilization maps through a dedicated service
   to allow CDN operators a mutual scheduling of such data transfers
   across administrative domains, which becomes even more significant
   through the CDNi protocol.

   Another use case that stresses the need for multi-timeframe
   information is the one of private users or user groups having
   limitations in their connectivity either in time or resources or
   both.  These kind of users definitely need to plan their data
   transfers to and from various locations an be sure to optimize for
   example the 'routingcost' jointly with some 'pathoccupationcost' and
   possibly the 'hopcount'.  These users often have very poor means to



Randriamasy & Schwan       Expires May 3, 2012                 [Page 24]


Internet-Draft               Multi-Cost ALTO                October 2011


   have any information on the network that may provide them some
   guidance and the ALTO protocol could greatly help them while
   optimizing traffic on networks that face continuous resources and/or
   connectivity challenges.

   In the next iteration of this draft we plan specify a multi-timeframe
   map service for ALTO to allow the targeted scheduling of data
   transfers between datacenter locations or other types of locations.


6.  Proposed additional Properties and Costs

   This section proposes further extensions on new Costs Types, to be
   discussed in the WG.

6.1.  For further extensions: dynamic Costs

   It is agreed in the ALTO requirements that: "information that can
   change very rapidly, such as transport-layer congestion, is out of
   scope for an ALTO service.  Such information is better suited to be
   transferred through an in-band technique at the transport layer
   instead".  However NP managing ALTO Servers as well as Application
   Client using ALTO information have common interests to use some
   information on time (or space) varying information that is not
   provided in real time, which is neither desirable nor feasible, but
   rather a synthetis of such information.  Such information is made
   available for ALTO Servers in order to reflect how the NP wishes the
   information to be used by the Applicaton Client.

   One example of such information is the path bandwidth.  This can be
   captured in real time by end systems, in terms of transmission rate.
   On the other hand, the NSP can formulate preferences on given paths,
   at given time periods on given time scales.

   One way for the NSP to provide guidance on highly dynamic network
   state information such as delay and load while preserving
   confidentiality and moderating processing load, is to provide them in
   a synthetic or abstract form, for example as a numerical indicator.
   It is important to have the possibility to reflect that the provided
   values are applicable for a given time period, for example busy hours
   or days, and are subject to changes over time.  Also, how the NP has
   evaluated the cost associated to a given network state information is
   out of scope ot the ALTO protocol.

   The usage of a time related cost is more proactive in that it can be
   used like a "time table" to figure out the best time to schedule data
   transfer and also anticipate predictable events including predictable
   flash crowds.  The time-related information is not necessarily



Randriamasy & Schwan       Expires May 3, 2012                 [Page 25]


Internet-Draft               Multi-Cost ALTO                October 2011


   historical and statistic.  This is why the proposed time-sensitive
   Costs should be viewed as synthetic or as abstraction of real
   measurements rather than as statistics.

6.1.1.  Path Occupation Cost and Endpointoccupationcost

   The 'pathoccupationcost' can be used to reflect the NP view on the
   utilized path bandwidth at given time slots of given timeframes.  For
   example, during daytime in the PC time zone, or between hh/mm and
   hh/mm in another time zone.

   A Cost metric called 'endpointoccupationcost' and that accounts for
   the computation resources usage can be provided with the "dynamic"
   mode as well with a similar time scope updated for example with the
   knowledge of the NSP operating the CDN.

   Both of these metrics are encoded with the 'JSONNumber' type.

   Their optimal value is their minimal value.

   They should also be provided in the numerical mode, that is as one
   single value, if requested so by the ALTO Client.  This could be the
   case for an ALTO Server providing values at a short time scale (e.g.
   some minutes), or in the opposite, providing a timeless cost.

6.1.2.  Dynamic Cost  Attributes

   For further extensions, specifications around "dynamic" costs are
   proposed and will be completed in further versions of this draft.

6.1.2.1.  The dynamic Cost Mode

   The "dynamic" mode applies to Costs that are eligible for the
   "numerical" Cost Mode and can also be expressed as such.  In that
   sense, the "dynamic" mode is an extension of the "numerical" mode.
   Example are "pathoccupationcost" and "pathlosscost" that respectively
   report on the occupied bandwidth and packet loss on a path.

   Other Cost Types such as JSONBool could also claim the "dynamic"
   mode, as states may be "true" or "false" depending on given periods.
   To stick to the target usage of Costs which is to be integrated in
   some evaluation process, an alternative could be to assign a
   numerical value to boolean costs and carefully map "true" and "false"
   with values '0' and '1'.







Randriamasy & Schwan       Expires May 3, 2012                 [Page 26]


Internet-Draft               Multi-Cost ALTO                October 2011


6.1.3.  Proposed  dynamic Cost Scope capability

   To ensure that the Application Client uses the NP provided
   information on dynamic Costs in an inambuguous way, a capability
   called Cost Scope is introduced here, to report on the validity of
   the "dynamic" cost values.  This draft focuses on the time related
   scope.  Indeed, one may as well imagine some costs proposed in the
   future that could also be scoped w.r.t. space.

   o  Unit: ranging from "seconds" to "year", expresses the granularity
      of the information,

   o  Size: the scope of the dynamic cost, that is the number of units
      of the dynamic cost sample,

   o  Reference time zone,

   o  Begin: the index of the first unit in the sample,

   o  Next update: the date at which the sample will be re-computed,

   o  Last update: the last re-computation day.

   Attributes 'Last update 'and 'Next update' report on the update
   frequency and age of the information.

6.1.3.1.  Example of time scope for a dynamic cost

   An example is: a metric called 'pathoccupationcost' (POC for short)
   is computed with a granularity of 2 hours, starting a 0h00, for 24
   hours, with reference time GMT.  The goal is to enable applications
   to see which time intervals in a day are the most favorable to
   operate.

6.1.4.  Example of dynamic information resources in the IRD

   The example IRD given in Section 4.1.1 includes an URI called
   "http://custom.alto.example.com/multi/endpointmulticost/lookup", in
   which the ALTO Server provides additional Mutliple Endpoint Costs
   including a Cost called "pathoccupationcost" for which the Cost Mode
   is "dynamic".  This resource is accessible with other costs, via a
   separate subdomain called "custom.alto.example.com".  The Endpoint
   Costs available via this subdomain are the "hopcount", "routingcost"
   and "pathoccupationcost" Cost Types, with the two first ones in the
   "numerical" Cost Mode and "pathoccupationcost" in the "dynamic" cost
   mode.

   An ALTO Client can discover the services available by



Randriamasy & Schwan       Expires May 3, 2012                 [Page 27]


Internet-Draft               Multi-Cost ALTO                October 2011


   "custom.alto.example.com" by successfully performing an OPTIONS
   request to "http://custom.alto.example.com/multi/endpointmulticost".

OPTIONS /multi/endpointmulticost HTTP/1.1
   Host: custom.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

   {
     "resources" : [
      {
         "uri" : "http://custom.alto.example.com/multi/endpointmulticost",
         "media-types" : [ "application/alto-endpointmulticost+json" ],
         "accepts" : [ "application/alto-endpointmulticostparams+json" ],
         "capabilities" : {
           "cost-constraints" : true,
           "cost-modes" : [ "numerical", "numerical", "dynamic" ],
           "cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ],
           "cost-scope":  [ "permanent", "permanent",
                            {"unit": "hour", "size": 24, "begin": 0,
                             "time zone": "GMT",
                             "lastupdate": mm/hh/dd/mm/yyyy,
                             "nextupdate": mm/hh/dd/mm/yyyy}
           ]
         }
       }
     ]
   }


6.1.4.1.  Example of response with a "dynamic" cost

   To be completed














Randriamasy & Schwan       Expires May 3, 2012                 [Page 28]


Internet-Draft               Multi-Cost ALTO                October 2011


POST /endpointcost/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: [TODO]
  Content-Type: application/alto-endpointmulticostparams+json
  Accept: application/alto-endpointmulticost+json,application/alto-error+json

  {
    "cost-type" : ["routingcost", "pathoccupationcost"],
    "cost-mode" : ["numerical", "dynamic"],
    "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-endpointmulticost+json

  {
    "meta" : {},
    "data" : {
      "cost-type" : ["routingcost", "pathoccupationcost"],
      "cost-mode" : ["numerical", "dynamic"],
      "map" : {
        "ipv4:192.0.2.2": {
          "ipv4:192.0.2.89"    : [1, [7, ..., 24 values]],
          "ipv4:198.51.100.34" : [2, [4, ..., 24 values]],
          "ipv4:203.0.113.45"  : [3, [2, ..., 24 values]]
        }
      }
    }
  }




7.  IANA Considerations

   Information for the ALTO Endpoint property registry maintained by the
   IANA and related to the new Endpoints supported by the acting ALTO
   server.  These definitions will be formulated according to the syntax
   defined in Section on "ALTO Endpoint Property Registry" of



Randriamasy & Schwan       Expires May 3, 2012                 [Page 29]


Internet-Draft               Multi-Cost ALTO                October 2011


   [ID-alto-protocol],

   Information for the ALTO Cost Type Registry maintained by the IANA
   and related to the new Cost Types supported by the acting ALTO
   server.  These definitions will be formulated according to the syntax
   defined in Section on "ALTO Cost Type Registry" of
   [ID-alto-protocol],

7.1.  Information for IANA on proposed Cost Types

   When a new ALTO Cost Type is defined, accepted by the ALTO working
   group and requests for IANA registration MUST include the following
   information, detailed in Section 11.2: Identifier, Intended
   Semantics, Security Considerations.

7.2.  Information for IANA on proposed Endpoint Propeeries

   Likewise, an ALTO Endpoint Property Registry could serve the same
   purposes as the ALTO Cost Type registry.  Application to IANA
   registration for Endpoint Properties would follow a similar process.


8.  Acknowledgements

   Thank you to Dave Mac Dysan (Verizon) for fruitful discussions and
   comments on the last draft.

   Sabine Randriamasy is partially supported by the MEDIEVAL project
   (http://www.ict-medieval.eu/), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   248565).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the MEDIEVAL project or the European Commission.

   Nico Schwan is partially supported by the ENVISION project
   (http://www.envision-project.org), a research project supported by
   the European Commission under its 7th Framework Program (contract no.
   248565).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the ENVISION project or the European Commission.


9.  References






Randriamasy & Schwan       Expires May 3, 2012                 [Page 30]


Internet-Draft               Multi-Cost ALTO                October 2011


9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5693]  "Application Layer Traffic Optimization (ALTO) Problem
              Statement", October 2009.

9.2.  Informative References

   [ID-ALTO-Requirements7]
              "draft-ietf-alto-reqs-07.txt", January 2011.

   [ID-alto-protocol]
              , Eds., ""ALTO Protocol" draft-ietf-alto-protocol-09.txt",
              June 2011.

   [draft-jenkins-alto-cdn-use-cases-01]
              ""Use Cases for ALTO within CDNs"
              draft-jenkins-alto-cdn-use-cases-01", June 2011.


Authors' Addresses

   Sabine Randriamasy (editor)
   Alcatel-Lucent Bell Labs
   Route de Villejust
   NOZAY  91460
   FRANCE

   Email: Sabine.Randriamasy@alcatel-lucent.com


   Nico Schwan
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   STUTTGART  70435
   GERMANY

   Email: Nico.Schwan@alcatel-lucent.com











Randriamasy & Schwan       Expires May 3, 2012                 [Page 31]