Network Working Group R. Penno
Internet-Draft S. Raghunath
Intended status: Experimental J. Medved
Expires: April 28, 2011 Juniper Networks
R. Alimi
Google
R. Yang
Yale University
S. Previdi
Cisco Systems
October 25, 2010
ALTO and Content Delivery Networks
draft-penno-alto-cdn-02
Abstract
Networking applications can request through the ALTO protocol
information about the underlying network topology from the ISP or
Content Provider (henceforth referred as Provider) point of view. In
other words, information about what a Provider prefers in terms of
traffic optimization -- and a way to distribute it. The ALTO Service
provides information such as preferences of network resources with
the goal of modifying network resource consumption patterns while
maintaining or improving application performance.
One of the main use cases of the ALTO Service is its integration with
Content Delivery Networks (CDN). The purpose of this draft is
twofold: first, to describe how ALTO can be used in existing and new
CDNs, both within an ISP and in separate organizational entities from
the ISP; second, to collect requirements for ALTO usage in CDNs and
to provide recommendations into the development of the ALTO protocol
for better support of CDNs.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Penno, et al. Expires April 28, 2011 [Page 1]
Internet-Draft ALTO and CDNs October 2010
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Penno, et al. Expires April 28, 2011 [Page 2]
Internet-Draft ALTO and CDNs October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Request Routing as an Integration Point of ALTO into CDN . . . 5
4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS Request Routing . . . . . . . . . . . . . . . . . . . 6
5. Basic Scheme of CDN/ALTO Integration . . . . . . . . . . . . . 6
5.1. Basic Integration Scheme . . . . . . . . . . . . . . . . . 6
5.1.1. ALTO for HTTP Redirect . . . . . . . . . . . . . . . . 7
5.1.2. ALTO for DNS Resolution . . . . . . . . . . . . . . . 8
5.2. Multi-hop Redirection . . . . . . . . . . . . . . . . . . 8
5.3. CDN Node Discovery and Status Notification . . . . . . . . 8
5.3.1. CDN Node Status Updates received by Request Router . . 9
5.3.2. CDN Node Status Updates received by ALTO . . . . . . . 10
6. Request Routing using ALTO Services . . . . . . . . . . . . . 10
6.1. Request Routing using the Map Service . . . . . . . . . . 10
6.2. Request Routing using the Endpoint Cost Service . . . . . 11
7. Multiple Administrative Domains . . . . . . . . . . . . . . . 12
7.1. CDN nodes/Request Router in a separate administrative
domain from that of ISP . . . . . . . . . . . . . . . . . 12
7.2. Managed DNS Domain with Three Administrative Domains . . . 15
7.2.1. Managed DNS Redirect to Local CDN . . . . . . . . . . 15
7.2.2. Managed DNS with CDN-Provided Request Routing . . . . 16
8. Protocol Recommendations . . . . . . . . . . . . . . . . . . . 17
8.1. Necessary Additions . . . . . . . . . . . . . . . . . . . 17
8.1.1. NA1: PID Attributes . . . . . . . . . . . . . . . . . 17
8.1.2. NA2: PID Attributes and Query . . . . . . . . . . . . 17
8.2. Helpful Additions . . . . . . . . . . . . . . . . . . . . 18
8.2.1. HA1: Push Mechanism . . . . . . . . . . . . . . . . . 18
8.2.2. HA2: Incremental Map Updates . . . . . . . . . . . . . 18
8.2.3. HA3: ALTO Border Router PID attribute . . . . . . . . 18
8.2.4. HA4: CDN ALTO Server Discovery . . . . . . . . . . . . 18
8.2.5. HA5: Extensible ALTO Cost Maps . . . . . . . . . . . . 18
8.2.6. NA4: Federated Deployment of ALTO Servers . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Penno, et al. Expires April 28, 2011 [Page 3]
Internet-Draft ALTO and CDNs October 2010
1. Introduction
Content Delivery Networks are becoming increasingly important in the
Internet [ARBOR] and many CDNs today already use some form of
proximity through geolocation. But in many cases the content
provider/distributor and the Internet Service Provider are disjoint
and even if content servers are co-located into the ISP's networks,
there is no standardized way to share server location and/or network
topology information. Therefore a natural step forward would be to
use ALTO to share this information.
Another key aspect of ALTO in the context of CDNs deployments is that
it is desirable that no changes to the hosts are needed (or that
changes to hosts would be transparent to the user). In other words,
a traditional web browser is all there is needed to take advantage of
ALTO information. This is a significant difference from the P2P
applications where a special client is typically needed and ALTO is
normally used as a way to reduce operational expense.
2. Scope
This document discusses how Content Delivery Networks can benefit
from ALTO through integration of the ALTO Service with the main
request routing techniques. There are two objectives:
o Present basic integration schemes of ALTO into CDNs.
o Provide protocol recommendations to ALTO: Whenever a new
requirement on protocol functionality is identified to achieve
integration with CDNs, it will be enumerated with 'REQ-<N>'. Each
requirement is documented in a section of its own in order to
foster parallel discussions and possible adoption.
3. Terminology
Content-aware Proximity Request Router: The Request Router knows
about locations and presence of content & media objects in the
network. Therefore the redirection to a CDN node is made based on
both the availability of content or content-type in that CDN node
and the proximity of the CDN node to the requesting user.
Service-aware Proximity Request Router: The Request Router knows
about locations of CDN nodes in the network and redirects user to
the closest CDN node. A redirection is made irrespective of
content presence in the CDN node; if content is not present, the
node will be populated with the content while the content is
Penno, et al. Expires April 28, 2011 [Page 4]
Internet-Draft ALTO and CDNs October 2010
served to the user.
HTTP Request Router: a Content-aware or Service-aware Proximity
Request Router for HTTP. It embeds an HTTP Server that performs
HTTP Redirects, an ALTO client that retrieves network mapping from
the ALTO Server, and a Location Database which stores network
mappings received from the ALTO Client. The HTTP Server consults
the Location Database when making redirection decisions.
4. Request Routing as an Integration Point of ALTO into CDN
Content Distribution is a rich and evolving field. New architectures
and approaches (e.g., a hybrid architecture using both servers and
P2P) continue to be developed in the research community and industry
and some are being deployed in production networks. While we would
like to provide a survey of each possible CDN architecture and show
how it may be integrated with ALTO, it would be a daunting task to
track such a rapidly-changing field.
One scheme that is out of the scope of this document is P2P-only
CDNs, where the application tracker takes the role of the ALTO
Client, fetching the Network and Cost Maps from the ALTO Server and
integrating them with its peer database. The result is a peer
database that takes into account both the current peer metrics, such
as peer availability or content availability, and network metrics,
such as topological localization. This architecture in context of
file sharing was extensively studied and trialed by ISPs such as
Comcast [RFC5632] and China Telecom [I-D.lee-alto-chinatelecom-trial]
under the ALTO/P4P [P4P] protocol. Thus, P2P-only CDNs are not
discussed in this document.
Today, multiple request routing approaches can be used even in CDNs
with purely server-based infrastructure. Thus, we take the approach
of developing a basic request routing scheme covering all major CDN
types. Specifically, the Request Routing Component of a CDN directs
a request to a serving CDN node, and thus is the major integration
point to utilize information available through ALTO. There are
multiple request routing mechanisms, including HTTP Redirect, DNS
name resolution, and anycast. We focus on HTTP Redirect and DNS name
resolution. We briefly review the two mechanisms.
4.1. HTTP Redirect
In this mechanism, an HTTP GET request from a host is received by an
HTTP Request Router which sends back an HTTP responses with Status-
Code 302 (Redirect) informing the host of the most optimal location
to fetch the content. The HTTP Redirection method is already
Penno, et al. Expires April 28, 2011 [Page 5]
Internet-Draft ALTO and CDNs October 2010
commonly used in production CDNs as described in RFC3568 [RFC3568].
ALTO integration provides localization services where the device that
performs the redirection becomes an ALTO client.
4.2. DNS Request Routing
In this mechanism, the DNS server handling host requests provides the
Request Routing Component. When the host performs a DNS query/
lookup, the IP address contained in the response is already optimal
for that query.
DNS queries can be either iterative or recursive. Iterative queries
can be used with ALTO if the host itself queries the DNS Servers, or
if the DNS Proxy used by the host is topologically close to the host.
If the Host queries the DNS Servers, the authoritative DNS Server can
see directly the host's IP address. If the DNS Proxy's is
topologically close to the Host, its IP address is a good
approximation for the host's location. In recursive queries, the
authoritative DNS Server sees the IP address of the previous DNS
Server in the resolution chain, and the IP address of the host is
unknown. DNS-based request routing does not work with recursive DNS
queries.
In an iterative DNS lookup with DNS Proxy, the host queries the
Proxy, which in turn first queries one of the root servers to find
the server authoritative for the top-level domain (com in our
example). The Proxy then queries the obtained top-level-domain DNS
server for the address of the DNS server authoritative for the CDN
domain. Finally, the Proxy queries the DNS server that is
authoritative for the cdn.com domain. The authoritative DNS Server
for the cdn.com will perform the request routing to the most
appropriate CDN node, based on the source IP address of the
requestor. The host will then request the content directly from the
CDN Node.
5. Basic Scheme of CDN/ALTO Integration
Although HTTP Redirect and DNS are quite different mechanisms to
direct a request to a serving CDN node, as we will see, the basic
structure of integrating ALTO with them can be quite similar. Thus,
we first present common structures. We refer to the HTTP Redirect
component or the DNS component of a CDN as a CDN Request Router.
5.1. Basic Integration Scheme
Figure 1 shows a general structure to embed an ALTO Client into a CDN
Request Router.
Penno, et al. Expires April 28, 2011 [Page 6]
Internet-Draft ALTO and CDNs October 2010
+-----------------+
| Request Router |
+-----------+ 1 | |
| |---------> | |
| Requestor |<-------- | |
+-----------+ 2 | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |
+-----------------+
Figure 1: Request Router with ALTO
5.1.1. ALTO for HTTP Redirect
To make the basic scheme more concrete, Figure 2 shows the case that
the Request Router uses HTTP Redirect.
+---------------------+
| HTTP Request Router |
+------+ 1 | +-------------+ |
| |--------------> | | HTTP Server | |
| Host |<-------------- | +-------------+ |
+------+ 2 | ^ |
| | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+---------------------+
| ^
| | ALTO Protocol
v |
+---------------------+
| ALTO Server |
+---------------------+
Figure 2: ALTO for HTTP Request Router
Penno, et al. Expires April 28, 2011 [Page 7]
Internet-Draft ALTO and CDNs October 2010
5.1.2. ALTO for DNS Resolution
Figure 3 shows the case that the Request Router uses DNS Resolution.
2 +----------------+
+------------------> | root |
| +----------------- | Name Server | +----------+
| | 3 +----------------+ | Content |
| | | Provider |
| | 4 +----------------+ +----------+
| | +------------> | com |
| | | +----------- | Name Server |
| | | | 5 +----------------+
| | | |
| V | V
+---------+ +----------------+
| DNS |---------> | cdn.com |
| Proxy |<--------- | Name Server |
+---------+ 7 | |
^ | | +------------+ |
1 | | 8 | |ALTO Client | |
| V | +------------+ |
+---------+ +----------------+
| Host | | ^
+---------+ | | ALTO Protocol
| | |
| V |
V +----------------+
CDN Node | ALTO Server |
+----------------+
Figure 3: ALTO for DNS Resolution.
5.2. Multi-hop Redirection
The preceding examples show the logical flow for redirection. It is
important to state that there maybe multiple redirection hops.
For HTTP Redirect, the requestor may be redirected again by the first
CDN node. For DNS, the first DNS server may direct, using aggregated
ALTO information (e.g., from multiple ALTO Servers of multiple ISPs),
the DNS resolution to a second level DNS server, which then may use
more specific ALTO information as well as CDN node status.
5.3. CDN Node Discovery and Status Notification
Since ALTO for HTTP Redirect and that for DNS have many common
issues, we use the basic general scheme unless stated otherwise.
Penno, et al. Expires April 28, 2011 [Page 8]
Internet-Draft ALTO and CDNs October 2010
One common issue is how Request Router discovers the available CDN
nodes and their locations. The exact mechanism is outside the scope
of this document.
It is desirable that not only CDN node locations, but also real-time
CDN node status (like health, load, cache utilization, CPU, etc.) is
communicated to the CDN.
Specifically, CDN node status can be retrieved from the existing Load
Balancer infrastructure. Most Load Balancers today have mechanisms
to poll caches/servers via ping, HTTP Get, traceroute, etc. Most LBs
have SNMP trap capabilities to let other devices know about these
thresholds.
[yry: move]In addition to the CDN node status, network status can
also be retrieved from TE/RP databases.
We see two ways that CDN node status can be communicated into the
request routing decision process.
5.3.1. CDN Node Status Updates received by Request Router
In this use case the Request Router receives CDN Status updates
directly.
Specifically, the Request Router can implement an SNMP agent and get
to know whatever is needed.
+-----------------+
| Request Router |
+-----------+ 1 | |
| |---------> | |<--- Real-time CDN
| Requestor |<-------- | | status updates
+-----------+ 2 | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |
+-----------------+
Figure 4: CDN Node Status to Request Router
Penno, et al. Expires April 28, 2011 [Page 9]
Internet-Draft ALTO and CDNs October 2010
5.3.2. CDN Node Status Updates received by ALTO
This model generally simplifies the Request Router. It allows an
easier distribution of the Request Router, and to keep real time CDN
status data updates in a logically centralized ALTO Server or in an
ALTO Server Cluster. It allows for the Request Router and the ALTO
Server to be in different administrative domains. For example, the
Request Router can be in a Content Provider's domain, the ALTO Server
and CDN Nodes in a Network Service Provider's domain.
Specifically, ALTO Server could provide an API (for example, a Web
Service or XMPP-based API) that could be used by CDN nodes to
communicate their status to the ALTO server directly.
+-----------------+
| Request Router |
+-----------+ 1 | |
| |---------> | |
| Requestor |<-------- | |
+-----------+ 2 | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |<--- Real-time CDN
+-----------------+ status updates
Figure 5: CDN Node Status to ALTO
6. Request Routing using ALTO Services
Either the Map Service or the Endpoint Cost Service of ALTO can be
used by the Request Router.
6.1. Request Routing using the Map Service
The ALTO client embedded in the Request Router fetches the Network
and Cost Maps from the ALTO Server and provides that information to
the Request Router.
As an illustrative example, we consider the case of HTTP Redirect. A
simple Request Router may be given (from an external source) the list
of available CDN nodes. The Request Router precomputes a redirection
Penno, et al. Expires April 28, 2011 [Page 10]
Internet-Draft ALTO and CDNs October 2010
table indexed by source PID with values being the closest CDN nodes.
This redirection table can be built based on information from Network
and Cost Maps. Then when the Request Router receives an HTTP GET
request, it looks up the PID of the source IP address on the request,
indexes the redirection table using the request PID to select a CDN
node, and finally returns a response that is an HTTP redirect with
the URL of the selected CDN node. The URL in 302 Redirect may
contain the IP address of the selected CDN node or a domain name
instead of IP address due to virtual hosting. Therefore the IP
addresses contained in the cost maps may need to be correlated to
domain names a priori. In practice, the redirection table may be
indexed by both source and content to provide better redirection.
The illustrative example can also be extended to DNS.
The Network Maps generated by the ALTO Server will contain both Host
PIDs and CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN
PIDs contain IP addresses of available CDN nodes. Cost Maps may
contain only cost from each host PID to each CDN PID and not the full
matrix across all PIDs. The reason is that the Request Router may
redirect a host only to a CDN node, not to another host as in the P2P
case. Moreover, there is no generic way to disambiguate PIDs
containing only hosts from PIDs containing CDN nodes.
It is possible that a Request Router may be designated as being
responsible only for a fixed set of Host PIDs. This information can
be made available to the Request Router before it receives requests
from hosts. If the set of Host PIDs is not known ahead of time, the
latency for serving requests will be impacted by the capabilities of
the ALTO server.
With such information ahead of time, a Request Router that uses the
Network Maps Service may pre-download the Network Map for the
interesting Host PIDs and the CDN PIDs. It can also start
periodically pulling Cost Map for relevant PID 2-tuples.
The Request Router can rely on the ALTO Server generated Cache-
Control headers to decide how often to fetch CDN PID network map and
Host PID network maps.
For Alto protocol requirements related to request routing with the
Map Service see Section 8.1.1 and Section 8.1.2.
6.2. Request Routing using the Endpoint Cost Service
Alternatively, the Request Router may request the Endpoint service
from the ALTO client.
Penno, et al. Expires April 28, 2011 [Page 11]
Internet-Draft ALTO and CDNs October 2010
Specifically, the Request Router requests the Endpoint Cost Service
in order to rank/rate the content locations (i.e., IP addresses of
CDN nodes) based on their distance/cost (by default the Endpoint Cost
Service operates based on Routing Distance) from/to the user address.
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 location.
A Request Router that uses the Endpoint Cost Service may query the
ALTO Server for rankings of CDN Node IP addresses for each
interesting Host and cache the results for later usage.
7. Multiple Administrative Domains
The preceding discussion works well in a single administrative domain
setting: the CDN nodes are in the administrative domain of the ISP.
However, the CDN nodes, the ISP, and the Request Router can be in
different administrative domains. In this section, we consider a few
such deployment cases. We use DNS as an example.
7.1. CDN nodes/Request Router in a separate administrative domain from
that of ISP
In many situations, the CDN nodes and the Request Router are in a
separate network managed by an entity that is distinct from the ISP.
Consequently, the CDN nodes belong to a network with its own ALTO
server that is distinct from the ALTO server of the ISP where the
subscriber belongs.
Penno, et al. Expires April 28, 2011 [Page 12]
Internet-Draft ALTO and CDNs October 2010
.................................
: +-----------------+ :
: | cdn.com | :
: | Name Server | :
+----------+ : | | :
| Content | : | +-------------+ | :
| Provider | : | | ALTO Client | | :
+----------+ : | +-------------+ | :
: +-----------------+ :
: ^ :
: | :
: +-----------------+ :
................................. : | ALTO Server | :
: : : | | :
: +----------------+ : : | +-------------+ | :
: | ALTO Server |--------------------->| ALTO Client | | :
: +----------------+ : : | +-------------+ | :
: : : +-----------------+ :
: : : :
: +------+ C(1-4) +--------+ : : +--------+ C(6-8) +------+ :
: | Host |<--------->| Border |: c6 :| Border |<--------->| CDN | :
: | PID1 | +-->| Router |-------| Router |<--+ | PID8 | :
: +------+ |+->| PID4 | : :| PID6 |<-+| +------+ :
: || +--------+ : : +--------+ || :
: || : : || :
: +------+ C(2-4)|| : : ||C(6-9) +------+ :
: | Host |<------+| : : |+------>| CDN | :
: | PID2 | | : : | | PID9 | :
: +------+ | : : | +------+ :
: | : : | :
: | : : | :
: +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ :
: | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | :
: | PID3 | | Router |-------| Router | | PID10| :
: +------+ | PID5 | : : | PID7 | +------+ :
: +--------+ : : +--------+ :
: : : :
: ISP Administrative Domain : : CDN Administrative Domain :
:...............................: :...............................:
Figure 6: Map advertising between ISP and CDN domains
The ALTO server in the CDN provider network is assumed to be
initialized with information about the ISP networks it serves. For
every such ISP network, it consults the routing plane to find the set
of Border routers. The CDN network ALTO server computes the cost of
reaching each Border router from every CDN node (say, C_cdn).
Penno, et al. Expires April 28, 2011 [Page 13]
Internet-Draft ALTO and CDNs October 2010
Next, the CDN ALTO server contacts the ISP network's ALTO server and
downloads the network map. In order to help the CDN ALTO server
compute the cost from a CDN node to a subscriber's PID, we break it
down into two parts - the cost from the CDN node to the Border Router
(C_cdn) and the cost from the Border Router to the subscriber's PID
(say, C_isp). Note that for any chosen exit point, C_cdn may be
computed locally by the CDN ALTO Server. However, the fundamental
issue is that C_isp depends on the exit point (Border outer) chosen
by the CDN. There are multiple ways for the CDN ALTO Server to
compute C_isp given the Network Map and Cost Map from the ISP's ALTO
Server.
One possibility is for the ISP ALTO Server to define a special Border
Router PID (denoted by a PID attribute) which also indicates the
corresponding Border Router PID in the CDN. The attributes and
values may be agreed-upon by the ISP and CDN when the ALTO Services
are configured. For example, in the example shown in Figure 5, the
ISP ALTO Server indicates that its PID4 and PID5 are Border PIDs,
with corresponding PIDs in the CDN as PID6, and PID7, respectively.
Then, CDN ALTO Server can locally compute C_isp = cost(ISP Border
Router PID, Subscriber PID).
A second possibility for computing C_isp is to make use of Border
Router IP addresses. The CDN's Border Router can locally determine
the IP address of the connected border router in the ISP. In this
approach, neither the CDN ALTO Server nor the ISP ALTO Server define
PID attributes. The ISP ALTO Server is not required to define
special PIDs for Border Routers - it only needs to ensure that Border
Router IP addresses are aggregated appropriately in its Network Map.
Specifically, we identify two scenarios for the CDN ALTO Server to
compute C_isp and C_cdn.
In the first scenario, the CDN does not conduct CDN-level multi-path
routing from the CDN nodes to the subscriber hosts. Thus, the
routing path from a CDN IP address to a subscriber host IP address is
typically uniquely (if no ECMP) determined by the network routing
system. In this scenario, for a given CDN node IP address to a
subscriber host IP address, the CDN ALTO Server uses the routing
system to compute the Border Egress router inside the CDN, and the
corresponding Border Ingress router inside the ISP. Then the CDN
ALTO Server has C_cdn(CDN node IP, Border Egress router IP inside the
CDN), and C_isp(Border Ingress router IP inside the ISP, Subscriber
IP). The computation of C_cdn and C_isp can be done using ALTO in
the traditional way through either the Network Map and Cost Map or
the Endpoint Cost Service.
In the second scenario, the CDN may support CDN-level multi-path
Penno, et al. Expires April 28, 2011 [Page 14]
Internet-Draft ALTO and CDNs October 2010
routing from the CDN nodes to the subscriber hosts. In particular,
from each CDN node, the CDN has a capability (e.g., through
tunneling) to send to a subscriber host IP through multiple Border
Egress routers (e.g., through any Egress router that receives an
announcement from the ISP of the subscriber host IP). In this case,
the cost of reaching a host PID from a given CDN node is then
determined as the minimum cost among all possible intermediate Border
Routers.
If the network is homogeneous, then a good approximation of the cost
between each host PID and a given CDN node can be given as: C_cdn(CDN
Node, Border router) + C_isp(Border router, Subscriber PID). In this
computation, the Border Router is the one that is on the best path
from the CDN node to the Subscriber PID.
The CDN ALTO server now has a cost map that provides the cost from
each CDN node to all known Subscriber PIDs. The ALTO client in the
CDN DNS server downloads this cost map in preparation for subscriber
DNS requests.
When a subscriber DNS request arrives at the CDN provider's DNS
server, it looks up the network map and maps the source IP address to
a Subscriber PID. It then uses the cost map to pick the best CDN
node for this Subscriber PID.
7.2. Managed DNS Domain with Three Administrative Domains
Many organizations / content providers outsource DNS management to
the external vendors for various reasons like reliability,
performance improvement, DNS security etc. Managed DNS service could
be used either with caches owned by the organization itself (section
6.3.1) OR with external CDNs (section 6.3.2)
7.2.1. Managed DNS Redirect to Local CDN
One of the common functions offered by managed DNS service vendor is
DNS traffic management where DNS resolver can load balance traffic
dynamically across CDN servers.
Typically managed DNS service provider has DNS resolvers spread
across geographical locations to improve performance. This also
makes easier for DNS resolver to redirect host to the nearest cache.
Such a DNS resolver would be an ideal candidate to implement ALTO
client where it can fetch network map and cost map from ALTO servers
located in the same geographical area only. Load balancing
implemented with the knowledge of network and cost map would be more
efficient than other mechanisms like round robin.
Penno, et al. Expires April 28, 2011 [Page 15]
Internet-Draft ALTO and CDNs October 2010
2 +----------------+
+--------------------> | root |
| +------------------- | Name Server |
| | 3 +----------------+
| |
| | 4 +----------------+
| | +--------------> | com |
| | | +------------- | Name Server |
| | | | 5 +----------------+
| | | |
_|-|---|-|--------------------.
,-'' | V | V `--.
' +---------+ 6 +---------------`+.
| | DNS |-------->| xyz.com | `
| | Proxy |<--------| DNS Resolver | |
| +---------+ 7 | | |
| 1^ | 8 | +------------+ | |
| | | | |ALTO Client | | |
| +-----V---+ | +------------+ | |
| | Host | +----------------.-'
| +---------+ | ^ .-'
| | DOMAIN 1 | |-' ALTO Protocol
| V |.-'| (Map Service)
`--. CDN Node __.--:-| |
`----. _.--' | |
`---.-'' ,---------+-------.
,'+----------------+ \
/ | ALTO Server | :
( +----------------+ |
\ ;
\ DOMAIN 2 ,'
`-----------------'
In the figure above, there exists 2 possibilities:
Case 1: Domain 1 and Domain 2 are connected to the same service
provider network. This case is similar to section 6.1
Case 2: Domain 1 and Domain 2 are connected to different service
provider network. This case is similar to section 6.2
7.2.2. Managed DNS with CDN-Provided Request Routing
It is also possible to utilize a Managed DNS service and still rely
on a CDN's request routing. For example, this could be done if a
network provider wishes to utilize a Managed DNS provider, but also
wishes to integrate its own CDN using ALTO with DNS-based request
routing.
Penno, et al. Expires April 28, 2011 [Page 16]
Internet-Draft ALTO and CDNs October 2010
To support this, the network provider may submit any necessary
configuration files (e.g., indicating necessary CNAME records) to
redirect CDN requests to the CDN's DNS request routing mechanism.
Requests for the CDN (e.g., 'cdn.isp.com') will then be directed by
DNS request routing, while requests for other hosts are handled by
the Managed DNS solution.
8. Protocol Recommendations
In the previous sections, this document has taken the approach of
providing information on existing CDN approaches and possible
benefits of utilizing ALTO. However, in developing the taxonomy, use
cases, and deployment scenarios, we have identified cases where the
ALTO Protocol [I-D.ietf-alto-protocol] and Server Discovery
[I-D.kiesel-alto-3pdisc] [I-D.song-alto-server-discovery]
[I-D.stiemerling-alto-dns-discovery] may be lacking capabilities that
may be helpful and/or necessary for usage with CDNs. We now focus on
detailing these gaps with the goal of providing feedback and
recommendations. Note that some protocol changes may be necessary in
the core protocol, while others may be implemented as extensions.
This section will be updated to track changes in the ALTO Protocol,
ALTO Server Discovery, and accompanying protocols.
8.1. Necessary Additions
This section details changes to the ALTO protocols that would be
necessary to make use of ALTO within CDN infrastructures. We
classify a change as "necessary" if there is a core feature of a CDN/
ALTO integration that is not possible to implement with the existing
protocols.
8.1.1. NA1: PID Attributes
In order to disambiguate between PIDs that contain endpoints of a
specific class, a PID property is needed. A PID can be classified as
containing "CDN nodes", "Mobile Hosts", "Wireline Hosts", etc. This
mechanism can be used to provide an ALTO Client a list of nodes of a
particular type, along with the ALTO Costs to each node.
8.1.2. NA2: PID Attributes and Query
PID attributes can be used by the ALTO Client to select a appropriate
host and also passed as a constraint in the map filtering service.
Penno, et al. Expires April 28, 2011 [Page 17]
Internet-Draft ALTO and CDNs October 2010
8.2. Helpful Additions
This section details changes to the ALTO Protocol that would be
helpful to make use of ALTO within CDN infrastructures. We classify
a change as "helpful" if there is a compelling extension to existing
CDNs that would be possible with additional functionality within
ALTO, or if there is a component of CDN/ALTO integration that could
be made more efficient or otherwised improved with additional ALTO
functionality.
8.2.1. HA1: Push Mechanism
It is important for the ALTO Service through the ALTO protocol or a
companion protocol to provide a push mechanism from server to client.
The push mechanism can be a notification that new data is available
or the data itself.
8.2.2. HA2: Incremental Map Updates
A natural evolution to the protocol if maps are large and change
often is to allow for incremental map updates. In this sense the map
contained in the reply would be considered the delta from the
previous version.
8.2.3. HA3: ALTO Border Router PID attribute
In order for administrative domains to collate costs across domain
boundaries, the border routers may be placed in their own PIDs. Such
PIDs may be identified by a Border Router attribute.
8.2.4. HA4: CDN ALTO Server Discovery
In certain deployment scenarios, it may be beneficial for an ALTO
client to directly query a CDN's ALTO Server (instead of the CDN's
ALTO Server only being consulted as a backend process). For example,
this can provide more accurate guidance than DNS request routing
since the client's IP address may be directly used by the CDN in
order to select a cache node. This would require an ALTO Client
(e.g., an ISP subscriber) to be able to discover an ALTO Server owned
and/or managed by a CDN. This could be done by an extension to the
discovery protocol, or it could be done by allowing an ISP's ALTO
Server to redirect certain queries to a CDN ALTO Server.
8.2.5. HA5: Extensible ALTO Cost Maps
Certain deployment scenarios may benefit from additional information
being carried within ALTO information. For example, a trusted
neighboring ISP B may be able to help ISP A optimize multihoming
Penno, et al. Expires April 28, 2011 [Page 18]
Internet-Draft ALTO and CDNs October 2010
costs. To provide an extensible way to communicate additional data,
the ALTO Protocol could be extended to include opaque data strings
(in addition to numeric and ordinal values) in an ALTO Cost Map.
8.2.6. NA4: Federated Deployment of ALTO Servers
There is a need to define how ALTO servers may communicate with each
other in a federated model.
9. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. Security Considerations
When the ALTO Server and Client are operated by different entities
the issue of trust and security comes forward. The exchange of
information could be done using the encryption methods already
present in HTTP but preventing unauthorized redistribution comes into
play. A further issue is if the ALTO information information is
transitive, which modifications are allowed.
11. Acknowledgements
We would like to thank Mayuresh Bakshi for valuable input and
contributions to this draft. We would also like to thank Nabil
Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry
Sutanto for their comments.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[ARBOR] Labovitz, "Internet Traffic and Content Consolidation",
2009, <http://www.ietf.org/proceedings/10mar/slides/
plenaryt-4.pdf>.
Penno, et al. Expires April 28, 2011 [Page 19]
Internet-Draft ALTO and CDNs October 2010
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-05 (work in progress), July 2010.
[I-D.kiesel-alto-3pdisc]
Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.
Stiemerling, "Third-party ALTO server discovery",
draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.
[I-D.lee-alto-chinatelecom-trial]
Li, K., Wang, A., and K. Zhou, "ALTO and DECADE service
trial within China Telecom",
draft-lee-alto-chinatelecom-trial-00 (work in progress),
July 2010.
[I-D.song-alto-server-discovery]
Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V.
Avila, "ALTO Service Discovery",
draft-song-alto-server-discovery-03 (work in progress),
July 2010.
[I-D.stiemerling-alto-dns-discovery]
Stiemerling, M. and H. Tschofenig, "A DNS-based ALTO
Server Discovery Procedure",
draft-stiemerling-alto-dns-discovery-00 (work in
progress), July 2010.
[P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A.
Silberschatz, "P4P: Provider Portal for (P2P)
Applications", March 2009.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003.
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
Y. Yang, "Comcast's ISP Experiences in a Proactive Network
Provider Participation for P2P (P4P) Technical Trial",
RFC 5632, September 2009.
Authors' Addresses
Reinaldo Penno
Juniper Networks
Email: rpenno@juniper.net
Penno, et al. Expires April 28, 2011 [Page 20]
Internet-Draft ALTO and CDNs October 2010
Satish Raghunath
Juniper Networks
Email: satishr@juniper.net
Jan Medved
Juniper Networks
Email: jmedved@juniper.net
Richard Alimi
Google
Email: ralimi@google.com
Richard Yang
Yale University
Email: yry@yale.edu
Stefano Previdi
Cisco Systems
Email: sprevidi@cisco.com
Penno, et al. Expires April 28, 2011 [Page 21]