5. Using ALTO for CDNs
5.1.1. Usage Scenario
This section briefly introduces the usage of ALTO for CDNs, as
explained in [CDN-USE]. 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
ISP 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 ISP backbone and to
provide better user experience measured by reduced latency and higher
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 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 [RFC3568].
| CDN Request Router |
| with ALTO Client |
|| ALTO protocol
| ALTO |
| Server |
: Provisioning protocol
,-' Source of `-.
( topological )
`-. information ,-'
Figure 26: Use of ALTO Information for CDN Request Routing
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. The definition of "closest" may
be as simple as geographical or IP topology distance, but it may also
consider other combinations of metrics and CDN or ISP policies. As
illustrated in Figure 26, ALTO could provide this information.
User Agent Request Router Surrogate
| | |
| F1 Initial Request | |
| +--+ |
| | | F2 Surrogate Selection |
| |<-+ (using ALTO) |
| F3 Redirection Response | |
| | |
| F4 Content Request | |
| | |
| | F5 Content |
| | |
Figure 27: Example of CDN Surrogate SelectionFigure 27 illustrates the interaction between a user agent, a request
router, and a surrogate for the delivery of content in a single CDN.
As explained in [CDN-USE], the user agent makes an initial request to
the CDN (F1). This may be an application-level request (e.g., HTTP)
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 (F3), for example, by returning an appropriate
DNS A/AAAA record or an HTTP 302 redirect, etc. The user agent uses
this information to connect directly to the surrogate and request the
desired content (F4), which is then delivered (F5).
5.1.2. Applicability of ALTO
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 ISP's routing protocols or use of active
probing, the use of an ALTO service to expose that information may
provide additional control to the ISP over how their network map/cost
is exposed. Additionally, it may enable the ISP 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:
o 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 ISP to control the level of
topology detail they are willing to share with the CDN.
o 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 ISP to encourage the
CDN to use network links that would not ordinarily be preferred by
a Shortest Path First routing calculation.
o The routing plane may be operated and controlled by a different
operational entity (even within a single ISP) than 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).
When CDN servers are deployed outside of an ISP's network or in a
small number of central locations within an ISP's network, a
simplified view of the ISP'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 ISP 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 optimal servers for the ISP.
The request router in a CDN will typically 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.
A general issue for CDNs is that the CDN logic has to match the
client's IP address with the closest CDN surrogate, for approaches
that are both DNS or HTTP redirect based (see, for instance,
[ALTO-CDN]). This matching is not trivial, for example, in DNS-based
approaches, where the IP address of the DNS original requester is
unknown (see [RFC7871] for a discussion of this and a solution
In addition to use by a single CDN, ALTO can also be used in
scenarios that interconnect several CDNs. This use case is detailed
5.2. Deployment Recommendations
5.2.1. ALTO Services
In its simplest form, an ALTO server would provide an ISP 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. If an ISP offers an ALTO Network and Cost
Map Service to expose a cost mapping/ranking between end user IP
subnets (within that ISP's network) and CDN surrogate IP subnets/
locations, periodic updates of the maps may be needed. As introduced
in Section 3.3), 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
An alternative would be to use the ALTO ECS: when an end user
requests 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 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.
Since CDNs operate in a controlled environment, the ALTO Network and
Cost Map Service and ECS have a similar level of security and
confidentiality of network-internal information. However, the
Network and 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.
If a CDN already has means to model connectivity policies, the map-
based approaches could possibly be integrated into that. If the ECS
service is preferred, a request router that uses ECS could cache the
results of ECS queries for later usage in order to address the
scalability limitations of ECS and to reduce the number of
transactions between the CDN and ALTO server. 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
5.2.2. Guidance Considerations
The following discusses how a CDN could make use of ALTO services.
In one deployment scenario, ALTO could expose ISP end-user
reachability to a CDN. The request router needs to have information
about 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 ISP and the CDN. For example, if CDN surrogates
are deployed within the access or aggregation network, the ISP is
likely to want to utilize 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.
In addition, CDN surrogates could also use ALTO guidance, e.g., if
there is more than one upstream source of content or several origins.
In this case, ALTO could help a surrogate with the decision about
which upstream source to use. This specific variant of using ALTO is
not further detailed in this document.
If content can be provided by several CDNs, there may be a need to
interconnect these CDNs. In this case, ALTO can be used as an
interface [CDNI-FCI], in particular, for footprint and capabilities
Other, and more advanced, scenarios of deploying ALTO are also listed
in [CDN-USE] and [ALTO-CDN].
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 ISP's networks, whereas a CDN deployed within a particular
ISP's network requires a finer granularity of knowledge.
An ALTO server ranks addresses based on topology information it
acquires from the network. By default, according to [RFC7285],
distance in ALTO represents an abstract "routingcost" that can be
computed, for instance, from routing protocol information. But an
ALTO server may also take into consideration other criteria or other
information sources for policy, state, and performance information
(e.g., geolocation), as explained in Section 3.2.2.
The different methods and algorithms through which the ALTO server
computes topology information and rankings is out of the scope of
this document. If rankings are based on routing protocol
information, 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 be handled internally in the network, and they
should have limited impact on a CDN. However, catastrophic events
such as main trunks failures or backbone partitioning will have to be
taken into account by the ALTO server to redirect traffic away from
the impacted area.
An ALTO server implementation may want to keep state about ALTO
clients in order to inform and signal to these clients when a major
network event happened, e.g., by a notification mechanism. In a CDN/
ALTO interworking architecture with few CDN components interacting
with the ALTO server, there are less scalability issues in
maintaining state about clients in the ALTO server, compared to ALTO
guidance to any Internet user.
6. Other Use Cases
This section briefly surveys and references other use cases that have
been tested or suggested for ALTO deployments.
6.1. Application Guidance in Virtual Private Networks (VPNs)
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 themselves as if they are on a private network. Network
Service Providers (NSPs) offer different types of VPNs. [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.
From the perspective of an application at an endpoint, a VPN may not
be very different from any other IP connectivity solution, but there
are a number of specific applications that could benefit from ALTO
topology exposure and guidance in VPNs. As, in the general Internet,
one advantage is that applications do not have to perform excessive
measurements on their own. For instance, potential use cases for
ALTO application guidance in VPN environments are:
o Enterprise application optimization: Enterprise customers often
run distributed applications that exchange large amounts of data,
e.g., for synchronization of replicated data bases. Network
topology information could be useful for placement of replicas as
well as for the scheduling of transfers.
o Private cloud computing solution: An enterprise customer could run
its own data centers at several 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.
o 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.
These examples focus on enterprises, which are typical users of VPNs.
VPN customers typically have no insight into the network topology
that transports the VPN. Similar to other ALTO use cases, better-
than-random application-level decisions would be enabled by an ALTO
server offered by the NSP, as illustrated in Figure 28.
| Customer's |
| management |
| application |.
| (ALTO client) | .
+---------------+ . VPN provisioning
/\ . (out-of-scope)
|| ALTO .
| 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
| App b | | App c |
Figure 28: Using ALTO in VPNs
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 often run 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.
Also, a VPN will not necessarily be static. The customer could
possibly modify the VPN and add new VPN sites by a Web portal,
network management systems, or other OSS solutions. Prior to adding
a new VPN site, an application will not 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
The VPN use cases, requirements, and solutions are further detailed
6.2. In-Network Caching
Deployment of intra-domain P2P caches has been proposed for
cooperation between the network operator and the P2P service
providers, e.g., to reduce the bandwidth consumption in access
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
Further details and deployment considerations can be found in
6.3. Other Application-Based Network Operations
An ALTO server can be part of an overall framework for Application-
Based Network Operations (ABNO) [RFC7491] that brings together
different technologies. Such an architecture may include additional
components such as a PCE for on-demand and application-specific
reservation of network connectivity, reliability, and resources (such
as bandwidth). Some use cases how to leverage ALTO for joint network
and application-layer optimization are explained in [RFC7491].
7. Security Considerations
Security concerns were extensively discussed from the very beginning
of the development of the ALTO protocol, and they have been
considered in detail in the ALTO requirements document [RFC6708] as
well as in the ALTO protocol specification document [RFC7285]. The
two main security concerns are related to the unwanted disclosure of
information through ALTO and the negative impact of specially
crafted, wrong ("faked") guidance presented to an ALTO client. In
addition to this, the usual concerns related to the operation of any
networked application apply.
This section focuses on the peer-to-peer use case, which is -- from a
security perspective -- probably the most difficult ALTO use case
that has been considered. Special attention is given to the two main
7.1. ALTO as a Protocol Crossing Trust Boundaries
The optimization of peer-to-peer applications was the first use case
and the impetus for the development of the ALTO protocol, in
particular, file sharing applications such as BitTorrent [RFC5594].
As explained in Section 4.1.1, for the publisher of the ALTO
information (i.e., the ALTO server operator), it may not be apparent
who is in charge of the P2P application overlay. Some P2P
applications do not have any central control entity and the whole
overlay consists only of the peers, which are under control of the
individual users. Other P2P applications may have some control
entities such as super peers or trackers, but these may be located in
foreign countries and under the control of unknown organizations. As
outlined in Section 4.2.2, in some scenarios, it may be very
beneficial to forward ALTO information to such trackers, super peers,
etc., located in remote networks. This situation is aggravated by
the vast number of different P2P applications that are evolving
quickly and often without any coordination with the network
In summary, it can be said that in many instances of the P2P use
case, the ALTO protocol bridges the border between the "managed" IP
network infrastructure under strict administrative control and one or
more "unmanaged" application overlays, i.e., overlays for which it is
hard to tell who is in charge of them. This differs from more-
controlled environments (e.g., in the CDN use case), in which
bilateral agreements between the producer and consumer of guidance
7.2. Information Leakage from the ALTO Server
An ALTO server will be provisioned with information about the ISP's
network and possibly also with information about neighboring ISPs.
This information (e.g., network topology, business relations, etc.)
is often considered to be confidential to the ISP and can include
very sensitive information. ALTO does not require any particular
level of details of information disclosure; hence, the provider
should evaluate how much information is revealed and the associated
Furthermore, if the ALTO information is very fine grained, it may
also be considered sensitive with respect to user privacy. For
example, consider a hypothetical endpoint property "provisioned
access link bandwidth" or "access technology (ADSL, VDSL, FTTH,
etc.)" and an ALTO service that publishes this property for
individual IP addresses. This information could not only be used for
traffic optimization but, for example, also for targeted advertising
to residential users with exceptionally good (or bad) connectivity,
such as special banner ads. For an advertisement system, it would be
more complex to obtain such information otherwise, e.g., by bandwidth
Different scenarios related to the unwanted disclosure of an ALTO
server's information have been itemized and categorized in RFC 6708,
Section 5.2.1., cases (1)-(3) [RFC6708].
In some use cases, it is not possible to use access control (see
Section 7.3) to limit the distribution of ALTO knowledge to a small
set of trusted clients. In these scenarios, it seems tempting not to
use network maps and cost maps at all, and instead completely rely on
ECS and endpoint ranking in the ALTO server. While this practice may
indeed reduce the amount of information that is disclosed to an
individual ALTO client, some issues should be considered: first, when
using the map-based approach, it is trivial to analyze the maximum
amount of information that could be disclosed to a client -- the full
maps. In contrast, when providing endpoint-cost service only, the
ALTO server operator could be prone to a false feeling of security,
while clients use repeated queries and/or collaboration to gather
more information than they are expected to get (see Section 5.2.1.,
case (3) in [RFC6708]). Second, the ECS reveals more information
about the user or application behavior to the ALTO server, e.g.,
which other hosts are considered as peers for the exchange of a
significant amount of data (see Section 5.2.1., cases (4)-(6) in
Consequently, users may be more reluctant to use the ALTO service at
all if it is based on the ECS instead of providing network and cost
maps. Given that some popular P2P applications are sometimes used
for purposes such as distribution of files without the explicit
permission from the copyright owner, it may also be in the interest
of the ALTO server operator that an ALTO server cannot infer the
behavior of the application to be optimized. One possible conclusion
could be to publish network and cost maps through ALTO that are so
coarse grained that they do not violate the network operator's or the
In other use cases, in more-controlled environments (e.g., in the CDN
use case) bilateral agreements, access control (see Section 7.3), and
encryption could be used to reduce the risk of information leakage.
7.3. ALTO Server Access
Depending on the use case of ALTO, it may be desired to apply access
restrictions to an ALTO server, i.e., by requiring client
authentication. According to [RFC7285], ALTO requires that HTTP
Digest Authentication be supported, in order to achieve client
authentication and possibly to limit the number of parties with whom
ALTO information is directly shared. TLS Client Authentication may
also be supported.
In general, well-known security management techniques and best
current practices [RFC4778] for operational ISP infrastructure also
apply to an ALTO service, including functions to protect the system
from unauthorized access, key management, reporting security-relevant
events, and authorizing user access and privileges.
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 Figure 21). 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 compromised computers that
are part of a botnet).
If the ALTO server has to be accessible by parties not located in the
ISP's network (see Figure 22), 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 not be the intention of the ISP, as the server is not only
subject to more possible attacks, but also the server load could
increase, since possibly more ALTO clients have to be served.
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.
Access control can also help to prevent Denial-of-Service (DoS)
attacks by arbitrary hosts from the Internet. DoS can both affect an
ALTO server and an ALTO client. A server can get overloaded if too
many 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
7.4. Faking ALTO Guidance
The ALTO services enables an ALTO service provider to influence the
behavior of network applications. An attacker who is able to
generate false replies, or e.g. an attacker who can intercept the
ALTO server discovery procedure, can provide faked ALTO guidance.
Here is a list of examples of how the ALTO guidance could be faked
and what possible consequences may arise:
Sorting: An attacker could change the 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. In
another example, fake guidance could give unrealistically low
costs to devices in an ISP's mobile network, thus encouraging
other devices to contact them, thereby degrading the ISP's mobile
network and causing customer dissatisfaction.
Preference of a single peer: A single IP address (thus a peer) could
be marked as to be preferred over all 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 DoS attack.
The ALTO protocol protects the authenticity and integrity of ALTO
information while in transit by leveraging the authenticity and
integrity protection mechanisms in TLS (see Section 8.3.5 of
[RFC7285]). It has not yet been investigated how wrong ALTO guidance
given by an authenticated ALTO server can impact the operation of the
network and the applications.
8.1. Normative References
IANA, "Application-Layer Traffic Optimization (ALTO)
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009,
[RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
and Y. Yang, "Application-Layer Traffic Optimization
(ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
September 2012, <http://www.rfc-editor.org/info/rfc6708>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
This memo is the result of contributions made by several people:
o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP
deployment requirements and monitoring.
o Rich Woundy contributed text to Section 3.3.
o Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed
Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, Wendy Roome, and Sabine
Randriamasy provided very useful comments and reviewed the document.
University of Stuttgart Information Center
Networks and Communication Systems Department
Cisco Systems, Inc.
Via Del Serafico 200