draft-ietf-alto-multi-cost-05.txt   draft-ietf-alto-multi-cost-06.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: August 26, 2017 N. Schwan Expires: September 11, 2017 N. Schwan
Thales Deutschland Thales Deutschland
February 22, 2017 March 10, 2017
Multi-Cost ALTO Multi-Cost ALTO
draft-ietf-alto-multi-cost-05 draft-ietf-alto-multi-cost-06
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 August 26, 2017. This Internet-Draft will expire on September 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5
3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5
3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 6 3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 6
3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6 3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6
3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 7 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 7
3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7
3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8
3.6.1. Extended constraint predicates . . . . . . . . . . . 8 3.6.1. Extended constraint predicates . . . . . . . . . . . 8
3.6.2. Extended logical combination of predicates . . . . . 8 3.6.2. Extended logical combination of predicates . . . . . 8
3.6.3. Testable Cost Types in constraints . . . . . . . . . 9 3.6.3. Testable Cost Types in constraints . . . . . . . . . 9
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 . . . . . . . . . . . . . . 10
4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11
4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . 16
4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Information Resource Directory . . . . . . . . . . . . . 18 5.1. Information Resource Directory . . . . . . . . . . . . . 18
5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 20 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 20
5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 21 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 21
5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 23 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 23
5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 24 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 24
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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 Cost Maps and their modes provide values such as Current ALTO Cost Maps and their modes provide values such as
hopcount and administrative routing cost to reflect ISP routing hopcount and administrative routing cost to reflect ISP routing
preferences. Recently, new use cases have extended the usage scope preferences. Recently, new use cases have extended the usage scope
of ALTO to Content Delivery Networks (CDN), Data Centers and of ALTO to Content Delivery Networks (CDN), Data Centers and
applications that need additional information to select their applications that need additional information to select their
endpoints or handle their PIDs. endpoints or handle their Provider-defined IDentifiers (PID)s.
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.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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 Section {4.1.4} of [RFC7285] specifies that "The Endpoint Cost
the Endpoint Cost Service to return array-valued costs to ALTO Service allows an ALTO Server to return costs directly amongst
Clients who also are aware of these extensions. endpoints.", whereas the Filtered Cost Map Service returns costs
amongst PIDs. This document uses the technique described in
Section 3.3 to extend the Endpoint Cost Service to return array-
valued costs to ALTO Clients who also are aware of these extensions.
3.5. Full Cost Map Resources 3.5. Full Cost Map Resources
Section {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
destination PIDs. Hence a Multi-Cost aware ALTO Client can use an
extended Filtered Cost Map resource to get a full Multi Cost Map.
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
return the entire Cost Map if the ALTO Client omits the source and
destination PIDs. Hence an ALTO Client can use an extended Filtered
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"]
skipping to change at page 9, line 45 skipping to change at page 9, line 45
], ],
"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. (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".)
The choice of using an index to refer to cost-types aims at
minimizing the length of the expression of constraints, especially
for those combining several OR and AND expressions. It was also the
shortest path from the constraints design in RFC 7285.
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 constraint 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) constraint 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"
and "hopcount". A multi-cost capable Client will see this and "hopcount". A multi-cost capable Client will see this
capability, and will limit its constraint tests to those metrics. capability, and will limit its constraint tests to those metrics.
Because capability "cost-constraints" is false (by default), a legacy Because capability "cost-constraints" is false (by default), a legacy
skipping to change at page 16, line 5 skipping to change at page 16, line 12
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:
o In "meta", the field "cost-type" is provided with a dummy value. o In "meta", the value of field "cost-type" will be ignored by the
Instead, the field "multi-cost-types" is added with the same value receiver and set to {}. Instead, the field "multi-cost-types" is
as the "multi-cost-types" input parameter. added with the same value as the "multi-cost-types" input
parameter.
o The costs are JSONArrays, instead of JSONNumbers. All arrays have o The costs are JSONArrays, instead of JSONNumbers. All arrays have
the same cardinality as the "multi-cost-types" input parameter, the same cardinality as the "multi-cost-types" input parameter,
and contain the cost type values in that order. If a cost type is and contain the cost type values in that order. If a cost type is
not available for a particular source and destination, the ALTO not available for a particular source and destination, the ALTO
Server MUST use the JSON "null" value for that array element. If Server MUST use the JSON "null" value for that array element. If
none of the cost types are available for a particular source and none of the cost types are available for a particular source and
destination, the ALTO Server MAY omit the entry for that source destination, the ALTO Server MAY omit the entry for that source
and destination. and destination.
 End of changes. 15 change blocks. 
23 lines changed or deleted 32 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/