One document matched: draft-randriamasy-alto-multi-cost-06.txt
Differences from draft-randriamasy-alto-multi-cost-05.txt
Network Working Group S. Randriamasy, Ed.
Internet-Draft N. Schwan
Intended status: Experimental Alcatel-Lucent Bell Labs
Expires: September 13, 2012 March 12, 2012
Multi-Cost ALTO
draft-randriamasy-alto-multi-cost-06
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 in two ways. First, including
information on multiple cost types in a single ALTO transaction
provides a better mapping of the Selected Endpoints to needs of the
growing diversity of Content and Resources Networking Applications
and to the network conditions. Second, one ALTO query and response
exchange on N Cost Types is faster and lighter than N single cost
transactions. All this also helps producing a faster and more robust
choice when multiple Endpoints need to be selected.
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.
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."
Randriamasy & Schwan Expires September 13, 2012 [Page 1]
Internet-Draft Multi-Cost ALTO March 2012
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 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 September 13, 2012 [Page 2]
Internet-Draft Multi-Cost ALTO March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Application scope and terminology . . . . . . . . . . . . . . 6
3. Uses cases for using multiple costs . . . . . . . . . . . . . 7
3.1. Use cases for using additional costs . . . . . . . . . . . 7
3.1.1. Delay Sensitive Overlay Applications . . . . . . . . . 8
3.1.2. Selection of physical servers involved in
virtualized applications . . . . . . . . . . . . . . . 8
3.1.3. CDN Surrogate Selection . . . . . . . . . . . . . . . 9
3.1.4. Some proposed additional properties and costs . . . . 10
3.2. Use cases for multi-cost transactions . . . . . . . . . . 11
3.2.1. Optimized Endpoint Cost Service . . . . . . . . . . . 11
3.2.2. Optimized Filtered Cost maps . . . . . . . . . . . . . 11
3.2.3. Unpredicable Endpoint cost value changes . . . . . . . 12
4. ALTO Protocol updates to support multi-cost transactions . . . 14
4.1. List of ALTO protocol updates required and recommended . . 15
4.2. Updates required in the member format for objects . . . . 16
4.2.1. Format update on cost value from JSONNumber to
JSONArray . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1.1. Updates on object DstCosts . . . . . . . . . . . . 16
4.2.1.2. Updates on object EndpointDstCosts . . . . . . . . 17
4.2.2. Format update on CostMode and CostType . . . . . . . . 17
4.2.2.1. Updates on object ReqFilteredCostMap . . . . . . . 18
4.2.2.2. Updates on object ReqEndpointCostMap . . . . . . . 18
4.2.2.3. Updates on object InfoResourceCostMap . . . . . . 19
4.2.2.4. Updates on object InfoResourceEndpointCostMap . . 20
4.3. Rules required on object member description . . . . . . . 20
4.3.1. Rule on cost value order specification . . . . . . . . 20
4.3.2. Rule on mapping for cost-type and cost-mode arrays . . 20
4.4. Updates recommended in the object structure . . . . . . . 20
4.5. Rule recommended on the cost value mode . . . . . . . . . 21
4.6. Updated format specification for the ALTO Endpoint Cost . 21
4.7. Updated format specification for the ALTO Cost Map . . . . 23
5. "Multi-Cost ALTO" protocol extensions for multi-cost
transacti . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Required ALTO protocol updates . . . . . . . . . . . . . . 25
5.1.1. Rule required on the cost value mode . . . . . . . . . 25
5.2. Information Resources Directory . . . . . . . . . . . . . 26
5.2.1. Example of Multi-Cost specific resources in the IRD . 26
5.3. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 28
5.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 28
5.3.3. Input Parameters . . . . . . . . . . . . . . . . . . . 28
5.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 28
5.3.5. Response . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 31
Randriamasy & Schwan Expires September 13, 2012 [Page 3]
Internet-Draft Multi-Cost ALTO March 2012
5.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 31
5.4.3. Input Parameters . . . . . . . . . . . . . . . . . . . 32
5.4.4. Capabilities +++ MaxCostTypes . . . . . . . . . . . . 34
5.4.5. Response . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 34
5.5. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 35
5.5.1. Endpoint Multi-Cost . . . . . . . . . . . . . . . . . 36
5.5.2. Media Type . . . . . . . . . . . . . . . . . . . . . . 36
5.5.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . 36
5.5.4. Input Parameters . . . . . . . . . . . . . . . . . . . 36
5.5.5. Capabilities . . . . . . . . . . . . . . . . . . . . . 37
5.5.6. Response . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.7. Example . . . . . . . . . . . . . . . . . . . . . . . 38
5.6. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 39
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6.1. Information for IANA on proposed Cost Types . . . . . . . 40
6.2. Information for IANA on proposed Endpoint Propeeries . . . 40
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . . 41
8.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Randriamasy & Schwan Expires September 13, 2012 [Page 4]
Internet-Draft Multi-Cost ALTO March 2012
1. Introduction
IETF is designing a new service called ALTO that provides guidance to
overlay applications, which have to select one or several hosts from
a set of candidates that are able to provide a desired resource.
This guidance is based on parameters that affect performance and
efficiency of the data transmission between the hosts, e.g., the
topological distance. The purpose of ALTO 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.
Current ALTO Costs and their modes provide values that are seen to be
stable over a longer period of time, such as hopcount and
administrative routing cost to reflect ISP routing preferences.
Recently, new use cases have extended the usage scope of ALTO to
Content Delivery Networks, Data centers and applications that need
additonal information to select their Endpoints or handle their PIDs.
Thus a multitude of new Cost Types that better reflect the
requirements of these applications are expected to be specified, in
particular cost values that change more frequently than previously
assumed.
The current ALTO protocol draft [ID-alto-protocol-11] allows to query
multiple Endpoint properties at once but it restricts ALTO Cost Maps
and Enpoint Cost services to only one Cost Type and Cost Mode per
ALTO request and per ALTO response. It assumes that one request/
response transaction is used per Cost Type; in contrast there is is
no way for a client to retrieve several Cost Types simultaneously.
An ALTO Client that wants to retrieve information for several Cost
Types thus needs to request and receive a response as many times as
desired Cost Types.
Getting all costs in one single query/response ALTO transaction is
more efficient in terms of RTT, traffic, as well as information
processing by the ALTO Client and server load. Vector costs provide
a robust and natural input to multi-variate path computation as well
as robust multi-variate selection multiple Endpoints. In particular,
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 transmission. Additionally, for many
emerging applications that need information on several cost types,
having them gathered in one map will save time.
Randriamasy & Schwan Expires September 13, 2012 [Page 5]
Internet-Draft Multi-Cost ALTO March 2012
There are three parts in this draft: the first part exposes use cases
motivating the introduction of new cost types and why multi-cost
transactions are useful; the second part specifies the core ALTO
protocol extensions that are required or recommended to support
requests and responses on multiple Cost Types in one single
transaction. These extensions also integrate the discussions within
the ALTO Working Group; the third part lists the Multi-Cost ALTO
services that can be supported by these extensions.
Note that the second part relies on the previous version of the ALTO
protocol draft, see [ID-alto-protocol]. It partially integrates an
update of the current version issued recently, see
[ID-alto-protocol-11], that proposes a generic encoding of cost
values in the 'JSONValue' data type. The proposed Multi-Cost
specifications will be updated according to the outcome of WG
discussions.
2. Application scope and terminology
This draft generalizes the case of a P2P client to include the case
of a CDN client, a client of an application running on a virtual
server, 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 request router 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 (NP) and reflects
its preferences for the choice of endpoints. The NP defines in
particular the network map, the routing cost among Network Locations,
the cost types used to reflect it, and which ALTO services are
available at a given ALTO server.
The draft uses terms defined as follows:
o Endpoint (EP): can be a Peer, a CDN storage location, a physical
server involved in a virtual server-supported application, a Party
in a resource sharing swarm such as a computation Grid or an
online multi-party game.
Randriamasy & Schwan Expires September 13, 2012 [Page 6]
Internet-Draft Multi-Cost ALTO March 2012
o Endpoint Discovery (EP Discovery) : this term covers the different
types of processes used to discover different types of endpoints.
o Network Service Provider (NSP): includes both ISPs, who provide
means 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.
o ALTO transaction: a request/response exchange between an ALTO
Client and an ALTO Server.
o Application Client (AC): this term generalizes the case of a P2P
client to include the case of a CDN client, a client of an
application running on a virtual server, a GRID application client
and any Client having the choice in several connection points for
data or resource exchange.
3. Uses cases for using multiple costs
The ALTO protocol specification in [ID-alto-protocol-11] focuses 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. Recent ALTO use cases now extend to CDNs, Data
centers and other applications that need additonal information to
select their Endpoints or handle their PIDs. The needed Cost Types
depend on the QoE requirements that are specific to the applications.
Moreover, the cost values that they may use may change more rapidly
than assumed up to now.
The goal of this section is to describe forward looking use case
scenarios that are likely to benefit from ALTO, in order to motivate
the introduction of new Cost Types and Endpoint Properties as well as
the ALTO Multi-Cost extension.
3.1. Use cases for using additional costs
ALTO Cost Types and Endpoint Properties are registered in 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
Randriamasy & Schwan Expires September 13, 2012 [Page 7]
Internet-Draft Multi-Cost ALTO March 2012
into network regions. Both registries accept new entries after
Expert Review. 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. One basic example advocating for multiple cost-type
transactions is an Application Client looking for destination
Endpoints or Source/Destination PID pairs yielding jointly the lowest
'routingcost' and path delay. We hereby assume that 'routingcost'
values report some monetary cost and that the Application Client
chooses to rely on the hop count to reflect the path delay.
3.1.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.
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
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, possibly 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. Thus a cost type that
is able to indicate latency to some extend without the need for end-
to-end measurements between endpoints is likely to be useful.
3.1.2. Selection of physical servers involved in virtualized
applications
Virtualized applications in large Datacenters are supported by
virtualized servers that actually gather resources distributed on
several physical servers. The federation of these resources is often
orchestrated by a centralized entity that needs to select the
physical servers from or to which it will take resources. This
entity can be co-located with an ALTO Client that will request and
get the ALTO information on the network formed by the physical
servers. The physical servers can be assimilated to endpoints with
which the orchestration entity trades application resources or
Randriamasy & Schwan Expires September 13, 2012 [Page 8]
Internet-Draft Multi-Cost ALTO March 2012
content. These resources include computation resources, storage
capacity and path bandwidth between the physical servers.
Here too, the applications that are ran are diverse and may have
different and specific QoE requirements. The Endpoint selection
typically needs to consider both the computational resources at the
Endpoints and the resources e.g. in bandwidth on the transmission
paths to or among Endpoints. Thus the application QoE requirements
drive the Endpoint selection with more or less weight on QoE specific
metrics such as hopcount/delay, bandwidth and other resources, that
are typically combined with the routing cost and need to jointly
integrate the Endpoint and transmission path perspective in the
decision process, which is difficult to do with one single Cost Type.
3.1.3. CDN Surrogate Selection
Another 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. Finally the
provisioning of abstracted network topology information across
administrative boundaries gains importance for cache federations.
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.
For example, information reporting on the occupation level of a cache
could be based on a cost reflecting: its remaining computation
resources, its remaining storage capacity w.r.t its capacity in
storage or 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
Randriamasy & Schwan Expires September 13, 2012 [Page 9]
Internet-Draft Multi-Cost ALTO March 2012
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.
3.1.4. Some proposed additional properties and costs
In addition to CDN caches, Endpoint Properties and Costs can be
useful to report on the occupation of an Endpoint, given that an
Endpoint can as well be a physical server in a datacenter or any
entitie as defined in Section 2 of this draft.
Example new properties and cost on Endpoints include:
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 storage capacity of the
Endpoint.
* EP Nominal Bandwidth: denoting the capacity in computation
resources of the Endpoint.
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.
Likewise, new Cost types are needed to report on the network
resources of the network paths involved in the content
transportation. In particular the utilized network path bandwidth.
A Cost type named 'pathoccupationcost' (POC) can be used to reflect
the NP view on the utilized path bandwidth. Such an ALTO Cost Type
is likely to have values that change frequently. By no means, as
stated in the ALTO requirements, are ALTO Cost types expected to
reflect real-time values, as these gan be gathered by other
mecanisms. A Cost Type such as 'pathoccupationcost' should be rather
used as an abstraction that may be represented e.g. by a single
statistical value or may be derived according to different time
periods or other parameters.
Randriamasy & Schwan Expires September 13, 2012 [Page 10]
Internet-Draft Multi-Cost ALTO March 2012
3.2. Use cases for multi-cost transactions
Given cost-types are suitable for given applications; for example
delay sensitive applications look jointly for low routing cost and
low delay, where as others such as non real time content download
lokks jointly for moderate delay and minimal losses.
The Multi-Cost Services proposed in this draft consist in:
o including several Cost Types in a Cost Map and Endpoint Cost
request,
o providing ALTO responses including the values for several Cost
Types.
The 2 main motivations to use multi-cost ALTO are: optimisation and
coping with unpredictable and/or rapid value changes.
The Multi-cost Endpoint Service and Multi-Cost Map service allow
optimization by saving transportation time, information processing
time and reducing the volume of transported ALTO information. At the
same time, Multi-cost ALTO services can directly provide a more
complete set of cost information.
Moreover, in some cases, when several Cost Types are used to select
Endpoints it is necessary to synchronise the cost value update. In
particular in the presence of unpredictable and/or rapid changes on
at least one of the ALTO cost values.
3.2.1. Optimized Endpoint Cost Service
The Endpoint Cost service provides cost information on both the
application Endpoint resources and the networking resources allowing
access to these endpoints. The Endpoint Cost Service in addition,
may be invoked in "short term" situations, that is for frequent
requests and/or requiring fast responses. For the Endpoint Cost
Service, the volume of requested ALTO information is restricted and
proportional to a set of candidate Endpoints and thereby lower than
the volume of an entire Cost Map. Therefore the ECS invoked for
'nearly-instant' information request is particularly well suited for
multi-cost ALTO transactions, supporting requests on several Cost
type values simultaneously and the provision of these values
simultaneously.
3.2.2. Optimized Filtered Cost maps
The set of cost-types is not deemed to be restricted to 'routingcost'
and ALTO Servers may provide information on a broader set. One thing
Randriamasy & Schwan Expires September 13, 2012 [Page 11]
Internet-Draft Multi-Cost ALTO March 2012
to consider is that the frequency of updates can vary from a cost
type to another one. Additionally the volume of entire cost map with
values of all available cost types, may get rapidly prohibitive for
frequent downloads. Given these considerations the Application
Client may take better advantage when:
o requesting multi-cost maps filtered w.r.t. cost types of
compaptible update frequencies or dates, which is the
responsability of the Application Client,
o requesting multi-cost maps filtered w.r.t. a restricted set of PID
pairs.
3.2.3. Unpredicable Endpoint cost value changes
In some cases, it is necessary to synchronise the cost value update
when several cost types are used to select Endpoints. In particular
in the presence of unpredictable and/or rapid changes on at least one
of the ALTO cost values. The term 'rapid' here means "Typical update
intervals [that] may be several orders of magnitude longer than the
typical network-layer packet round-trip time (RTT)", as described in
[ID-ALTO-Requirements13] up to a couple of minutes.
Of course, querying all Endpoint cost values simultaneously is
allways more time and resources efficient that doing it sequentially,
but the necessity may become critical in such cases.
Figure 1 and Figure 2 show an example of a delay sensitive
application using 'routingcost' and hopcount. At some time T=2, the
route changes and also the hopcount or the 'routingcost' changes.
The 2 examples illustrate the need to get hopcount and routingcost
values at the same type to re-evaluate the EP costs w.r.t. the QoE
needs of the application.
Randriamasy & Schwan Expires September 13, 2012 [Page 12]
Internet-Draft Multi-Cost ALTO March 2012
T = 1 : EP1: routingcost = 40, hopcount = 2
EP2: routingcost = 30, hopcount = 3
EP1 is selected because application is time-sensitive and
hopcount metrics has a higher weight
.-----.
O ---------- O ------------- | EP2 |
/ `-----'
/
/ .-----.
O ------------------------ O ---- | EP1 |
`-----'
T = 2 : EP1: routingcost = 40, hopcount = 3
EP2: routingcost = 30, hopcount = 3
Route to EP1 has changed. Hopcount is now 3.
==> EP2 is selected because routingcost is lower for
the same hopcount value.
.-----.
O ---------- O -------------| EP2 |
/ \ `-----'
/ `-----.
/ `------. .-----.
O ---------- X --------- [O] ---- | EP1 |
`-----'
Figure 1: Endpoint selection using 2 Cost Types with joint request on
updated cost values.
Randriamasy & Schwan Expires September 13, 2012 [Page 13]
Internet-Draft Multi-Cost ALTO March 2012
T = 1 : EP1: routingcost = 30, hopcount = 2
EP2: routingcost = 30, hopcount = 3
==> EP1 is selected because application is time-sensitive and
hopcount metrics has higher weight
.-----.
O ---------- O ------------- | EP2 |
/ `-----'
/
/ .-----.
O ------------------------ O ---- | EP1 |
`-----'
T = 2 : EP1: routingcost = 40, hopcount = 2
EP2: routingcost = 30, hopcount = 3
Routingcost to EP1 has increased. Hopcount is the same.
==> Delay sensitive applications willing to minimize hopcount
remain with EP1 while other applications may remain
with EP2, that now has a lower routingcost.
.-----.
O ---------- O -------------| EP2 |
/ `-----'
/
/ .-----.
O ------------------------ O ---- | EP1 |
`-----'
Figure 2: Endpoint selection using 2 Cost Types with joint request on
updated cost values and for delay sensitive applications.
4. ALTO Protocol updates to support multi-cost transactions
To allow running Multi-Cost ALTO Services some minor changes in the
core protocol are needed. Instead of adding a set of multi-cost
specific media-types, the main updates consist into changing the JSON
type of the value taken by a few members of the objects describing
the information resources.
As written in the introduction, this section relies on the previous
version of the ALTO protocol draft, see [ID-alto-protocol]. It
partially integrates an update of the current version issued
recently, see [ID-alto-protocol-11], that proposes a generic encoding
of cost values in the 'JSONValue' data type. The proposed Multi-Cost
specifications will be updated according to the outcome of WG
discussions.
Randriamasy & Schwan Expires September 13, 2012 [Page 14]
Internet-Draft Multi-Cost ALTO March 2012
This section lists and details the proposed changes according to the
previous ALTO protocol draft, [ID-alto-protocol] .
If members 'cost-type' and 'cost-mode' of objects
InfoResourceCostMap, InfoResourceEndpointCostMap, ReqFilteredCostMap,
ReqEndpointCostMap remain specified as single values in the base ALTO
ptotocol, then Multi-Cost specific media types need to be used
similarly to those specified in the previous version of this draft,
see [draft-randriamasy-alto-multi-cost-05].
4.1. List of ALTO protocol updates required and recommended
The following updates to the current ALTO protocol, see
[ID-alto-protocol], are required or recommended to support multi-cost
ALTO transactions. The new resulting JSON formats are specified in
the next sections.
o Updates required in the format of objects member(s):
* Objects DstCosts (to destination PIDs) and EndpointDstCosts (to
destination Endpoints): JSON type of cost value member evolves
from JSONNumber to JSONArray.
* Objects InfoResourceCostMap, ReqFilteredCostMap,
ReqEndpointCostMap, InfoResourceEndpointCostMap: members 'cost-
mode' and 'cost-type' have now an array of values rather than a
single value.
o Updates recommended in the object structure:
* Objects CostMapCapability and FilteredCostMapCapability: new
member giving the maximum number of Cost Types in a response.
o Rules required on object member description:
* Order in which the multiple cost values are provided in the
responses,
* Number of values in member 'cost-types' of objects
InfoResourceCostMap, InfoResourceEndpointCostMap,
ReqFilteredCostMap, ReqEndpointCostMap.
o Rule recommended on the cost value mode:
* when the mode 'numerical' is available or applicable.
Randriamasy & Schwan Expires September 13, 2012 [Page 15]
Internet-Draft Multi-Cost ALTO March 2012
4.2. Updates required in the member format for objects
This section specifies the changes in the object member format that
are required to enable multi-cost ALTO transactions.
The term Single Cost qualifies the items as they are specified in the
current ALTO protocol draft, up to version 10
4.2.1. Format update on cost value from JSONNumber to JSONArray
The fundamental change to support multi-cost is to encode the cost
values with the type JSONArray instead of JSONNumber. This way, the
cost between 2 PIDs or to an Endpoint can be represented in a generic
way:
o with several Cost Types,
o with Cost Types whose value can each be encoded with any type of
JSON value.
Note that the evolution from JSONNumber to a more generic value type
is already suggested in the ALTO WG discussions.
Cost value format change affects objects DstCosts and
EndpointDstCosts. A simple example of Multi-Cost value is:
Cost value array :
[23, 6]
mapped with Cost Types:
["routingcost", "hopcount"]
The following example illustrates how multi-cost values can cover a
broader set of aspects:
Cost value array :
[23, 6, [2, 5, 4, 1], "medium"]
mapped with Cost Types:
["routingcost", "hopcount", "quarterlyvaluexxx", "statustring"]
4.2.1.1. Updates on object DstCosts
Object DstCosts changes as follows:
Randriamasy & Schwan Expires September 13, 2012 [Page 16]
Internet-Draft Multi-Cost ALTO March 2012
Current ALTO protocol specification:
object DstCosts {
JSONNumber [PIDName];
...
};
---------------
Multi-Cost capable ALTO specification:
object DstCosts {
JSONArray [PIDName];
...
};
4.2.1.2. Updates on object EndpointDstCosts
Object EndpointDstCosts changes similarly to object Dstcost, as
follows:
Current ALTO protocol specification
object EndpointDstCosts {
JSONNumber [TypedEndpointAddr];
...
};
---------------
Multi-Cost ALTO capable specification
object EndpointDstCosts {
JSONArray [TypedEndpointAddr];
...
};
4.2.2. Format update on CostMode and CostType
Objects InfoResourceCostMap, ReqFilteredCostMap, ReqEndpointCostMap,
InfoResourceEndpointCostMap have members 'cost-mode' and 'cost-type'
that list which cost types are used to report on the cost and in
which mode each of this cost type is represented.
In Multi-Cost ALTO several cost types are used per destination PID or
Randriamasy & Schwan Expires September 13, 2012 [Page 17]
Internet-Draft Multi-Cost ALTO March 2012
endpoint, so the member 'cost-type' of these objects now must be a
array of values rather than a single value. Likewise, the member
'cost-mode' lust be now an array of values, where each value reports
the representation mode of each of the members of the 'cost-type'
list.
The change on members 'cost-mode' and 'cost-type' from a single value
to an array of values are done in the same way with the same rules
for all the objects cited above and are specified as follows:
4.2.2.1. Updates on object ReqFilteredCostMap
Current ALTO protocol specification
object {
CostMode cost-mode;
CostType cost-type;
JSONString constraints<0..*>; [OPTIONAL]
PIDFilter pids; [OPTIONAL]
} ReqFilteredCostMap;
---------------
Multi-Cost ALTO capable specification
object {
CostMode cost-mode<1..*>;
CostType cost-type<1..*>;
JSONString constraints<0..*>; [OPTIONAL]
PIDFilter pids; [OPTIONAL]
} ReqFilteredCostMap;
4.2.2.2. Updates on object ReqEndpointCostMap
Randriamasy & Schwan Expires September 13, 2012 [Page 18]
Internet-Draft Multi-Cost ALTO March 2012
Current ALTO protocol specification
object {
CostMode cost-mode;
CostType cost-type;
JSONString constraints; [OPTIONAL]
EndpointFilter endpoints;
} ReqEndpointCostMap;
---------------
Multi-Cost ALTO capable specification
object {
CostMode cost-mode<1..*>;
CostType cost-type<1..*>;
JSONString constraints; [OPTIONAL]
EndpointFilter endpoints;
} ReqEndpointCostMap;
4.2.2.3. Updates on object InfoResourceCostMap
Current ALTO protocol specification
object {
CostMode cost-mode;
CostType cost-type;
VersionTag map-vtag;
CostMapData map;
} InfoResourceCostMap;
---------------
Multi-Cost ALTO capable specification
object {
CostMode cost-mode<1..*>;
CostType cost-type<1..*>;
VersionTag map-vtag;
CostMapData map;
} InfoResourceCostMap;
Randriamasy & Schwan Expires September 13, 2012 [Page 19]
Internet-Draft Multi-Cost ALTO March 2012
4.2.2.4. Updates on object InfoResourceEndpointCostMap
SINGLE COST ALTO
object {
CostMode cost-mode;
CostType cost-type;
EndpointCostMapData map;
} InfoResourceEndpointCostMap;
---------------
MULTI COST ALTO
object {
CostMode cost-mode<1..*>;
CostType cost-type<1..*>;
EndpointCostMapData map;
} InfoResourceEndpointCostMap;
4.3. Rules required on object member description
When several cost values are provided, it is necessary to
unambiguously specify to which cost type each value corresponds and
in which mode each value is provided.
4.3.1. Rule on cost value order specification
The cost values each Source/Destination pair MUST be provided in the
same order as in the array of cost types. This way, the cost type
values are provided without any ambiguity on the cost type they
report on.
4.3.2. Rule on mapping for cost-type and cost-mode arrays
The cost-mode array MUST be of the same size as the cost-type array.
Each value of this array maps to the cost type ID at the same place
in the cost type array and this value specifies the mode in which the
value for this cost type is provided.
4.4. Updates recommended in the object structure
Objects CostMapCapability and FilteredCostMapCapability: new member
giving the maximum number of Cost Types in a response.
Randriamasy & Schwan Expires September 13, 2012 [Page 20]
Internet-Draft Multi-Cost ALTO March 2012
4.5. Rule recommended on the cost value mode
In multi-cost transactions: when the mode 'numerical' is available or
applicable to a cost type, it MUST be the one used to represent the
cost values. In any case, the cost mode used for each cost-type MUST
be exactly specified.
The following example illustrates how how this rule can be applied:
Cost value array:
[23, 6, [21, 9, 4, 12], "medium"]
mapped with Cost Types:
["routingcost", "hopcount", "quarterlyvaluexxx", "statustring"]
with each cost type value expressed in mode:
["numerical", "numerical", "dynamic", "string"]
In this example, it is assumed that when the value of a cost type is
expressed by an array of numbers such as [21, 9, 4, 12], the values
in this array are expressed in the 'numerical' mode.
4.6. Updated format specification for the ALTO Endpoint Cost
Given the format updates specified above, the new specification of
object InfoResourceEndpointCostMap in the ALTO protocol would look as
follows; the term '[CHANGED]' is put at the end of all the changed
lines in the initial ALTO object specification in [ID-alto-protocol],
(Section 7.7.5.1.5):
Randriamasy & Schwan Expires September 13, 2012 [Page 21]
Internet-Draft Multi-Cost ALTO March 2012
object EndpointDstCosts {
JSONArray [PIDName]; [CHANGED]
...
};
object {
EndpointDstCosts [PIDName]<0..*>;
...
} EndpointCostMapData;
object {
CostMode cost-mode<1..*>; [CHANGED]
CostType cost-type<1..*>; [CHANGED]
EndpointCostMapData map;
} InfoResourceEndpointCostMap;
with members:
cost-mode The array of Cost Modes (Section 5.1.2) used in the
returned Cost Map. Each member of this array is the Cost Mode
used for the Cost Type at the same place in the 'cost-type'
array. [CHANGED]
cost-type The array of Cost Types (Section 5.1.1) used in the
Cost Map. [CHANGED]
map The Endpoint Cost Map data itself.
EndpointCostMapData 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
EndpointDstCosts object denotes the associated cost 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. If the ALTO Server does not
define a cost from a Source Endpoint to a particular Destination
Endpoint, it MAY be omitted from the response.
[ADDED]
The associated cost value between each Source and Destination
Endpoints is expressed as an array of 1 to N values. Each value
corresponds to the Cost Type specified in the same rank of
array member 'cost-type'. EndpointDstCosts array values MUST be
listed in the same order as in the 'cost-type' array.
Randriamasy & Schwan Expires September 13, 2012 [Page 22]
Internet-Draft Multi-Cost ALTO March 2012
4.7. Updated format specification for the ALTO Cost Map
Given the format updates specified above, the new specification of
object InfoResourceEndpointCostMap in the ALTO protocol would look as
follows; the term '[CHANGED]' is put at the end of all the changed
lines in the initial ALTO object specification in [ID-alto-protocol],
(Section 7.7.2.2.5):
Randriamasy & Schwan Expires September 13, 2012 [Page 23]
Internet-Draft Multi-Cost ALTO March 2012
object DstCosts {
JSONArray [PIDName]; [CHANGED]
...
};
object {
DstCosts [PIDName]<0..*>;
...
} CostMapData;
object {
CostMode cost-mode<1..*>; [CHANGED]
CostType cost-type<1..*>; [CHANGED]
VersionTag map-vtag;
CostMapData map;
} InfoResourceCostMap;
with members:
cost-mode The array of Cost Modes (Section 5.1.2) used in the
Cost Map. Each member of this array is the Cost Mode used for
the Cost Type at the same place in the 'cost-type' array.
[CHANGED]
cost-type The array of Cost Types (Section 5.1.1) used in the
Cost Map. [CHANGED]
map-vtag The Version Tag (Section 5.3) of the Network Map used to
generate the Cost Map. [UNCHANGED]
map The Cost Map data itself.
CostMapData 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 DstCosts
object denotes the associated array of costs to a set of destination
PIDs (Section 5.2) [CHANGED]; the name for each member in the object
is the PIDName string identifying the corresponding Destination PID.
[ADDED]
DstCosts array values MUST be listed in the same order as in the
'cost-type' array.
Randriamasy & Schwan Expires September 13, 2012 [Page 24]
Internet-Draft Multi-Cost ALTO March 2012
5. "Multi-Cost ALTO" protocol extensions for multi-cost transacti
This section proposes extensions 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 information on several Cost Types, then
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 an array, where each component corresponds to
a specified Cost Type. The correspondence between the components and
the cost types is implicitely indicated in the ALTO response.
Indeed, following the rule specified in Section 5.3.1 of the present
draft, the values in the Cost values MUST be provided in the same
order as in the array of cost types.
The following ALTO services have 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.
5.1. Required ALTO protocol updates
5.1.1. Rule required on the cost value mode
In multi-cost transactions: when the mode 'numerical' is available or
applicable to a cost type, it MUST be the one used to represent the
cost values. In any case, the cost mode used for each cost-type MUST
be exactly specified.
The following example illustrates how how this roule can be applied:
[23, 6, [21, 9, 4, 12], "medium"]
mapped with Cost Types:
["routingcost", "hopcount", "quarterlyvaluexxx", "statustring"]
Randriamasy & Schwan Expires September 13, 2012 [Page 25]
Internet-Draft Multi-Cost ALTO March 2012
and expressed in modes:
["numerical", "numerical", "dynamic", "string"]
In this example, it is assumed that when the value of a cost type is
expressed by an array array of numbers such as [21, 9, 4, 12],, the
values in this array are expressed in the numerical mode.
5.2. Information Resources Directory
When the ALTO server supports the provision of information on
multiple costs in a single transaction, the Information Resources
Directory will list the corresponding resources. The media type and
encoding specifications remain the same as in the current ALTO
protocol.
5.2.1. Example of Multi-Cost specific resources in the IRD
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 September 13, 2012 [Page 26]
Internet-Draft Multi-Cost ALTO March 2012
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 current ALTO Protocol
.....
}, {
"uri" : "http://alto.example.com/multi/costmap",
"media-types" : ["application/alto-costmap+json"],
"capabilities" : {
"cost-types" : [ "routingcost", "hopcount" ],
"cost-modes" : [ "numerical", "numerical" ]
}
}, {
"uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : ["application/alto-costmap+json"],
"accepts" : ["application/alto-costmapfilter+json"],
"capabilities" : {
"cost-constraints" : true,
"max-cost-types" : 2,
"cost-types" : [ "routingcost", "hopcount", "Dquartervalue", "bblevel" ],
"cost-modes" : [ "numerical", "numerical", "dynamic", "string" ]
}
}, {
"uri" : "http://alto.example.com/multi/endpointcost/lookup",
"media-types" : [ "application/alto-endpointcost+json" ],
"accepts" : [ "application/alto-endpointcostparams+json" ],
"capabilities" : {
"cost-constraints" : true,
"max-cost-types" : 3,
"cost-types" : [ "routingcost", "hopcount", "bblevel" ],
"cost-modes" : [ "numerical", "numerical", "string" ]
}
}
]
}
Randriamasy & Schwan Expires September 13, 2012 [Page 27]
Internet-Draft Multi-Cost ALTO March 2012
5.3. 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.
5.3.1. Media Type
The media type is "application/alto-costmap+json". Same as for
Single cost map
5.3.2. HTTP Method
This resource is requested using the HTTP GET method.
5.3.3. Input Parameters
None.
5.3.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
Randriamasy & Schwan Expires September 13, 2012 [Page 28]
Internet-Draft Multi-Cost ALTO March 2012
defined by a JSON Object of type CostMapCapability:
object {
CostType cost-types<0..*>;
CostMode cost-modes<0..*>;
} CostMapCapability;
with members
cost-types The Cost Types ( Section 5.XX) supported by the
corresponding URI. If not present, this member MUST be
interpreted as an empty array.
cost-modes The Cost Mode ( Section 5.XX) supported for each of
the supported Cost Types listed in the "cost-types".
This array MUST have the same size as the array cost-types.
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.
5.3.5. Response
The returned InfoResourceEntity object has "data" member of type
InfoResourceCostMap:
Randriamasy & Schwan Expires September 13, 2012 [Page 29]
Internet-Draft Multi-Cost ALTO March 2012
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 Cost Map.
map-vtag The Version Tag (Section 5.3) of the Network Map used to
generate the Cost Map.
map The Cost Map data itself.
CostMapData 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 DstCosts object denotes the associated array of one or several
values, where each value corresponds costs types 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. DstCosts MUST be 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.
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.
5.3.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.
Randriamasy & Schwan Expires September 13, 2012 [Page 30]
Internet-Draft Multi-Cost ALTO March 2012
GET /multicostmap/num HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
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] },
"PID2": { "PID1": [5,5], "PID2": [1,11], "PID3": [15,9] },
"PID3": { "PID1": [20,12], "PID2": [15,1], "PID3": [1,18] }
}
}
}
5.4. 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
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.
5.4.1. Media Type
The media type is "application/alto-costmap+json", same as for Single
cost map, see also section 4.2.1 of this draft.
5.4.2. HTTP Method
This resource is requested using the HTTP POST method.
Randriamasy & Schwan Expires September 13, 2012 [Page 31]
Internet-Draft Multi-Cost ALTO March 2012
5.4.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 September 13, 2012 [Page 32]
Internet-Draft Multi-Cost ALTO March 2012
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;
object {
CostType cost-type<0..*>;
CostMode cost-mode<0..*>;
JSONString constraints<0..*>; [OPTIONAL]
PIDFilter pids; [OPTIONAL]
} ReqFilteredCostMap;
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 values encoded with the 'JSONnumber' type, the
Cost Mode SHOULD 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 September 13, 2012 [Page 33]
Internet-Draft Multi-Cost ALTO March 2012
5.4.4. Capabilities +++ MaxCostTypes
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 {
MaxCostTypes max-cost-types; ===> SHOULD NOT BE MENTIONNED IN CORE SERVICES???
CostMode cost-modes<0..*>;
CostType cost-types<0..*>;
JSONBool cost-constraints;
} FilteredCostMapCapability;
with members:
max-cost-types; ++++ TBC +++++++++
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.
5.4.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.
5.4.6. Example
Randriamasy & Schwan Expires September 13, 2012 [Page 34]
Internet-Draft Multi-Cost ALTO March 2012
POST multi/costmap/filtered HTTP/1.1
Host: alto.example.com
Content-Type: application/alto-costmapfilter+json
Accept: application/alto-costmap+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] }
}
}
}
5.5. 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 September 13, 2012 [Page 35]
Internet-Draft Multi-Cost ALTO March 2012
This Service introduces a new media type to define the service and
the input parameters.
5.5.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.
5.5.2. Media Type
The media type is "application/alto-endpointcost+json".
5.5.3. HTTP Method
This resource is requested using the HTTP POST method
5.5.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 ReqEndpointCostMap:
object {
TypedEndpointAddr srcs<0..*>; [OPTIONAL]
TypedEndpointAddr dsts<1..*>;
} EndpointFilter;
object{
CostType cost-type<0..*>;
CostMode cost-mode<0..*>;
JSONString constraints; [OPTIONAL]
EndpointFilter endpoints;
} ReqEndpointCostMap;
with members:
Randriamasy & Schwan Expires September 13, 2012 [Page 36]
Internet-Draft Multi-Cost ALTO March 2012
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
Endpoint 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.
5.5.5. Capabilities
See section 4.3.4 of this draft.
5.5.6. Response
The returned InfoResourceEntity object has "data" member equal to
InfoResourceEndpointCostMap, where:
Randriamasy & Schwan Expires September 13, 2012 [Page 37]
Internet-Draft Multi-Cost ALTO March 2012
object EndpointDstCosts {
JSONArray [TypedEndpointAddr];
...
};
object {
EndpointDstCosts [TypedEndpointAddr]<0..*>;
...
} EndpointMultiCostMapData;
object {
CostMode cost-mode<0..*>;
CostType cost-type<0..*>;
EndpointCostMapData map;
} InfoResourceEndpointCostMap;
InfoResourceEndpointCostMap 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.
EndpointCostMapData 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.
5.5.7. Example
Randriamasy & Schwan Expires September 13, 2012 [Page 38]
Internet-Draft Multi-Cost ALTO March 2012
POST multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: [TODO]
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+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]
}
}
}
}
5.6. 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 September 13, 2012 [Page 39]
Internet-Draft Multi-Cost ALTO March 2012
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.
6. 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
[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],
6.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.
6.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.
7. Acknowledgements
The authors would like to thank Dave Mac Dysan and Vijay Gurbani for
fruitful discussions and comments on this draft and previous
versions.
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.
Randriamasy & Schwan Expires September 13, 2012 [Page 40]
Internet-Draft Multi-Cost ALTO March 2012
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.
8. References
8.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.
8.2. Informative References
[ID-ALTO-Requirements13]
"draft-ietf-alto-reqs-13.txt", January 2012.
[ID-alto-protocol]
, Eds., ""ALTO Protocol" draft-ietf-alto-protocol-10.txt",
October 2011.
[ID-alto-protocol-11]
, Eds., ""ALTO Protocol" draft-ietf-alto-protocol-11.txt",
March 2012.
[draft-jenkins-alto-cdn-use-cases-01]
""Use Cases for ALTO within CDNs"
draft-jenkins-alto-cdn-use-cases-01", June 2011.
[draft-randriamasy-alto-multi-cost-05]
"Multi-Cost ALTO", October 2011.
Randriamasy & Schwan Expires September 13, 2012 [Page 41]
Internet-Draft Multi-Cost ALTO March 2012
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 September 13, 2012 [Page 42]
| PAFTECH AB 2003-2026 | 2026-04-24 04:32:07 |