One document matched: draft-roome-alto-interop-ietf93-00.xml
<?xml version="1.0" encoding="US-ASCII"?> <!-- -*- fill-column: 120; -*- -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-roome-alto-interop-ietf93-00" ipr="trust200902">
<front>
<title abbrev="ALTO Interop">Interoperability Testing of the ALTO Protocol</title>
<author fullname="Wendy Roome" initials="W." surname="Roome">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>600 Mountain Ave, Rm 3B-324</street>
<city>Murray Hill</city>
<region>NJ</region>
<code>07974</code>
<country>USA</country>
</postal>
<phone>+1-908-582-7974</phone>
<email>w.roome@alcatel-lucent.com</email>
</address>
</author>
<author fullname="GuohaiChen" initials="G." surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region> </region>
<code></code>
<country>China</country>
</postal>
<phone>+8615805180590</phone>
<email>chenguohai@huawei.com chenguohai67@outlook.com</email>
</address>
</author>
<date year="2015" month="June" />
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>alto</keyword>
<keyword>interoperability</keyword>
<keyword>bakeoff</keyword>
<abstract>
<t>The Application-Layer Traffic Optimization (ALTO) protocol is
designed to allow entities with knowledge about the network
infrastructure to export such information to applications that
need to choose one or more endpoints to connect to among large
sets of logically equivalent ones. This document defines
a data set that may be used to test the functionality
and interoperability of ALTO clients and servers.</t>
</abstract>
</front>
<middle>
<section title="Overview" anchor="overview">
<t>The Application-Layer Traffic Optimization (ALTO) protocol is
designed to allow entities with knowledge about the network
infrastructure to export such information to applications that
need to choose one or more endpoints to connect to among large
sets of logically equivalent ones. </t>
<t>This document defines procedures to
test the functionality and interoperability of ALTO clients and servers.</t>
<t>This document is informational and is NOT NORMATIVE on any
aspects of the ALTO protocol. The normative behavior of ALTO
entities is prescribed in <xref target="RFC7285"/>.</t>
<t><xref target="server-data"/> defines the network maps,
cost maps and other data necessary to provision an ALTO server.
This ensures that all tested servers will return the same results,
so a client may verify that a server is operating correctly.
<xref target="server-resources"/> defines the required and optional
resources for an ALTO server to provide.
<xref target="client"/> describes the actions expected from a client.
<xref target="error-tests"/> describes a set of invalid client requests,
to verify that a server can respond correctly to client errors.</t>
<t>While every effort has been made to catalogue representative test
cases, this document does not attempt to codify every test case
that arises in ALTO. The aim of the document is to focus on
areas that highlight the key offerings of the ALTO protocol.</t>
</section> <!-- overview -->
<section title="Server Data" anchor="server-data">
<t>This section defines the data necessary to provision a tested ALTO server
in a uniform manner. First it defines a default network map,
and associated cost maps for the "routingcost" and "hopcount" metrics.
Next it defines an optional alternate network map,
along with "routingcost" and "hopcount" costs for that map.
Finally it defines a set of optional endpoint properties.</t>
<t><xref target="json-maps"/> gives network and cost map data
defined in this section formatted in JSON.</t>
<section title="Default Network Map And Cost Maps">
<t>Every tested ALTO server MUST provide a default network map
with the PIDs defined below:</t>
<figure anchor="fig:def-netmap" title="Default Network Map">
<artwork><![CDATA[
PID IP Address Block
---------------------------------------
mine 100.0.0.0/8
mine1 100.0.0.0/10
mine1a 100.0.1.0/24, 100.0.64.0/24, 100.0.192.0/24
mine2 100.64.0.0/10
mine3 100.128.0.0/10
peer1 128.0.0.0/16, 130.0.0.0/16, 2001:DB8:0000::/33
peer2 129.0.0.0/16, 131.0.0.0/16, 2001:DB8:8000::/33
tran1 132.0.0.0/16
tran2 135.0.0.0/16
default 0.0.0.0/0, ::0/0
loopback 127.0.0.0/8, ::1/128
linklocal 169.254.0.0/16, ff80::/10
private 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, fc00::/7
]]></artwork>
</figure>
<t>Each ALTO server MUST provide a cost map for the "routingcost"
metric. The following table presents the numerical values
for those costs. If a server provides a numerical-mode cost map,
it MUST use these values. If a server provides an ordinal-mode cost map,
the server may use whatever values it wants,
provided the ordinal values preserve the order of the numerical values.</t>
<figure anchor="fig:def-routingcost" title=""routingcost" Numerical Cost Map">
<artwork><![CDATA[
default linklocal loopback mine mine1 mine1a mine2 mine3
default 1.0 - - 75.0 75.0 75.0 75.0 75.0
linklocal - 1.0 - - - - - -
loopback - - 0.0 - - - - -
mine 75.0 - - 1.0 15.0 15.0 15.0 15.0
mine1 75.0 - - 15.0 1.0 2.5 5.0 7.0
mine1a 75.0 - - 15.0 2.0 1.0 7.0 9.0
mine2 75.0 - - 15.0 5.5 7.0 1.0 6.0
mine3 75.0 - - 15.0 7.0 9.0 6.0 1.0
peer1 - - - 30.0 20.0 22.0 23.0 25.0
peer2 - - - 30.0 25.0 24.0 25.0 28.0
private 75.0 - - - - - - -
tran1 - - - 50.0 40.0 42.0 43.0 45.0
tran2 - - - 50.0 45.0 48.0 46.0 49.0
peer1 peer2 private tran1 tran2
default - - 75.0 - -
linklocal - - - - -
private - - - - -
mine 30.0 30.0 - 50.0 50.0
mine1 20.0 25.0 - 40.0 45.0
mine1a 22.0 24.0 - 42.0 48.0
mine2 23.0 25.0 - 43.0 46.0
mine3 25.0 28.0 - 45.0 49.0
peer1 1.0 - - - -
peer2 - 1.0 - - -
private - - 1.0 - -
tran1 - - - 1.0 -
tran2 - - - - 1.0
]]></artwork>
</figure>
<t>Note that this is a partial cost map, in that it does not
define a cost for every source and destination PID.</t>
<t>Each ALTO server MAY provide a cost map for the "hopcount" metric.
The following table gives the numerical values.
As with "routingcost", a numerical-mode cost map MUST use these values,
and an ordinal-mode cost map may use any values consistent with this ordering.</t>
<figure anchor="fig:def-hopcount" title=""hopcount" Numerical Cost Map">
<artwork><![CDATA[
default linklocal loopback mine mine1 mine1a mine2 mine3
default 1 - - 10 10 10 10 10
linklocal - 1 - - - - - -
loopback - - 0 - - - - -
mine 10 - - 1 3 3 3 3
mine1 10 - - 3 1 2 2 2
mine1a 10 - - 3 2 1 2 3
mine2 10 - - 3 2 2 1 2
mine3 10 - - 3 2 3 2 1
peer1 - - - 5 4 5 4 4
peer2 - - - 6 5 6 5 5
private 10 - - - - - - -
tran1 - - - 8 6 7 6 6
tran2 - - - 8 7 8 7 7
peer1 peer2 private tran1 tran2
default - - 10 - -
mine 5 6 - 8 8
mine1 4 5 - 6 7
mine1a 5 6 - 7 8
mine2 4 5 - 6 7
mine3 4 5 - 6 7
peer1 1 - - - -
peer2 - 1 - - -
private - - 1 - -
tran1 - - - 1 -
tran2 - - - - 1
]]></artwork>
</figure>
</section>
<section title="Alternate Network Map And Cost Maps">
<t>Every tested ALTO server MAY provide an alternate,
or secondary, network map with the PIDs defined below:</t>
<figure anchor="fig:alt-netmap" title="Alternate Network Map">
<artwork><![CDATA[
PID IP Address Block
---------------------------------------
dc1 101.0.0.0/16
dc2 102.0.0.0/16
dc3 103.0.0.0/16
dc4 104.0.0.0/16
user1 201.0.0.0/16
user2 202.0.0.0/16
user3 203.0.0.0/16
user4 204.0.0.0/16
default 0.0.0.0/0, ::0/0
loopback 127.0.0.0/8, ::1/128
linklocal 169.254.0.0/16, ff80::/10
private 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, fc00::/7
]]></artwork>
</figure>
<t>Each ALTO server MAY provide a cost map for the "routingcost"
metric for the alternate network map. The following table presents the numerical values
for those costs. If a server provides a numerical-mode cost map,
it MUST use these values. If a server provides an ordinal-mode cost map,
the server may use whatever values it wants,
provided the ordinal values preserve the order of the numerical values.</t>
<figure anchor="fig:alt-routingcost" title=""routingcost" Numerical Cost Map">
<artwork><![CDATA[
dc1 dc2 dc3 dc4 default user1 user2 user3 user4
dc1 0.0 5.0 5.0 5.0 50.0 10.0 20.0 30.0 40.0
dc2 5.0 0.0 5.0 5.0 50.0 20.0 10.0 20.0 30.0
dc3 5.0 5.0 0.0 5.0 50.0 30.0 20.0 10.0 20.0
dc4 5.0 5.0 5.0 0.0 50.0 40.0 30.0 20.0 10.0
default 50.0 50.0 50.0 50.0 0.0 - - - -
user1 10.0 20.0 30.0 40.0 - 0.0 - - -
user2 20.0 10.0 20.0 30.0 - - 0.0 - -
user3 30.0 20.0 10.0 20.0 - - - 0.0 -
user4 40.0 30.0 20.0 10.0 - - - - 0.0
]]></artwork>
</figure>
<t>Note that this is a partial cost map, in that it does not
define a cost for every source and destination PID.</t>
<t>Each ALTO server MAY provide a cost map for the "hopcount" metric.
The following table gives the numerical values.
As with "routingcost", a numerical-mode cost map MUST use these values,
and an ordinal-mode cost map may use any values consistent with this ordering.</t>
<figure anchor="fig:alt-hopcount" title=""hopcount" Numerical Cost Map">
<artwork><![CDATA[
dc1 dc2 dc3 dc4 default user1 user2 user3 user4
dc1 0 1 1 1 8 3 4 5 6
dc2 1 0 1 1 8 4 3 4 5
dc3 1 1 0 1 8 5 4 3 4
dc4 1 1 1 0 8 6 5 4 3
default 8 8 8 8 0 - - - -
user1 3 4 5 6 - 0 - - -
user2 4 3 4 5 - - 0 - -
user3 5 4 3 4 - - - 0 -
user4 6 5 4 3 - - - - 0
]]></artwork>
</figure>
</section>
<section title="Endpoint Properties">
<t>An ALTO server may provide the private endpoint property "priv:ietf-type"
with the following values for endpoints in the indicated address blocks:</t>
<figure anchor="fig:endpoint-props" title="Values for "priv:ietf-type" endpoint property">
<artwork><![CDATA[
Value IP Address Block
---------------------------------------
mine 100.0.0.0/8
peer 128.0.0.0/6, 2001:DB8::/32
transit 132.0.0.0/16, 135.0.0.0/16
]]></artwork>
</figure>
</section>
</section> <!-- server data -->
<section title="Server Resources and Configuration" anchor="server-resources">
<t>An ALTO server MUST provide the following resources,
as required by <xref target="RFC7285"/>:</t>
<t><list style="symbols">
<t>An Information Resource Directory (IRD) which describes
all of the server's resources.</t>
<t>A Network Map resource for the default network
defined above.</t>
<t>A Cost Map resource for the "routingcost" metric
for the default network map.
The mode may be either "numerical" or "ordinal".
If "numerical", the values MUST be identical
to those defined above. If "ordinal", the server can use
whatever values it wants, but the ordering
MUST be consistent with the ordering of the "numerical" values.</t>
<t>An Endpoint Property Service for the "pid" property
for the default network map.</t>
</list></t>
<t>A server MAY provide whatever additional resources it desires,
as long as they are consistent with the network maps,
cost maps and endpoint properties defined in <xref target="server-data"/>.
In particular, a server may provide:</t>
<t><list style="symbols">
<t>An additional Network Map resource,
using the PIDs and address prefixes
for the alternate network map defined above.</t>
<t>Cost Map resources for the "routingcost" and/or "hopcount" metrics,
in either "numerical" or "ordinal" modes,
using the values defined above.</t>
<t>Filtered Network Map resources
for either or both network maps.</t>
<t>Filtered Cost Map resources for any combination
of "routingcost" and "hopcount" metrics,
in either "numerical" and "ordinal" modes,
for either or both network maps.
The resources may or may not accept constraint tests.</t>
<t>Endpoint Cost Service(s) or any combination
of "routingcost" and "hopcount" metrics,
in either "numerical" and "ordinal" modes.
The cost values MUST be consistent with those
for the default network map.
The resources may or may not accept constraint tests.</t>
<t>Endpoint Property Service(s) for the custom
endpoint properties defined above.</t>
</list></t>
<t>However, a server MUST NOT
provide more than the two network maps defined in this document.
This restriction simplifies testing,
because it allows a client to automatically identify the alternate
network map (e.g., any network map which is not the default
must be the alternate network). If servers could offer three
or more network maps, a client would have to be provisioned
with the resource id of the alternate network map.</t>
<t>Note that if a server provides a Network Map resource
for the alternate network map, <xref target="RFC7285"/>
requires the server to also provide a Cost Map resource
for the "routingcost" metric, in either "numerical" or "ordinal" mode,
and an Endpoint Property Service for that network map's "pid" property.</t>
<t>A server MAY structure the IRD however it wants.
In particular, a server may</t>
<t><list style="symbols">
<t>Use secondary IRDs which the root IRD references.</t>
<t>Use arbitrary resource IDs and cost type names.</t>
<t>Use arbitrary URIs, in any recognized URI format.</t>
<t>Provide multiple versions of POST-mode resources.
For example, if a server provides the secondary network map,
it must provide an Endpoint Property Service for the
"pid" properties for both maps. A server may provide
one EPS for both properties, or a separate EPS for each property.</t>
</list></t>
</section>
<section title="Client Actions" anchor="client">
<t>When given the URI for an ALTO server's IRD,
an ALTO client should read the IRD,
and for each resource that it recognizes,
verify that the server returns the correct response.
Note that most of the data the server returns
is determined by the network maps, cost maps
and property values specified in <xref target="server-data"/>,
and hence can be verified by a client.
Some data cannot be determined a priori
(e.g., resource id and tag of a network map),
but a client can verify their consistency
(e.g., a cost map's dependent-vtag field should match
the vtag field of the associated network map).</t>
<t>It is expected that not every client will be able
recognize and verify every possible resource.
However, each client MUST be able to verify
the default network map and the associated "routingcost" cost map.
In particular, although clients are not required
to recognize the alternate network map,
if presented with an IRD with two network maps,
every client MUST be able to distinguish the default network map,
and its associated cost map, from the alternate network map.</t>
<t>Ideally clients should be scripted.
That is, when given the URI for a server,
an ideal client would verify the server automatically,
without further operator intervention.
A client should log the resources it tested,
and clearly highlight any response the client considered incorrect.</t>
<t>The HTTP GET-mode resources (Network Map and Cost Map)
do not require client input, and hence testing is straight-forward:
the client sends the appropriate HTTP GET request,
and verifies the response.</t>
<t>However, POST-mode resources, such as Filtered Cost Maps
and Endpoint Property Services, require client input.
The following sections present recommended input parameters
for various resources, and clients SHOULD implement as many
of these tests as possible. Clients MAY add additional tests,
and are encouraged to do so.</t>
<section title="Filtered Network Map Tests">
<t><list style="symbols">
<t>Empty "pid" array, omitted or empty "address-types" array.
The server should return the entire network map.</t>
<t>Empty "pids" array, "address-types" array containing just "ipv6".
The server should return PIDs with ipv6 addresses,
and only those PIDs.</t>
<t>"pids" array with one or more non-existent PID names,
such as "not-a-pid". The server should return an empty network map.</t>
<t>"pids" array with a set of valid PID names (client's choice),
plus one or more non-existent PID names. The server should
return the valid PIDs and ignore the invalid ones.</t>
</list></t>
</section>
<section title="Filtered Cost Map Tests">
<t>All tests require an appropriate "cost-type" parameter.
At a minimum, clients should run these tests for the "routingcost" metric
for the default network map. If possible, clients should also
run these tests for the "hopcount" metric and the alternate network map.</t>
<t>Clients should remember that when testing "ordinal" costs,
any values are acceptable as long as they are consistent with
the order of the "numerical" costs defined in <xref target="server-data"/>.
Clients are also reminded that ordinal values are only comparable
to other values in the same request, and a server may recalculate ordinal values
for each request. Hence the same cost point may have ordinal value "6"
in a full cost map, but have value "1" in a filtered cost map.</t>
<t><list style="symbols">
<t>Empty "srcs" and "dsts" arrays.
The server should return the entire cost map.</t>
<t>Empty "srcs" array, "dsts" array with one or more valid PIDs.
The server should return costs from all PIDs to the
specified destination PIDs.</t>
<t>Empty "dsts" array, "srcs" array with one or more valid PIDs.
The server should return costs from the
specified source PIDs to all destination PIDs.</t>
<t>"srcs" and "dsts" arrays with only non-existent PID names.
The server should return an empty cost map.</t>
<t>"srcs" and "dsts" arrays with a set of valid PID names (client's choice),
plus one or more non-existent PID names in one or the arrays.
The server should return costs for the valid PIDs
and ignore the non-existent ones.</t>
<t>The two-element constraint test "ge 20", "le 30"
for the numerical "routingcost" for the default network map,
with empty "srcs" and "dsts" arrays
(assuming that resource allows constraints, of course).
The server should return the all costs in the range, namely:
<figure anchor="fig:client-fcm-constraint" title="Filtered Cost Map Constraint Test">
<artwork><![CDATA[
mine mine1 mine1a mine2 mine3 peer1 peer2
mine - - - - - 30.0 30.0
mine1 - - - - - 20.0 25.0
mine1a - - - - - 22.0 24.0
mine2 - - - - - 23.0 25.0
mine3 - - - - - 25.0 28.0
peer1 30.0 20.0 22.0 23.0 25.0 - -
peer2 30.0 25.0 24.0 25.0 28.0 - -
]]></artwork></figure></t>
</list></t>
</section>
<section title="Endpoint Property Service Tests">
<t>Every client should verify that the server's EPS resource
for the default network's "pid" property
returns the correct PID name for a representative set of endpoint addresses.
If possible, clients should also verify the alternate network's "pid" property
and the "priv:ietf-type" property.</t>
<t>The table below gives the expected values for a set of addresses.
Clients are encouraged to test other addresses as well.</t>
<t>
<figure anchor="fig:client-eps"
title="EPS Test Addresses And Property Values">
<artwork><![CDATA[
Address def.pid alt.pid priv:ietf-type
---------------- ------- ------- --------------
ipv4:0.0.0.1 default default -
ipv4:10.1.2.3 private private -
ipv4:100.0.0.1 mine1 default mine
ipv4:100.0.1.1 mine1a default mine
ipv4:100.0.192.1 mine1a default mine
ipv4:100.0.64.1 mine1a default mine
ipv4:100.130.0.1 mine3 default mine
ipv4:100.200.0.1 mine default mine
ipv4:100.75.0.1 mine2 default mine
ipv4:101.0.0.1 default dc1 -
ipv4:101.1.0.1 default default -
ipv4:102.0.0.1 default dc2 -
ipv4:103.0.0.1 default dc3 -
ipv4:104.0.0.1 default dc4 -
ipv4:127.0.0.1 loopback loopback -
ipv4:127.255.255.255 loopback loopback -
ipv4:128.0.0.1 peer1 default peer
ipv4:129.0.0.1 peer2 default peer
ipv4:130.0.0.1 peer1 default peer
ipv4:131.0.0.1 peer2 default peer
ipv4:132.0.0.1 tran1 default transit
ipv4:135.0.0.1 tran2 default transit
ipv4:169.254.1.2 linklocal linklocal -
ipv4:201.0.0.1 default user1 -
ipv4:201.1.2.3 default default -
ipv4:202.0.0.1 default user2 -
ipv4:203.0.0.1 default user3 -
ipv4:204.0.0.1 default user4 -
ipv4:99.0.0.1 default default -
ipv6:::1 loopback loopback -
ipv6:::2 default default -
ipv6:2001:db8:: peer1 default peer
ipv6:2001:db8:8000::1 peer2 default peer
ipv6:fc00:1:: private private -
ipv6:ff80:1:2:: linklocal linklocal -
]]></artwork></figure></t>
</section>
<section title="Endpoint Cost Service Tests">
<t>If the ALTO server provides an Endpoint Cost Service (ECS),
and if the client supports ECS queries,
then the client SHOULD send representative ECS queries to the server.
For ECS, the server should use the costs associated with the default network map,
so the client can verify the server's response.</t>
<t>An ECS-aware client SHOULD send the following queries to the server,
for the "routingcost" and/or "hopcount" metrics,
as suppored by the server. A client may add additional tests as desired.</t>
<section title="ECS Test 1">
<t>This test determines the costs between various endpoints
in the "mine*" and "peer*" PIDs:
<figure anchor="fig:ecs-test-1" title="ECS Test 1">
<artwork><![CDATA[
Query:
sources:
ipv4:100.0.0.128
ipv4:100.131.39.11
destinations:
ipv4:100.0.0.100
ipv4:100.8.1.100
ipv4:100.0.1.100
ipv4:100.64.0.100
ipv4:100.128.4.100
ipv4:130.0.1.100
ipv4:132.0.8.100
Costs: routingcost hopcount
ipv4:100.0.0.128 =>
ipv4:100.0.0.100 1.0 1
ipv4:100.8.1.100 1.0 1
ipv4:100.0.1.100 2.5 2
ipv4:100.64.0.100 5.0 2
ipv4:100.128.4.100 7.0 2
ipv4:130.0.1.100 20.0 4
ipv4:132.0.8.100 40.0 6
ipv4:100.131.39.11 =>
ipv4:100.0.0.100 7.0 2
ipv4:100.8.1.100 7.0 2
ipv4:100.0.1.100 9.0 3
ipv4:100.64.0.100 6.0 2
ipv4:100.128.4.100 1.0 1
ipv4:130.0.1.100 25.0 4
ipv4:132.0.8.100 45.0 6
]]></artwork></figure></t>
</section>
<section title="ECS Test 2">
<t>This test determines the costs between endpoints
in the "default" PID:
<figure anchor="fig:ecs-test-2" title="ECS Test 2">
<artwork><![CDATA[
Query:
sources:
ipv4:10.0.1.0
ipv6:::2
destinations:
ipv4:10.0.1.1
ipv6:::1:2
Costs: routingcost hopcount
ipv4:10.0.1.0 =>
ipv4:10.0.1.1 1.0 1
ipv6:::1:2 75.0 10
ipv6:::2 =>
ipv4:10.0.1.1 75.0 10
ipv6:::1:2 1.0 1
]]></artwork></figure></t>
</section>
<section title="ECS Test 3">
<t>This test determines the costs between endpoints
in the "loopback" PID:
<figure anchor="fig:ecs-test-3" title="ECS Test 3">
<artwork><![CDATA[
Query:
sources:
ipv4:127.0.0.1
ipv6:::1
destinations:
ipv4:127.0.1.0
Costs: routingcost hopcount
ipv4:127.0.0.1 =>
ipv4:127.0.1.0 0.0 0
ipv6:::1 =>
ipv4:127.0.1.0 0.0 0
]]></artwork></figure></t>
</section>
<section title="ECS Test 4">
<t>This test determines the cost when the client
does not specify any destination addresses.
In this case, the server SHOULD use the client's address
as the destination. The costs, however, will depend on the PID
for the client's address, which in turn will depend on
the network configuration of the test environment.
But in most cases, the client's PID will be in either
the "default" or "private" PIDs.
<figure anchor="fig:ecs-test-4" title="ECS Test 4">
<artwork><![CDATA[
Query:
sources:
ipv4:100.0.0.128
ipv4:100.131.39.11
ipv4:0.0.0.1
ipv4:10.0.0.1
ipv6:::2
destinations:
(none specified)
Costs: routingcost hopcount
(for clients in "default" PID)
ipv4:100.0.0.128 =>
(client address) 75.0 10
ipv4:100.131.39.11 =>
(client address) 75.0 10
ipv4:0.0.0.1
(client address) 1.0 1
ipv4:10.0.0.1
(client address) 75.0 10
ipv6:::2
(client address) 1.0 1
(for clients in "private" PID)
ipv4:100.0.0.128 =>
(client address) - -
ipv4:100.131.39.11 =>
(client address) - -
ipv4:0.0.0.1
(client address) 75.0 10
ipv4:10.0.0.1
(client address) 1.0 1
ipv6:::2
(client address) 75.0 10
]]></artwork></figure></t>
</section>
<section title="ECS Test 5">
<t>This test determines the cost when the client
does not specify any source addresses.
In this case, the server SHOULD use the client's address
as the source. However, as with the previous test,
the costs will depend on the PID
for the client's address, which in turn will depend on
the network configuration of the test environment.
But in most cases, the client's PID will be in either
the "default" or "private" PIDs.
<figure anchor="fig:ecs-test-5" title="ECS Test 5">
<artwork><![CDATA[
Query:
sources:
(none specified)
destinations:
ipv4:100.0.0.128
ipv4:100.131.39.11
ipv4:0.0.0.1
ipv4:10.0.0.1
ipv6:::2
Costs: routingcost hopcount
(for clients in "default" PID)
(client address) =>
ipv4:100.0.0.128 75.0 10
ipv4:100.131.39.11 75.0 10
ipv4:0.0.0.1 1.0 1
ipv4:10.0.0.1 75.0 10
ipv6:::2 1.0 1
(for clients in "private" PID)
(client address) =>
ipv4:100.0.0.128 - -
ipv4:100.131.39.11 - -
ipv4:0.0.0.1 75.0 10
ipv4:10.0.0.1 1.0 1
ipv6:::2 75.0 10
]]></artwork></figure></t>
</section>
</section>
</section>
<section title="Error Tests" anchor="error-tests">
<t>A client may send various invalid requests to a server
to verify that the server returns a reasonable response.
The following tests are suggested; clients may do additional tests
as desired.</t>
<t>Each error test is defined by
<list style="hanging">
<t hangText="description: ">A short description of the test.</t>
<t hangText="resource: ">The type of server resource to which
this test applies. E.g., Filtered Cost Map, Endpoint Property Service, etc.</t>
<t hangText="accept: ">The "Accept" HTTP header that the client should
send to the server, if something other than the media-type
for that resource's response.</t>
<t hangText="content-type: ">For POST requests,
the Content-Type HTTP header the client should
send to the server.</t>
<t hangText="input: ">For POST requests, the JSON input
the client should send to send to the server.</t>
<t hangText="http-status: ">The HTTP status code the server should return.</t>
<t hangText="code, field, value: ">The values of the corresponding fields
the server should return in an ALTO error message
(see Section 8.5.2 of <xref target="RFC7285"/>).</t>
</list>
</t>
<t>For "property" fields in Endpoint Property Service tests,
clients should replace the property name "default.pid"
with the resource-specific name of the server's default network map's
"pid" property. That is, if the resource id of the server's default network map
is "mynet", replace "default.pid" with "mynet.pid".</t>
<section title="Invalid Field Type">
<t>For an EPS request, the "endpoints" input field
should be a JSON array of one or more addresses. In this test,
it is a scalar JSON string.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": "ipv4:1.2.3.4" }
http-status: 400 Bad Request
code: E_INVALID_FIELD_TYPE
field: endpoints
]]></artwork></figure>
</section>
<section title="Missing "properties" Field">
<t>This test omits the required "properties" input field.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "endpoints": ["ipv4:1.2.3.4"] }
http-status: 400 Bad Request
code: E_MISSING_FIELD
field: properties
]]></artwork></figure>
</section>
<section title="Invalid Property Name">
<t>This test requests the (presumably!) invalid property "no-such-property".</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["no-such-property"],
"endpoints": "ipv4:1.2.3.4" }
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: properties
value: no-such-property
]]></artwork></figure>
</section>
<section title="Invalid Endpoint Addresses">
<t>These tests verify that a server rejects various invalid endpoint addresses.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": ["ipv4:1.2.3.256"] }
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: endpoints
value: ipv4:1.2.3.256
]]></artwork></figure>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": ["ipv6:2001:db800::"] }
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: endpoints
value: ipv6:2001:db800::
]]></artwork></figure>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": ["ipv4:2001:db8::"] }
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: endpoints
value: ipv4:2001:db8::
]]></artwork></figure>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": ["ipv6:1.2.3.4"] }
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: endpoints
value: ipv6:1.2.3.4
]]></artwork></figure>
</section>
<section title="Invalid Cost Type">
<t>This test requests the (presumably!) invalid cost metric "no-such-metric".
If the server's Filtered Cost Map resource only provides "ordinal" mode
cost types, the client should change "numerical" mode to "ordinal" mode,
to prevent the server from rejecting the request because of an invalid cost mode.</t>
<figure><artwork><![CDATA[
resource: Filtered Cost Map
accept: application/alto-costmap+json
content-type: application/alto-costmapfilter+json
input: { "cost-type": [
"cost-metric": "no-such-cost",
"cost-mode": "numerical" ],
"endpoints": {
"srcs": [],
"dsts": [] }
}
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: cost-type/cost-metric
value: no-such-cost
]]></artwork></figure>
</section>
<section title="Invalid Cost Mode">
<t>This test requests the invalid cost mode "no-such-mode".
The client should direct this request to a Filtered Cost Map resource
which can return the "routingcost" metric,
to prevent the server from rejecting the request because of an invalid cost metric.</t>
<figure><artwork><![CDATA[
resource: Filtered Cost Map
accept: application/alto-costmap+json
content-type: application/alto-costmapfilter+json
input: { "cost-type": [
"cost-metric": "routingcost",
"cost-mode": "no-such-mode" ],
"endpoints": {
"srcs": [],
"dsts": [] }
}
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: cost-type/cost-mode
value: no-such-mode
]]></artwork></figure>
</section>
<section title="Invalid Cost Constraints">
<t>This test uses a constraint test with the undefined "ne" operator.
The client should direct this request to a Filtered Cost Map resource
which can return the "routingcost" metric in "numerical" mode,
to prevent the server from rejecting the request
because of an invalid cost metric or mode.</t>
<figure><artwork><![CDATA[
resource: Filtered Cost Map which accepts constraints
accept: application/alto-costmap+json
content-type: application/alto-costmapfilter+json
input: { "cost-type": [
"cost-metric": "routingcost",
"cost-mode": "numerical" ],
"endpoints": {
"srcs": [],
"dsts": [] },
"constraints": ["ne 10"]
}
http-status: 400 Bad Request
code: E_INVALID_FIELD_VALUE
field: constraints
value: no-such-mode
]]></artwork></figure>
</section>
<section title="JSON Syntax Error">
<t>This test gives syntactically incorrect JSON input to the server.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: application/alto-endpointpropparams+json
input: { "properties": }
http-status: 400 Bad Request
code: E_SYNTAX
]]></artwork></figure>
</section>
<section title="Invalid Accept Header In GET Request">
<t>This test attempts to GET the Full Network Map, without including
the appropriate media-type ("application/alto-networkmap+json")
in the "Accept" HTTP header. Note that the client must ensure that
the HTTP library does not automatically append "*/*"
to the "Accept" header. Note that because this is an HTTP error,
<xref target="RFC7285"/> does not specify
the content the server is expected to return.</t>
<figure><artwork><![CDATA[
resource: Full Network Map
accept: text/html
http-status: 406 Not Acceptable
]]></artwork></figure>
</section>
<section title="Invalid Accept Header In POST Request">
<t>This test requests a property without including
the appropriate media-type ("application/alto-endpointprop+json")
in the "Accept" HTTP header. Note that the client must ensure that
the HTTP library does not automatically append "*/*"
to the "Accept" header. Note that because this is an HTTP error,
<xref target="RFC7285"/> does not specify
the content the server is expected to return.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: text/html
content-type: application/alto-endpointpropparams+json
input: { "properties": ["default.pid"],
"endpoints": ["ipv4:1.2.3.4"] }
http-status: 406 Not Acceptable
]]></artwork></figure>
</section>
<section title="Invalid Content-Type Header In POST Request">
<t>This test requests a property but provides input
with an incorrect Content-Type. Note that because this is an HTTP error,
<xref target="RFC7285"/> does not specify
the content the server is expected to return.</t>
<figure><artwork><![CDATA[
resource: Endpoint Property Service
accept: application/alto-endpointprop+json
content-type: text/text
input: { "properties": ["default.pid"],
"endpoints": ["ipv4:1.2.3.4"] }
http-status: 415 Unsupported Media Type
(or 404 Not Found or 400 Bad Request)
]]></artwork></figure>
</section>
</section>
<section title="Security considerations" anchor="sec-cons">
<t>This document does not present any new security considerations
above and beyond what is documented in the ALTO protocol
<xref target="RFC7285"/>.</t>
</section> <!-- sec-cons -->
<section title="IANA considerations" anchor="iana-cons">
<t>This document does not require any action from IANA.</t>
</section> <!-- iana-cons -->
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC7159">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray"/>
<date month="March" year="2014"/>
</front>
<seriesInfo name="RFC" value="7159" />
</reference>
<reference anchor="RFC7285">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
<author fullname="R. Alimi" initials="R." surname="Almi"/>
<author fullname="R. Penno" initials="R." surname="Penno"/>
<author fullname="Y. Yang" initials="Y." surname="Yang"/>
<author fullname="S. Kiesel" initials="S." surname="Kiesel"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="W. Roome" initials="W." surname="Roome"/>
<author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
<author fullname="R. Woundy" initials="R." surname="Woundy"/>
<date month="September" year="2014"/>
</front>
<seriesInfo name="RFC" value="7285"/>
</reference>
</references>
<section title="Appendix: JSON Network And Cost Maps" anchor="json-maps">
<t>This section presents the network and cost maps defined in <xref target="server-data"/>
formatted as JSON (<xref target="RFC7159"/>) objects.</t>
<section title="Default Network Map">
<figure anchor="fig:json-def-netmap" title="Default Network Map, in JSON">
<artwork><![CDATA[
"network-map": {
"default": {
"ipv4": ["0.0.0.0/0"],
"ipv6": ["::/0"] },
"linklocal": {
"ipv4": ["169.254.0.0/16"],
"ipv6": ["FF80::/10"] },
"loopback": {
"ipv4": ["127.0.0.0/8"],
"ipv6": ["::1/128"] },
"mine": {
"ipv4": ["100.0.0.0/8"] },
"mine1": {
"ipv4": ["100.0.0.0/10"] },
"mine1a": {
"ipv4": ["100.0.64.0/24", "100.0.192.0/24", "100.0.1.0/24"] },
"mine2": {
"ipv4": ["100.64.0.0/10"] },
"mine3": {
"ipv4": ["100.128.0.0/10"] },
"peer1": {
"ipv4": ["130.0.0.0/16", "128.0.0.0/16"],
"ipv6": ["2001:DB8::/33"] },
"peer2": {
"ipv4": ["131.0.0.0/16", "129.0.0.0/16"],
"ipv6": ["2001:DB8:8000::/33"] },
"private": {
"ipv4": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
"ipv6": ["FC00::/7"] },
"tran1": {
"ipv4": ["132.0.0.0/16"] },
"tran2": {
"ipv4": ["135.0.0.0/16"] }
}
]]></artwork>
</figure>
</section>
<section title="Default "routingcost" Cost Map">
<figure anchor="fig:json-def-routingcost" title="Default "routingcost" Cost Map, in JSON">
<artwork><![CDATA[
"cost-map": {
"default": {
"default": 1.0, "mine": 75.0, "mine1": 75.0, "mine1a": 75.0,
"mine2": 75.0, "mine3": 75.0, "private": 75.0 },
"linklocal": {
"linklocal": 1.0 },
"loopback": {
"loopback": 0.0 },
"mine": {
"default": 75.0, "mine": 1.0, "mine1": 15.0, "mine1a": 15.0,
"mine2": 15.0, "mine3": 15.0, "peer1": 30.0, "peer2": 30.0,
"tran1": 50.0, "tran2": 50.0 },
"mine1": {
"default": 75.0, "mine": 15.0, "mine1": 1.0, "mine1a": 2.5,
"mine2": 5.0, "mine3": 7.0, "peer1": 20.0, "peer2": 25.0,
"tran1": 40.0, "tran2": 45.0 },
"mine1a": {
"default": 75.0, "mine": 15.0, "mine1": 2.0, "mine1a": 1.0,
"mine2": 7.0, "mine3": 9.0, "peer1": 22.0, "peer2": 24.0,
"tran1": 42.0, "tran2": 48.0 },
"mine2": {
"default": 75.0, "mine": 15.0, "mine1": 5.5, "mine1a": 7.0,
"mine2": 1.0, "mine3": 6.0, "peer1": 23.0, "peer2": 25.0,
"tran1": 43.0, "tran2": 46.0 },
"mine3": {
"default": 75.0, "mine": 15.0, "mine1": 7.0, "mine1a": 9.0,
"mine2": 6.0, "mine3": 1.0, "peer1": 25.0, "peer2": 28.0,
"tran1": 45.0, "tran2": 49.0 },
"peer1": {
"mine": 30.0, "mine1": 20.0, "mine1a": 22.0, "mine2": 23.0,
"mine3": 25.0, "peer1": 1.0 },
"peer2": {
"mine": 30.0, "mine1": 25.0, "mine1a": 24.0, "mine2": 25.0,
"mine3": 28.0, "peer2": 1.0 },
"private": {
"default": 75.0, "private": 1.0 },
"tran1": {
"mine": 50.0, "mine1": 40.0, "mine1a": 42.0, "mine2": 43.0,
"mine3": 45.0, "tran1": 1.0 },
"tran2": {
"mine": 50.0, "mine1": 45.0, "mine1a": 48.0, "mine2": 46.0,
"mine3": 49.0, "tran2": 1.0 }
}
]]></artwork>
</figure>
</section>
<section title="Default "hopcount" Cost Map">
<figure anchor="fig:json-def-hopcount" title="Default "hopcount" Cost Map, in JSON">
<artwork><![CDATA[
"cost-map": {
"default": {
"default": 1, "mine": 10, "mine1": 10, "mine1a": 10,
"mine2": 10, "mine3": 10, "private": 10 },
"linklocal": {
"linklocal": 1 },
"loopback": {
"loopback": 0 },
"mine": {
"default": 10, "mine": 1, "mine1": 3, "mine1a": 3,
"mine2": 3, "mine3": 3, "peer1": 5, "peer2": 6,
"tran1": 8, "tran2": 8 },
"mine1": {
"default": 10, "mine": 3, "mine1": 1, "mine1a": 2,
"mine2": 2, "mine3": 2, "peer1": 4, "peer2": 5,
"tran1": 6, "tran2": 7 },
"mine1a": {
"default": 10, "mine": 3, "mine1": 2, "mine1a": 1,
"mine2": 2, "mine3": 3, "peer1": 5, "peer2": 6,
"tran1": 7, "tran2": 8 },
"mine2": {
"default": 10, "mine": 3, "mine1": 2, "mine1a": 2,
"mine2": 1, "mine3": 2, "peer1": 4, "peer2": 5,
"tran1": 6, "tran2": 7 },
"mine3": {
"default": 10, "mine": 3, "mine1": 2, "mine1a": 3,
"mine2": 2, "mine3": 1, "peer1": 4, "peer2": 5,
"tran1": 6, "tran2": 7 },
"peer1": {
"mine": 5, "mine1": 4, "mine1a": 5, "mine2": 4,
"mine3": 4, "peer1": 1 },
"peer2": {
"mine": 6, "mine1": 5, "mine1a": 6, "mine2": 5,
"mine3": 5, "peer2": 1 },
"private": {
"default": 10, "private": 1 },
"tran1": {
"mine": 8, "mine1": 6, "mine1a": 7, "mine2": 6,
"mine3": 6, "tran1": 1 },
"tran2": {
"mine": 8, "mine1": 7, "mine1a": 8, "mine2": 7,
"mine3": 7, "tran2": 1 }
}
]]></artwork>
</figure>
</section>
<section title="Alternate Network Map">
<figure anchor="fig:json-alt-netmap" title="Alternate Network Map, in JSON">
<artwork><![CDATA[
"network-map": {
"dc1": {
"ipv4": ["101.0.0.0/16"] },
"dc2": {
"ipv4": ["102.0.0.0/16"] },
"dc3": {
"ipv4": ["103.0.0.0/16"] },
"dc4": {
"ipv4": ["104.0.0.0/16"] },
"default": {
"ipv4": ["0.0.0.0/0"],
"ipv6": ["::/0"] },
"linklocal": {
"ipv4": ["169.254.0.0/16"],
"ipv6": ["FF80::/10"] },
"loopback": {
"ipv4": ["127.0.0.0/8"],
"ipv6": ["::1/128"] },
"private": {
"ipv4": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
"ipv6": ["FC00::/7"] },
"user1": {
"ipv4": ["201.0.0.0/16"] },
"user2": {
"ipv4": ["202.0.0.0/16"] },
"user3": {
"ipv4": ["203.0.0.0/16"] },
"user4": {
"ipv4": ["204.0.0.0/16"] }
}
]]></artwork>
</figure>
</section>
<section title="Alternate "routingcost" Cost Map">
<figure anchor="fig:json-alt-routingcost" title="Alternate "routingcost" Cost Map, in JSON">
<artwork><![CDATA[
"cost-map": {
"dc1": {
"dc1": 0.0, "dc2": 5.0, "dc3": 5.0, "dc4": 5.0,
"default": 50.0, "user1": 10.0, "user2": 20.0,
"user3": 30.0, "user4": 40.0 },
"dc2": {
"dc1": 5.0, "dc2": 0.0, "dc3": 5.0, "dc4": 5.0,
"default": 50.0, "user1": 20.0, "user2": 10.0,
"user3": 20.0, "user4": 30.0 },
"dc3": {
"dc1": 5.0, "dc2": 5.0, "dc3": 0.0, "dc4": 5.0,
"default": 50.0, "user1": 30.0, "user2": 20.0,
"user3": 10.0, "user4": 20.0 },
"dc4": {
"dc1": 5.0, "dc2": 5.0, "dc3": 5.0, "dc4": 0.0,
"default": 50.0, "user1": 40.0, "user2": 30.0,
"user3": 20.0, "user4": 10.0 },
"default": {
"dc1": 50.0, "dc2": 50.0, "dc3": 50.0, "dc4": 50.0,
"default": 0.0 },
"user1": {
"dc1": 10.0, "dc2": 20.0, "dc3": 30.0, "dc4": 40.0,
"user1": 0.0 },
"user2": {
"dc1": 20.0, "dc2": 10.0, "dc3": 20.0, "dc4": 30.0,
"user2": 0.0 },
"user3": {
"dc1": 30.0, "dc2": 20.0, "dc3": 10.0, "dc4": 20.0,
"user3": 0.0 },
"user4": {
"dc1": 40.0, "dc2": 30.0, "dc3": 20.0, "dc4": 10.0,
"user4": 0.0 }
}
]]></artwork>
</figure>
</section>
<section title="Alternate "hopcount" Cost Map">
<figure anchor="fig:json-alt-hopcount" title="Alternate "hopcount" Cost Map, in JSON">
<artwork><![CDATA[
"cost-map": {
"dc1": {
"dc1": 0, "dc2": 1, "dc3": 1, "dc4": 1,
"default": 8, "user1": 3, "user2": 4, "user3": 5,
"user4": 6 },
"dc2": {
"dc1": 1, "dc2": 0, "dc3": 1, "dc4": 1,
"default": 8, "user1": 4, "user2": 3, "user3": 4,
"user4": 5 },
"dc3": {
"dc1": 1, "dc2": 1, "dc3": 0, "dc4": 1,
"default": 8, "user1": 5, "user2": 4, "user3": 3,
"user4": 4 },
"dc4": {
"dc1": 1, "dc2": 1, "dc3": 1, "dc4": 0,
"default": 8, "user1": 6, "user2": 5, "user3": 4,
"user4": 3 },
"default": {
"dc1": 8, "dc2": 8, "dc3": 8, "dc4": 8,
"default": 0 },
"user1": {
"dc1": 3, "dc2": 4, "dc3": 5, "dc4": 6,
"user1": 0 },
"user2": {
"dc1": 4, "dc2": 3, "dc3": 4, "dc4": 5,
"user2": 0 },
"user3": {
"dc1": 5, "dc2": 4, "dc3": 3, "dc4": 4,
"user3": 0 },
"user4": {
"dc1": 6, "dc2": 5, "dc3": 4, "dc4": 3,
"user4": 0 }
},
]]></artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:19:06 |