draft-ietf-alto-multi-cost-00.txt   draft-ietf-alto-multi-cost-01.txt 
Network Working Group S. Randriamasy, Ed. Network Working Group S. Randriamasy, Ed.
Internet-Draft W. Roome, Ed. Internet-Draft W. Roome, Ed.
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: November 23, 2015 N. Schwan Expires: April 21, 2016 N. Schwan
Thales Deutschland Thales Deutschland
May 22, 2015 October 19, 2015
Multi-Cost ALTO Multi-Cost ALTO
draft-ietf-alto-multi-cost-00 draft-ietf-alto-multi-cost-01
Abstract Abstract
The ALTO (Application Layer-Traffic Optimization) Protocol The ALTO (Application Layer-Traffic Optimization) Protocol
([RFC7285]) defines several services that return various metrics ([RFC7285]) defines several services that return various metrics
describing the costs between network endpoints. For example, when describing the costs between network endpoints. For example, when
downloading a file that is mirrored on several sites, a user downloading a file that is mirrored on several sites, a user
application may use these ALTO cost metrics to determine the most application may use these ALTO cost metrics to determine the most
efficient mirror site. efficient mirror site.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
efficient. In addition, this document extends the ALTO constraint efficient. In addition, this document extends the ALTO constraint
tests to allow a user to specify an arbitrary logical combination of tests to allow a user to specify an arbitrary logical combination of
tests on several cost metrics. tests on several cost metrics.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2015. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . . 6 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5
3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . . 6 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5
3.2. Compatibility With Legacy Clients . . . . . . . . . . . . 6 3.2. Compatibility With Legacy Clients . . . . . . . . . . . . 6
3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 7 3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6
3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 8 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 7
3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 8 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7
3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8
4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . . 9 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 9
4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . . 9 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 9
4.1.1. Accept Input Parameters . . . . . . . . . . . . . . . 9 4.1.1. Accept Input Parameters . . . . . . . . . . . . . . . 9
4.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . . 13 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 13
4.2.1. Accept Input Parameters . . . . . . . . . . . . . . . 13 4.2.1. Accept Input Parameters . . . . . . . . . . . . . . . 13
4.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 14
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Information Resource Directory . . . . . . . . . . . . . . 14 5.1. Information Resource Directory . . . . . . . . . . . . . 14
5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . . 16 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 16
5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . . 17 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 17
5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . . 18 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 18
5.5. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 20 5.5. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Privacy And Security Considerations . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Privacy And Security Considerations . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
IETF has designed a new service called ALTO that provides guidance to IETF has designed a new service called ALTO that provides guidance to
overlay applications, which have to select one or several hosts from overlay applications, which have to select one or several hosts from
a set of candidates that are able to provide a desired resource. a set of candidates that are able to provide a desired resource.
This guidance is based on parameters that affect performance and This guidance is based on parameters such the topological distance,
efficiency of the data transmission between the hosts, e.g., the that affect performance and efficiency of the data transmission
topological distance. The purpose of ALTO is to improve Quality of between the hosts. The purpose of ALTO is to improve Quality of
Experience (QoE) in the application while reducing resource Experience (QoE) in the application while reducing resource
consumption in the underlying network infrastructure. The ALTO consumption in the underlying network infrastructure. The ALTO
protocol conveys the Internet View from the perspective of a Provider protocol conveys the Internet View from the perspective of a Provider
Network region that spans from a region to one or more Autonomous Network region that spans from a region to one or more Autonomous
System (AS). Together with this Network Map, it provides the System (AS) and is called a Network Map. ALTO may also provide the
Provider determined Cost Map between locations of the Network Map. Provider determined Cost Map between locations of the Network Map or
Last, it provides the Ranking of Endpoints w.r.t. their routing cost. Endpoint Cost Map between groups of individual endpoints. Last,
these costs are provided as numerical or ordinal values.
Current ALTO Costs and their modes provide values that are seen to be Current ALTO Costs and their modes provide values that are seen to be
stable over a longer period of time, such as hopcount and stable over a longer period of time, such as hopcount and
administrative routing cost to reflect ISP routing preferences. administrative routing cost to reflect ISP routing preferences.
Recently, new use cases have extended the usage scope of ALTO to Recently, new use cases have extended the usage scope of ALTO to
Content Delivery Networks, Data Centers and applications that need Content Delivery Networks, Data Centers and applications that need
additional information to select their Endpoints or handle their additional information to select their Endpoints or handle their
PIDs. PIDs.
Thus a multitude of new Cost Types that better reflect the Thus a multitude of new Cost Types that better reflect the
skipping to change at page 4, line 48 skipping to change at page 4, line 8
It would be far more efficient, in terms of RTT, traffic, and It would be far more efficient, in terms of RTT, traffic, and
processing load on the ALTO client and server, to get all costs with processing load on the ALTO client and server, to get all costs with
a single query/response transaction. Vector costs provide a robust a single query/response transaction. Vector costs provide a robust
and natural input to multi-variate path computation as well as robust and natural input to multi-variate path computation as well as robust
multi-variate selection of multiple Endpoints. In particular, one multi-variate selection of multiple Endpoints. In particular, one
Cost Map reporting on N Cost Types is less bulky than N Cost Maps 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 containing one Cost Type each. This is valuable for both the storage
of these maps and their transmission. Additionally, for many of these maps and their transmission. Additionally, for many
emerging applications that need information on several Cost Types, emerging applications that need information on several Cost Types,
having them gathered in one map will save time. having them gathered in one map will save time. Another potential
advantage is consistency: provide values on several Cost Types in one
single batch is useful for Clients needing synchronized ALTO
information updates.
Along with multi-cost values queries, the filtering capabilities need Along with multi-cost values queries, the filtering capabilities need
to be extended to allow constraints on multiple metrics. The base to be extended to allow constraints on multiple metrics. The base
protocol allows a client to provide optional constraint tests for a protocol allows a client to provide optional constraint tests for a
Filtered Cost Map or the Endpoint Cost Service. In the base Filtered Cost Map or the Endpoint Cost Service. In the base
protocol, the constraint tests are limited to the AND-combination of protocol, the constraint tests are limited to the AND-combination of
simple comparison tests on the value of the (single) requested Cost simple comparison tests on the value of the (single) requested Cost
Type. It is therefore necessary to allow constraints on multiple Type. It is therefore necessary to allow constraints on multiple
metrics. Beyond that, applications that are sensitive to several metrics. Beyond that, applications that are sensitive to several
metrics and struggle with complicated network conditions may need to metrics and struggle with complicated network conditions may need to
arbitrate between conflicting objectives such as routing cost and arbitrate between conflicting objectives such as routing cost and
network performance. To address this issue, this document proposes network performance. To address this issue, this document proposes
to extend the base protocol by extending constraints to test multiple to extend the base protocol by extending constraints to test multiple
metrics, and by allowing these constraints to be combined with metrics, and by allowing these constraints to be combined with
logical 'ORs' as well as logical 'ANDs'. This allows an application logical 'ORs' as well as logical 'ANDs'. This allows an application
to make requests such as: "select solutions with either (moderate to make requests such as: "select solutions with either (moderate
"hopcount" AND high "routingcost") OR (higher "hopcount" AND moderate "hopcount" AND high "routingcost") OR (higher "hopcount" AND moderate
"routingcost")". "routingcost")". To ensure compatibility with legacy ALTO Clients,
Multi-Cost extensions are specified for the Filtered Cost Map service
and the Endpoint Cost Map service only, while enabling to provide
full Cost maps as well.
This document is organized as follows: Section 2 defines terminology This document is organized as follows: Section 2 defines terminology
used in this document. Section 3 gives a non-normative overview of used in this document. Section 3 gives a non-normative overview of
the multi-cost extensions, and Section 4 gives their formal the multi-cost extensions, and Section 4 gives their formal
definition. Section 5 gives several complete examples. The definition. Section 5 gives several complete examples. The
remaining sections describe the IANA and privacy considerations. remaining sections describe the IANA and privacy considerations.
2. Terminology 2. Terminology
This document uses terms defined as follows: This document uses terms defined as follows:
o {1.2.3}: References of this form are to sections in the ALTO o {1.2.3}: References of this form are to sections in the ALTO
protocol specification [RFC7285]. protocol specification [RFC7285].
o When refering to a section of this document, the format 1.2.3,
without brackets, will be used.
o Endpoint (EP): can be a Peer, a CDN storage location, a physical o Endpoint (EP): can be a Peer, a CDN storage location, a physical
server involved in a virtual server-supported application, a Party server involved in a virtual server-supported application, a Party
in a resource sharing swarm such as a computation Grid or an in a resource sharing swarm such as a computation Grid or an
online multi-party game. online multi-party game.
o Endpoint Discovery (EP Discovery) : this term covers the different o Endpoint Discovery (EP Discovery) : this term covers the different
types of processes used to discover the eligible endpoints. types of processes used to discover the eligible endpoints.
o Network Service Provider (NSP): includes both ISPs, who provide o Network Service Provider (NSP): includes both ISPs, who provide
means to transport the data, and Content Delivery Networks (CDNs) means to transport the data, and Content Delivery Networks (CDNs)
who care for the dissemination, persistent storage and possibly who care for the dissemination, persistent storage and possibly
identification of the best/closest content copy. identification of the best/closest content copy.
o ALTO transaction: a request/response exchange between an ALTO o ALTO transaction: a request/response exchange between an ALTO
Client and an ALTO Server. Client and an ALTO Server.
o Application Client (AC): this term generalizes the case of a P2P 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 client to include the case of a CDN client, a client of an
application running on a virtual server, a GRID application client application running on a virtual server, a Grid application client
and any Client having the choice in several connection points for and any Client having the choice in several connection points for
data or resource exchange. data or resource exchange.
3. Overview Of Approach 3. Overview Of Approach
The following is a non-normative overview of the multi-cost The following is a non-normative overview of the multi-cost
extensions defined in this document. It assumes the reader is extensions defined in this document. It assumes the reader is
familiar with Cost Map resources in the ALTO Protocol ([RFC7285]). familiar with Cost Map resources in the ALTO Protocol ([RFC7285]).
3.1. Multi-Cost Data Format 3.1. Multi-Cost Data Format
skipping to change at page 7, line 32 skipping to change at page 7, line 11
For example, the following fragment from an IRD defines an extended For example, the following fragment from an IRD defines an extended
Filtered Cost Map resource: Filtered Cost Map resource:
"filtered-multicost-map" : { "filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered", "uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : [ "application/alto-costmapfilter+json" ],
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"max-cost-types" : 3, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-hopcount" ], "num-hopcount" ],
... ...
} }
A legacy client will ignore the "max-cost-types" capability, and will A legacy client will ignore the "max-cost-types" capability, and will
send a request with the input parameter "cost-type" describing the send a request with the input parameter "cost-type" describing the
desired cost metric, as defined in [RFC7285]. The ALTO Server will desired cost metric, as defined in [RFC7285]. The ALTO Server will
return a single-valued legacy Cost Map. return a single-valued legacy Cost Map.
skipping to change at page 8, line 7 skipping to change at page 7, line 33
supports the multi-cost extensions, and can send a POST request with supports the multi-cost extensions, and can send a POST request with
the new input parameter "multi-cost-types", whose value is an array the new input parameter "multi-cost-types", whose value is an array
of cost types. Because the request has the "multi-cost-types" of cost types. Because the request has the "multi-cost-types"
parameter (rather than the "cost-type" parameter defined in the base parameter (rather than the "cost-type" parameter defined in the base
protocol), the server realizes that the client also supports the protocol), the server realizes that the client also supports the
extensions in this document, and hence responds with a Multi Cost extensions in this document, and hence responds with a Multi Cost
Map, with the costs in the order listed in "multi-cost-types". Map, with the costs in the order listed in "multi-cost-types".
3.4. Endpoint Cost Service Resources 3.4. Endpoint Cost Service Resources
This document uses the technique described above to extend Endpoint This document uses the technique described in Section 3.3 to extend
Cost Service to return array-valued costs to clients who also are the Endpoint Cost Service to return array-valued costs to clients who
aware of these extensions. also are aware of these extensions.
3.5. Full Cost Map Resources 3.5. Full Cost Map Resources
Because Full Cost Map resources are GET-mode requests, with no Full Cost Map resources are GET-mode requests, with no capabilities
capabilities other than the name of the cost type they return, it is other than the name of the cost type they return. It is therefore
not possible to define an array-valued Full Cost Map resource so that not possible to define an array-valued Full Cost Map resource so that
multi-cost-aware clients can recognize it, but legacy clients will multi-cost-aware clients can recognize it and legacy clients will
ignore it. ignore it. Indeed, the response for a Full Cost Map conveying
multiple cost types would include a "meta" field that would itself
include a "cost-type" field, that would list several values
corresponding to the cost types of the cost map. A legacy client
would not be able to understand this list. It would not know what
the cost type of the map is and neither would it be able to interpret
the cost values array provided by a Multi-Cost full maps.
However {11.3.2.3} of [RFC7285] requires a Filtered Cost Map to However {11.3.2.3} of [RFC7285] requires a Filtered Cost Map to
return the entire Cost Map if the client omits the source and return the entire Cost Map if the client omits the source and
destination PIDs. Hence a client can use an extended Filtered Cost destination PIDs. Hence a client can use an extended Filtered Cost
Map resource to get a full Multi Cost Map. Map resource to get a full Multi Cost Map.
3.6. Extended Constraint Tests 3.6. Extended Constraint Tests
[RFC7285] defines a simple constraint test capability for Filtered [RFC7285] defines a simple constraint test capability for Filtered
Cost Maps and Endpoint Cost Services. If a resource supports Cost Maps and Endpoint Cost Services. If a resource supports
skipping to change at page 8, line 43 skipping to change at page 8, line 26
Then the server only returns costs in the range [10,20]. Then the server only returns costs in the range [10,20].
To be useful with multi-cost requests, the constraint tests require To be useful with multi-cost requests, the constraint tests require
several extensions. First, because a multi-cost request involves several extensions. First, because a multi-cost request involves
more than one cost metric, the simple predicates must be extended to more than one cost metric, the simple predicates must be extended to
specify the metric to test. Therefore we extend the predicate syntax specify the metric to test. Therefore we extend the predicate syntax
to "[##] op value", where "##" is the index of a cost metric in this to "[##] op value", where "##" is the index of a cost metric in this
multi cost request. multi cost request.
Second, the "AND" of simple predicates is not sufficient; to be Second, if the client for example wants values either greater than 10
useful, clients must be able to express "OR" tests. Hence we add a or smaller than 20, the "AND" of simple predicates is not sufficient;
new field, "or-constraints", to the client request. The value is an to be useful, clients must be able to express "OR" tests. Hence we
array of arrays of simple predicates, and represents the OR of ANDs add a new field, "or-constraints", to the client request. The value
of those predicates. is an array of arrays of simple predicates, and represents the OR of
ANDs of those predicates.
Thus the following request tells the server to limit its response to Thus the following request tells the server to limit its response to
cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else
"routingcost" <= 10 AND "hopcount" <= 6: "routingcost" <= 10 AND "hopcount" <= 6:
{ {
"multi-cost-types": [ "multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"}, {"cost-metric": "routingcost", "cost-mode": "numerical"},
{"cost-metric": "hopcount", "cost-mode": "numerical"} {"cost-metric": "hopcount", "cost-mode": "numerical"}
], ],
skipping to change at page 9, line 39 skipping to change at page 9, line 24
"constraints": ["[0] le 6"], "constraints": ["[0] le 6"],
"pids": {...} "pids": {...}
} }
In this example, "[0]" means the constraint applies to "hopcount" In this example, "[0]" means the constraint applies to "hopcount"
because that is the first cost type in the "testable-cost-types" because that is the first cost type in the "testable-cost-types"
parameter. parameter.
4. Protocol Extensions for Multi-Cost ALTO Transactions 4. Protocol Extensions for Multi-Cost ALTO Transactions
This section provides the formal specifications of extensions to
RFC7285 to support Multi-Cost ALTO transactions.
4.1. Filtered Cost Map Extensions 4.1. Filtered Cost Map Extensions
This document extends Filtered Cost Maps, as defined in {11.3.2} of This document extends Filtered Cost Maps, as defined in {11.3.2} of
[RFC7285], by adding new input parameters and capabilities, and by [RFC7285], by adding new input parameters and capabilities, and by
returning JSONArrays instead of JSONNumbers as the cost values. returning JSONArrays instead of JSONNumbers as the cost values.
The media type (11.3.2.1}, HTTP method (11.3.2.2} and "uses" The media type (11.3.2.1}, HTTP method (11.3.2.2} and "uses"
specifications (11.3.2.5} are unchanged. specifications (11.3.2.5} are unchanged.
4.1.1. Accept Input Parameters 4.1.1. Accept Input Parameters
skipping to change at page 10, line 24 skipping to change at page 10, line 24
object { object {
PIDName srcs<0..*>; PIDName srcs<0..*>;
PIDName dsts<0..*>; PIDName dsts<0..*>;
} PIDFilter; } PIDFilter;
cost-type: If present, as defined in {11.3.2.3} of [RFC7285], with cost-type: If present, as defined in {11.3.2.3} of [RFC7285], with
the additional requirement that the client MUST provide either the additional requirement that the client MUST provide either
"cost-type" or "multi-cost-types", but MUST NOT provide both. "cost-type" or "multi-cost-types", but MUST NOT provide both.
multi-cost-types: If present, the ALTO Server MUST return array- multi-cost-types: If present, the ALTO Server MUST return array-
valued costs for the cost types in thls list. For each entry, the valued costs for the cost types in thlis list. For each entry,
"cost-metric" and "cost-mode" fields MUST match one of the the "cost-metric" and "cost-mode" fields MUST match one of the
supported cost types indicated in this resource's "capabilities" supported cost types indicated in this resource's "capabilities"
field (Section 4.1.2). The client MUST NOT use this field unless field (Section 4.1.2). The client MUST NOT use this field unless
this resource's "max-cost-types" capability exists and has a value this resource's "max-cost-types" capability exists and has a value
greater than 0. The client MUST specify either "cost-type" or greater than 0. The client MUST specify either "cost-type" or
"multi-cost-types", but MUST NOT specify both. "multi-cost-types", but MUST NOT specify both.
testable-cost-types: A list of cost types for extended constraint testable-cost-types: A list of cost types for extended constraint
tests, as described for the "constraints" parameter. If present, tests, as described for the "constraints" parameter. If present,
the cost types must be a subset of the cost types in the the cost types must be a subset of the cost types in the
resource's "testable-cost-type-names" capability (Section 4.1.2). resource's "testable-cost-type-names" capability (Section 4.1.2).
This feature allows a client to test a cost type whose actual
value is irrelevant, as long as it satisfies the tests. For
example, a client may want a Filtered Cost Map for cost metric
"routingcost" that is restricted to those PID pairs that satisfy
constraints on metric "hopcount". This feature is also useful for
a server that does not allow constraints on all the cost types
indicated in this resource's capabilities.
constraints: Unless this resource's "max-cost-types" capability constraints: Unless this resource's "max-cost-types" capability
(Section 4.1.2) is defined with a value greater than 0, this (Section 4.1.2) is defined with a value greater than 0, this
parameter is an array of constraint tests as defined in {11.3.2.3} parameter is an array of constraint tests where each test is
of [RFC7285]. formulated as defined in {11.3.2.3} of [RFC7285].
This parameter MUST NOT be specified if the "or-constraints"
parameter is specified, or if the resource's "cost-constraints"
capability is false.
If this resource's "max-cost-types" capability is greater than 0, If this resource's "max-cost-types" capability is greater than 0,
then this parameter MUST be an array of extended constraint tests, then this parameter MUST be an array of extended constraint tests,
where each test consists of two or three entities separated by where each test consists of two or three entities separated by
white space: (1) an optional cost type index, of the form "[#]", white space: (1) an optional cost type index, of the form "[#]",
with default value "[0]", (2) a required operator, and (3) a with default value "[0]", (2) a required operator, and (3) a
required target value. The operator and target value are as required target value. The operator and target value are as
defined in {11.3.2.3} of [RFC7285]. The cost type index specifies defined in {11.3.2.3} of [RFC7285]. The cost type index specifies
the cost type to test. If the "testable-cost-types" parameter is the cost type to test. If the "testable-cost-types" parameter is
present, assuming the index is "i", the test applies to the i'th present, assuming the index is "i", the test applies to the i'th
cost type in "testable-cost-types" (starting with index 0). cost type in "testable-cost-types" (starting with index 0).
Otherwise, if the "multi-cost-types" parameter is present, the Otherwise, if the "multi-cost-types" parameter is present, the
test applies to the i'th cost type in "multi-cost-types". If test applies to the i'th cost type in "multi-cost-types". If
neither of those parameters are present, the test applies to the neither of those parameters is present, the test applies to the
cost type in the "cost-type" parameter. In this case, the index cost type in the "cost-type" parameter. In this case, the index
MUST be 0. Regardless of how the tested cost type is selected, it MUST be 0. Regardless of how the tested cost type is selected, it
MUST be a cost type in the resource's "testable-cost-type-names" MUST be a cost type in the resource's "testable-cost-type-names"
capability, or, if omitted, the resource's "cost-type-names" capability, or, if omitted, the resource's "cost-type-names"
capability. capability.
This parameter MUST NOT be specified if the "or-constraints" As an example: suppose "multi-cost-types" has the single element
parameter is specified, or if the resource's "cost-constraints" "routingcost", "testable-cost-types" has the single element
capability is false. "hopcount", and "constraints" has the single element "[0] le 5".
This is equivalent to the database query "SELECT routingcost WHERE
Note that this feature allows a client to test cost types which hopcount <= 5".
the server does not return. For example, suppose "multi-cost-
types" has the single element "routingcost", "testable-cost-types"
has the single element "hopcount", and "constraints" has the
single element "[0] le 5". This is equivalent to the database
query "SELECT routingcost WHERE hopcount <= 5".
Also note that as long as this resource's "max-cost-types" Note that as long as this resource's "max-cost-types" capability
capability is greater than 0, a client may use the extended is greater than 0, a client may use the extended constraint tests
constraint tests even on single-valued cost map requests, that is, even on single-valued cost map requests, that is, requests with
requests with the "cost-type" parameter rather than "multi-cost- the "cost-type" parameter rather than "multi-cost-types".
types".
or-constraints: A JSONArray of JSONArrays of JSONStrings, where each or-constraints: A JSONArray of JSONArrays of JSONStrings, where each
string is a constraint test as defined for the "constraints" string is a constraint test as defined for the "constraints"
parameter. The constraint tests are interpreted as the logical OR parameter. The constraint tests are interpreted as the logical OR
of ANDs. That is, the ALTO Server should return a cost point only of ANDs. That is, the ALTO Server should return a cost point only
if it satisfies all constraints in any one of the sub-arrays. if it satisfies all constraints in any one of the sub-arrays.
This parameter MUST NOT be specified unless this resource's "cost- This parameter MUST NOT be specified unless this resource's "cost-
constraints" capability is "true" and its "max-cost-types" constraints" capability is "true" and its "max-cost-types"
capability is defined with a value greater than 0 (Section 4.1.2). capability is defined with a value greater than 0 (Section 4.1.2).
skipping to change at page 22, line 17 skipping to change at page 22, line 17
This document does define any new media types or introduce any new This document does define any new media types or introduce any new
IANA considerations. IANA considerations.
7. Privacy And Security Considerations 7. Privacy And Security Considerations
This document does introduce any privacy or security issues not This document does introduce any privacy or security issues not
already present in the ALTO protocol. already present in the ALTO protocol.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Vijay Gurbani, Dave Mac Dysan, Dhruv The authors would like to thank Richard Alimi, Vijay Gurbani, Dave
Dhodi and Young Lee for fruitful discussions and comments on this Mac Dysan, Dhruv Dhodi, Young Lee, Richard Yang and Wang Xin for
document and previous versions. fruitful discussions and feedback on this document and previous
versions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5693] "Application Layer Traffic Optimization (ALTO) Problem [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem
Statement", October 2009. Statement", October 2009.
[RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, Traffic Optimization (ALTO) Protocol", RFC 7285, September
September 2014. 2014.
9.2. Informative References 9.2. Informative References
[RFC6708] "Application-Layer Traffic Optimization (ALTO) [RFC6708] "Application-Layer Traffic Optimization (ALTO)
Requirements", February 2012. Requirements", February 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-cost-schedule-01]
"ALTO Cost Schedule", July 2012.
Authors' Addresses Authors' Addresses
Sabine Randriamasy (editor) Sabine Randriamasy (editor)
Alcatel-Lucent/Bell Labs Alcatel-Lucent/Bell Labs
Route de Villejust Route de Villejust
NOZAY 91460 NOZAY 91460
FRANCE FRANCE
Email: Sabine.Randriamasy@alcatel-lucent.com Email: Sabine.Randriamasy@alcatel-lucent.com
Wendy Roome (editor) Wendy Roome (editor)
Alcatel-Lucent/Bell Labs Alcatel-Lucent/Bell Labs
600 Mountain Ave, Rm 3B-324 600 Mountain Ave, Rm 3B-324
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA USA
Phone: +1-908-582-7974 Phone: +1-908-582-7974
Email: w.roome@alcatel-lucent.com Email: w.roome@alcatel-lucent.com
Nico Schwan Nico Schwan
 End of changes. 29 change blocks. 
92 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/