draft-ietf-alto-multi-cost-03.txt   draft-ietf-alto-multi-cost-04.txt 
Network Working Group S. Randriamasy Network Working Group S. Randriamasy
Internet-Draft W. Roome Internet-Draft W. Roome
Intended status: Standards Track Nokia Bell Labs Intended status: Standards Track Nokia Bell Labs
Expires: February 11, 2017 N. Schwan Expires: March 16, 2017 N. Schwan
Thales Deutschland Thales Deutschland
August 10, 2016 September 12, 2016
Multi-Cost ALTO Multi-Cost ALTO
draft-ietf-alto-multi-cost-03 draft-ietf-alto-multi-cost-04
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. An ALTO Server may describing the costs between network endpoints. An ALTO Server may
offer a variety of cost metrics, based on latency,bandwidth, hop offer a variety of cost metrics, based on latency,bandwidth, hop
count, jitter, or whatever else the ALTO Server deems useful. For count, jitter, or whatever else the ALTO Server deems useful. For
example, when downloading a file that is mirrored on several sites, a example, when downloading a file that is mirrored on several sites, a
user application may consider more than one metric, perhaps trading user application may consider more than one metric, perhaps trading
bandwidth for latency to determine the most efficient mirror site. bandwidth for latency to determine the most efficient mirror site.
While the base ALTO Protocol allows a client to use more than one While the base ALTO Protocol allows an ALTO Client to use more than
cost metric, to do so, the client must request each metric one cost metric, to do so, the Client must request each metric
separately. This document defines a new service that allows a client separately. This document defines a new service that allows a Client
to retrieve several cost metrics with one request, which is to retrieve several cost metrics with one request, which is
considerably more efficient. In addition, this document extends the considerably more efficient. In addition, this document extends the
ALTO constraint tests to allow a user to specify an arbitrary logical ALTO constraint tests to allow a user to specify an arbitrary logical
combination of tests on several cost metrics. combination of 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 February 11, 2017. This Internet-Draft will expire on March 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . . 6
3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 6 3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . . 7
3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6 3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 7
3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 7 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 8
3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 8
3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 9
3.6.1. Extended constraint predicates . . . . . . . . . . . 8 3.6.1. Extended constraint predicates . . . . . . . . . . . . 9
3.6.2. Extended logical combination of predicates . . . . . 8 3.6.2. Extended logical combination of predicates . . . . . . 9
3.6.3. Testable Cost Types in constraints . . . . . . . . . 9 3.6.3. Testable Cost Types in constraints . . . . . . . . . . 10
3.6.4. Testable Cost Type Names in IRD capabilities . . . . 9 3.6.4. Testable Cost Type Names in IRD capabilities . . . . . 10
3.6.5. Legacy ALTO Client issues . . . . . . . . . . . . . . 10 3.6.5. Legacy ALTO Client issues . . . . . . . . . . . . . . 11
4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . . 12
4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . . 12
4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 13
4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 16 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . . 17
4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 17
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . . 18
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Information Resource Directory . . . . . . . . . . . . . 18 5.1. Information Resource Directory . . . . . . . . . . . . . . 19
5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 20 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . . 21
5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 21 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . . 22
5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 23 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . . 24
5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 24 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . . 25
5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 26 5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Privacy And Security Considerations . . . . . . . . . . . . . 27 7. Privacy And Security Considerations . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
IETF has defined ALTO services in [RFC7285] to provide guidance to IETF has defined ALTO services in [RFC7285] to provide 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 such as the topological This guidance is based on parameters such as the topological
distance, that affect performance and efficiency of the data distance, that affect performance and efficiency of the data
transmission between the hosts. The purpose of ALTO is to improve transmission between the hosts. The purpose of ALTO is to improve
Quality of Experience (QoE) in the application while reducing Quality of Experience (QoE) in the application while reducing
resource consumption in the underlying network infrastructure. The resource consumption in the underlying network infrastructure. The
ALTO protocol conveys the Internet View from the perspective of a ALTO protocol conveys the Internet View from the perspective of a
Provider Network region that spans from a region to one or more Provider Network region that spans from a region to one or more
Autonomous System (AS) and is called a Network Map. ALTO may also Autonomous System (AS) and is called a Network Map. ALTO may also
provide the Provider determined Cost Map between locations of the provide the Provider determined Cost Map between locations of the
Network Map or Endpoint Cost Map between groups of individual Network Map or Endpoint Cost Map between groups of individual
endpoints. Last, these costs are provided as numerical or ordinal endpoints. Last, these costs are provided as numerical or ordinal
values. values.
Current ALTO Costs and their modes provide values such as hopcount Current ALTO Cost Maps and their modes provide values such as
and administrative routing cost to reflect ISP routing preferences. hopcount and administrative routing cost to reflect ISP routing
Recently, new use cases have extended the usage scope of ALTO to preferences. Recently, new use cases have extended the usage scope
Content Delivery Networks (CDN), Data Centers and applications that of ALTO to Content Delivery Networks (CDN), Data Centers and
need additional information to select their Endpoints or handle their applications that need additional information to select their
PIDs. endpoints or handle their PIDs.
Thus a multitude of new Cost Types that better reflect the Thus a multitude of new Cost Types that better reflect the
requirements of these applications are expected to be specified. requirements of these applications are expected to be specified.
Handling multiple costs, however, can add more complexities, such as Handling multiple costs, however, can add more complexities, such as
overheads and consistency. In particular, cost values that change overheads and consistency. In particular, cost values that change
more frequently than previously assumed may require more frequent more frequently than previously assumed may require more frequent
ALTO requests. Moreover, to make sure to have up to date values, ALTO requests. Moreover, to make sure to have up to date values,
applications using several frequently changing metrics will tend to applications using several frequently changing metrics will tend to
refresh their values simultaneously. refresh their values simultaneously.
The ALTO protocol [RFC7285], which this document refers to as the The ALTO protocol [RFC7285], which this document refers to as the
base protocol, restricts ALTO Cost Maps and Endpoint Cost services to base protocol, restricts ALTO Cost Maps and Endpoint Cost Services to
only one Cost Type and Cost Mode per ALTO request. To retrieve only one Cost Type and Cost Mode per ALTO request. To retrieve
information for several Cost Types, an ALTO client must send several information for several Cost Types, an ALTO Client must send several
separate requests to the Server. separate requests to the Server.
It would be far more efficient, in terms of Round Trip Time (RTT), It would be far more efficient, in terms of Round Trip Time (RTT),
traffic, and processing load on the ALTO Client and Server, to get traffic, and processing load on the ALTO Client and Server, to get
all costs with a single query/response transaction. Vector costs all costs with a single query/response transaction. Vector costs
provide a robust and natural input to multi-variate path computation provide a robust and natural input to multi-variate path computation
as well as robust multi-variate selection of multiple Endpoints. In as well as robust multi-variate selection of multiple endpoints. In
particular, one Cost Map reporting on N Cost Types is less bulky than 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 N Cost Maps containing one Cost Type each. This is valuable for both
the storage of these maps and for their transmission. Additionally, the storage of these maps and for their transmission. Additionally,
for many emerging applications that need information on several Cost for many emerging applications that need information on several Cost
Types, having them gathered in one map will save time. Another Types, having them gathered in one map will save time. Another
potential advantage is consistency: providing values for several Cost potential advantage is consistency: providing values for several Cost
Types in one single batch is useful for ALTO clients needing Types in one single batch is useful for ALTO Clients needing
synchronized ALTO information updates. 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 an ALTO client to provide optional constraint tests protocol allows an ALTO Client to provide optional constraint tests
for a Filtered Cost Map or the Endpoint Cost Service. In the base for a 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 extends
to extend the base protocol by extending constraints to test multiple the base protocol by extending constraints to test multiple metrics,
metrics, and by allowing these constraints to be combined with and by allowing these constraints to be combined with logical 'ORs'
logical 'ORs' as well as logical 'ANDs'. This allows an application as well as logical 'ANDs'. This allows an application to make
to make requests such as: "select solutions with either (moderate requests such as: "select solutions with either (moderate "hopcount"
"hopcount" AND high "routingcost") OR (higher "hopcount" AND moderate AND high "routingcost") OR (higher "hopcount" AND moderate
"routingcost")". To ensure compatibility with legacy ALTO clients, "routingcost")". To ensure compatibility with legacy ALTO Clients,
only the Filtered Cost Map and Endpoint Cost Map services are only the Filtered Cost Map and Endpoint Cost Map services are
extended to return Multi-Cost values. Full Cost Map services remain extended to return Multi-Cost values. Full Cost Map services remain
unchanged, and are restricted to returning single cost values. unchanged, and are restricted to returning single cost values.
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
definitions. Section 5 gives several complete examples. The definitions. 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
o {1.2.3}: References with curly brackets are to sections in the o {1.2.3}: References with curly brackets are to sections in the
ALTO protocol specification [RFC7285]. ALTO protocol specification [RFC7285].
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 application running on a virtual server, a Grid application
client, or any application client that can choose between several client, or any application client that can choose between several
connection points for data or resource exchange. connection points for data or resource exchange.
o Client: this term refers to an ALTO client, when used with a o Client: This term refers to an ALTO client, when used with a
capital "C". capital "C".
o Endpoint (EP): an endpoint can be for example a Peer, a CDN o Endpoint (EP): An endpoint is defined as in {2.1} of [RFC7285].
storage location, a physical server involved in a virtual server- It can be for example a peer, a CDN storage location, a physical
supported application, a party in a resource sharing swarm such as server involved in a virtual server-supported application, a party
a computation grid or an online multi-party game. in a resource sharing swarm such as a computation grid or an
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 CDNs who care for the means to transport the data, and CDNs who care for the
dissemination, persistent storage and possibly identification of dissemination, persistent storage and possibly identification of
the best/closest content copy. the best/closest content copy.
o Server: this term refers to an ALTO server, when used with a o Server: This term refers to an ALTO server, when used with a
capital "S". capital "S".
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 6, line 29 skipping to change at page 7, line 23
} }
"cost-map" : { "cost-map" : {
"PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] },
... ...
} }
} }
3.2. Compatibility With Legacy ALTO Clients 3.2. Compatibility With Legacy ALTO Clients
The multi-cost extensions defined in this document must not break The multi-cost extensions defined in this document must not break
legacy implementations (that is, ALTO clients and servers which are legacy implementations (that is, ALTO Clients and servers which are
not aware of these extensions). One way to achieve that would be to not aware of these extensions). One way to achieve that would be to
define a new media type for an array-valued Multi Cost Map. However, define a new media type for an array-valued Multi Cost Map. However,
as indicated above, an array-valued Multi Cost Map is almost as indicated above, an array-valued Multi Cost Map is almost
identical to a single-valued Cost Map, so it should be simple to identical to a single-valued Cost Map, so it should be simple to
write a parser which handles either type of cost map. Hence defining write a parser which handles either type of cost map. Hence defining
a new media type could result in a lot of wasteful duplication. a new media type could result in a lot of wasteful duplication.
Therefore this document does not define any new media types. Therefore this document does not define any new media types.
Instead, as described below, it extends the specifications in the Instead, as described below, it extends the specifications in the
ALTO Server's Information Resource Directory (IRD) so that legacy ALTO Server's Information Resource Directory (IRD) so that legacy
clients will not request array-valued Multi Cost Map resources. This Clients will not request array-valued Multi Cost Map resources. This
relies on the requirement that ALTO clients MUST ignore unknown relies on the requirement that ALTO Clients MUST ignore unknown
fields ({8.3.7}). fields ({8.3.7}).
3.3. Filtered Multi Cost Map Resources 3.3. Filtered Multi Cost Map Resources
This document extends the Filtered Cost Map service to allow the same This document extends the Filtered Cost Map service to allow the same
resource to return either a single-valued Cost Map, as defined in resource to return either a single-valued Cost Map, as defined in
[RFC7285], or an array-valued Multi Cost Map, as defined in this [RFC7285], or an array-valued Multi Cost Map, as defined in this
document. An extended Filtered Cost Map resource has a new document. An extended Filtered Cost Map resource has a new
capability, "max-cost-types". The value is the maximum number of capability, "max-cost-types". The value is the maximum number of
cost types this resource can return for one request. The existence cost types this resource can return for one request. The existence
skipping to change at page 7, line 22 skipping to change at page 8, line 17
"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" : 2, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-hopcount" ], "num-hopcount" ],
... ...
} }
A legacy ALTO client will ignore the "max-cost-types" capability, and A legacy ALTO Client will ignore the "max-cost-types" capability, and
will send a request with the input parameter "cost-type" describing will send a request with the input parameter "cost-type" describing
the desired cost metric, as defined in [RFC7285]. The ALTO Server the desired cost metric, as defined in [RFC7285]. The ALTO Server
will return a single-valued legacy Cost Map. will return a single-valued legacy Cost Map.
However, a multi-cost-aware ALTO client will realize that this However, a multi-cost-aware ALTO Client will realize that this
resource supports the multi-cost extensions, and can send a POST resource supports the multi-cost extensions, and can send a POST
request with the new input parameter "multi-cost-types", whose value request with the new input parameter "multi-cost-types", whose value
is an array of cost types. Because the request has the "multi-cost- is an array of cost types. Because the request has the "multi-cost-
types" parameter (rather than the "cost-type" parameter defined in types" parameter (rather than the "cost-type" parameter defined in
the base protocol), the Server realizes that the ALTO client also the base protocol), the Server realizes that the ALTO Client also
supports the extensions in this document, and hence responds with a supports the extensions in this document, and hence responds with a
Multi Cost Map, with the costs in the order listed in "multi-cost- Multi Cost Map, with the costs in the order listed in "multi-cost-
types". types".
3.4. Endpoint Cost Service Resources 3.4. Endpoint Cost Service Resources
This document uses the technique described in Section 3.3 to extend This document uses the technique described in Section 3.3 to extend
the Endpoint Cost Service to return array-valued costs to ALTO the Endpoint Cost Service to return array-valued costs to ALTO
clients who also are aware of these extensions. Clients who also are aware of these extensions.
3.5. Full Cost Map Resources 3.5. Full Cost Map Resources
Full Cost Map resources are GET-mode requests, with no capabilities Full Cost Map resources are GET-mode requests, with no capabilities
other than the name of the cost type they return. Therefore unless other than the name of the cost type they return. Therefore unless
we create a new media type for array-valued Cost Maps, it is not we create a new media type for array-valued Cost Maps, it is not
possible to define a Multi-Cost Full Cost Map resource so that multi- possible to define a Multi-Cost Full Cost Map resource so that multi-
cost-aware ALTO clients can recognize it and legacy ALTO clients will cost-aware ALTO Clients can recognize it and legacy ALTO Clients will
ignore it. Indeed, the response for a Full Cost Map conveying ignore it. Indeed, the response for a Full Cost Map conveying
multiple cost types would include a "meta" field that would itself multiple cost types would include a "meta" field that would itself
include a "cost-type" field, that would list several values include a "cost-type" field, that would list several values
corresponding to the cost types of the cost map. A legacy ALTO corresponding to the cost types of the cost map. A legacy ALTO
client would not be able to understand this list. It would not know 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 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. 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 ALTO client omits the source and return the entire Cost Map if the ALTO Client omits the source and
destination PIDs. Hence an ALTO client can use an extended Filtered destination PIDs. Hence an ALTO Client can use an extended Filtered
Cost Map resource to get a full Multi Cost Map. Cost 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
constraints, the Server restricts the response to costs that satisfy constraints, the Server restricts the response to costs that satisfy
a list of simple predicates provided by the ALTO client. For a list of simple predicates provided by the ALTO Client. For
example, if the ALTO client gives the constraints example, if the ALTO Client gives the constraints
"constraints": ["ge 10", "le 20"] "constraints": ["ge 10", "le 20"]
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. several extensions.
3.6.1. Extended constraint predicates 3.6.1. Extended constraint predicates
skipping to change at page 9, line 50 skipping to change at page 10, line 50
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. (If "testable-cost-types" is omitted, it is assumed to be parameter. (If "testable-cost-types" is omitted, it is assumed to be
the same as "multi-cost-types".) the same as "multi-cost-types".)
3.6.4. Testable Cost Type Names in IRD capabilities 3.6.4. Testable Cost Type Names in IRD capabilities
In [RFC7285], when a resource's capability "constraints" is true, the In [RFC7285], when a resource's capability "constraints" is true, the
Server accepts constraints on all the cost types listed in the "cost- Server accepts constraints on all the cost types listed in the "cost-
type-names" capability. However, some ALTO Servers may not be type-names" capability. However, some ALTO Servers may not be
willing to allow contraint tests on all available cost metrics. willing to allow constraint tests on all available cost metrics.
Therefore the Multi-Cost ALTO protocol extension defines the Therefore the Multi-Cost ALTO protocol extension defines the
capability field "testable-cost-type-names". Like "cost-type-names", capability field "testable-cost-type-names". Like "cost-type-names",
it is an array of cost type names. If present, that resource only it is an array of cost type names. If present, that resource only
allows constraint tests on the cost types in that list. "testable- allows constraint tests on the cost types in that list. "testable-
cost-type-names" MUST be a subset of "cost-type-names". cost-type-names" MUST be a subset of "cost-type-names".
3.6.5. Legacy ALTO Client issues 3.6.5. Legacy ALTO Client issues
While a multi-cost-aware Client will recognize the "testable-cost- While a multi-cost-aware Client will recognize the "testable-cost-
type-names" field, and will honor those restrictions, a legacy Client type-names" field, and will honor those restrictions, a legacy Client
will not. Hence a legacy may send a request with a constraint test will not. Hence a legacy may send a request with a constraint test
on any of the cost types listed in "cost-type-names". on any of the cost types listed in "cost-type-names".
To avoid that problem, the "testable-cost-type-names" and "cost- To avoid that problem, the "testable-cost-type-names" and "cost-
constraints" fields are mutually exclusive: a resource may define one constraints" fields are mutually exclusive: a resource may define one
or the other capability, but MUST NOT define both. Thus a resource or the other capability, but MUST NOT define both. Thus a resource
that does not allow constraint tests on all cost metrics will set that does not allow constraint tests on all cost metrics will set
"testable-cost-type-names" to the testable metrics, and will set "testable-cost-type-names" to the testable metrics, and will set
"cost-constraints" to "false". A multi-cost-aware Client will "cost-constraints" to "false". A multi-cost-aware Client will
recognize the "testable-cost-type-names" field, and will realize that recognize the "testable-cost-type-names" field, and will realize that
its existence means the resource does allow (limited) contraint its existence means the resource does allow (limited) constraint
tests, while a legacy Client will think that resource does not allow tests, while a legacy Client will think that resource does not allow
constraint tests at all. To allow legacy Clients to use constraint constraint tests at all. To allow legacy Clients to use constraint
tests, the ALTO Server MAY define an additional resource with "cost- tests, the ALTO Server MAY define an additional resource with "cost-
constraints" set to "true" and "cost-type-names" set to the metrics constraints" set to "true" and "cost-type-names" set to the metrics
which can be tested. which can be tested.
In the IRD example below, the resource "filtered-cost-map-extended" In the IRD example below, the resource "filtered-cost-map-extended"
provides values for three metrics: "num-routingcost", "num-hopcount" provides values for three metrics: "num-routingcost", "num-hopcount"
and "num-bwscore". The capability "testable-cost-type-names" and "num-bwscore". The capability "testable-cost-type-names"
indicates that the Server only allows constraints on "routingcost" indicates that the Server only allows constraints on "routingcost"
skipping to change at page 15, line 26 skipping to change at page 16, line 26
types" capability is defined with a value greater than 0 types" capability is defined with a value greater than 0
(Section 4.1.1), and if the resource allows constraint tests (the (Section 4.1.1), and if the resource allows constraint tests (the
resource's "cost-constraints" capability is "true" or its resource's "cost-constraints" capability is "true" or its
"testable-cost-type-names" capability is not empty). Otherwise "testable-cost-type-names" capability is not empty). Otherwise
this parameter MUST NOT be specified. this parameter MUST NOT be specified.
This parameter MUST NOT be specified if the "constraints" This parameter MUST NOT be specified if the "constraints"
parameter is specified. parameter is specified.
This parameter MUST NOT contain any empty array of AND predicates. This parameter MUST NOT contain any empty array of AND predicates.
An empty array would be equivalent to a constraint that is always
"true". An OR combination including such a constraint would be
always "true" and thus useless.
As an example, suppose "multi-cost-types" has the two elements As an example, suppose "multi-cost-types" has the two elements
"routingcost" and "bandwidthscore", and "testable-cost-types" has "routingcost" and "bandwidthscore", and "testable-cost-types" has
the two elements "routingcost" and "hopcount", and "or- the two elements "routingcost" and "hopcount", and "or-
constraints" has the two elements ["[0] le 100", "[1] le 2"] and constraints" has the two elements ["[0] le 100", "[1] le 2"] and
["[0] le 10", "[1] le 6"]. This is equivalent to the database ["[0] le 10", "[1] le 6"]. This is equivalent to the database
query: "SELECT and provide routingcost and bandwidth score WHERE query: "SELECT and provide routingcost and bandwidthscore WHERE
("routingcost" <= 100 AND "hopcount" <= 2) OR else ("routingcost" ("routingcost" <= 100 AND "hopcount" <= 2) OR ("routingcost" <= 10
<= 10 AND "hopcount" <= 6)". AND "hopcount" <= 6)".
Note that an empty array of AND predicates is equivalent to a
constraint that is allways "true". An OR combination including
such a constraint would be allways "true" and thus useless.
Also note that if the "max-cost-types" capability has a value Note that if the "max-cost-types" capability has a value greater
greater than 0, a Client MAY use the "or-constraints" parameter than 0, a Client MAY use the "or-constraints" parameter together
together with the "cost-type" parameter. That is, if the Client with the "cost-type" parameter. That is, if the Client and Server
and Server are both aware of the extensions in this document, a are both aware of the extensions in this document, a Client MAY
Client MAY use an "OR" test for a single-valued cost request. use an "OR" test for a single-valued cost request.
pids, srcs, dsts: As defined in {11.3.2.3} of [RFC7285]. pids, srcs, dsts: As defined in {11.3.2.3} of [RFC7285].
4.1.3. Response 4.1.3. Response
If the Client specifies the "cost-type" input parameter, the response If the Client specifies the "cost-type" input parameter, the response
is exactly as defined in {11.2.3.6} of [RFC7285]. If the Client is exactly as defined in {11.2.3.6} of [RFC7285]. If the Client
provides the "multi-cost-types" instead, then the response is changed provides the "multi-cost-types" instead, then the response is changed
as follows: as follows:
skipping to change at page 28, line 8 skipping to change at page 29, line 8
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 Richard Alimi, Fred Baker, Dhruv The authors would like to thank Richard Alimi, Fred Baker, Dhruv
Dhodi, Vijay Gurbani, Gao Kai, Dave Mac Dysan, Young Lee, Hans Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for
Seidel, Richard Yang, Qiao Xiang and Wang Xin for fruitful fruitful discussions and feedback on this document and previous
discussions and feedback on this document and previous versions. versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang
Xin provided substantial review feedback and suggestions to the
protocol design.
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", BCP 14, RFC 2119, Requirement Levels", RFC 2119, BCP 14, March 1997.
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, September Traffic Optimization (ALTO) Protocol", RFC 7285,
2014. September 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.
Authors' Addresses Authors' Addresses
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
 End of changes. 36 change blocks. 
105 lines changed or deleted 105 lines changed or added

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