Network Working Group R. Penno
Internet-Draft S. Raghunath
Intended status: Experimental J. Medved
Expires: January 13, 2011 M. Bakshi
Juniper Networks
R. Alimi
Yale University
S. Previdi
Cisco Systems
July 12, 2010
ALTO and Content Delivery Networks
draft-penno-alto-cdn-01
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, 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.
A main use case of the ALTO Service is its integration with of
Content Delivery Networks (CDN). In this document we describe the
deployment scenarios and considerations for a ALTO Service in the
case 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
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
Penno, et al. Expires January 13, 2011 [Page 1]
Internet-Draft Abbreviated-Title July 2010
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 January 13, 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 January 13, 2011 [Page 2]
Internet-Draft Abbreviated-Title July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Content Location Selection . . . . . . . . . . . . . . . . . . 5
4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. The Map Service . . . . . . . . . . . . . . . . . . . 6
4.1.2. The Endpoint Cost Service . . . . . . . . . . . . . . 7
4.1.3. CDN Node Discovery and Status . . . . . . . . . . . . 7
4.2. DNS Integration . . . . . . . . . . . . . . . . . . . . . 10
4.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 11
5. Administrative domains and ALTO . . . . . . . . . . . . . . . 11
5.1. CDN nodes in the ISP administrative domain . . . . . . . . 11
5.2. CDN nodes in a separate administrative domain from
that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Integrating with managed DNS service . . . . . . . . . . . 15
5.3.1. Managed DNS resolver used to redirect to local
cache . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Managed DNS resolver used with multiple CDN vendors . 17
6. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Penno, et al. Expires January 13, 2011 [Page 3]
Internet-Draft Abbreviated-Title July 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 information. Therefore a
natural step forward would be to use ALTO to share 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 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. Whenever a gap in protocol functionality
is identified to achieve such integration, it will be enumerated with
'GAP-<N>'. Each gap is documented in a section of its own in order
to foster parallel discussions and possible adoption.
3. Terminology
Content-aware Proximity Redirector: The Redirector knows about
locations and presence of content & media objects in the network.
Therefore the redirection to a CDN node is made based on
availability of content or content-type in that CDN node and the
proximity of the CDN node to the user.
Service-aware Proximity Redirector: The Redirector 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 before or when the content is served
to the user.
HTTP Redirector: a Content-aware or Service-aware Proximity
Redirector 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
Penno, et al. Expires January 13, 2011 [Page 4]
Internet-Draft Abbreviated-Title July 2010
received from the ALTO Client. The HTTP Server consults the
Location Database when making redirection decisions.
4. Content Location Selection
There are multiple mechanisms that ISPs and CDNs can use to select
the location from which content is served to a particular host, where
information from one or more ALTO Servers can be used to improve or
optimize the selection. In particular, two commonly used location
selection mechanisms are HTTP Redirect and DNS name resolution.
Thus, we focus on these two mechanisms.
4.1. HTTP Redirect
In this case an HTTP GET request from a host is received by an HTTP
Redirector 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 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.
Usage of the ALTO Server with HTTP Redirects is shown in the
following figure. Either the Map Service or the Endpoint Cost
Service can be used by the ALTO client embedded in the HTTP
Redirector entity.
+-----------------+
| HTTP Redirector |
+------+ 1 | +-------------+ |
| |--------------> | | HTTP Server | |
| Host |<-------------- | +-------------+ |
+------+ 2 | ^ |
| | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |
+-----------------+
Figure 1: HTTP Redirector
Penno, et al. Expires January 13, 2011 [Page 5]
Internet-Draft Abbreviated-Title July 2010
4.1.1. The Map Service
The ALTO client embedded in the HTTP Redirector fetches the Network
and Cost Maps from the ALTO Server and provides that information to
the HTTP Redirector. As an illustrative example, a simple Redirector
may be given (from an external source) the list of available CDN
nodes. The Redirector precomputes a redirection 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 it receives an HTTP GET request (1), it looks up the PID of
the source IP address on the GET request, indexes the redirection
table using the request PID to select a CDN node, and finally returns
an HTTP redirect with the URL of the selected CDN node. In practice,
the redirection table may be indexed by both source and content to
provide better redirection.
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.
The Network Maps generated by the ALTO server contain Host PIDs and
CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain
IP addresses of available CDN nodes. Cost Maps contain only cost
from each host PID to each CDN PID and not the full matrix across all
PIDs. The reason is that the HTTP Redirector can only redirect a
host 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 (GAP).
The cost for CDN PID to CDN PID and between host PIDs are assumed to
be infinity (GAP). The HTTP Redirector looks up the source address
on the HTTP GET request, and uses the cost map to select the best CDN
PID and a CDN node from it. The CDN node selection method can be
random, round-robin, or the HTTP Redirector can use some level of
content awareness (i.e. send requests for the same content (URL) to
the same CDN node.
GAP-1 (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. Note that the Alto Server will have to be
told which subnets belong to hosts and which subnets belong to CDN
Nodes.
GAP-2 (PID Attributes and Query): PID attributes can be used by
the ALTO Client to select an appropriate CDN Node and also passed
as a constraint in the map filtering service.
Penno, et al. Expires January 13, 2011 [Page 6]
Internet-Draft Abbreviated-Title July 2010
GAP-3 (Default Cost): The issue of default cost is one of
importance. Without a default PID with endpoint '0.0.0.0/0', what
should be the cost between two PIDs? Moreover, is the default PID
mandatory in the protocol?
4.1.2. The Endpoint Cost Service
Alternatively, ALTO client embedded in the HTTP Redirector, requests
the endpoint cost service from the ALTO client.
The Redirector knows the IP address of the user (content requester)
and the different content locations. It then 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.
Note that the mechanisms through which the CDN acquires the IP
addresses of the content locations (i.e.: how to locate the requested
content) are part of the CDN implementation and their description is
outside the scope of this document.
Once the Redirector 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.
4.1.3. CDN Node Discovery and Status
The method of discovering available caches and their locations is
outside the scope of this document. We assume the CDN nodes are
discovered in some way. It is desirable that not only CDN node
locations, but also real-time status (like health, load, cache
utilization, CPU, etc.) is communicated either to the HTTP Redirector
or to the ALTO Server.
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. The HTTP Redirector or the ALTO Server can implement an
SNMP agent and get to know whatever is needed. For greenfield
installations, the ALTO Server could also 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.
In addition to the CDN node status, network status can also be
retrieved from TE/RP databases.
Penno, et al. Expires January 13, 2011 [Page 7]
Internet-Draft Abbreviated-Title July 2010
4.1.3.1. CDN Node Status Updates received by HTTP Redirector
In this use case the HTTP Redirector receives CDN Status updates.
+-----------------+
| HTTP Redirector |
+------+ 1 | +-------------+ |
| |--------------> | | HTTP Server | |
| Host |<-------------- | +-------------+ |
+------+ 2 | ^ |<--- Real-time CDN
| | | status updates
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |
+-----------------+
Figure 2: RT CDN Updates to HTTP Redirector
4.1.3.2. CDN Node Status Updates received by ALTO Server
This model generally simplifies the HTTP Redirector. It allows an
easier distribution of the HTTP Redirector, 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 HTTP Redirector and the ALTO
Server to be in different administrative domains. For example, the
HTTP Redirector can be in a Content Provider's domain, the ALTO
Server and CDN Nodes in a Network Service Provider's domain.
Penno, et al. Expires January 13, 2011 [Page 8]
Internet-Draft Abbreviated-Title July 2010
+-----------------+
| HTTP Redirector |
+------+ 1 | +-------------+ |
| |--------------> | | HTTP Server | |
| Host |<-------------- | +-------------+ |
+------+ 2 | ^ |
| | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+-----------------+
| ^
| | ALTO Protocol
v |
+-----------------+
| ALTO Server |<--- Real-time CDN
+-----------------+ status updates
Figure 3: RT CDN Updates to ALTO Server
In this model it is recommended that a given HTTP Redirector may be
designated as being responsible for a fixed set of Host PIDs. This
information can be made available to the HTTP Redirector 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, an HTTP Redirector 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 maps for relevant PID 2-tuples.
An HTTP Redirector 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.
The HTTP Redirector 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. In order to better deal with outages of
caches or changes to CDN PIDs, a push mechanism from ALTO server to
ALTO client would be needed (GAP-4). In the general P2P scenario
this may not make sense, but with content delivery this may be
important from a service continuity perspective.
If the maps are large and change often a natural extension to the
protocol is to allow incremental Map Updates (GAP-5). This
requirement becomes more emphasized when the ALTO Server is the
recipient of CDN nodes' status updates, because their load/status
Penno, et al. Expires January 13, 2011 [Page 9]
Internet-Draft Abbreviated-Title July 2010
changes are typically more frequent than topology changes in the
network.
GAP-4 (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.
GAP-5 (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.
4.2. DNS Integration
In the case of DNS request routing, the DNS server handling host
requests is integrated with an ALTO client. When the host performs a
DNS query/lookup, the IP address contained in the response is already
optimal for that query. As in the previous example, no changes in
the host are needed.
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 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, as shown in examples in
the next section, 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.
Penno, et al. Expires January 13, 2011 [Page 10]
Internet-Draft Abbreviated-Title July 2010
4.3. ALTO Server Discovery
5. Administrative domains and ALTO
With DNS-based redirection, among others, there are two models that
are worth further study - one, where the CDN nodes are in the
administrative domain of the ISP and two, where CDN nodes are part of
a separate domain from that of the ISP. In the first use case, the
Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server
for the CDN domain are in the same administrative domain. In the
second use case, Hosts and CDN Nodes are in different administrative
domains.
5.1. CDN nodes in the ISP administrative domain
When the CDN nodes are within the ISP's administrative domain, the
DNS server with the ALTO client is under the ISP's management. A
best CDN nodes can be picked by performing ALTO query on the source
IP address (and the target domain name) of the DNS request.
Penno, et al. Expires January 13, 2011 [Page 11]
Internet-Draft Abbreviated-Title July 2010
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 | :
: +----------------+ :
: :
: NSP/CDN Administrative Domain :
:.............................................................:
Figure 4: DNS Resolution with single admin domain
5.2. CDN nodes in a separate administrative domain from that of ISP
In many situations, the CDN nodes 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 January 13, 2011 [Page 12]
Internet-Draft Abbreviated-Title July 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 5: 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 January 13, 2011 [Page 13]
Internet-Draft Abbreviated-Title July 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 January 13, 2011 [Page 14]
Internet-Draft Abbreviated-Title July 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.
GAP-6: Federation of ALTO servers: There is a need to define how
ALTO servers may communicate with each other in a federated model.
GAP-7: 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.
5.3. Integrating with managed DNS service
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)
5.3.1. Managed DNS resolver used to redirect to local cache
One of the common functions offered by managed DNS service vendor is
DNS traffic management where DNS resolver can load balance traffic
dynamically across content servers.
Typically managed DNS service provider has DNS resolvers spread
Penno, et al. Expires January 13, 2011 [Page 15]
Internet-Draft Abbreviated-Title July 2010
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.
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
Penno, et al. Expires January 13, 2011 [Page 16]
Internet-Draft Abbreviated-Title July 2010
5.3.2. Managed DNS resolver used with multiple CDN vendors
In this Model, Managed DNS service can be used along with multiple
CDN vendors where DNS resolver can redirect to different caches
depending on the subdomain e.g. DNS resolver could have below
records
subdomain1.xyz.com CNAME cdn1.com
subdomain2.xyz.com CNAME cdn2.com
In this case CDN DNS resolver needs to be an ALTO client. This
deployment will be similar to ones described in section 6.1 and
section 6.2 earlier.
6. Tracker Integration
In the case of P2P CDNs, the application tracker takes the role of
the ALTO Client, fetching the map from the ALTO Server and
integrating it its peer database. The result is a peer database
taking into account current metrics such as peer availability,
content availability and also localization. This architecture in the
context of file sharing was extensively studied and trialed by ISPs
such as Comcast [RFC5632] under the P4P [P4P] protocol.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. 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.
9. Acknowledgements
We would like to thank Richard Yang for valuable input and
Penno, et al. Expires January 13, 2011 [Page 17]
Internet-Draft Abbreviated-Title July 2010
contributions to this draft. We would also like to thank Nabil
Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry
Sutanto for their comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[ARBOR] Labovitz, "Internet Traffic and Content Consolidation",
2009, <http://www.ietf.org/proceedings/10mar/slides/
plenaryt-4.pdf>.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-03 (work in progress),
March 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 January 13, 2011 [Page 18]
Internet-Draft Abbreviated-Title July 2010
Satish Raghunath
Juniper Networks
Email: satishr@juniper.net
Jan Medved
Juniper Networks
Email: jmedved@juniper.net
Mayuresh Bakshi
Juniper Networks
Email: mbakshi@juniper.net
Richard Alimi
Yale University
Email: richard.alimi@yale.edu
Stefano Previdi
Cisco Systems
Email: sprevidi@cisco.com
Penno, et al. Expires January 13, 2011 [Page 19]