draft-ietf-alto-multi-cost-01.txt   draft-ietf-alto-multi-cost-02.txt 
Network Working Group S. Randriamasy, Ed. Network Working Group S. Randriamasy
Internet-Draft W. Roome, Ed. Internet-Draft W. Roome
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Nokia Bell Labs
Expires: April 21, 2016 N. Schwan Expires: December 15, 2016 N. Schwan
Thales Deutschland Thales Deutschland
October 19, 2015 June 13, 2016
Multi-Cost ALTO Multi-Cost ALTO
draft-ietf-alto-multi-cost-01 draft-ietf-alto-multi-cost-02
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 2, line 10 skipping to change at page 2, line 10
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 April 21, 2016. This Internet-Draft will expire on December 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 Clients . . . . . . . . . . . . 6 3.2. Compatibility With Legacy 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
4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 9 3.6.1. Extended constraint predicates . . . . . . . . . . . 8
4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 9 3.6.2. Extended logical combination of predicates . . . . . 8
4.1.1. Accept Input Parameters . . . . . . . . . . . . . . . 9 3.6.3. Testable Cost Types in constraints . . . . . . . . . 9
4.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . 12 3.6.4. Testable Cost Type Names in IRD capabilities . . . . 9
4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12 3.6.5. Legacy client issues . . . . . . . . . . . . . . . . 10
4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 13 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11
4.2.1. Accept Input Parameters . . . . . . . . . . . . . . . 13 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11
4.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Information Resource Directory . . . . . . . . . . . . . 14 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 15
5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 16 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16
5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 17 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16
5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 18 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 20 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Information Resource Directory . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 19
7. Privacy And Security Considerations . . . . . . . . . . . . . 22 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 7. Privacy And Security Considerations . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 such the topological distance, This guidance is based on parameters such as the topological
that affect performance and efficiency of the data transmission distance, that affect performance and efficiency of the data
between the hosts. The purpose of ALTO is to improve Quality of transmission between the hosts. The purpose of ALTO is to improve
Experience (QoE) in the application while reducing resource Quality of Experience (QoE) in the application while reducing
consumption in the underlying network infrastructure. The ALTO resource consumption in the underlying network infrastructure. The
protocol conveys the Internet View from the perspective of a Provider ALTO protocol conveys the Internet View from the perspective of a
Network region that spans from a region to one or more Autonomous Provider Network region that spans from a region to one or more
System (AS) and is called a Network Map. ALTO may also provide the Autonomous System (AS) and is called a Network Map. ALTO may also
Provider determined Cost Map between locations of the Network Map or provide the Provider determined Cost Map between locations of the
Endpoint Cost Map between groups of individual endpoints. Last, Network Map or Endpoint Cost Map between groups of individual
these costs are provided as numerical or ordinal values. 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 (CDN), Data Centers and applications that
additional information to select their Endpoints or handle their need 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
requirements of these applications are expected to be specified, in requirements of these applications are expected to be specified, in
particular cost values that change more frequently than previously particular cost values that change more frequently than previously
assumed. assumed.
The ALTO protocol [RFC7285] restricts ALTO Cost Maps and Endpoint The ALTO protocol [RFC7285] restricts ALTO Cost Maps and Endpoint
Cost services to only one Cost Type and Cost Mode per ALTO request. Cost services to only one Cost Type and Cost Mode per ALTO request.
To retrieve information for several Cost Types, an ALTO client must To retrieve information for several Cost Types, an ALTO client must
send several separate requests to the server. send several separate requests to the server.
It would be far more efficient, in terms of RTT, traffic, and It would be far more efficient, in terms of Round Trip Time (RTT),
processing load on the ALTO client and server, to get all costs with traffic, and processing load on the ALTO client and server, to get
a single query/response transaction. Vector costs provide a robust all costs with a single query/response transaction. Vector costs
and natural input to multi-variate path computation as well as robust provide a robust and natural input to multi-variate path computation
multi-variate selection of multiple Endpoints. In particular, one as well as robust multi-variate selection of multiple Endpoints. In
Cost Map reporting on N Cost Types is less bulky than N Cost Maps particular, one Cost Map reporting on N Cost Types is less bulky than
containing one Cost Type each. This is valuable for both the storage N Cost Maps containing one Cost Type each. This is valuable for both
of these maps and their transmission. Additionally, for many the storage of these maps and for their transmission. Additionally,
emerging applications that need information on several Cost Types, for many emerging applications that need information on several Cost
having them gathered in one map will save time. Another potential Types, having them gathered in one map will save time. Another
advantage is consistency: provide values on several Cost Types in one potential advantage is consistency: providing values for several Cost
single batch is useful for Clients needing synchronized ALTO Types in one single batch is useful for Clients needing synchronized
information updates. 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")". To ensure compatibility with legacy ALTO Clients, "routingcost")". To ensure compatibility with legacy ALTO Clients,
Multi-Cost extensions are specified for the Filtered Cost Map service only the Filtered Cost Map and Endpoint Cost Map services are
and the Endpoint Cost Map service only, while enabling to provide extended to return Multi-Cost values. Full Cost Map services remain
full Cost maps as well. 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
definition. 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
This document uses terms defined as follows: o {1.2.3}: References with curly brackets are to sections in the
ALTO protocol specification [RFC7285].
o {1.2.3}: References of this form are to sections in the ALTO
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): A Peer, a CDN storage location, a physical server
server involved in a virtual server-supported application, a Party involved in a virtual server-supported application, a party in a
in a resource sharing swarm such as a computation Grid or an resource sharing swarm such as a computation grid or an online
online multi-party game. 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 CDNs who care for the
who care for the dissemination, persistent storage and possibly dissemination, persistent storage and possibly identification of
identification of the best/closest content copy. 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
and any Client having the choice in several connection points for client, or any Client that can choose between several connection
data or resource exchange. points for 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
Formally, the cost entries in an ALTO Cost Map can be any type of Formally, the cost entries in an ALTO Cost Map can be any type of
skipping to change at page 6, line 21 skipping to change at page 6, line 21
] ]
} }
"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 Clients 3.2. Compatibility With Legacy Clients
The multi-cost extensions defined in this document should not break The multi-cost extensions defined in this document must not break
legacy implementations (that is, clients and servers which are not legacy implementations (that is, clients and servers which are not
aware of these extensions). One way to achieve that would be to 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 Cost Map resources. This clients will not request array-valued Multi Cost Map resources. This
relies on the requirement that implementations MUST ignore unknown relies on the requirement that ALTO Clients MUST ignore unknown
fields ({8.3.7} in [RFC7285]). 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
of this capability means the resource understands the extensions in of this capability means the resource understands the extensions in
skipping to change at page 7, line 40 skipping to change at page 7, line 40
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 clients who the Endpoint Cost Service to return array-valued costs to clients who
also are aware of these extensions. 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. It is therefore other than the name of the cost type they return. Therefore unless
not possible to define an array-valued Full Cost Map resource so that we create a new media type for array-valued Cost Maps, it is not
multi-cost-aware clients can recognize it and legacy clients will possible to define a Multi-Cost Full Cost Map resource so that multi-
ignore it. Indeed, the response for a Full Cost Map conveying cost-aware clients can recognize it and legacy clients will ignore
multiple cost types would include a "meta" field that would itself it. Indeed, the response for a Full Cost Map conveying multiple cost
include a "cost-type" field, that would list several values types would include a "meta" field that would itself include a "cost-
corresponding to the cost types of the cost map. A legacy client type" field, that would list several values corresponding to the cost
would not be able to understand this list. It would not know what types of the cost map. A legacy client would not be able to
the cost type of the map is and neither would it be able to interpret understand this list. It would not know what the cost type of the
the cost values array provided by a Multi-Cost full maps. 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
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 client. For example, if a list of simple predicates provided by the client. For example, if
the client gives the constraints the 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. First, because a multi-cost request involves several extensions.
more than one cost metric, the simple predicates must be extended to
specify the metric to test. Therefore we extend the predicate syntax
to "[##] op value", where "##" is the index of a cost metric in this
multi cost request.
Second, if the client for example wants values either greater than 10 3.6.1. Extended constraint predicates
or smaller than 20, the "AND" of simple predicates is not sufficient;
to be useful, clients must be able to express "OR" tests. Hence we
add a new field, "or-constraints", to the client request. The value
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 First, because a multi-cost request involves more than one cost
metric, the simple predicates must be extended to specify the metric
to test. Therefore we extend the predicate syntax to "[##] op
value", where "##" is the index of a cost metric in this multi-cost
request.
3.6.2. Extended logical combination of predicates
Second, once multiple cost metrics are involved, the "AND" of simple
predicates is no longer sufficient. To be useful, clients must be
able to express "OR" tests. Hence we add a new field, "or-
constraints", to the client request. The value 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
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"}
], ],
"or-constraints": [ "or-constraints": [
["[0] le 100", "[1] le 2"], ["[0] le 100", "[1] le 2"],
["[0] le 10", "[1] le 6"] ["[0] le 10", "[1] le 6"]
], ],
"pids": {...} "pids": {...}
} }
Finally, a client might want to test a cost type whose actual value 3.6.3. Testable Cost Types in constraints
is irrelevant, as long as it satisfies the tests. For example, the
following request tells the server to return just "routingcost" for Finally, a client may want to test a cost type whose actual value is
those source and destination pairs for which "hopcount" is <= 6: irrelevant, as long as it satisfies the tests. For example, a client
may want the value of the cost metric "routingcost" for all PID pairs
that satisfy constraints on the metric "hopcount", without needing
the actual value of "hopcount".
For example, the following request tells the server to return just
"routingcost" for those source and destination pairs for which
"hopcount" is <= 6:
{ {
"multi-cost-types": [ "multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"}, {"cost-metric": "routingcost", "cost-mode": "numerical"},
], ],
"testable-cost-types": [ "testable-cost-types": [
{"cost-metric": "hopcount", "cost-mode": "numerical"}, {"cost-metric": "hopcount", "cost-mode": "numerical"},
], ],
"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. (If "testable-cost-types" is omitted, it is assumed to be
the same as "multi-cost-types".)
3.6.4. Testable Cost Type Names in IRD capabilities
In [RFC7285], when a resource's capability "constraints" is true, the
server accepts constraints on all the cost types listed in the "cost-
type-names" capability. However, some ALTO Servers may not be
willing to allow contraint tests on all available cost metrics.
Therefore the Multi-Cost ALTO protocol extension defines the
capability field "testable-cost-type-names". Like "cost-type-names",
it is an array of cost type names. If present, that resource only
allows constraint tests on the cost types in that list. "testable-
cost-type-names" MUST be a subset of "cost-type-names".
3.6.5. Legacy client issues
While a multi-cost-aware client will recognize the "testable-cost-
type-names" field, and will honor those restrictions, a legacy client
will not. Hence a legacy may send a request with a constraint test
on any of the cost types listed in "cost-type-names".
To avoid that problem, the "testable-cost-type-names" and "cost-
constraints" fields are mutually exclusive: a resource may define one
or the other capability, but MUST NOT define both. Thus a resource
that does not allow constraint tests on all cost metrics will set
"testable-cost-type-names" to the testable metrics, and will set
"cost-constraints" to "false". A multi-cost-aware client will
recognize the "testable-cost-type-names" field, and will realize that
its existence means the resource does allow (limited) contraint
tests, while a legacy client will think that resource does not allow
constraint tests at all. To allow legacy clients to use constraint
tests, the ALTO Server MAY define an additional resource with "cost-
constraints" set to "true" and "cost-type-names" set to the metrics
which can be tested.
In the IRD example below, the resource "filtered-cost-map-extended"
provides values for three metrics: "num-routingcost", "num-hopcount"
and "num-bwscore". The capability "testable-cost-type-names"
indicates that the server only allows constraints on "routingcost"
and "hopcount". A multi-cost capable client will see this
capability, and will limit its constraint tests to those metrics.
Because capability "cost-constraints" is false (by default), a legacy
client will not use constraint tests on this resource at all.
The second resource, "filtered-multicost-map", is similar to the
first, except that all the metrics it returns are testable.
Therefore it sets "cost-constraints" to "true", and does not set the
"testable-cost-type-names" field. A legacy client that needs a
constraint test will use this resource rather than the first. A
multi-cost-aware client that does not need to retrieve the "num-
bwscore" metric may use either resource.
"filtered-cost-map-extended" : {
"uri" : "http://alto.example.com/multi/extn/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ],
"uses" : [ "my-default-network-map" ],
"capabilities" : {
"max-cost-types" : 3,
"cost-type-names" : [ "num-routingcost",
"num-hopcount",
"num-bwscore"],
"testable-cost-type-names" : [ "num-routingcost",
"num-hopcount" ]
}
},
"filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ],
"uses" : [ "my-default-network-map" ],
"capabilities" : {
"cost-constraints" : true,
"max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost",
"num-hopcount"],
}
}
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 This section formally specifies the extensions to [RFC7285] to
RFC7285 to support Multi-Cost ALTO transactions. 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. Capabilities
The filtered cost map capabilities are extended with two new members:
o max-cost-types,
o testable-cost-type-names
The capability "max-cost-types" indicates whether this resource
supports the Multi-Cost ALTO extensions, and the capability
"testable-cost-type-names" allows the resource to restrict constraint
tests to a subset of the available cost types. The
FilteredCostMapCapabilities object in {11.3.2.4} is extended as
follows:
object {
JSONString cost-type-names<1..*>;
[JSONBool cost-constraints;]
[JSONNumber max-cost-types;]
[JSONString testable-cost-type-names<1..*>;]
} FilteredCostMapCapabilities;
cost-type-names and cost-constraints: As defined in {11.3.2.4} of
[RFC7285].
max-cost-types: If present with value N greater than 0, this
resource understands the multi-cost extensions in this document,
and can return a Multi Cost Map with any combination of N or fewer
cost types in the "cost-type-names" list. If omitted, the default
value is 0.
testable-cost-type-names: If present, the resource allows constraint
tests, but only on the cost type names in this array. Each name
in "testable-cost-type-names" MUST also be in "cost-type-names".
If "testable-cost-type-names" is present, the "cost-constraints"
capability MUST NOT be "true", and if "cost-constraints" is
"true", "testable-cost-type-names" MUST NOT be present. Thus if
"cost-constraints" is "true", the resource MUST accept constraint
tests on any cost type in "cost-type-names".
As discussed in Section 3.6.4, this capability is useful when a
server is unable or unwilling to implement constraint tests on all
cost types. As discussed in Section 3.6.5, "testable-cost-type-
names" and "cost-constraints" are mutually exclusive to prevent
legacy clients from issuing constraint tests on untestable cost
types.
4.1.2. Accept Input Parameters
The ReqFilteredCostMap object in {11.3.2.3} of [RFC7285] is extended The ReqFilteredCostMap object in {11.3.2.3} of [RFC7285] is extended
as follows: as follows:
object { object {
[CostType cost-type;] [CostType cost-type;]
[CostType multi-cost-types<1..*>;] [CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;] [CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;] [JSONString constraints<0..*>;]
[JSONString or-constraints<0..*>;] [JSONString or-constraints<0..*><0..*>;]
PIDFilter pids; PIDFilter pids;
} ReqFilteredCostMap; } ReqFilteredCostMap;
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: As defined in {11.3.2.3} of [RFC7285], with the
the additional requirement that the client MUST provide either additional requirement that the client MUST specify either "cost-
"cost-type" or "multi-cost-types", but MUST NOT provide both. type" or "multi-cost-types", but MUST NOT specify 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 thlis list. For each entry, valued costs for the cost types in this list. For each entry, the
the "cost-metric" and "cost-mode" fields MUST match one of 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 member "cost-type-names" of this
field (Section 4.1.2). The client MUST NOT use this field unless resource's "capabilities" field (Section 4.1.1). The client MUST
this resource's "max-cost-types" capability exists and has a value NOT use this field unless this resource's "max-cost-types"
greater than 0. The client MUST specify either "cost-type" or capability exists and has a value greater than 0. This field MUST
"multi-cost-types", but MUST NOT specify both. NOT have more than "max-cost-types" cost types. The client MUST
specify either "cost-type" or "multi-cost-types", but MUST NOT
testable-cost-types: A list of cost types for extended constraint specify both.
tests, as described for the "constraints" parameter. If present,
the cost types must be a subset of the cost types in the
resource's "testable-cost-type-names" capability (Section 4.1.2).
This feature allows a client to test a cost type whose actual Note that if "multi-cost-types" has one cost type, the values in
value is irrelevant, as long as it satisfies the tests. For the cost map will be arrays with one value.
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 testable-cost-types: A list of cost types used for extended
(Section 4.1.2) is defined with a value greater than 0, this constraint tests, as described for the "constraints" and "or-
parameter is an array of constraint tests where each test is constraints" parameters. These cost types must either be a subset
formulated as defined in {11.3.2.3} of [RFC7285]. of the cost types in the resource's "testable-cost-type-names"
capability (Section 4.1.1), or else, if the resource's capability
"cost-constraints" is true, a subset of the cost types in the
resource's "cost-type-names" capability
This parameter MUST NOT be specified if the "or-constraints" If "testable-cost-types" is omitted, it is assumed to have the
parameter is specified, or if the resource's "cost-constraints" cost types in "multi-cost-types" or "cost-type".
capability is false.
If this resource's "max-cost-types" capability is greater than 0, This feature is useful when a client wants to test a cost type
then this parameter MUST be an array of extended constraint tests, whose actual value is irrelevant, as long as it satisfies the
where each test consists of two or three entities separated by tests. For example, a client may want the cost metric
white space: (1) an optional cost type index, of the form "[#]", "routingcost" for those PID pairs whose "hopcount" is less than
with default value "[0]", (2) a required operator, and (3) a 10. The exact hopcount does not matter.
required target value. The operator and target value are as
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
present, assuming the index is "i", the test applies to the i'th
cost type in "testable-cost-types" (starting with index 0).
Otherwise, if the "multi-cost-types" parameter is present, the
test applies to the i'th cost type in "multi-cost-types". If
neither of those parameters is present, the test applies to the
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 a cost type in the resource's "testable-cost-type-names"
capability, or, if omitted, the resource's "cost-type-names"
capability.
As an example: suppose "multi-cost-types" has the single element constraints: If this resource's "max-cost-types" capability
"routingcost", "testable-cost-types" has the single element (Section 4.1.1) has the value 0 (or is not defined), this
"hopcount", and "constraints" has the single element "[0] le 5". parameter is as defined in {11.3.2.3} of [RFC7285]: an array of
This is equivalent to the database query "SELECT routingcost WHERE constraint tests related to each other by a logical AND. In this
hopcount <= 5". case it MUST NOT be specified unless the resource's "cost-
constraints" capability is "true".
Note that as long as this resource's "max-cost-types" capability If this resource's "max-cost-types" capability has a value greater
is greater than 0, a client may use the extended constraint tests than 0, then a "constraints" parameter with the array of extended
even on single-valued cost map requests, that is, requests with predicates [P1, P2, ...] is equivalent to an "or-constraints"
the "cost-type" parameter rather than "multi-cost-types". parameter with the value [[P1, P2, ...]]. In this case, the
"constraints" parameter MUST NOT be specified if the "or-
constraints" parameter is specified.
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 an extended constraint predicate as defined below. The
parameter. The constraint tests are interpreted as the logical OR "or-constraint" tests are interpreted as the logical OR of ANDs of
of ANDs. That is, the ALTO Server should return a cost point only predicates. That is, the ALTO Server should return a cost point
if it satisfies all constraints in any one of the sub-arrays. only if it satisfies all constraints in any one of the sub-arrays.
This parameter MUST NOT be specified unless this resource's "cost-
constraints" capability is "true" and its "max-cost-types" This parameter MAY be specified if this resource's "max-cost-
capability is defined with a value greater than 0 (Section 4.1.2). types" capability is defined with a value greater than 0
(Section 4.1.1), and if the resource allows constraint tests (the
resource's "cost-constraints" capability is "true" or its
"testable-cost-type-names" capability is not empty). Otherwise
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.
Note that if the "max-cost-types" capability has a value greater An extended constraint predicate consists of two or three entities
than 0, a client MAY use the "or-constraints" parameter together separated by white space: (1) an optional cost type index, of the
with the "cost-type" parameter. That is, if the client and server form "[#]", with default value "[0]", (2) a required operator, and
are both aware of the extensions in this document, a client MAY (3) a required target value. The operator and target value are as
use an "OR" test for a single-valued cost request. defined in {11.3.2.3} of [RFC7285]. The cost type index, i,
specifies the cost type to test. If the "testable-cost-type"
pids, srcs, dsts: As defined in {11.3.2.3} of [RFC7285]. parameter is present, the test applies to the i'th cost type in
"testable-cost-types", starting with index 0. Otherwise if the
4.1.2. Capabilities "multi-cost-types" parameter is present, the test applies to the
i'th cost type in that array. If neither parameters are present,
The FilteredCostMapCapabilities object in {11.3.2.4} is extended as the test applies to the cost type in the "cost-type" parameter, in
follows: which this case the index MUST be 0. Regardless of how the tested
cost type is selected, it MUST be in the resource's "testable-
object { cost-type-names" capability, or, if not present, in the "cost-
JSONString cost-type-names<1..*>; type-names" capability.
[JSONBool cost-constraints;]
[JSONNumber max-cost-types;]
[JSONString testable-cost-type-names<0..*>;]
} FilteredCostMapCapabilities;
max-cost-types: If present with value N greater than 0, this As an example, suppose "multi-cost-types" has the single element
resource understands the multi-cost extensions in this document, "routingcost", "testable-cost-types" has the single element
and can return a Multi Cost Map with any combination of N or fewer "hopcount", and "or-constraints" has the single element "[0] le
cost types in the "cost-type-names" list. If omitted, the default 5". This is equivalent to the database query "SELECT and provide
value is 0. routingcost WHERE hopcount <= 5".
testable-cost-type-names: If present, and if "cost-constraints" is Note that the index is optional, so a constraint test as defined
true, the resource only allows constraint tests on the cost type in {11.3.2.3}, such as "le 10", is equivalent to "[0] le 10".
names in this array. Each name in "testable-cost-type-names" MUST Thus legacy constraint tests are also legal extended constraint
be in "cost-type-names". If omitted or empty, the default is the tests.
value of the "cost-type-names" capability.
cost-type-names and cost-constraints: As defined in {11.3.2.4} of Also note that if the "max-cost-types" capability has a value
[RFC7285]. greater than 0, a client MAY use the "or-constraints" parameter
together with the "cost-type" parameter. That is, if the client
and server are both aware of the extensions in this document, a
client MAY use an "OR" test for a single-valued cost request.
Note that "testable-cost-type-names" allows an ALTO Server to provide pids, srcs, dsts: As defined in {11.3.2.3} of [RFC7285].
constraint tests on some, but not all, cost types.
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 replaced with the field o In "meta", the field "cost-type" is replaced with the field
"multi-cost-types", with the same value as the "multi-cost-types" "multi-cost-types", with the same value as the "multi-cost-types"
input parameter. 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.
4.2. Endpoint Cost Service Extensions 4.2. Endpoint Cost Service Extensions
This document extends the Endpoint Cost Service, as defined in This document extends the Endpoint Cost Service, as defined in
{11.5.1} of [RFC7285], by adding new input parameters and {11.5.1} of [RFC7285], by adding new input parameters and
capabilities, and by returning JSONArrays instead of JSONNumbers as capabilities, and by returning JSONArrays instead of JSONNumbers as
the cost values. the cost values.
The media type (11.5.1.1}, HTTP method (11.5.1.2} and "uses" The media type (11.5.1.1}, HTTP method (11.5.1.2} and "uses"
specifications (11.5.1.5} are unchanged. specifications (11.5.1.5} are unchanged.
4.2.1. Accept Input Parameters 4.2.1. Capabilities
The extensions to the Endpoint Cost Service capabilities are
identical to the extensions to the Filtered Cost Map (see
Section 4.1.1).
4.2.2. Accept Input Parameters
The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended
as follows: as follows:
object { object {
[CostType cost-type;] [CostType cost-type;]
[CostType multi-cost-types<1..*>;] [CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;] [CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;] [JSONString constraints<0..*>;]
[JSONString or-constraints<0..*>;] [JSONString or-constraints<0..*><0..*>;]
EndpointFilter endpoints; EndpointFilter endpoints;
} ReqFilteredCostMap; } ReqFilteredCostMap;
object { object {
[TypedEndpointAddr srcs<0..*>;] [TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;] [TypedEndpointAddr dsts<0..*>;]
} EndpointFilter; } EndpointFilter;
cost-type: As defined in {11.5.1.3} of [RFC7285], with the cost-type: As defined in {11.5.1.3} of [RFC7285], with the
additional requirement that the client MUST specify either "cost- additional requirement that the client MUST specify either "cost-
type" or "multi-cost-types", but not both. type" or "multi-cost-types", but MUST NOT specify 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 this list. For each entry, the valued costs for the cost types in this list. For each entry, the
"cost-metric" and "cost-mode" fields MUST match one of 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.2.2). The client MUST NOT use this field unless field (Section 4.2.1). 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. Although optional, the client MUST specify either greater than 0. This field MUST NOT have more than "max-cost-
"cost-type" or "multi-cost-types". The client MUST NOT specify types" cost types. The client MUST specify either "cost-type" or
both. "multi-cost-types", but MUST NOT specify both.
Note that if "multi-cost-types" has one cost type, the values in
the cost map will be arrays with one value.
testable-cost-types, constraints, or-constraints: Defined testable-cost-types, constraints, or-constraints: Defined
equivalently to the corresponding input parameters for an extended equivalently to the corresponding input parameters for an extended
Filtered Cost Map (Section 4.1.1). Filtered Cost Map (Section 4.1.2).
endpoints, srcs, dsts: As defined in {11.5.1.3} of [RFC7285]. endpoints, srcs, dsts: As defined in {11.5.1.3} of [RFC7285].
4.2.2. Capabilities
The extensions to the Endpoint Cost Service capabilities are
identical to the extensions to the Filtered Cost Map (see
Section 4.1.2).
4.2.3. Response 4.2.3. Response
The extensions to the Endpoint Cost Service response are similar to The extensions to the Endpoint Cost Service response are similar to
the extensions to the Filtered Cost Map response (Section 4.1.3). the extensions to the Filtered Cost Map response (Section 4.1.3).
Specifically, if the client specifies the "cost-type" input Specifically, if the client specifies the "cost-type" input
parameter, the response is exactly as defined in {11.5.1.6} of parameter, the response is exactly as defined in {11.5.1.6} of
[RFC7285]. If the client provides the "multi-cost-types" instead, [RFC7285]. If the client provides the "multi-cost-types" instead,
then the response is changed as follows: then the response is changed as follows:
o In "meta", the field "cost-type" is replaced with the field o In "meta", the field "cost-type" is replaced with the field
"multi-cost-types", with the same value as the "multi-cost-types" "multi-cost-types", with the same value as the "multi-cost-types"
input parameter. 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.
5. Examples 5. Examples
5.1. Information Resource Directory 5.1. Information Resource Directory
The following is an example of an ALTO Server's Information Resource The following is an example of an ALTO Server's Information Resource
Directory. In addition to Network and Cost Map resources, it defines Directory. In addition to Network and Cost Map resources, it defines
a Filtered Cost Map and an Endpoint Cost Service, both which two Filtered Cost Map and an Endpoint Cost Service, which all
understand the multi-cost extensions. understand the multi-cost extensions.
GET /directory HTTP/1.1 GET /directory HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TODO] Content-Length: [TODO]
Content-Type: application/alto-directory+json Content-Type: application/alto-directory+json
skipping to change at page 15, line 23 skipping to change at page 18, line 8
"default-alto-network-map" : "my-default-network-map", "default-alto-network-map" : "my-default-network-map",
"cost-types" : { "cost-types" : {
"num-routing" : { "num-routing" : {
"cost-mode" : "numerical", "cost-mode" : "numerical",
"cost-metric" : "routingcost" "cost-metric" : "routingcost"
}, },
"num-hopcount" : { "num-hopcount" : {
"cost-mode" : "numerical", "cost-mode" : "numerical",
"cost-metric" : "hopcount" "cost-metric" : "hopcount"
}, },
"num-bwscore" : {
"cost-mode" : "numerical",
"cost-metric" : "bandwidthscore"
},
..... .....
Other ALTO cost types as described Other ALTO cost types as described in RFC7285
in current ALTO Protocol
..... .....
} }
}, },
"resources" : { "resources" : {
"my-default-network-map" : { "my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap", "uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json" "media-type" : "application/alto-networkmap+json"
}, },
"numerical-routing-cost-map" : { "numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num-routing", "uri" : "http://alto.example.com/costmap/num-routing",
"media-types" : [ "application/alto-costmap+json" ], "media-types" : [ "application/alto-costmap+json" ],
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-type-names" : [ "num-routing" ] "cost-type-names" : [ "num-routing" ]
} }
}, },
"numerical-hopcount-cost-map" : { "numerical-hopcount-cost-map" : {
"uri" : "http://alto.example.com/costmap/num-hopcount", "uri" : "http://alto.example.com/costmap/num-hopcount",
"media-types" : [ "application/alto-costmap+json" ], "media-types" : [ "application/alto-costmap+json" ],
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-type-names" : [ "num-hopcount" ] "cost-type-names" : [ "num-hopcount" ]
} }
}, },
......... .........
Other resources as described in RFC7285
.........
"filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ],
"uses" : [ "my-default-network-map" ],
"capabilities" : {
"cost-constraints" : true,
"max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost",
"num-hopcount" ]
}
And other information resources as described in RFC7285 },
......... "filtered-cost-map-extended" : {
"filtered-multicost-map" : { "uri" : "http://alto.example.com/multi/extn/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,
"cost-constraints" : true, "cost-type-names" : [ "num-routingcost",
"max-cost-types" : 2, "num-hopcount",
"cost-type-names" : [ "num-routingcost", "num-bwscore"],
"num-hopcount" ], "testable-cost-type-names" : [ "num-routingcost",
"testable-cost-type-names" : [ "num-routingcost", "num-hopcount" ]
"num-hopcount" ] }
} },
}, "endpoint-multicost-map" : {
"endpoint-multicost-map" : { "uri" : "http://alto.example.com/multi/endpointcost/lookup",
"uri" : "http://alto.example.com/multi/endpointcost/lookup", "media-types" : [ "application/alto-endpointcost+json" ],
"media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ],
"accepts" : [ "application/alto-endpointcostparams+json" ], "uses" : [ "my-default-network-map" ],
"uses" : [ "my-default-network-map" ], "capabilities" : {
"capabilities" : { "cost-constraints" : true,
"cost-constraints" : true, "max-cost-types" : 2,
"max-cost-types" : 2, "cost-type-names" : [ "num-routingcost",
"cost-type-names" : [ "num-routingcost", "num-hopcount" ]
"num-hopcount" ],
"testable-cost-type-names" : [ "num-routingcost",
"num-hopcount" ]
} }
} }
} }
} }
5.2. Multi-Cost Filtered Cost Map: Example #1 5.2. Multi-Cost Filtered Cost Map: Example #1
This example illustrates a static multi-cost ALTO transaction, where This example illustrates a simple multi-cost ALTO transaction. The
the utilized Cost Types all have static values. We assume that the ALTO Server provides two Cost Types, "routingcost" and "hopcount",
Cost Types available at the ALTO Server are "routingcost" and both in "numerical" mode. The ALTO Server does not know the value of
"hopcount" and the "numerical" mode is available for both of them. the "routingcost" between PID2 and PID3, and hence uses "null" for
The "routingcost" may be based on monetary considerations where as those costs.
the "hopcount" is used to report on the path delay. We also assume
that ALTO server does not know the value of the "routingcost" between
PID2 and PID3, and hence uses 'null' for those costs.
POST /multi/costmap/filtered" HTTP/1.1 POST /multi/costmap/filtered" HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: ###
{ {
"multi-cost-types": [ "multi-cost-types": [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
], ],
"pids" : { "pids" : {
"srcs" : [ ], "srcs" : [ ],
"dsts" : [ ] "dsts" : [ ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TODO]
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
Content-Length: ###
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ "dependent-vtags" : [
{"resource-id": "my-default-network-map", {"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
} }
], ],
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
] ]
} }
} }
"cost-map" : { "cost-map" : {
"PID1": { "PID1":[1,0], "PID2":[4,23], "PID3":[10,5] }, "PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] },
"PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] }, "PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] },
"PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] }
} }
} }
5.3. Multi-Cost Filtered Cost Map: Example #2 5.3. Multi-Cost Filtered Cost Map: Example #2
This is an example of using constraints to restrict the returned This example uses constraints to restrict the returned source/
source/destination PID pairs to those with "routingcost" between 5 destination PID pairs to those with "routingcost" between 5 and 10,
and 10, or "hopcount" equal to 0. or "hopcount" equal to 0.
POST multi/multicostmap/filtered HTTP/1.1 POST /multi/costmap/filtered HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Type: application/alto-costmapfilter+json
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: ###
{ {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
], ],
"or-constraints" : [ ["[0] ge 5", "[0] le 10"], "or-constraints" : [ ["[0] ge 5", "[0] le 10"],
["[1] eq 0"] ] ["[1] eq 0"] ]
"pids" : { "pids" : {
"srcs" : [ "PID1", "PID2" ], "srcs" : [ "PID1", "PID2" ],
"dsts" : [ "PID1", "PID2", "PID3" ] "dsts" : [ "PID1", "PID2", "PID3" ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
Content-Length: ###
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ "dependent-vtags" : [
{"resource-id": "my-default-network-map", {"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
} }
], ],
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
skipping to change at page 18, line 48 skipping to change at page 21, line 50
"cost-map" : { "cost-map" : {
"PID1": { "PID1": [1,0], "PID3": [10,5] }, "PID1": { "PID1": [1,0], "PID3": [10,5] },
"PID2": { "PID2": [1,0] } "PID2": { "PID2": [1,0] }
} }
} }
5.4. Multi-Cost Filtered Cost Map: Example #3 5.4. Multi-Cost Filtered Cost Map: Example #3
This example uses extended constraints to limit the response to cost This example uses extended constraints to limit the response to cost
points with ("routingcost" <= 10 and "hopcount" <= 2), or else points with ("routingcost" <= 10 and "hopcount" <= 2), or else
("routingcost" <= 2 and "hopcount" <= 6). Unlike the previous ("routingcost" <= 3 and "hopcount" <= 6). Unlike the previous
example, the client is only interested in the "routingcost" cost example, the client is only interested in the "routingcost" cost
type, and uses the "cost-type" parameter instead of "multi-cost- type, and uses the "cost-type" parameter instead of "multi-cost-
types" to tell the server to return scalar costs instead of array types" to tell the server to return scalar costs instead of array
costs: costs:
POST multi/multicostmap/filtered HTTP/1.1 POST /multi/multicostmap/filtered HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Type: application/alto-costmapfilter+json
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: ###
{ {
"cost-type" : { "cost-type" : {
"cost-mode": "numerical", "cost-metric": "routingcost" "cost-mode": "numerical", "cost-metric": "routingcost"
}, },
"testable-cost-types" : [ "testable-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
], ],
"or-constraints": [ "or-constraints": [
skipping to change at page 19, line 29 skipping to change at page 23, line 4
], ],
"or-constraints": [ "or-constraints": [
["[0] le 10", "[1] le 2"], ["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"] ["[0] le 3", "[1] le 6"]
], ],
"pids" : { "pids" : {
"srcs" : [ ], "srcs" : [ ],
"dsts" : [ ] "dsts" : [ ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
Content-Length: ###
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ "dependent-vtags" : [
{"resource-id": "my-default-network-map", {"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
} }
], ],
"cost-type" : { "cost-type" : {
"cost-mode": "numerical", "cost-metric": "routingcost" "cost-mode": "numerical", "cost-metric": "routingcost"
} }
} }
"cost-map" : { "cost-map" : {
"PID1": { "PID1": 1, "PID3": 10 }, "PID1": { "PID1": 1, "PID3": 10 },
"PID2": { "PID2": 1 }, "PID2": { "PID2": 1 },
"PID3": { "PID3": 1 } "PID3": { "PID3": 1 }
} }
} }
5.5. Endpoint Cost Service 5.5. Multi-Cost Filtered Cost Map: Example #4
This example uses extended constraints to limit the response to cost
points with ("routingcost" <= 10 and "hopcount" <= 2), or else
("routingcost" <= 3 and "hopcount" <= 6). In this example, the
client is interested in the "routingcost" and "bandwidthscore" cost
metrics, but not in the "hopcount" metric:
POST /multi/extn/costmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: ###
{
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "bandwidthscore"}
],
"testable-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"}
],
"or-constraints": [
["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"]
],
"pids" : {
"srcs" : [ ],
"dsts" : [ ]
}
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: ###
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "bandwidthscore"}
]
}
"cost-map" : {
"PID1": { "PID1": [1,16] "PID3": [10,19] },
"PID2": { "PID2": [1,8] },
"PID3": { "PID3": [1,19] }
}
}
5.6. Endpoint Cost Service
This example uses the Endpoint Cost Service to retrieve the This example uses the Endpoint Cost Service to retrieve the
"routingcost" and "hopcount" for selected endpoints, limiting the "routingcost" and "hopcount" for selected endpoints, limiting the
response to costs with either low hopcount and reasonable routingcost response to costs with either low hopcount and reasonable routingcost
(hopcount <= 2 and routingcost <= 10), or else low routingcost and (hopcount <= 2 and routingcost <= 10), or else low routingcost and
reasonable hopcount (routingcost <= 3 and hopcount <= 6). reasonable hopcount (routingcost <= 3 and hopcount <= 6).
POST /multi/endpointcost/lookup HTTP/1.1 POST /multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: [TODO]
Content-Type: application/alto-endpoincostparams+json
Accept: application/alto-endpointcost+json, Accept: application/alto-endpointcost+json,
application/alto-error+json application/alto-error+json
Content-Type: application/alto-endpoincostparams+json
Content-Length: ###
{ {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
], ],
"or-constraints": [ "or-constraints": [
["[0] le 10", "[1] le 2"], ["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"] ["[0] le 3", "[1] le 6"]
], ],
"endpoints" : { "endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ], "srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ],
"dsts": [ "dsts": [
"ipv4:192.0.2.89", "ipv4:192.0.2.89",
"ipv4:198.51.100.34", "ipv4:198.51.100.34",
"ipv4:203.0.113.45" "ipv4:203.0.113.45",
"ipv6:2001:db8::10"
] ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TODO] Content-Length: ###
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta" : { "meta" : {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
] ]
} }
"endpoint-cost-map" : { "endpoint-cost-map" : {
"ipv4:192.0.2.2": { "ipv4:192.0.2.2": {
"ipv4:192.0.2.89": [15, 5], "ipv4:192.0.2.89": [15, 5],
"ipv4:203.0.113.45": [4, 23] "ipv4:203.0.113.45": [4, 23]
}
"ipv6:2001:db8::1:0": {
"ipv4:198.51.100.34": [16, 5],
"ipv6:2001:db8::10": [10, 2]
} }
} }
} }
6. IANA Considerations 6. IANA Considerations
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 Richard Alimi, Vijay Gurbani, Dave The authors would like to thank Richard Alimi, Fred Baker, Dhruv
Mac Dysan, Dhruv Dhodi, Young Lee, Richard Yang and Wang Xin for Dhodi, Vijay Gurbani, Gao Kai, Dave Mac Dysan, Young Lee, Richard
fruitful discussions and feedback on this document and previous Yang, Qiao Xiang and Wang Xin for fruitful discussions and feedback
versions. 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", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 22, line 46 skipping to change at page 27, line 12
Traffic Optimization (ALTO) Protocol", RFC 7285, September Traffic Optimization (ALTO) Protocol", RFC 7285, 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.
Authors' Addresses Authors' Addresses
Sabine Randriamasy (editor) Sabine Randriamasy
Alcatel-Lucent/Bell Labs Nokia Bell Labs
Route de Villejust Route de Villejust
NOZAY 91460 NOZAY 91460
FRANCE FRANCE
Email: Sabine.Randriamasy@alcatel-lucent.com Email: Sabine.Randriamasy@nokia-bell-labs.com
Wendy Roome (editor)
Alcatel-Lucent/Bell Labs Wendy Roome
Nokia 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@nokia-bell-labs.com
Nico Schwan Nico Schwan
Thales Deutschland Thales Deutschland
Lorenzstrasse 10 Lorenzstrasse 10
Stuttgart 70435 Stuttgart 70435
Germany Germany
Email: nico.schwan@thalesgroup.com Email: nico.schwan@thalesgroup.com
 End of changes. 86 change blocks. 
319 lines changed or deleted 525 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/