One document matched: draft-ietf-alto-deployments-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-alto-deployments-09"
ipr="trust200902">
<front>
<title abbrev="Deployment Considerations">ALTO Deployment
Considerations</title>
<author fullname="Martin Stiemerling" initials="M." surname="Stiemerling" role="editor">
<organization abbrev="NEC Europe Ltd.">NEC Laboratories
Europe</organization>
<address>
<postal>
<street>Kurfuerstenanlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<phone>+49 6221 4342 113</phone>
<facsimile>+49 6221 4342 155</facsimile>
<email>martin.stiemerling@neclab.eu</email>
<uri>http://ietf.stiemerling.org</uri>
</address>
</author>
<author fullname="Sebastian Kiesel" initials="S" surname="Kiesel" role="editor">
<organization abbrev="University of Stuttgart">University of Stuttgart,
Computing Center</organization>
<address>
<postal>
<street>Allmandring 30</street>
<city>Stuttgart</city>
<code>70550</code>
<country>Germany</country>
</postal>
<email>ietf-alto@skiesel.de</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization abbrev="Cisco"> Cisco Systems, Inc. </organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<code>00191</code>
<city>Rome</city>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization abbrev="Alcatel-Lucent Bell Labs">Alcatel-Lucent Bell Labs</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<code>70435</code>
<city>Stuttgart</city>
<country>Germany</country>
</postal>
<email>michael.scharf@alcatel-lucent.com</email>
</address>
</author>
<date year="2014" />
<area>APP</area>
<workgroup>ALTO</workgroup>
<keyword>ALTO</keyword>
<keyword>ALTO Deployment Considerations</keyword>
<abstract>
<t>Many Internet applications are used to access resources such
as pieces of information or server processes that are available
in several equivalent replicas on different hosts. This
includes, but is not limited to, peer-to-peer file sharing
applications. The goal of Application-Layer Traffic Optimization
(ALTO) is to provide guidance to applications that have to
select one or several hosts from a set of candidates, which are
able to provide a desired resource. This memo discusses
deployment related issues of ALTO. It addresses different use
cases of ALTO such as peer-to-peer file sharing and CDNs,
security considerations, recommendations for network
administrators, and also guidance for application designers
using ALTO.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many Internet applications are used to access resources such
as pieces of information or server processes that are
available in several equivalent replicas on different
hosts. This includes, but is not limited to, peer-to-peer (P2P)
file sharing applications and Content Delivery Networks
(CDNs). The goal of Application-Layer Traffic Optimization
(ALTO) is to provide guidance to applications that have to
select one or several hosts from a set of candidates, which are
able to provide a desired resource. The basic ideas and problem
space of ALTO is described in <xref target="RFC5693"></xref> and
the set of requirements is discussed in <xref
target="RFC6708"></xref>.</t>
<t>However, there are no considerations about what operational issues
are to be expected once ALTO will be deployed. This includes, but is not
limited to, location of the ALTO server, imposed load to the ALTO
server, or from whom the queries are performed.</t>
<t>Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.</t>
</section>
<section title="General Considerations">
<section title="ALTO Entities">
<section anchor="sec.general_deployment" title="Baseline Scenario">
<t>The ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> is a client/server
protocol, operating between a number of ALTO clients and an ALTO
server, as sketched in <xref target="fig.overview"></xref>.</t>
<t><figure anchor="fig.overview"
title="Baseline Deployment Scenario of the ALTO Protocol">
<artwork><![CDATA[ +----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
]]></artwork>
</figure></t>
</section>
<section anchor="sec.general_overview" title="Placement of ALTO Entities">
<t>The ALTO server and ALTO clients can be situated at
various entities in a network deployment. The first
differentiation is whether the ALTO client is located on the
actual host that runs the application, as shown in <xref
target="fig.tracker_less"></xref>, or if the ALTO client is
located on a resource directory, as shown in <xref
target="fig.tracker"></xref>.</t>
<t><figure anchor="fig.tracker_less"
title="Overview of protocol interaction between ALTO elements without a resource directory">
<artwork><![CDATA[
+-----+
=====| |**
==== +-----+ *
==== * *
==== * *
+-----+ +------+===== +-----+ *
| |.....| |======================| | *
+-----+ +------+===== +-----+ *
Source of ALTO ==== * *
topological service ==== * *
information ==== +-----+ *
=====| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol]]></artwork>
</figure></t>
<t><xref target="fig.tracker_less"></xref> shows the
operational model for applications that do not use a resouce
directory. An example would be a peer-to-peer file sharing
application that does not use a tracker, such as edonkey.</t>
<t><figure anchor="fig.tracker"
title="Overview of protocol interaction between ALTO elements with a resource directory">
<artwork><![CDATA[ +-----+
**| |**
** +-----+ *
** * *
** * *
+-----+ +------+ +-----+** +-----+ *
| |.....| |=====| |**********| | *
+-----+ +------+ +-----+** +-----+ *
Source of ALTO Resource ** * *
topological service directory ** * *
information ** +-----+ *
**| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol]]></artwork>
</figure></t>
<t>In <xref target="fig.tracker"></xref>, a use case with a
resource directory is illustrated, e.g., a tracker in
peer-to-peer filesharing. Both deployment scenarios may
differ in the number of ALTO clients that access an ALTO
service: If ALTO clients are implemented in a resource
directory, ALTO servers may be accessed by a limited and less
dynamic set of clients, whereas in the general case any host
could be an ALTO client. This use case is further detailed in
<xref target="sec.p2p_cons"></xref>.</t>
<t>Using ALTO in CDNs may be similar to a resource directory
<xref target="I-D.jenkins-alto-cdn-use-cases"></xref>. The
ALTO server can also be queried by CDN entities to get a
guidance about where the a particular client accessing data
in the CDN is exactly located in the ISP's network, as discussed
in <xref target="sec.cdn_cons"></xref>.</t>
</section>
</section>
<section anchor="sec.alto_apps" title="Classification of Deployment Scenarios">
<section anchor="sec.alto_classification" title="Deployment Degrees of Freedom">
<t>ALTO is a general-purpose solution and it is intended to
be used by a wide range of applications. This implies that
there are different possibilities where the ALTO entities
are actually located, i.e., if the ALTO clients and the ALTO
server are in the same ISP's domain, or if the clients and
the ALTO server are managed/owned/located in different
domains.</t>
<t>ALTO deployments can be differentiated e.g. according to
the following aspects:</t>
<t><list style="numbers">
<t>Applicable trust model: The deployment of ALTO can
differ depending on whether ALTO client and ALTO server
are operated within the same organization and/or network,
or not. This affects a lot of constraints, because the
trust model is very different. For instance, as discussed
later in this memo, the level-of-detail of maps can depend
on who the involved parties actually are.</t>
<t>Size of user group: The main use case of ALTO is to
provide guidance to any Internet application. However, an
operator of an ALTO server could also decide to only offer
guidance to a set of well-known ALTO clients, e. g., after
authentication and authorization. In the peer-to-peer
application use case, this could imply that only selected
trackers are allowed to access the ALTO server. The
security implications of using ALTO in closed groups
differ from the public Internet.</t>
<t>Covered destinations: In general, an ALTO server has to
be able to provide guidance for all potential
destinations. Yet, in practice a given ALTO client may
only be interested in a subset of destinations, e.g.,
only in the network cost between a limited set of resource
providers. For instance, CDN optimization may not need the
full ALTO cost maps, because traffic between individual
residential users is not in scope. This may imply that an
ALTO server only has to provide the costs that matter for
a given user, e. g., by customized maps.</t>
</list></t>
<t>The following sections enumerate different classes of use
cases for ALTO, and they discuss the deployment implications
of each of them.</t>
<t>However, it must be emphasized that any application using
ALTO must also work if no ALTO servers can be found or if no
responses to ALTO queries are received, e.g., due to
connectivity problems or overload situations (see also <xref
target="RFC6708"/>).</t>
</section>
<section title="Information Exposure">
<t>An ALTO server stores information about preferences
(e.g., a list of preferred autonomous systems, IP ranges,
etc.) and ALTO clients can retrieve these preferences. There
are basically two different approaches on where the
preferences are actually processed:</t>
<t><list style="numbers">
<t>The ALTO server has a list of preferences and clients
can retrieve this list via the ALTO protocol. This
preference list can partially be updated by the
server. The actual processing of the data is done on the
client and thus there is no data of the client's operation
revealed to the ALTO server .</t>
<t>The ALTO server has a list of preferences or
preferences calculated during runtime and the ALTO client
is sending information of its operation (e.g., a list of
IP addresses) to the server. The server is using this
operational information to determine its preferences and
returns these preferences (e.g., a sorted list of the IP
addresses) back to the ALTO client.</t>
</list></t>
<t>Approach 1 has the advantage (seen from the client) that
all operational information stays within the client and is
not revealed to the provider of the server. On the other
hand, approach 1 requires that the provider of the ALTO
server, i.e., the network operator, reveals information
about its network structure (e.g., AS numbers, IP ranges,
topology information in general) to the ALTO client. The
ALTO protocol supports this scheme by the Network and Cost
Map Service.</t>
<t>Approach 2 has the advantage (seen from the operator)
that all operational information stays with the ALTO server
and is not revealed to the ALTO client. On the other hand,
approach 2 requires that the clients send their operational
information to the server. This approach is realized by the
ALTO Endpoint Cost Service (ECS).</t>
<t>Both approaches have their pros and cons, as detailed in
<xref target="risks"></xref>.</t>
</section>
<section title="More Advanced Deployments">
<t>From an ALTO client's perspective, there are two fundamental
ways to use ALTO:</t>
<t><list style="numbers">
<t>Single server: An ALTO client only obtains guidance
from a single ALTO server instance, e.g., an ALTO server
that is offered by the network service provider of the
corresponding access network. This ALTO server can be
discovered e.g. by ALTO server discovery <xref
target="I-D.ietf-alto-server-discovery"></xref>
<xref target="I-D.kist-alto-3pdisc"></xref>.</t>
<t>Multiple servers: An ALTO client is aware of more than
one ALTO server. This scenario is mostly identical to the
former one if all those servers provide the same guidance
(e.g., load balancing). Yet, an ALTO client can also
decide to access multiple servers providing different
guidance, possibly from different operators. In that case,
it may be difficult for an ALTO client to compare the
guidance from different servers. How to discover multiple
servers is an open issue.</t>
</list></t>
<t>There are also different options regarding the guidance
offered by an ALTO server:</t>
<t><list style="numbers">
<t>Authorative servers: An ALTO server instance can provide
guidance for all destinations for all kinds of ALTO
clients.</t>
<t>Cascaded servers: An ALTO server may itself include an
ALTO client and query other ALTO servers, e.g., for
certain destinations. This results is a cascaded
deployment of ALTO servers, as further explained
below.</t>
<t>Inter-server synchronization: Different ALTO servers
my communicate by other means. This approach is not further
discussed in this document.</t>
</list></t>
<!--<section anchor="advanced" title="Cascading ALTO Servers">-->
<t>An assumption of the ALTO solution is that ISP operate
ALTO servers independently, irrespectively of other
ISPs. This may true for most envisioned deployments of ALTO
but there are certain deployments that may have different
settings. <xref target="fig-alto-proxy"></xref> shows such
setting with a university network that is connected to two
upstream providers. ISP2 is the national research network
and ISP1 is a commercial upstream provider to this
university network. The university, as well as ISP1, are
operating their own ALTO server. The ALTO clients, located
on the peers will contact the ALTO server located at the
university.</t>
<t><figure anchor="fig-alto-proxy" title="Cascaded ALTO Server">
<artwork><![CDATA[
+-----------+
| ISP1 |
| ALTO |
| Server |
+----------=+
,-------= ,------.
,-' =`-. ,-' `-.
/ Upstream= \ / Upstream \
( ISP1 = ) ( ISP2 )
\ = / \ /
`-. =,-' `-. ,-'
`---+---= `+------'
| = |
| =======================
|,-------------. | =
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. =======================| Server |
`-= +-' +-----------+
=`+------------'|
= | |
+--------+-+ +-+--------+
| Peer1 | | PeerN |
+----------+ +----------+
]]></artwork>
</figure></t>
<t>In this setting all "destinations" useful for the peers
within ISP2 are free-of-charge for the peers located in the
university network (i.e., they are preferred in the rating
of the ALTO server). However, all traffic that is not
towards ISP2 will be handled by the ISP1 upstream
provider. Therefore, the ALTO server at the university has
also to include the guidance given by the ISP1 ALTO server
in its replies to the ALTO clients. This is an example for
cascaded ALTO servers.</t>
<!--</section>-->
</section>
</section>
</section>
<section anchor="sec.ISP_deployment_req_general" title="Deployment Considerations by ISPs">
<section anchor="sec.guidance" title="Objectives for the Guidance to Applications">
<!--<section anchor="sec.ISP_deployment" title="Motivation for Traffic Optimization">-->
<section anchor="sec.ISP_deployment_req" title="General Objectives for Traffic Optimization">
<t>The Internet is a large network consisting of many
networks worldwide. These networks are built by network
operators or Internet Service Providers (named ISP in this
memo), and these networks provide network connectivity to
access networks, such as cable networks, xDSL networks,
3G/4G mobile networks, etc. Some of these networks are also
built by universities or big organizations. These network
providers need to manage, to control and to audit the
traffic. Thus, it's important for ISPs to understand the
requirement of optimizing traffic, and how to deploy ALTO
service in these manageability and controllability
networks.</t>
<t>The objective of ALTO is to give guidance to applications
on what IP addresses or IP prefixes are to be preferred
according to the operator of the ALTO server. The ALTO
protocol gives means to let the ALTO server operator express
its preference, whatever this preference is.</t>
<t>ALTO enables ISPs to perform traffic engineering by
influencing application resource selections. This traffic
engineering can have different objectives:</t>
<t><list style='numbers'>
<t>Inter-network traffic localization: ALTO can help to
reduce inter-domain traffic. The networks of ISPs are
connected through peering points. From a business view,
the inter-network settlement is needed for exchanging
traffic between these networks. These peering agreements
can be costly. To reduce these costs, a simple objective
is to decrease the traffic exchange across the peering
points and thus keep the traffic in the own network or
Autonomous System (AS) as far as possible.</t>
<t>Intra-network traffic localization: In case of large
ISPs, the network may be grouped into several networks,
domains, or Autonomous Systems (ASs). The core
network includes one or several backbone networks, which
are connected to multiple aggregation, metro, and access
networks. If traffic can be limited to access networks,
this decreases the usage of backbone and thus helps to
save resources and costs.</t>
<t>Network off-loading: Compared to fixed networks, mobile
networks have some special characteristics, including
smaller link bandwidth, high cost, limited radio frequency
resource, and limited terminal battery. In mobile
networks, the usage of wireless link should be decreased
as far as possible and be used efficiently. For example,
in the case of a P2P service, the hosts in fixed networks
should avoid retrieving data from hosts in the mobile
networks, and hosts in mobile networks should prefer the
data retrieval from hosts in fixed networks.</t>
<t>Application tuning: ALTO is also a powerful tool to
optimize the performance of applications that depend on
the network and perform resource selection decisions.</t>
</list></t>
<t>In the following, these objectives are explained in more
detail with deployment examples.</t>
</section>
<section title="Inter-Network Traffic Localization">
<!--<section title="Keeping Traffic Local in a Network">-->
<t>ALTO guidance can be used to keep traffic local in a
network. An ALTO server can let applications prefer other
hosts within the same network operator's network instead of
randomly connecting to other hosts that are located in
another operator's network. Here, a network operator would
always express its preference for hosts in its own network,
while hosts located outside its own network are to be
avoided (i.e., they are undesired to be considered by the
applications). <xref target="fig.network_local"></xref>
shows such a scenario where hosts prefer hosts in the same
network (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host
4 in ISP2). </t>
<t><figure anchor="fig.network_local"
title="ALTO Traffic Network Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 ########|ALTO Client|
/ \ / # \ +-----------+
/ ISP X \ | # | +-----------+
/ \ \ ########| Host 2 |
; +----------------------------|ALTO Client|
| | | `-. ,-' +-----------+
| | | `-------'
| | | ,-------. +-----------+
: | ; ,-' `########| Host 3 |
\ | / / ISP 2 # \ |ALTO Client|
\ | / / # \ +-----------+
\ +---------+ # | +-----------+
`-. ,-' \ | ########| Host 4 |
`---' \ +------------------|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
### preferred "connections"
--- non-preferred "connections"
]]></artwork>
</figure></t>
<t>TBD: Describes limits of this approach (e.g., traffic
localization guidance is of less use if the peers cannot
upload); describe how maps would look like.</t>
</section>
<section title="Intra-Network Traffic Localization">
<!--<section title="Objective: Intra-Network Localization/Bottleneck Off-Loading">-->
<t>The above sections described the results of the ALTO
guidance on an inter-network level. However, ALTO can also
be used for intra-network localization. In this case, ALTO
provides guidance which internal hosts are to be preferred
inside a single network or, e.g., one AS. <xref
target="fig.no_intra_network_local"></xref> shows such a
scenario where Host 1 and Host 2 are located in Net 2 of
ISP1 and connect via a low capacity link to the core (Net 1)
of the same ISP1. If Host 1 and Host 2 exchange their data
with remote hosts, they would probably congest the
bottleneck link.</t>
<t><figure anchor="fig.no_intra_network_local"
title="Without Intra-Network ALTO Traffic Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | ######### | +-----------+
/ Net 1 \ \ # / | Host 2 |
; ###; \ # ##########|ALTO Client|
| X~~~~~~~~~~~~X#######,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
]]></artwork>
</figure></t>
<t>The operator can guide the hosts in such a situation to try first
local hosts in the same network islands, avoiding or at least
lowering the effect on the bottleneck link, as shown in <xref
target="fig.intra_network_local"></xref>.</t>
<t><figure anchor="fig.intra_network_local"
title="With Intra-Network ALTO Traffic Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Peer 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | # | +-----------+
/ Net 1 \ \ #########| Peer 2 |
; ; \ ##########|ALTO Client|
| #~~~~~~~~~~~########,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
]]></artwork>
</figure></t>
</section>
<section title="Network Off-Loading">
<!--<section title="Objective: Off-Loading Traffic from Network"> -->
<t>Another scenario is off-loading traffic from
networks. This use of ALTO can be beneficial in particular
in mobile broadband networks. The network operator may have
the desire to guide hosts in its own network to use hosts in
remote networks. One reason can be that the wireless network
is not made for the load cause by, e.g., peer-to-peer
applications, and the operator has the need that peers fetch
their data from remote peers in other parts of the
Internet.</t>
<t><figure anchor="fig.network_de_local"
title="ALTO Traffic Network De-Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 +-------|ALTO Client|
/ \ / | \ +-----------+
/ ISP X \ | | | +-----------+
/ \ \ +-------| Host 2 |
; #-###########################|ALTO Client|
| # | `-. ,-' +-----------+
| # | `-------'
| # | ,-------. +-----------+
: # ; ,-' `+-------| Host 3 |
\ # / / ISP 2 | \ |ALTO Client|
\ # / / | \ +-----------+
\ ########### | | +-----------+
`-. ,-' \ # +-------| Host 4 |
`---' \ ###################|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
=== preferred "connections"
--- non-preferred "connections"
]]></artwork>
</figure></t>
<t><xref target="fig.network_de_local"></xref> shows the
result of such a guidance process where Host 2 prefers a
connection with Host 4 instead of Host 1, as shown in <xref
target="fig.network_local"></xref>.</t>
<t>TBD: Limits of this approach in general and with respect
to p2p. describe how maps would look like.</t>
</section>
<section title="Application Tuning">
<t>ALTO can also provide guidance to optimize the
application-level topology of networked applications, e.g.,
by exposing network performance information. Applications
can often run own measurements to determine network
performance, e.g., by active delay measurements or bandwidth
probing, but such measurements result in overhead and
complexity. Accessing an ALTO server can be a simpler
alternative. In addition, an ALTO server may also expose
network information that applications cannot easily measure
or reverse-engineer.</t>
</section>
</section>
<section title="Provisioning of ALTO Maps">
<section anchor="sec.data_sources" title="Data Sources">
<t>An ALTO server collects topological information from a
variety of sources in the network and provides a cohesive,
abstracted view of the network topology to applications
using an ALTO client. The ALTO server builds an
ALTO-specific network topology that represents the network
as it should be understood and utilized by the
application.</t>
<t>ALTO abstract network topologies can be auto-generated
from the physical or logical topology of the underlying
network. The generation would typically be based on
policies and rules set by the network operator. The maps and
the guidance can significantly differ depending on the use
case, the network architecture, and the trust relationship
between ALTO server and ALTO client, etc. Besides the security
requirements that consist of not delivering any confidential
or critical information about the infrastructure, there are
efficiency requirements in terms of what aspects of
the network are visible and required by the given use case
and/or application.</t>
<t>The ALTO server builds topology (for either Map and ECS
services) based on multiple sources that may include routing
protocols, network policies, state and performance
information, geo-location, etc. The network topology
information is controlled and managed by the ALTO server. In
all cases, the ALTO topology will not contain any details
that would endanger the network integrity and security. For
instance, ALTO is not intended to leak raw IGP/BGP databases
to ALTO clients.</t>
<t><figure anchor="fig.data_sources" title="Data sources for ALTO">
<artwork><![CDATA[
+--------+ +--------+
| Client | | Client |
+--------+ +--------+
^ ^
| | ALTO protocol
+---------+
| ALTO |
| Server |
+---------+
^ ^ ^ Potential
| | | data sources
+--------+ | +--------+
| | |
+---------+ +---------+ +---------+
| BGP | | I2RS | | NMS |
| Speaker | | Client | | OSS |
+---------+ +---------+ +---------+
^ ^ ^
| | |
Link-State I2RS SNMP/NETCONF,
NLRI for data traffic statistics,
IGP/BGP IPFIX, etc.
]]></artwork>
</figure></t>
<t>As illustrated in <xref
target="fig.data_sources"></xref>, the topology data used by
an ALTO server can originate from different data
sources:</t>
<t><list style='symbols'>
<t>The document <xref
target="I-D.ietf-idr-ls-distribution"></xref>
describes a mechanism by which links state and traffic
engineering information can be collected from networks and
shared with external components using the BGP routing
protocol. This is achieved using a new BGP Network Layer
Reachability Information (NLRI) encoding format. The
mechanism is applicable to physical and virtual IGP links
and can also include Traffic Engineering (TE) data. For
instance, prefix data can be carried and originated in
BGP, while TE data is originated and carried in an IGP.
The mechanism described is subject to policy control. Note
an ALTO Server can use other mechanisms to get network
data, for example, peering with multiple IGP and BGP
Speakers.</t>
<t>The Interface to the Routing System (I2RS) is a
solution for state transfer in and out of the Internet's
routing system <xref
target="I-D.ietf-i2rs-architecture"></xref>. An ALTO
server could use an I2RS client to observe routing-related
information.</t>
<t>An ALTO server can also leverage Network Management
Station (NMS) or an Operations Support System (OSS) as
data sources. A NMS or OSS solutions are used to control,
operate, and manage a network, e.g., using the Simple
Network Management Protocol (SNMP) or NETCONF. As
explained for instance in <xref
target="I-D.farrkingel-pce-abno-architecture"></xref>, the
NMS and OSS can be consumers of network events reported
and can act on these reports as well as displaying them to
users and raising alarms. The NMS and OSS can also access
the Traffic Engineering Database (TED) and Label Switched
Path Database (LSP-DB) to show the users the current state
of the network. In addition, NMS and OSS systems may have
access to IGP/BGP routing information, network inventory
data (e.g., links, nodes, or link properties not visible
to routing protocols, such as Shared Risk Link Groups),
statistics collection system that provides traffic
information, such as traffic demands or link utilizations
obtained from IP Flow Information Export (IPFIX), as well
as other information (e.g., syslog). NMS or OSS systems
also may have functions to correlate and orchestrate
information originating from other data sources. For
instance, it could be required to correlate IP prefixes
with routers (Provider, Provider Edge, Custumer Edge,
etc.), IGP areas, VLAN IDs, or policies.</t>
</list></t>
</section>
<section anchor="sec.ISP_deployment_req_other" title="Privacy Requirements">
<t>Providing ALTO guidance results in a win-win situation
both for network providers and users of the ALTO
information. Applications possibly get a better
performance, while the the network provider has means to
optimize the traffic engineering and thus its costs.</t>
<t>Still, ISPs may have other important requirements when
deploying ALTO: In particular, an ISP may not be willing
to expose sensitive operational details of its
network. The topology abstraction of ALTO enables an ISP
to expose the network topology at a desired granularity
only.</t>
<t>With the ALTO Endpoint Cost Service, the ALTO client does
not to have to implement any specific algorithm or mechanism
in order to retrieve, maintain and process network topology
information (of any kind). The complexity of the network
topology (computation, maintenance and distribution) is kept
in the ALTO server and ECS is delivered on demand. This
allows the ALTO server to enhance and modify the way the
topology information sources are used and combined. This
simplifies the enforcement of privacy policies of the
ISP.</t>
<t>The ALTO Network Map and Cost Map service expose an
abstracted view on the ISP network topology. Therefore, in
this case care is needed when constructing those maps, as
further discussed in <xref
target="host_group_descriptors"/>.</t>
</section>
<section anchor="host_group_descriptors" title="Map Partitioning and Grouping">
<t>Host group descriptors are used in the ALTO client
protocol to describe the location of a host in the network
topology. These identifiers are called Partition ID (PID)
and e.g. expand to a set of IP address ranges (CIDR).</t>
<t>An automated ALTO implementation may use dynamic
algorithms to aggregate network topology. However, it is
often desirable to have a mechanism through which the
network operator can control the level and details of
network aggregation based on a set of requirements and
constraints. This will typically be governed by policies
that enforce a certain level of abstraction and prevent
leakage of sensitive operational data.</t>
<t>For instance, an ALTO server may leverage BGP information
that is available in a networks service provider network
layer and compute the group of prefix. An example are BGP
Communities, which are used in MPLS/IP networks as a common
mechanism to aggregate and group prefixes. A BGP Community
is an attribute used to tag a prefix to group prefixes based
on mostly any criteria (as an example, most ISP networks
originate BGP prefixes with communities identifying the
Point of Presence (PoP) where the prefix has been
originated). These BGP communities could be used to map IP
address ranges to PIDs. By an additional policy, the ALTO
server operator may decide an arbitrary cost defined between
groups. Alternatively, there are algorithms that allows a
dynamic computation of cost between groups.</t>
</section>
<section anchor="rating_criteria" title="Rating Criteria and/or Cost Calculation">
<t>Rating criteria are used in the ALTO client protocol to
express topology- or connectivity-related properties, which
are evaluated in order to generate the ALTO guidance. The
ALTO client protocol specification defines a basic set of
rating criteria, which have to be supported by all
implementations, and an extension procedure for adding new
criteria.</t>
<t>The following list gives an overview on further rating
criteria that have been proposed or which are in use by
ALTO-related prototype implementations. This list is not
intended as normative text. Instead, the only purpose of the
following list is to document the rating criteria that have
been proposed so far. It can also depend on the use case of
ALTO whether such rating criteria are useful, and whether
the corresponding information would indeed be made
available by ISPs.</t>
<!--<section anchor="rating_criteria_distance"
title="Distance-related Rating Criteria">-->
<t>Distance-related rating criteria:</t>
<t><list style='symbols'>
<t>Relative topological distance: The term relative means that a
larger numerical value means greater distance, but it is
up to the ALTO service how to compute the values, and the
ALTO client will not be informed about the nature of the
information. One way of generating this kind of
information may be counting AS hops, but when querying
this parameter, the ALTO client must not assume that the
numbers actually are AS hops.</t>
<t>Absolute topological distance, expressed in the number
of traversed autonomous systems (AS).</t>
<t>Absolute topological distance, expressed in the number
of router hops (i.e., how much the TTL value of an IP
packet will be decreased during transit).</t>
<t>Absolute physical distance, based on knowledge of the
approximate geolocation (e.g., continent, country) of an IP
address.</t>
</list></t>
<!--</section>-->
<!--<section anchor="rating_criteria_performance"
title="Performance-related Rating Criteria">-->
<t>Performance-related rating criteria:</t>
<t><list style='symbols'>
<t>The minimum achievable throughput between the resource
consumer and the candidate resource provider, which is
considered useful by the application (only in ALTO
queries).</t>
<t>An arbitrary upper bound for the throughput from/to the
candidate resource provider (only in ALTO responses). This
may be, but is not necessarily the provisioned access
bandwidth of the candidate resource provider.</t>
<t>The maximum round-trip time (RTT) between resource
consumer and the candidate resource provider, which is
acceptable for the application for useful communication
with the candidate resource provider (only in ALTO queries).</t>
<t>An arbitrary lower bound for the RTT between resource
consumer and the candidate resource provider (only in ALTO
responses). This may be, for example, based on
measurements of the propagation delay in a completely
unloaded network. </t>
</list></t>
<!--<section anchor="rating_criteria_charging"
title="Charging-related Rating Criteria">-->
<t>Charging-related rating criteria:</t>
<t><list style='symbols'>
<t>Traffic volume caps, in case the Internet access of the
resource consumer is not charged by "flat rate". For each
candidate resource provider, the ALTO service could
indicate the amount of data that may be transferred
from/to this resource provider until a given point in
time, and how much of this amount has already been
consumed. Furthermore, it would have to be indicated how
excess traffic would be handled (e.g., blocked, throttled,
or charged separately at an indicated price). The
interaction of several applications running on a host, out
of which some use this criterion while others don't, as
well as the evaluation of this criterion in resource
directories, which issue ALTO queries on behalf of other
peers, are for further study.</t>
</list></t>
<!--</section>-->
<t>These rating criteria are subject to the remarks below:</t>
<t>The ALTO client must be aware, that with high
probability, the actual performance values differ
significantly from these upper and lower bounds. In
particular, an ALTO client must not consider the "upper
bound for throughput" parameter as a permission to send data
at the indicated rate without using congestion control
mechanisms.</t>
<t>The discrepancies are due to various reasons, including,
but not limited to the facts that</t>
<t><list style='symbols'>
<t>the ALTO service is not an admission control system</t>
<t>the ALTO service may not know the instantaneous
congestion status of the network</t>
<t>the ALTO service may not know all link bandwidths,
i.e., where the bottleneck really is, and there may be
shared bottlenecks</t>
<t>the ALTO service may not have all information about
the actual routing</t>
<t>the ALTO service may not know whether the candidate peer
itself is overloaded</t>
<t>the ALTO service may not know whether the candidate peer
throttles the bandwidth it devotes for the considered
application</t>
<t>the ALTO service may not know whether the candidate peer will
throttle the data it sends to us (e.g., because of some fairness
algorithm, such as tit-for-tat).</t>
</list></t>
<t>Because of these inaccuracies and the lack of complete,
instantaneous state information, which are inherent to the
ALTO service, the application must use other mechanisms
(such as passive measurements on actual data transmissions)
to assess the currently achievable throughput, and it must
use appropriate congestion control mechanisms in order to
avoid a congestion collapse. Nevertheless, these rating
criteria may provide a useful shortcut for quickly excluding
candidate resource providers from such probing, if it is
known in advance that connectivity is in any case worse than
what is considered the minimum useful value by the
respective application.</t>
<!--</section>-->
<!--<section anchor="rating_criteria_inappropriate"
title="Inappropriate Rating Criteria">-->
<t>Rating criteria that should not be defined for and used
by the ALTO service include:</t>
<t><list style='symbols'>
<t>Performance metrics that are closely related to the
instantaneous congestion status. The definition of
alternate approaches for congestion control is explicitly
out of the scope of ALTO. Instead, other appropriate
means, such as using TCP based transport, have to be used
to avoid congestion.</t>
<t>Performance metrics that raise privacy concerns. For
instance, it has been questioned whether an ALTO service
could publicly expose the provisioned access bandwidth,
e.g. of cable / DSL customers, because this could enables
identification of "premium" customers.</t>
<!--
<t>The provisioned access bandwidth, e.g. of cable / DSL
customers. This has been proposed several times and questioned,
because of problems with privacy, fears that "premium" customers
with high access bandwidth might attract so much traffic that
their service becomes de-facto worse, etc.</t>
-->
</list></t>
<!--</section>-->
</section>
</section>
<section anchor="risks" title="Known Limitations of ALTO">
<t>This section describes some known limitations of ALTO in
general or specific mechanisms in ALTO.</t>
<section title="Limitations of Map-based Approaches">
<t>The specification of the ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> uses so-called
network maps. The network map approach uses host group
descriptors that group one or multiple subnetworks (i.e., IP
prefixes) to a single aggregate. A set of IP prefixes is
called partition and the associated Host Group Descriptor is
called Partition ID (PID). The "costs" between the various
partition IDs is stored in a second map, the cost
map. Map-based approaches lower the signaling load on the
server as maps have to be retrieved only if they
change.</t>
<t>One main assumption for map-based approaches is that the
information provided in these maps is static for a longer
period of time. This assumption is fine as
long as the network operator does not change any parameter,
e.g., routing within the network and to the upstream peers,
IP address assignment stays stable (and thus the mapping to
the partitions). However, there are several cases where this
assumption is not valid:</t>
<t><list style="numbers">
<t>ISPs reallocate IP subnets from time to time;</t>
<t>ISPs reallocate IP subnets on short notice;</t>
<t>IP prefix blocks may be assigned to a router that serves
a variety of access networks;</t>
<t>Network costs between IP prefixes may change depending
on the ISP's routing and traffic engineering.</t>
</list></t>
<!-- text below is a copy of Rich Woundy's comment -->
<t>Explanation:</t>
<t>For 1): ISPs reallocate IPv4 subnets within their
infrastructure from time to time, partly to ensure the
efficient usage of IPv4 addresses (a scarce resource), and
partly to enable efficient route tables within their network
routers. The frequency of these "renumbering events" depend
on the growth in number of subscribers and the availability
of address space within the ISP. As a result, a subscriber's
household device could retain an IPv4 address for as short
as a few minutes, or for months at a time or even
longer.</t>
<t>It has been suggested that ISPs providing ALTO
services could sub-divide their subscribers' devices into
different IPv4 subnets (or certain IPv4 address ranges)
based on the purchased service tier, as well as based on the
location in the network topology. The problem is that this
sub-allocation of IPv4 subnets tends to decrease the
efficiency of IPv4 address allocation. A growing ISP that
needs to maintain high efficiency of IPv4 address
utilization may be reluctant to jeopardize their future
acquisition of IPv4 address space.</t>
<t>However, this is not an issue for map-based approaches if
changes are applied in the order of days.</t>
<!-- text above is a copy of Rich Woundy's comment -->
<t>For 2): ISPs can use techniques that allow the
reallocation of IP prefixes on very short notice, i.e.,
within minutes. An IP prefix that has no IP address
assignment to a host anymore can be reallocated to areas
where there is currently a high demand for IP addresses.</t>
<t>For 3): In residential access networks (e.g., DSL,
cable), IP prefixes are assigned to broadband gateways,
which are the first IP-hop in the access-network between the
Customer Premises Equipment (CPE) and the Internet. The
access-network between CPE and broadband gateway (called
aggregation network) can have varying characteristics (and
thus associated costs), but still using the same IP
prefix. For instance one IP addresses IP11 out of a IP
prefix IP1 can be assigned to a VDSL (e.g., 2 MBit/s uplink)
access line while the subsequent IP address IP12 is assigned
to a slow ADSL line (e.g., 128 kbit/s uplink). These IP
addresses are assigned on a first come first served basis,
i.e., the a single IP address out of the same IP prefix can
change its associated costs quite fast. This may not be an
issue with respect to the used upstream provider (thus the
cross ISP traffic) but depending on the capacity of the
aggregation-network this may raise to an issue.</t>
<!-- Below: Michael's comments -->
<t>For 4): The routing and traffic engineering inside an ISP
network, as well as the peering with other autonomous
systems, can change dynamically and affect the information
exposed by an ALTO server. As a result, cost map and
possibly also network maps can change.</t>
</section>
<section title="Limitiations of Non-Map-based Approaches">
<t>The specification of the ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> uses, amongst others
mechanism, a mechanism called Endpoint Cost Service
(ECS). ALTO clients can ask guidance for specific IP
addresses to the ALTO server. However, asking for IP
addresses, asking with long lists of IP addresses, and
asking quite frequently may overload the ALTO server. The
server has to rank each received IP address, which causes
load at the server. This may be amplified by the fact that
not only a single ALTO client is asking for guidance, but a
larger number of them. The results of the ECS are also more
difficult to cache than ALTO maps.</t>
<t>Caching of IP addresses at the ALTO client or the usage
of the H12 approach <xref
target="I-D.kiesel-alto-h12"></xref> in conjunction with
caching may lower the query load on the ALTO server.</t>
</section>
</section>
<section anchor="sec.monitoring" title="Monitoring the Performance of ALTO">
<section title="Supervising the Benefits of ALTO">
<t>An ISP providing ALTO may want to assess the benefits of
ALTO as part of the management and operations (cf. <xref
target="I-D.ietf-alto-protocol"></xref>). For instance, the
ISP might be interested in understanding whether the
provided ALTO maps are effective, and in order to decide
whether an adjustment of the ALTO configuration would be
useful. Such insight can be obtained from a monitoring
infrastructure. An NSP offering ALTO could consider the
impact on (or integration with) traffic engineering and the
deployment of a monitoring service to observe the effects of
ALTO operations. To construct an effective monitoring
infrastructure, the ISP should decise how to monitor the
performance of ALTO and identify and deploy data sources to
collect data to compute the performance metrics. The
required monitoring depends on the network infrastructure
and the use of ALTO, and an exhaustive description is
outside the scope of this document. </t>
</section>
<section title="How to Monitor ALTO Performance">
<t>ALTO realizes an interface between the network and
applications. This implies that an effective monitoring
infrastructure may have to deal with both network and
application performance metrics. This document does not
comprehensively list all performance metrics that could be
relevant, nor does it formally specify metrics.</t>
<t>The performance impact of ALTO can be classified in a
number of different categories:</t>
<t><list style='symbols'>
<t>Total amount and distribution of traffic: ALTO enables
ISPs to influence and localize traffic of applications
that use the ALTO service. An ISP may therefore be
interested in analyzing the impact on the traffic, i.e.,
whether network traffic patterns are shifted. For
instance, if ALTO shall be used to reduce the inter-domain
P2P traffic, it makes sense to evaluate the total amount
of inter-domain traffic of an ISP. Then, one possibility is to study
how the introduction of ALTO reduces the total interdomain
traffic (inbound and/our outbound). If the ISPs intention
is to localize the traffic inside his network, the
network-internal traffic distribution will be of
interest. Effectiveness of localization can be quantified
in different ways, e.g., by the load on core routers and
backbone links, or by considering more advanced effects,
such as the average number of hops that traffic traverses
inside a domain.</t>
<t>Application performance: The objective of ALTO is
improve application performance. ALTO can be used by very
different types applications, with different communication
characteristics and requirements. For instance, if ALTO
guidance achieves traffic localization, one would expect
that applications achieve a higher throughput and/or
smaller delays to retrieve data. Application-specific
performance characteristics (e.g., video or audio quality) can be
useful as well. In addition, selected statistics from
the TCP/IP stack in hosts can be useful, e.g., the
number of retransmitted TCP segments.</t>
<t>ALTO system performance: As mentioned in <xref
target="I-D.ietf-alto-protocol"></xref>, there are a
number of interesting parameters that can be measured at
an ALTO server, including the Requests and responses for
each service listed in a Information Directory (total
counts and size in bytes) or the CPU and memory
utilization. Also, the characteristics of the ALTO maps
can be monitored as well, e.g., regarding the frequency of
ALTO map updates, the number of PIDs, or the ALTO map
sizes (in-memory size, encoded size, number of
entries).</t>
<t>ALTO service utilization: Of potential interet can be
the share of applications or customers that actually use
an offered ALTO service, i.e., the degree of adoption.</t>
</list></t>
<t>Monitoring statistics can be aggregated,
averaged, and normalized in different ways. This document does
not mandate specific ways how to calculate metrics.</t>
<t>One way to quantify the benefit of deploying ALTO is to
measure before and after enabling the ALTO service. In
addition to passive monitoring, some data could also be
obtained by active measurements, but due to the resulting
overhead, the latter should be used with care. Yet, in all
monitoring activities an ALTO service provider has to take
into account that ALTO Clients are not bound to ALTO Server
guidance as ALTO is only one source of information, and any
measurement result may thus be biased.</t>
</section>
<section title="Monitoring Infrastructure">
<t>Understanding the impact of ALTO may require interaction
between different systems, operating at different layers.
Some information discussed in the preceding section is only
visible to an ISP, while application-level performance can
hardly be measured inside the network. It is possible that
not all information of potential interest can directly be
measured, either because no corresponding monitoring
infrastructure or measurement method exists, or because it
is not easily accessible.</t>
<t>Potential sources for monitoring the use of ALTO include:</t>
<t><list style='symbols'>
<t>Network Operations, Administration, and Maintenance (OAM)
systems: Many ISPs deploy OAM systems to monitor the
network traffic, which may have insight into traffic
volumes, network topology, and bandwidth information
inside the management area. Data can be obtained by SNMP,
Netflow, IP Flow Information Export (IPFIX), syslog,
etc.</t>
<t>Applications/clients: Relevant data could be obtained
by instrumentation of applications.</t>
<t>ALTO server: If available, log files or other
statistics data could be analyzed.</t>
<t>Other application entities: In several use cases, there
are other application entities that could provide data as well.
For instance, there may be centralized log servers that collect
data.</t>
</list></t>
<t>In many ALTO use cases some data sources are located
within an ISP while some other data is gathered at
application level. Correlation of data would require a
collaboration agreement between the ISP and an application
owner, including aggrements of data interchange formats,
methods of delivery, etc. In practice, such a collaboration
may not be possible in all use cases of ALTO, because the
monitoring data can be sensitive, and because the
interacting entities may have different priorities. Details
of how to build an over-arching monitoring system for
evaluating the benefits of ALTO are outside the scope of
this memo.</t>
</section>
</section>
<section anchor="sec.ISP_deployment2" title="Map Examples for Different Types of ISPs">
<section title="Small ISP with Single Internet Uplink">
<t>For a small ISP, the inter-domain traffic optimizing
problem is how to decrease the traffic exchanged with other
ISPs, because of high settlement costs. By using the ALTO
service to optimize traffic, a small ISP can define two
"optimization areas": one is its own network; the other one
consists of all other network destinations. The cost map can
be defined as follows: the cost of link between clients of
inner ISP's networks is lower than between clients of outer
ISP's networks and clients of inner ISP's network. As a
result, a host with ALTO client inside the network of this
ISP will prefer retrieving data from hosts connected to the
same ISP.</t>
<t>An example is given in <xref
target="fig.small_ISPs3"/>. It is assumed that ISP A is a
small ISP only having one access network. As operator of the
ALTO service, ISP A can define its network to be one
optimization area, named as PID1, and define other networks
to be the other optimization area, named as PID2. C1 is
denoted as the cost inside the network of ISP A. C2 is
denoted as the cost from PID2 to PID1, and C3 from PID1
to PID2. For the sake of simplifity, in the following C2=C3
is assumed. In order to keep traffic local inside ISP A, it
makes sense to define: C1<C2</t>
<figure anchor="fig.small_ISPs3"
title="Example ALTO deployment in small ISPs">
<artwork><![CDATA[
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 | | |
| | \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
]]></artwork>
</figure>
<t>A simplified extract of the corresponding ALTO network
and cost maps is listed in <xref
target="fig.small_ISP_network_map"/> and <xref
target="fig.small_ISP_cost_map"/>, assuming that the network
of ISP A has the IPv4 address ranges 192.0.2.0/24 and
198.51.100.0/25. In this example, the cost values C1 and C2
can be set to any number C1<C2.</t>
<figure anchor="fig.small_ISP_network_map"
title="Example ALTO network map">
<artwork><![CDATA[
HTTP/1.1 200 OK
...
Content-Type: application/alto-networkmap+json
{
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
]]></artwork>
</figure>
<figure anchor="fig.small_ISP_cost_map"
title="Example ALTO cost map">
<artwork><![CDATA[
HTTP/1.1 200 OK
...
Content-Type: application/alto-costmap+json
{
...
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": C1, "PID2": C2 },
"PID2": { "PID1": C2, "PID2": 0 },
}
}
]]></artwork>
</figure>
</section>
<section title="ISP with Several Fixed Access Networks">
<t>For a large ISP with a fixed network comprising several
access networks and a core network, the traffic optimizing
problems will include (1) using the backbone network
efficiently, (2) adjusting the traffic balance in different
access networks according to traffic conditions and
management policies, and (3) achieving a reduction of
settlement costs with other ISPs.</t>
<t>Such a large ISP deploying an ALTO service may want to
optimize its traffic according to the network topology of
its access networks. For example, each access network could
be defined to be one optimization area, i.e., traffic should
be kept locally withing that area if possible. Then the
costs between those access networks can be defined according
to a corresponding traffic optimizing requirement by
this ISP. One example setup is further described below and also
shown in <xref target="fig.large_ISPs"/>.</t>
<t>In this example, ISP A has one backbone network and three
access networks, named as AN A, AN B, and AN C. A P2P
application is used in this example. For the traffic
optimization, the first requirement is to decrease the P2P
traffic on the backbone network inside the Autonomous System
of ISP A; and the second requirement is to decrease the P2P
traffic to other ISPs, i.e., other Autonomous Systems. The
second requirement can be assumed to have priority over the
first one. Also, we assume that the settlement rate with ISP
B is lower than with other ISPs. Then ISP A can deploy an
ALTO service to meet these traffic optimization
requirements. In the following, we will give an example of
an ALTO setting and configuration according to these
requirements.</t>
<t>In inner network of ISP A, we can define each access
network to be one optimization area, and assign one PID to
each access network, such as PID 1, PID 2, and PID
3. Because of different peerings with different outer ISPs,
we define ISP B to be one optimization area, and we assign
PID 4 to it. We define all other networks to be one
optimization area and assign PID 5 to it.</t>
<t>We assign costs (C1, C2, C3, C4, C5, C6, C7, C8) as shown
in <xref target="fig.large_ISPs"/>. Cost C1 is denoted as
the link cost in inner AN A (PID 1), and C2 and C3 are
defined accordingly. C4 is denoted as the link cost from PID
1 to PID 2, and C5 is the correspinding cost from PID 3,
which is assumed to have a similar value. C6 is the cost
between PID 1 and PID 3. For simplicity, we assume
symmetrical costs between the AN this example. C7 is denoted
as the link cost from the ISP B to ISP A. C8 is the link
cost from other networks to ISP A.</t>
<t>According to previous discussion of the first requirement
and the second requirement, the relationship of these costs
will be defined as: (C1, C2, C3) < (C4, C5, C6) < (C7)
< (C8)</t>
<figure anchor="fig.large_ISPs"
title="ALTO deployment in large ISPs with layered fixed network structures">
<artwork><![CDATA[
+------------------------------------+ +----------------+
| ISP A +---------------+ | | |
| | Backbone | | C7 | ISP B |
| +--+ Network +---+ |<--------+ PID 4 |
| | +-------+-------+ | | | |
| | | | | | |
| | | | | +----------------+
| +---+--+ +--+---+ +-+----+ |
| |AN A | C4 |AN B | C5 |AN C | |
| |PID 1 +<-->|PID 2 |<--->+PID 3 | |
| |C1 | |C2 | |C3 | | +----------------+
| +---+--+ +------+ +-+----+ | | |
| | | | C8 | Other Networks |
| +----------------------+ |<--------+ PID 5 |
| C6 | | |
| | | |
+------------------------------------+ +----------------+
]]></artwork>
</figure>
</section>
<section title="ISP with Fixed and Mobile Network">
<t>An ISP with both mobile network and fixed network my
focus on optimizing the mobile traffic by keeping traffic in
the fixed network as far as possible, because wireless
bandwidth is a scarce resource and traffic is costly in
mobile network. In such a case, the main requirement of
traffic optimization could be decreasing the usage
of radio resources in the mobile network. An ALTO service
can be deployed to meet these needs.</t>
<t><xref target="fig.mobile_ISPs2"/> shows an example: ISP A
operates one mobile network, which is connected to a
backbone network. The ISP also runs two fixed access
networks AN A and AN B, which are also connected to the
backbone network. In this network structure, the mobile
network can be defined as one optimization area, and PID 1
can be assigned to it. Access networks AN A and B can also
be defined as optimization areas, and PID 2 and PID 3 can be
assigned, respectively. The cost values are then defined as
shown in <xref target="fig.mobile_ISPs2"/>.</t>
<t>To decrease the usage of wireless link, the relationship
of these costs can be defined as follows:</t>
<t>From view of mobile network: C4 < C1. This means that
clients in mobile network requiring data resource from other
clients will prefer clients in AN A to clients in the mobile
network. This policy can decrease the usage of wireless
link and power consumption in terminals.</t>
<t>From view of AN A: C2 < C6, C5 = maximum cost. This
means that clients in other optimization area will avoid
retrieving data from the mobile network.</t>
<figure anchor="fig.mobile_ISPs2" title="ALTO deployment in ISPs with mobile network">
<artwork><![CDATA[
+-----------------------------------------------------------------+
| |
| ISP A +-------------+ |
| +--------+ ALTO +---------+ |
| | | Service | | |
| | +------+------+ | |
| | | | |
| | | | |
| | | | |
| +-------+-------+ | C6 +--------+------+ |
| | AN A |<--------------| AN B | |
| | PID 2 | C7 | | PID 3 | |
| | C2 |-------------->| C3 | |
| +---------------+ | +---------------+ |
| ^ | | | ^ |
| | | | | | |
| | |C4 | | | |
| C5 | | | | | |
| | | +--------+---------+ | | |
| | +-->| Mobile Network |<---+ | |
| | | PID 1 | | |
| +------- | C1 |----------+ |
| +------------------+ |
+-----------------------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec.alto_p2p_expectations" title="Deployment Experiences">
<t>The examples in the previous section are simple and do not
consider specific requirements inside access networks, such
as different link types. Deploying an ALTO
service in real network will have to require further network
conditions and requirements. One real example is described in
greater detail in reference <xref
target="I-D.lee-alto-chinatelecom-trial"></xref>.</t>
<t>Also, experiments have been conducted with ALTO-like
deployments in Internet Service Provider (ISP) networks. For
instance, NTT performed tests with their HINT server
implementation and dummy nodes to gain insight on how an
ALTO-like service influence peer-to-peer systems <xref
target="I-D.kamei-p2p-experiments-japan"></xref>. The results
of an early experiment conducted in the Comcast network are
documented in <xref target="RFC5632"></xref>.</t>
</section>
</section>
<section anchor="sec.p2p_cons" title="Using ALTO for P2P Traffic Optimization">
<section title="Overview">
<section title="Usage Scenario">
<t>Peer-to-peer applications can be build without and with
use of a centralized resource directory ("tracker"). The
scope of this section is the interaction of P2P
applications with the ALTO service, focusing on the
use case with a centralized resource directory. In this
scenario, the resource consumer ("peer") asks the resource
directory for a list of candidate resource providers, which
can provide the desired resource.</t>
<t>For efficiency reasons (i.e., message size), usually only
a subset of all resource providers known to the resource
directory will be returned to the resource consumer. Some
or all of these resource providers, plus further resource
providers learned by other means such as direct
communication between peers, will be contacted by the
resource consumer for accessing the resource. The purpose
of ALTO is giving guidance on this peer selection, which is
supposed to yield better-than-random results. The tracker
response as well as the ALTO guidance are most beneficial in
the initial phase after the resource consumer has decided to
access a resource, as long as only few resource providers
are known. Later, when the resource consumer has already
exchanged some data with other peers and measured the
transmission speed, the relative importance of ALTO may
dwindle.</t>
</section>
<section title="Applicability of ALTO">
<t>A tracker-based P2P application can leverage ALTO in
different ways. In the following, the different alternatives
and their pros and cons are discussed.</t>
<figure anchor="fig.global_tracker"
title="Global tracker accessing ALTO server at various ISPs">
<artwork><![CDATA[ ,-------.
,---. ,-' `-. +-----------+
,-' `-. / ISP 1 \ | Peer 1 |*****
/ \ / +-------------+ \ | | *
/ ISP X \ +=====>| ALTO Server | )+-----------+ *
/ \ = \ +-------------+ / +-----------+ *
; +-----------+ : = \ / | Peer 2 | *
| | Tracker |<====+ `-. ,-' | |*****
| |ALTO Client|<====+ `-------' +-----------+ **
| +-----------+ | = ,-------. **
: * ; = ,-' `-. +-----------+ **
\ * / = / ISP 2 \ | Peer 3 | **
\ * / = / +-------------+ \ | |*****
\ * / +=====>| ALTO Server | )+-----------+ ***
`-. * ,-' \ +-------------+ / +-----------+ ***
`-*-' \ / | Peer 4 |*****
* `-. ,-' | | ****
* `-------' +-----------+ ****
* ****
* ****
***********************************************<******
Legend:
=== ALTO client protocol
*** Application protocol
]]></artwork>
</figure>
<t><xref target="fig.global_tracker"></xref> depicts a
tracker-based system in which the tracker embeds the ALTO
client. The tracker itself is hosted and operated by an
entity different than the ISP hosting and operating the ALTO
server. A tracker outside the network of the ISP is the
typical use case. For instance, a tracker like Pirate Bay
can serve Bittorrent peers world-wide. Initially, the
tracker has to look-up the ALTO server in charge for each
peer where it receives a ALTO query for. Therefore, the
ALTO server has to discover the handling ALTO server, as
described in <xref
target="I-D.ietf-alto-server-discovery"></xref>. However,
the peers do not have any way to query the server
themselves. This setting allows giving the peers a better
selection of candidate peers for their operation at an
initial time, but does not consider peers learned through
direct peer-to-peer knowledge exchange. This is called peer
exchange (PEX) in bittorent, for instance.</t>
<t><figure anchor="fig.localALTOServer"
title="Global Tracker - Local ALTO Servers">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. +==>| Peer 1 |*****
,-' `-. / ISP 1 \ = |ALTO Client| *
/ \ / +-------------+<=+ +-----------+ *
/ ISP X \ | + ALTO Server |<=+ +-----------+ *
/ \ \ +-------------+ /= | Peer 2 | *
; +---------+ : \ / +==>|ALTO Client|*****
| | Global | | `-. ,-' +-----------+ **
| | Tracker | | `-------' **
| +---------+ | ,-------. +-----------+ **
: * ; ,-' `-. +==>| Peer 3 | **
\ * / / ISP 2 \ = |ALTO Client|*****
\ * / / +-------------+<=+ +-----------+ ***
\ * / | | ALTO Server |<=+ +-----------+ ***
`-. * ,-' \ +-------------+ /= | Peer 4 |*****
`-*-' \ / +==>|ALTO Client| ****
* `-. ,-' +-----------+ ****
* `-------' ****
* ****
***********************************************<****
Legend:
=== ALTO client protocol
*** Application protocol
]]></artwork>
</figure></t>
<t>The scenario in <xref
target="fig.localALTOServer"></xref> lets the peers
directly communicate with their ISP's ALTO server (i.e.,
ALTO client embedded in the peers), giving thus the peers
the most control on which information they query for, as
they can integrate information received from trackers and
through direct peer-to-peer knowledge exchange.</t>
<t><figure anchor="fig-p4p_approach"
title="P4P approach with local tracker and local ALTO server">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' ISP 1 `-. ***>| Peer 1 |
,-' `-. /+-------------+\ * | |
/ \ / + Tracker |<** +-----------+
/ ISP X \ | +-----===-----+<** +-----------+
/ \ \ +-----===-----+ /* | Peer 2 |
; +---------+ : \+ ALTO Server |/ ***>| |
| | Global | | +-------------+ +-----------+
| | Tracker | | `-------'
| +---------+ | +-----------+
: ^ ; ,-------. | Peer 3 |
\ * / ,-' ISP 2 `-. ***>| |
\ * / /+-------------+\ * +-----------+
\ * / / + Tracker |<** +-----------+
`-. *,-' | +-----===-----+ | | Peer 4 |<*
`---* \ +-----===-----+ / | | *
* \+ ALTO Server |/ +-----------+ *
* +-------------+ *
* `-------' *
***********************************************
Legend:
=== ALTO client protocol
*** Application protocol
]]></artwork>
</figure></t>
<t>There are some attempts to let ISP's to deploy their
own trackers, as shown in <xref
target="fig-p4p_approach"></xref>. In this case, the
client has no chance to get guidance from the ALTO server,
other than talking to the ISP's tracker. However, the
peers would have still chance the contact other trackers,
deployed by entities other than the peer's ISP.</t>
<t><xref target="fig-p4p_approach"></xref> and <xref
target="fig.global_tracker"></xref> ostensibly take peers
the possibility to directly query the ALTO server, if the
communication with the ALTO server is not permitted for
any reason. However, considering the plethora of different
applications of ALTO, e.g., multiple tracker and
non-tracker based P2P systems and or applications
searching for relays, it seems to be beneficial for all
participants to let the peers directly query the ALTO
server. The peers are also the single point having all
operational knowledge to decide whether to use the ALTO
guidance and how to use the ALTO guidance. This is a
preference for the scenario depicted in Figure <xref
target="fig.localALTOServer"></xref>.</t>
</section>
</section>
<section title="Deployment Recommendations">
<section title="ALTO Services">
<t>In case of peer-to-peer networks, two different ALTO
services can be used: The Cost Map Service is often prefered
as solution by peer-to-peer software implementors and users,
since it avoids disclosuring peer IP addresses to a
centralized entity. Different to that, network operators may
have a preference for the Endpoint Cost Service, since it does
not require exposure of the network topology.</t>
<t>For actual use of ALTO in P2P applications, both software
vendors and network operators have to agree which ALTO
services to use. The ALTO protocol is flexible and supports
both services. Note that for other use cases of ALTO, in
particular in more controlled environments, both the Cost
Map Service as well as ECS might be feasible and it is more
an engineering tradeoff whether to use a map-based or
query-based ALTO service.</t>
</section>
<section anchor="sec.alto_in_tracker_p2p" title="Guidance Considerations">
<t>The ALTO protocol specification <xref
target="I-D.ietf-alto-protocol"/> details how an ALTO client
can query an ALTO server for guiding information and receive
the corresponding replies. However, in the considered
scenario of a tracker-based P2P application, there are two
fundamentally different possibilities where to place the
ALTO client:</t>
<t><list style='numbers'>
<t>ALTO client in the resource consumer ("peer")</t>
<t>ALTO client in the resource directory ("tracker")</t>
</list></t>
<t>In the following, both scenarios are compared in order to
explain the need for third-party ALTO queries.</t>
<t>In the first scenario (see <xref target="fig.rcq"/>), the
resource consumer queries the resource directory for the
desired resource (F1). The resource directory returns a
list of potential resource providers without considering
ALTO (F2). It is then the duty of the resource consumer to
invoke ALTO (F3/F4), in order to solicit guidance regarding
this list.</t>
<t><figure anchor="fig.rcq"
title="Basic message sequence chart for resource consumer-initiated ALTO query">
<artwork><![CDATA[
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO client protocol query |
|---------------------------------------------->|
| F4 ALTO client protocol reply |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
]]></artwork>
</figure></t>
<t>In the second scenario (see <xref target="fig.3pq"/>),
the resource directory has an embedded ALTO client, which we
will refer to as RDAC in this document. After receiving a
query for a given resource (F1) the resource directory
invokes the RDAC to evaluate all resource providers it knows
(F2/F3). Then it returns a, possibly shortened, list
containing the "best" resource providers to the resource
consumer (F4).</t>
<t><figure anchor="fig.3pq"
title="Basic message sequence chart for third-party ALTO query">
<artwork><![CDATA[
Peer Tracker w. RDAC ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO cli. p. query |
| |---------------------->|
| | F3 ALTO cli. p. reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
]]></artwork>
</figure></t>
<t>Note: the message sequences depicted in <xref
target="fig.rcq"/> and <xref target="fig.3pq"/> may occur
both in the target-aware and the target-independent query
mode (c.f. <xref target="RFC6708"/>). In the
target-independent query mode no message exchange with the
ALTO server might be needed after the tracker query, because
the candidate resource providers could be evaluated using a
locally cached "map", which has been retrieved from the ALTO
server some time ago.</t>
<t>The first approach has the following problem: While the
resource directory might know thousands of peers taking part
in a swarm, the list returned to the resource consumer is
usually shortened for efficiency reasons. Therefore, the
"best" (in the sense of ALTO) potential resource providers
might not be contained in that list anymore, even before
ALTO can consider them.</t>
<t>Much better traffic optimization could be achieved if the
tracker would evaluate all known peers using ALTO. This list
would then include a significantly higher fraction of "good"
peers. (Note, that if the tracker returned "good" peers
only, there might be a risk that the swarm might disconnect
and split into several disjunct partitions. However,
finding the right mix of ALTO-biased and random peer
selection is out of the scope of this document.) </t>
<t>Therefore, from an overall optimization perspective, the
second scenario with the ALTO client embedded in the
resource directory is advantageous, because it is ensured
that the addresses of the "best" resource providers are
actually delivered to the resource consumer. An
architectural implication of this insight is that the ALTO
server discovery procedures must support third-party
discovery. That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker
must be able to discover an ALTO server that can give
guidance suitable for that respective peer (see <xref
target="I-D.kist-alto-3pdisc"></xref>).</t>
</section>
</section>
</section>
<section anchor="sec.cdn_cons" title="Using ALTO for CDNs">
<section title="Overview">
<section title="Usage Scenario">
<t>This section discuss the usage of ALTO for Content
Delivery Networks (CDNs) <xref
target="I-D.jenkins-alto-cdn-use-cases"></xref>. CDNs are
used in the delivery of some Internet services
(e.g. delivery of websites, software updates and video
delivery) from a location closer to the location of the
user. A CDN typically consists of a network of servers often
attached to Network Service Provider (NSP) networks. The
point of attachment is often as close to content consumers
and peering points as economically or operationally feasible
in order to decrease traffic load on the NSP backbone and to
provide better user experience measured by reduced latency
and higher throughput.</t>
<t>CDNs use several techniques to redirect a client to a
server (surrogate). A request routing function within a CDN
is responsible for receiving content requests from user
agents, obtaining and maintaining necessary information
about a set of candidate surrogates, and for selecting and
redirecting the user agent to the appropriate surrogate. One
common way is relying on the DNS system, but there are many
other ways, see <xref target="RFC3568"></xref>.</t>
<t>In order to derive the optimal benefit from a CDN it
is preferable to deliver content from the servers (caches)
that are "closest" to the end user requesting the
content. "closest" may be as simple as geographical or IP
topology distance, but it may also consider other
combinations of metrics and CDN or Network Service Provider
(NSP) policies.</t>
<t><figure anchor="fig.cdn_redirection"
title="Example of CDN surrogate selection">
<artwork><![CDATA[
User Agent Request Router Surrogate
| | |
| F1 Initial Request | |
+---------------------------->| |
| +--+ |
| | | F2 Surrogate Selection |
| |<-+ (using ALTO) |
| F3 Redirection Response | |
|<----------------------------+ |
| | |
| F4 Content Request | |
+-------------------------------------------------------->|
| | |
| | F5 Content |
|<--------------------------------------------------------+
| | |
]]></artwork>
</figure></t>
<t><xref target="fig.cdn_redirection"/> illustrates the
interaction between a user agent, a request router, and a
surrogate for the delivery of content in a single CDN. As
also explained in <xref
target="I-D.jenkins-alto-cdn-use-cases"></xref>, the user
agent makes an initial request to the CDN (F1). This may be
an application-level request (e.g. HTTP, RTMP, etc.) or a
DNS request. In the second step (F2), the request router
selects an appropriate surrogate (or set of Surrogates)
based on the user agent's (or its proxy's) IP address, the
request router's knowledge of the network topology (which
can be obtained by ALTO) and reachability cost between CDN
caches and end users, and any additional CDN policies. Then,
the request router responds to the initial request with an
appropriate response containing a redirection to the
selected cache, for example by returning an appropriate DNS
A/AAAA record, a HTTP 302 redirect, etc. (F3). The user
agent uses this information to connect directly to the
surrogate and request the desired content (F4), which is
then delivered (F5).</t>
<t>In addition to use by a single CDN, ALTO can also be used
in scenarios that interconnect several CDNs. This use case
is detailed in <xref
target="I-D.seedorf-cdni-request-routing-alto"></xref>.</t>
</section>
<section title="Applicability of ALTO">
<t>The most simple use case for ALTO in a CDN context is to
improve the selection of a CDN surrogate or origin. In this
case, the CDN makes use of an ALTO server to choose a better
CDN surrogate or origin than would otherwise be the
case. Although it is possible to obtain raw network map and
cost information in other ways, for example passively
listening to the NSP's routing protocols or use of active
probing, the use of an ALTO service to expose that
information may provide additional control to the NSP over
how their network map/cost is exposed. Additionally it may
enable the NSP to maintain a functional separation between
their routing plane and network map computation functions.
This may be attractive for a number of reasons, for
example:</t>
<t><list style="symbols">
<t>The ALTO service could provide a filtered view of the
network and/or cost map that relates to CDN locations and
their proximity to end users, for example to allow the NSP
to control the level of topology detail they are willing
to share with the CDN.</t>
<t>The ALTO service could apply additional policies to the
network map and cost information to provide a CDN-specific
view of the network map/cost, for example to allow the NSP
to encourage the CDN to use network links that would not
ordinarily be preferred by a Shortest Path First routing
calculation.</t>
<t>The routing plane may be operated and controlled by a
different operational entity (even within a single NSP) to
the CDN. Therefore, the CDN may not be able to passively
listen to routing protocols, nor may it have access to
other network topology data (e.g., inventory
databases).</t>
</list></t>
<t>When CDN servers are deployed outside of an NSP's network
or in a small number of central locations within an NSP's
network a simplified view of the NSP's topology or an
approximation of proximity is typically sufficient to enable
the CDN to serve end users from the optimal server/location.
As CDN servers are deployed deeper within NSP networks it
becomes necessary for the CDN to have more detailed
knowledge of the underlying network topology and costs
between network locations in order to enable the CDN to
serve end users from the most optimal servers for the
NSP.</t>
<t>The request router in a CDN will typicallly also take
into account criteria and constraints that are not related
to network topology, such as the current load of CDN surrogates,
content owner policies, end user subscriptions, etc. This document
only discusses use of ALTO for network information.</t>
<!-- DNS -->
<t>A general issue for CDNs is that the CDN logic
has to match the client's IP address with the closest CDN
surrogate, both for DNS or HTTP redirect based approaches
(see, for instance, <xref
target="I-D.penno-alto-cdn"></xref>). This matching is not
trivial, for instance, in DNS based approaches, where the IP
address of the DNS original requester is unknown (see <xref
target="I-D.vandergaast-edns-client-ip"></xref> for a
discussion of this and a solution approach).</t>
</section>
</section>
<section title="Deployment Recommendations">
<section title="ALTO Services">
<t>In its simplest form an ALTO server would provide an NSP
with the capability to offer a service to a CDN that
provides network map and cost information. The CDN can use
that data to enhance its surrogate and/or origin
selection. An alternative would be the Endpoint Cost Service
(ECS).</t>
<!-- Map -->
<t> If an NSP offers an ALTO network and cost map service to
expose a cost mapping/ranking between end user IP subnets
(within that NSP's network) and CDN surrogate IP
subnets/locations, periodic updates of the maps may be
needed. It is common for broadband subscribers to obtain
their IP addresses dynamically and in many deployments the
IP subnets allocated to a particular network region can
change relatively frequently, even if the network topology
itself is reasonably static.</t>
<!-- ECS -->
<t>An alternative would be to use the ALTO Endpoint Cost
Service (ECS): When an end user request a given content, the CDN
request router issues an ECS request with the endpoint
address (IPv4/IPv6) of the end user (content requester) and
the set of endpoint addresses of the surrogate (content
targets). The ALTO server receives the request and ranks
the list of content targets addresses based on their
distance from the content requester. Once the request router
obtained from the ALTO Server the ranked list of locations
(for the specific user), it can incorporate this information
into its selection mechanisms in order to point the user to
the most appropriate surrogate.</t>
<t>When ALTO server receives an ECS request, it may not have
the most appropriate topology information in order to
accurately determine the ranking. In such a case the ALTO
server may want to adopt the following strategies:</t>
<t><list style="symbols">
<t>Reply with available information (best effort).</t>
<t>Redirect the request to another ALTO server presumed to
have better topology information (redirection).</t>
<t>Doing both (best effort and redirection). In this
case, the reply message contains both the rankings and the
indication of another ALTO server where more accurate
rankings may be delivered.</t>
</list></t>
<t>The decision process that is used to determine if
redirection is necessary and which mode to use is out of the
scope of this document.</t>
<!-- Map vs. ECS -->
<t>Since CDNs operate in a controlled environment, the ALTO
network/cost map service and ECS have a similar level of
security and confidentiality of network-internal
information. However, the network/cost map service and ECS
differ in the way the ALTO service is delivered and address
a different set of requirements in terms of topology
information and network operations.</t>
<t>In order to address the scalability limitations of ECS
and to reduce the number of transactions between CDN and
ALTO server, a request router that uses ECS could cache the
results of ECS queries for later usage. The ALTO server may
indicate in the reply message how long the content of the
message is to be considered reliable and insert a lifetime
value that will be used by the CDN in order to cache (and
then flush or refresh) the entry.</t>
</section>
<section title="Guidance Considerations">
<t>In the following, some deployment scenarios for ALTO
are outlined, as examples to demonstrate how a CDN could
make use of ALTO services.</t>
<t>In one deployment scenarion, ALTO could expose NSP end
user reachability to a CDN. The request router needs to have
information on which end user IP subnets are reachable via
which networks or network locations. The network map
services offered by ALTO could be used to expose this
topology information while avoiding routing plane peering
between the NSP and the CDN. For example, if CDN surrogates
are deployed within the access or aggregation network, the
NSP is likely to want to utilise the surrogates deployed in
the same access/aggregation region in preference to
surrogates deployed elsewhere, in order to alleviate the
cost and/or improve the user experience.</t>
<t>In addition, CDN surrogates could use ALTO guidance as
well, e.g., if there is more than one upstream source of
content or several origins. ALTO could help a surrogate
with the decision which upstream source to use.</t>
<t>If content can be provided by several CDNs, there may be
a need to interconnect these CDNs. In this case, ALTO can be
uses as interface <xref
target="I-D.seedorf-cdni-request-routing-alto"></xref>, in
particular for footprint and capabilities advertisement
interface. As explained in <xref
target="I-D.seedorf-cdni-request-routing-alto"></xref>, this
specific variant of using ALTO requires protocol extensions
and is therefore not further detailed in this document.</t>
<t>Other and more advanced scenarios of deploying ALTO are
also listed in <xref
target="I-D.jenkins-alto-cdn-use-cases"></xref> and <xref
target="I-D.penno-alto-cdn"></xref>.</t>
<!-- Granularity -->
<t>The granularity of ALTO information required depends on
the specific deployment of the CDN. For example, an
over-the-top CDN whose surrogates are deployed only within
the Internet "backbone" may only require knowledge of which
end user IP subnets are reachable via which NSPs' networks,
whereas a CDN deployed within a particular NSP's network
requires a finer granularity of knowledge.</t>
<!-- Ranking and Network Events -->
<t>ALTO server ranks addresses based on topology information
it acquires from the network. By default, according to
<xref target="I-D.ietf-alto-protocol"/>, distance in ALTO
represents the routing cost as computed by the routing layer
(e.g., OSPF, ISIS, BGP), but it may also take into
consideration other routing criteria such as MPLS-VPN
(MP-BGP) and MPLS-TE (RSVP), policy and state and
performance information in addition to other information
sources (policy, geo-location, state, and performance), as
explained in <xref target="sec.data_sources"/>.</t>
<t>The different methods and algorithms through which the
ALTO server computes topology information and rankings is
out of the scope of this document. However, and in the case
the rankings are based on routing (IP/MPLS) topology, it is
obvious that network events may impact the ranking
computation. Due to internal redundancy and resilience
mechanisms inside current networks, most of the network
events happening in the infrastructure will have limited
impact on a CDN. However, catastrophic events such as main
trunks failures or backbone partition will have to take into
account by the ALTO server so to redirect traffic away from
the failure impacted area. An ALTO server implementation may
want to keep state about ALTO clients so to inform and
signal to these clients when a major network event happened
so to clear the ALTO cache in the client. In a CDN/ALTO
interworking architecture where there's a few CDN component
interacting with the ALTO server there are no scalability
issues in maintaining state about clients in the ALTO
server.</t>
</section>
</section>
</section>
<section title="Other Use Cases">
<t>This section briefly surveys and references other use cases that have been suggested for ALTO.</t>
<section title="Virtual Private Networks (VPNs)">
<t>Virtual Private Network (VPN) technology is widely used in
public and private networks to create groups of users that are
separated from other users of the network and allows these
users to communicate among them as if they were on a private
network. Network Service Providers (NSPs) offer different
types of VPNs. <xref target="RFC4026"/> distinguishes between
Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) using different
sub-types. In the following, the term "VPN" is used to refer
to provider supplied virtual private networking.</t>
<t>ALTO topology exposure is also very useful for providing
application guidance in VPNs, so that applications do not have
to perform excessive measurements on their own. For instance,
potential use cases for ALTO optimization over VPNs are:</t>
<t><list style="symbols">
<t>Enterprise application optimization: Enterprise customers often
run distributed applications that exchange large amounts of data,
e.g., for synchronization of replicated data bases. Both for
placement of replicas as well as for the scheduling of transfers
insight into network topology information could be useful.</t>
<t>Private cloud computing solution: An enterprise customer could
run own data centers at the four sites. The cloud management system
could want to understand the network costs between different
sites for intelligent routing and placement
decisions of Virtual Machines (VMs) among the VPN sites.</t>
<t>Cloud-bursting: One or more VPN endpoints could be located
in a public cloud. If an enterprise customer needs additional
resources, they could be provided by a public cloud, which is
accessed through the VPN. Network topology awareness would
help to decide in which data center of the public cloud
those resources should be allocated.</t>
</list></t>
<t>These examples focus on enterprise customers of NSPs, which
are typical users of provider-supplied VPNs. Such VPN
customers typically have no insight into the network topology
that transports the VPN. If better-than-random decisions would
be enabled by an ALTO server offered by the NSP, as
illustrated in Figure <xref target="fig.vpn"></xref>.</t>
<figure title="Using ALTO in VPNs"
anchor="fig.vpn"><artwork><![CDATA[
+---------------+
| Customer's |
| management |
| application |.
| (ALTO client) | .
+---------------+ . VPN provisioning
^ . (out-of-scope)
| ALTO .
V .
+---------------------+ +----------------+
| ALTO server | | VPN portal/OSS |
| provided by NSP | | (out-of-scope) |
+---------------------+ +----------------+
^ VPN network
* and cost maps
*
/---------*---------\ Network service provider
| * |
+-------+ _______________________ +-------+
| App a | ()_____. .________. .____() | App d |
+-------+ | | | | | | +-------+
\---| |--------| |--/
| | | |
|^| |^| Customer VPN
V V
+-------+ +-------+
| App b | | App c |
+-------+ +-------+
]]></artwork></figure>
<t>A common characteristic of these use cases is that
applications will not necessarily run in the public Internet,
and that the relationship between the provider and customer of
the VPN is rather well-defined. Since VPNs run often in a
managed environment, an ALTO server may have access to
topology information (e.g., traffic engineering data) that
would not be available for the public Internet, and it may
expose it to the customer of the VPN only.</t>
<t>Also, A VPN will not necessarily be static. The customer
could possibly modify the VPN and add new VPN sites by a Web
portal or other Operation Support Systems (OSS)
solutions. Prior to adding a new VPN site, an application will
not be have connectivity to that site, i.e., an ALTO server
could offer access to information that an application cannot
measure on its own (e.g., expected delay to a new VPN
site).</t>
<t>The VPN use cases, requirements, and solutions are further
detailed in <xref
target="I-D.scharf-alto-vpn-service"></xref>.</t>
</section>
<section anchor="sec.p2pcache" title="In-Network Caching">
<t>Deployment of intra-domain P2P caches has been proposed for
a cooperations between the network operator and the P2P
service providers, e.g., to reduce the bandwith consumption in
access networks <xref
target="I-D.deng-alto-p2pcache"></xref>.</t>
<t><figure anchor="fig.p2pcache"
title="General architecture of intra-ISP caches">
<artwork><![CDATA[
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +---------+ |
| |L1 Cache | |
| +-----+---+ |
| +--------------------+----------------------+ |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | AN1 | | AN2 | | AN3 | |
| | +---------+ | | +----------+ | | | |
| | |L2 Cache | | | |L2 Cache | | | | |
| | +---------+ | | +----------+ | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | |
| +--------------------+ | |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | |
| | +---------+ | | | | | |
| | |L3 Cache | | | | | | |
| | +---------+ | | | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | | |
+--------+--------------------+----------------------+----------+
| | |
+---+---+ +---+---+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4| |Peer5| |Peer6|
+-----+ +-----+ +-----+ +-----+ +-----+
]]></artwork>
</figure></t>
<t><xref target="fig.p2pcache"/> depics the overall
architecture of a potential P2P cache deployments inside an
ISP 2 with various access network types. As shown in the
figure, P2P caches may be deployed at various levels,
including the interworking gateway linking with other ISPs,
internal access network gateways linking with different types
of accessing networks (e.g. WLAN, cellular and wired), and
even within an accessing network at the entries of individual
WLAN sub-networks. Moreover, depending on the network context
and the operator's policy, each cache can be a Forwarding
Cache or a Bidirectional Cache <xref
target="I-D.deng-alto-p2pcache"></xref>.</t>
<t>In such a cache architecture, the locations of caches could
be used as dividers of different PIDs to guide intra-ISP
network abstraction and mark costs among them according to the
location and type of relevant caches.</t>
<t>Further details and deployment considerations can be found
in <xref target="I-D.deng-alto-p2pcache"></xref>.</t>
</section>
<section title="Other Use Cases">
<t>TODO</t>
</section>
</section>
<section title="Security Considerations">
<t>The ALTO protocol itself as well as the ALTO client and
server raise new security issues beyond the ones mentioned in
<xref target="I-D.ietf-alto-protocol"></xref> and issues related
to message transport over the Internet. For instance, Denial of
Service (DoS) is of interest for the ALTO server and also for
the ALTO client. A server can get overloaded if too many TCP
requests hit the server, or if the query load of the server
surpasses the maximum computing capacity. An ALTO client can get
overloaded if the responses from the sever are, either
intentionally or due to an implementation mistake, too large to
be handled by that particular client.</t>
<t>This section is solely giving a first shot on security issues
related to ALTO deployments.</t>
<section title="Information Leakage from the ALTO Server">
<t>The ALTO server will be provisioned with information about
the owning ISP's network and very likely also with information
about neighboring ISPs. This information (e.g., network
topology, business relations, etc.) is considered to be
confidential to the ISP and must not be revealed.</t>
<t>The ALTO server will naturally reveal parts of that
information in small doses to peers, as the guidance given
will depend on the above mentioned information. This is seen
beneficial for both parties, i.e., the ISP's and the
peer's. However, there is the chance that one or multiple
peers are querying an ALTO server with the goal to gather
information about network topology or any other data
considered confidential or at least sensitive. It is unclear
whether this is a real technical security risk or whether this
is more a perceived security risk.</t>
</section>
<section title="ALTO Server Access">
<t>Depending on the use case of ALTO, several access
restrictions to an ALTO server may or may not apply.</t>
<t>For peer-to-peer applications, a potential deployment
scenario is that an ALTO server is solely accessible by peers
from the ISP network (as shown in <xref
target="fig.localALTOServer"></xref>). For instance, the
source IP address can be used to grant only access from that
ISP network to the server. This will "limit" the number of
peers able to attack the server to the user's of the ISP
(however, including botnet computers).</t>
<t>If the ALTO server has to be accessible by parties not
located in the ISP's network (see Figure <xref
target="fig.global_tracker"></xref>), e.g., by a third-party
tracker or by a CDN system outside the ISP's network, the
access restrictions have to be looser. In the extreme
case, i.e., no access restrictions, each and every host in the
Internet can access the ALTO server. This might no be the
intention of the ISP, as the server is not only subject to
more possible attacks, but also on the load imposed to the
server, i.e., possibly more ALTO clients to serve and thus
more work load.</t>
<t>There are also use cases where the access to the ALTO
server has to be much more strictly controlled, i. e., where
an authentication and authorization of the ALTO client to the
server may be needed. For instance, in case of CDN
optimization the provider of an ALTO service as well as
potential users are possibly well-known. Only CDN entities may
need ALTO access; access to the ALTO servers by residential
users may neither be necessary nor be desired.</t>
</section>
<section title="Faking ALTO Guidance">
<t>It has not yet been investigated how a faked or wrong ALTO
guidance by an ALTO server can impact the operation of the
network and also the peers.</t>
<t>Here is a list of examples how the ALTO guidance could be faked and
what possible consequences may arise:</t>
<t><list style="hanging">
<t hangText="Sorting">An attacker could change to sorting
order of the ALTO guidance (given that the order is of
importance, otherwise the ranking mechanism is of interest),
i.e., declaring peers located outside the ISP as peers to be
preferred. This will not pose a big risk to the network or
peers, as it would mimic the "regular" peer operation
without traffic localization, apart from the
communication/processing overhead for ALTO. However, it
could mean that ALTO is reaching the opposite goal of
shuffling more data across ISP boundaries, incurring more
costs for the ISP.</t>
<t hangText="Preference of a single peer">A single IP
address (thus a peer) could be marked as to be preferred all
over other peers. This peer can be located within the local
ISP or also in other parts of the Internet (e.g., a web
server). This could lead to the case that quite a number of
peers to trying to contact this IP address, possibly causing
a Denial of Service (DoS) attack.</t>
</list></t>
</section>
</section>
<section title="IANA Considerations">
<t>This document makes no specific request to IANA.</t>
</section>
<section title="Conclusion">
<t>This document discusses how the ALTO protocol can be deployed
in different use cases and provides corresponding guidance and
recommendations to network administrators and application
developers.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3568" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4026"?>
<?rfc include="reference.RFC.5632"?>
<?rfc include="reference.RFC.5693" ?>
<?rfc include="reference.RFC.6708" ?>
<?rfc include="reference.I-D.ietf-alto-protocol" ?>
<?rfc include="reference.I-D.ietf-alto-server-discovery"?>
<?rfc include="reference.I-D.kist-alto-3pdisc"?>
<?rfc include="reference.I-D.jenkins-alto-cdn-use-cases"?>
<?rfc include="reference.I-D.seedorf-cdni-request-routing-alto"?>
<?rfc include="reference.I-D.penno-alto-cdn"?>
<?rfc include="reference.I-D.scharf-alto-vpn-service"?>
<?rfc include="reference.I-D.deng-alto-p2pcache"?>
<?rfc include="reference.I-D.ietf-idr-ls-distribution"?>
<?rfc include="reference.I-D.ietf-i2rs-architecture"?>
<?rfc include="reference.I-D.farrkingel-pce-abno-architecture"?>
<?rfc include="reference.I-D.kamei-p2p-experiments-japan"?>
<?rfc include="reference.I-D.lee-alto-chinatelecom-trial"?>
<?rfc include="reference.I-D.kiesel-alto-h12"?>
<?rfc include="reference.I-D.vandergaast-edns-client-ip"?>
</references>
<section title="Contributing Authors and Acknowledgments">
<t>This memo is the result of contributions made by several
people, such as:</t>
<t><list style="symbols">
<t>Xianghue Sun, Lee Kai, and Richard Yang contributed text
on ISP deployment requirements and monitoring.</t>
<t>Stefano Previdi contributed parts of the <xref
target="sec.cdn_cons"/> on "Using ALTO for CDNs".</t>
<t>Rich Woundy contributed text to <xref
target="risks"/>.</t>
<t>Lingli Deng, Wei Chen, Qiuchao Yi, Yan Zhang contributed
<xref target="sec.p2pcache"/>.</t>
</list></t>
<t>The authors would like to thank Thomas-Rolf Banniza, Vinayak
Hegde, and Qin Wu for useful comments and reviews of the
document.</t>
<t>Martin Stiemerling is partially supported by the CHANGE
project ( http://www.change-project.eu), a research project
supported by the European Commission under its 7th Framework
Program (contract no. 257422). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the CHANGE project
or the European Commission.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:49:02 |