< draft-penno-alto-cdn-01.txt   draft-penno-alto-cdn-02.txt >
Network Working Group R. Penno Network Working Group R. Penno
Internet-Draft S. Raghunath Internet-Draft S. Raghunath
Intended status: Experimental J. Medved Intended status: Experimental J. Medved
Expires: January 13, 2011 M. Bakshi Expires: April 28, 2011 Juniper Networks
Juniper Networks
R. Alimi R. Alimi
Google
R. Yang
Yale University Yale University
S. Previdi S. Previdi
Cisco Systems Cisco Systems
July 12, 2010 October 25, 2010
ALTO and Content Delivery Networks ALTO and Content Delivery Networks
draft-penno-alto-cdn-01 draft-penno-alto-cdn-02
Abstract Abstract
Networking applications can request through the ALTO protocol Networking applications can request through the ALTO protocol
information about the underlying network topology from the ISP or information about the underlying network topology from the ISP or
Content Provider (henceforth referred as Provider) point of view. In Content Provider (henceforth referred as Provider) point of view. In
other words, what a Provider prefers in terms of traffic optimization other words, information about what a Provider prefers in terms of
-- and a way to distribute it. The ALTO Service provides information traffic optimization -- and a way to distribute it. The ALTO Service
such as preferences of network resources with the goal of modifying provides information such as preferences of network resources with
network resource consumption patterns while maintaining or improving the goal of modifying network resource consumption patterns while
application performance. maintaining or improving application performance.
A main use case of the ALTO Service is its integration with of One of the main use cases of the ALTO Service is its integration with
Content Delivery Networks (CDN). In this document we describe the Content Delivery Networks (CDN). The purpose of this draft is
deployment scenarios and considerations for a ALTO Service in the twofold: first, to describe how ALTO can be used in existing and new
case of CDNs. 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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 14 skipping to change at page 2, line 18
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Content Location Selection . . . . . . . . . . . . . . . . . . 5 4. Request Routing as an Integration Point of ALTO into CDN . . . 5
4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5 4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. The Map Service . . . . . . . . . . . . . . . . . . . 6 4.2. DNS Request Routing . . . . . . . . . . . . . . . . . . . 6
4.1.2. The Endpoint Cost Service . . . . . . . . . . . . . . 7 5. Basic Scheme of CDN/ALTO Integration . . . . . . . . . . . . . 6
4.1.3. CDN Node Discovery and Status . . . . . . . . . . . . 7 5.1. Basic Integration Scheme . . . . . . . . . . . . . . . . . 6
4.2. DNS Integration . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. ALTO for HTTP Redirect . . . . . . . . . . . . . . . . 7
4.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 11 5.1.2. ALTO for DNS Resolution . . . . . . . . . . . . . . . 8
5. Administrative domains and ALTO . . . . . . . . . . . . . . . 11 5.2. Multi-hop Redirection . . . . . . . . . . . . . . . . . . 8
5.1. CDN nodes in the ISP administrative domain . . . . . . . . 11 5.3. CDN Node Discovery and Status Notification . . . . . . . . 8
5.2. CDN nodes in a separate administrative domain from 5.3.1. CDN Node Status Updates received by Request Router . . 9
that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.2. CDN Node Status Updates received by ALTO . . . . . . . 10
5.3. Integrating with managed DNS service . . . . . . . . . . . 15 6. Request Routing using ALTO Services . . . . . . . . . . . . . 10
5.3.1. Managed DNS resolver used to redirect to local 6.1. Request Routing using the Map Service . . . . . . . . . . 10
cache . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Request Routing using the Endpoint Cost Service . . . . . 11
5.3.2. Managed DNS resolver used with multiple CDN vendors . 17 7. Multiple Administrative Domains . . . . . . . . . . . . . . . 12
6. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 17 7.1. CDN nodes/Request Router in a separate administrative
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 domain from that of ISP . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.2. Managed DNS Domain with Three Administrative Domains . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.1. Managed DNS Redirect to Local CDN . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2.2. Managed DNS with CDN-Provided Request Routing . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8. Protocol Recommendations . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.1. Necessary Additions . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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
1. Introduction 1. Introduction
Content Delivery Networks are becoming increasingly important in the Content Delivery Networks are becoming increasingly important in the
Internet [ARBOR] and many CDNs today already use some form of Internet [ARBOR] and many CDNs today already use some form of
proximity through geolocation. But in many cases the content proximity through geolocation. But in many cases the content
provider/distributor and the Internet Service Provider are disjoint provider/distributor and the Internet Service Provider are disjoint
and even if content servers are co-located into the ISP's networks, and even if content servers are co-located into the ISP's networks,
there is no standardized way to share information. Therefore a there is no standardized way to share server location and/or network
natural step forward would be to use ALTO to share information. 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 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 it is desirable that no changes to the hosts are needed (or that
transparent to the user). In other words, a traditional web browser changes to hosts would be transparent to the user). In other words,
is all there is needed to take advantage of ALTO information. This a traditional web browser is all there is needed to take advantage of
is a significant difference from the P2P applications where a special ALTO information. This is a significant difference from the P2P
client is typically needed and ALTO is normally used as a way to applications where a special client is typically needed and ALTO is
reduce operational expense. normally used as a way to reduce operational expense.
2. Scope 2. Scope
This document discusses how Content Delivery Networks can benefit This document discusses how Content Delivery Networks can benefit
from ALTO through integration of the ALTO Service with the main from ALTO through integration of the ALTO Service with the main
request routing techniques. Whenever a gap in protocol functionality request routing techniques. There are two objectives:
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 o Present basic integration schemes of ALTO into CDNs.
to foster parallel discussions and possible adoption.
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 3. Terminology
Content-aware Proximity Redirector: The Redirector knows about Content-aware Proximity Request Router: The Request Router knows
locations and presence of content & media objects in the network. about locations and presence of content & media objects in the
Therefore the redirection to a CDN node is made based on network. Therefore the redirection to a CDN node is made based on
availability of content or content-type in that CDN node and the both the availability of content or content-type in that CDN node
proximity of the CDN node to the user. and the proximity of the CDN node to the requesting user.
Service-aware Proximity Redirector: The Redirector knows about Service-aware Proximity Request Router: The Request Router knows
locations of CDN nodes in the network and redirects user to the about locations of CDN nodes in the network and redirects user to
closest CDN node. A redirection is made irrespective of content the closest CDN node. A redirection is made irrespective of
presence in the CDN node; if content is not present, the node will content presence in the CDN node; if content is not present, the
be populated with the content before or when the content is served node will be populated with the content while the content is
to the user. served to the user.
HTTP Redirector: a Content-aware or Service-aware Proximity HTTP Request Router: a Content-aware or Service-aware Proximity
Redirector for HTTP. It embeds an HTTP Server that performs HTTP Request Router for HTTP. It embeds an HTTP Server that performs
Redirects, an ALTO client that retrieves network mapping from the HTTP Redirects, an ALTO client that retrieves network mapping from
ALTO Server and a Location Database which stores network mappings the ALTO Server, and a Location Database which stores network
received from the ALTO Client. The HTTP Server consults the mappings received from the ALTO Client. The HTTP Server consults
Location Database when making redirection decisions. the Location Database when making redirection decisions.
4. Content Location Selection 4. Request Routing as an Integration Point of ALTO into CDN
There are multiple mechanisms that ISPs and CDNs can use to select Content Distribution is a rich and evolving field. New architectures
the location from which content is served to a particular host, where and approaches (e.g., a hybrid architecture using both servers and
information from one or more ALTO Servers can be used to improve or P2P) continue to be developed in the research community and industry
optimize the selection. In particular, two commonly used location and some are being deployed in production networks. While we would
selection mechanisms are HTTP Redirect and DNS name resolution. like to provide a survey of each possible CDN architecture and show
Thus, we focus on these two mechanisms. 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 4.1. HTTP Redirect
In this case an HTTP GET request from a host is received by an HTTP In this mechanism, an HTTP GET request from a host is received by an
Redirector which sends back an HTTP responses with Status-Code 302 HTTP Request Router which sends back an HTTP responses with Status-
(Redirect) informing the host of the most optimal location to fetch Code 302 (Redirect) informing the host of the most optimal location
the content. The HTTP Redirection method is already commonly used in to fetch the content. The HTTP Redirection method is already
production CDNs as described in RFC3568 [RFC3568]. ALTO integration commonly used in production CDNs as described in RFC3568 [RFC3568].
provides localization services where the device that performs the ALTO integration provides localization services where the device that
redirection becomes an ALTO client. performs the redirection becomes an ALTO client.
Usage of the ALTO Server with HTTP Redirects is shown in the 4.2. DNS Request Routing
following figure. Either the Map Service or the Endpoint Cost
Service can be used by the ALTO client embedded in the HTTP In this mechanism, the DNS server handling host requests provides the
Redirector entity. 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.
+-----------------+ +-----------------+
| HTTP Redirector | | Request Router |
+------+ 1 | +-------------+ | +-----------+ 1 | |
| |--------------> | | HTTP Server | | | |---------> | |
| Host |<-------------- | +-------------+ | | Requestor |<-------- | |
+------+ 2 | ^ | +-----------+ 2 | |
| | |
| +-------------+ | | +-------------+ |
| | ALTO Client | | | | ALTO Client | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
| ^ | ^
| | ALTO Protocol | | ALTO Protocol
v | v |
+-----------------+ +-----------------+
| ALTO Server | | ALTO Server |
+-----------------+ +-----------------+
Figure 1: HTTP Redirector Figure 1: Request Router with ALTO
4.1.1. The Map Service 5.1.1. ALTO for HTTP Redirect
The ALTO client embedded in the HTTP Redirector fetches the Network To make the basic scheme more concrete, Figure 2 shows the case that
and Cost Maps from the ALTO Server and provides that information to the Request Router uses HTTP Redirect.
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 | HTTP Request Router |
hosting. Therefore the IP addresses contained in the cost maps may +------+ 1 | +-------------+ |
need to be correlated to domain names a priori. | |--------------> | | HTTP Server | |
| Host |<-------------- | +-------------+ |
+------+ 2 | ^ |
| | |
| +-------------+ |
| | ALTO Client | |
| +-------------+ |
+---------------------+
| ^
| | ALTO Protocol
v |
+---------------------+
| ALTO Server |
+---------------------+
The Network Maps generated by the ALTO server contain Host PIDs and Figure 2: ALTO for HTTP Request Router
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 5.1.2. ALTO for DNS Resolution
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 Figure 3 shows the case that the Request Router uses DNS Resolution.
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 2 +----------------+
the ALTO Client to select an appropriate CDN Node and also passed +------------------> | root |
as a constraint in the map filtering service. | +----------------- | 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 |
+----------------+
GAP-3 (Default Cost): The issue of default cost is one of Figure 3: ALTO for DNS Resolution.
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 5.2. Multi-hop Redirection
Alternatively, ALTO client embedded in the HTTP Redirector, requests The preceding examples show the logical flow for redirection. It is
the endpoint cost service from the ALTO client. important to state that there maybe multiple redirection hops.
The Redirector knows the IP address of the user (content requester) For HTTP Redirect, the requestor may be redirected again by the first
and the different content locations. It then requests the Endpoint CDN node. For DNS, the first DNS server may direct, using aggregated
Cost Service in order to rank/rate the content locations (i.e., IP ALTO information (e.g., from multiple ALTO Servers of multiple ISPs),
addresses of CDN nodes) based on their distance/cost (by default the the DNS resolution to a second level DNS server, which then may use
Endpoint Cost Service operates based on Routing Distance) from/to the more specific ALTO information as well as CDN node status.
user address.
Note that the mechanisms through which the CDN acquires the IP 5.3. CDN Node Discovery and Status Notification
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 Since ALTO for HTTP Redirect and that for DNS have many common
locations (for the specific user) it can incorporate this information issues, we use the basic general scheme unless stated otherwise.
into its selection mechanisms in order to point the user to the most
appropriate location.
4.1.3. CDN Node Discovery and Status 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.
The method of discovering available caches and their locations is It is desirable that not only CDN node locations, but also real-time
outside the scope of this document. We assume the CDN nodes are CDN node status (like health, load, cache utilization, CPU, etc.) is
discovered in some way. It is desirable that not only CDN node communicated to the CDN.
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 Specifically, CDN node status can be retrieved from the existing Load
infrastructure. Most Load Balancers today have mechanisms to poll Balancer infrastructure. Most Load Balancers today have mechanisms
caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have to poll caches/servers via ping, HTTP Get, traceroute, etc. Most LBs
SNMP trap capabilities to let other devices know about these have SNMP trap capabilities to let other devices know about these
thresholds. The HTTP Redirector or the ALTO Server can implement an thresholds.
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 [yry: move]In addition to the CDN node status, network status can
retrieved from TE/RP databases. also be retrieved from TE/RP databases.
4.1.3.1. CDN Node Status Updates received by HTTP Redirector We see two ways that CDN node status can be communicated into the
request routing decision process.
In this use case the HTTP Redirector receives CDN Status updates. 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.
+-----------------+ +-----------------+
| HTTP Redirector | | Request Router |
+------+ 1 | +-------------+ | +-----------+ 1 | |
| |--------------> | | HTTP Server | | | |---------> | |<--- Real-time CDN
| Host |<-------------- | +-------------+ | | Requestor |<-------- | | status updates
+------+ 2 | ^ |<--- Real-time CDN +-----------+ 2 | |
| | | status updates
| +-------------+ | | +-------------+ |
| | ALTO Client | | | | ALTO Client | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
| ^ | ^
| | ALTO Protocol | | ALTO Protocol
v | v |
+-----------------+ +-----------------+
| ALTO Server | | ALTO Server |
+-----------------+ +-----------------+
Figure 2: RT CDN Updates to HTTP Redirector Figure 4: CDN Node Status to Request Router
4.1.3.2. CDN Node Status Updates received by ALTO Server 5.3.2. CDN Node Status Updates received by ALTO
This model generally simplifies the HTTP Redirector. It allows an This model generally simplifies the Request Router. It allows an
easier distribution of the HTTP Redirector, and to keep real time CDN easier distribution of the Request Router, and to keep real time CDN
status data updates in a logically centralized ALTO Server or in an status data updates in a logically centralized ALTO Server or in an
ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO ALTO Server Cluster. It allows for the Request Router and the ALTO
Server to be in different administrative domains. For example, the Server to be in different administrative domains. For example, the
HTTP Redirector can be in a Content Provider's domain, the ALTO Request Router can be in a Content Provider's domain, the ALTO Server
Server and CDN Nodes in a Network Service Provider's domain. 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.
+-----------------+ +-----------------+
| HTTP Redirector | | Request Router |
+------+ 1 | +-------------+ | +-----------+ 1 | |
| |--------------> | | HTTP Server | | | |---------> | |
| Host |<-------------- | +-------------+ | | Requestor |<-------- | |
+------+ 2 | ^ | +-----------+ 2 | |
| | |
| +-------------+ | | +-------------+ |
| | ALTO Client | | | | ALTO Client | |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+
| ^ | ^
| | ALTO Protocol | | ALTO Protocol
v | v |
+-----------------+ +-----------------+
| ALTO Server |<--- Real-time CDN | ALTO Server |<--- Real-time CDN
+-----------------+ status updates +-----------------+ status updates
Figure 3: RT CDN Updates to ALTO Server Figure 5: CDN Node Status to ALTO
In this model it is recommended that a given HTTP Redirector may be 6. Request Routing using ALTO Services
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 Either the Map Service or the Endpoint Cost Service of ALTO can be
Network Maps Service may pre-download the network map for the used by the Request Router.
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 6.1. Request Routing using the Map Service
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- The ALTO client embedded in the Request Router fetches the Network
Control headers to decide how often to fetch CDN PID network map and and Cost Maps from the ALTO Server and provides that information to
Host PID network maps. In order to better deal with outages of the Request Router.
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 As an illustrative example, we consider the case of HTTP Redirect. A
protocol is to allow incremental Map Updates (GAP-5). This simple Request Router may be given (from an external source) the list
requirement becomes more emphasized when the ALTO Server is the of available CDN nodes. The Request Router precomputes a redirection
recipient of CDN nodes' status updates, because their load/status table indexed by source PID with values being the closest CDN nodes.
changes are typically more frequent than topology changes in the This redirection table can be built based on information from Network
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.
GAP-4 (Push Mechanism): It is important for the ALTO Service The illustrative example can also be extended to DNS.
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 The Network Maps generated by the ALTO Server will contain both Host
protocol if maps are large and change often is to allow for PIDs and CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN
incremental map updates. In this sense the map contained in the PIDs contain IP addresses of available CDN nodes. Cost Maps may
reply would be considered the delta from the previous version. 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.
4.2. DNS Integration 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.
In the case of DNS request routing, the DNS server handling host With such information ahead of time, a Request Router that uses the
requests is integrated with an ALTO client. When the host performs a Network Maps Service may pre-download the Network Map for the
DNS query/lookup, the IP address contained in the response is already interesting Host PIDs and the CDN PIDs. It can also start
optimal for that query. As in the previous example, no changes in periodically pulling Cost Map for relevant PID 2-tuples.
the host are needed.
DNS queries can be either iterative or recursive. Iterative queries The Request Router can rely on the ALTO Server generated Cache-
can be used with ALTO if the host itself queries the DNS Servers, or Control headers to decide how often to fetch CDN PID network map and
if the DNS Proxy used by the host is topologically close to the host. Host PID network maps.
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 For Alto protocol requirements related to request routing with the
the next section, the host queries the Proxy, which in turn first Map Service see Section 8.1.1 and Section 8.1.2.
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.
4.3. ALTO Server Discovery 6.2. Request Routing using the Endpoint Cost Service
5. Administrative domains and ALTO Alternatively, the Request Router may request the Endpoint service
from the ALTO client.
With DNS-based redirection, among others, there are two models that Specifically, the Request Router requests the Endpoint Cost Service
are worth further study - one, where the CDN nodes are in the in order to rank/rate the content locations (i.e., IP addresses of
administrative domain of the ISP and two, where CDN nodes are part of CDN nodes) based on their distance/cost (by default the Endpoint Cost
a separate domain from that of the ISP. In the first use case, the Service operates based on Routing Distance) from/to the user address.
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 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.
When the CDN nodes are within the ISP's administrative domain, the A Request Router that uses the Endpoint Cost Service may query the
DNS server with the ALTO client is under the ISP's management. A ALTO Server for rankings of CDN Node IP addresses for each
best CDN nodes can be picked by performing ALTO query on the source interesting Host and cache the results for later usage.
IP address (and the target domain name) of the DNS request.
2 +----------------+ 7. Multiple Administrative Domains
+------------------> | 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 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.
5.2. CDN nodes in a separate administrative domain from that of ISP 7.1. CDN nodes/Request Router in a separate administrative domain from
that of ISP
In many situations, the CDN nodes are in a separate network managed In many situations, the CDN nodes and the Request Router are in a
by an entity that is distinct from the ISP. Consequently, the CDN separate network managed by an entity that is distinct from the ISP.
nodes belong to a network with its own ALTO server that is distinct Consequently, the CDN nodes belong to a network with its own ALTO
from the ALTO server of the ISP where the subscriber belongs. server that is distinct from the ALTO server of the ISP where the
subscriber belongs.
................................. .................................
: +-----------------+ : : +-----------------+ :
: | cdn.com | : : | cdn.com | :
: | Name Server | : : | Name Server | :
+----------+ : | | : +----------+ : | | :
| Content | : | +-------------+ | : | Content | : | +-------------+ | :
| Provider | : | | ALTO Client | | : | Provider | : | | ALTO Client | | :
+----------+ : | +-------------+ | : +----------+ : | +-------------+ | :
: +-----------------+ : : +-----------------+ :
skipping to change at page 13, line 45 skipping to change at page 13, line 45
: | : : | : : | : : | :
: +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ : : +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ :
: | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | : : | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | :
: | PID3 | | Router |-------| Router | | PID10| : : | PID3 | | Router |-------| Router | | PID10| :
: +------+ | PID5 | : : | PID7 | +------+ : : +------+ | PID5 | : : | PID7 | +------+ :
: +--------+ : : +--------+ : : +--------+ : : +--------+ :
: : : : : : : :
: ISP Administrative Domain : : CDN Administrative Domain : : ISP Administrative Domain : : CDN Administrative Domain :
:...............................: :...............................: :...............................: :...............................:
Figure 5: Map advertising between ISP and CDN domains Figure 6: Map advertising between ISP and CDN domains
The ALTO server in the CDN provider network is assumed to be The ALTO server in the CDN provider network is assumed to be
initialized with information about the ISP networks it serves. For initialized with information about the ISP networks it serves. For
every such ISP network, it consults the routing plane to find the set 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 of Border routers. The CDN network ALTO server computes the cost of
reaching each Border router from every CDN node (say, C_cdn). reaching each Border router from every CDN node (say, C_cdn).
Next, the CDN ALTO server contacts the ISP network's ALTO server and 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 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 compute the cost from a CDN node to a subscriber's PID, we break it
skipping to change at page 15, line 29 skipping to change at page 15, line 29
The CDN ALTO server now has a cost map that provides the cost from 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 each CDN node to all known Subscriber PIDs. The ALTO client in the
CDN DNS server downloads this cost map in preparation for subscriber CDN DNS server downloads this cost map in preparation for subscriber
DNS requests. DNS requests.
When a subscriber DNS request arrives at the CDN provider's DNS 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 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 a Subscriber PID. It then uses the cost map to pick the best CDN
node for this Subscriber PID. node for this Subscriber PID.
GAP-6: Federation of ALTO servers: There is a need to define how 7.2. Managed DNS Domain with Three Administrative Domains
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 Many organizations / content providers outsource DNS management to
the external vendors for various reasons like reliability, the external vendors for various reasons like reliability,
performance improvement, DNS security etc. Managed DNS service could performance improvement, DNS security etc. Managed DNS service could
be used either with caches owned by the organization itself (section be used either with caches owned by the organization itself (section
6.3.1) OR with external CDNs (section 6.3.2) 6.3.1) OR with external CDNs (section 6.3.2)
5.3.1. Managed DNS resolver used to redirect to local cache 7.2.1. Managed DNS Redirect to Local CDN
One of the common functions offered by managed DNS service vendor is One of the common functions offered by managed DNS service vendor is
DNS traffic management where DNS resolver can load balance traffic DNS traffic management where DNS resolver can load balance traffic
dynamically across content servers. dynamically across CDN servers.
Typically managed DNS service provider has DNS resolvers spread Typically managed DNS service provider has DNS resolvers spread
across geographical locations to improve performance. This also across geographical locations to improve performance. This also
makes easier for DNS resolver to redirect host to the nearest cache. makes easier for DNS resolver to redirect host to the nearest cache.
Such a DNS resolver would be an ideal candidate to implement ALTO 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 client where it can fetch network map and cost map from ALTO servers
located in the same geographical area only. Load balancing located in the same geographical area only. Load balancing
implemented with the knowledge of network and cost map would be more implemented with the knowledge of network and cost map would be more
efficient than other mechanisms like round robin. efficient than other mechanisms like round robin.
skipping to change at page 17, line 5 skipping to change at page 16, line 46
`-----------------' `-----------------'
In the figure above, there exists 2 possibilities: In the figure above, there exists 2 possibilities:
Case 1: Domain 1 and Domain 2 are connected to the same service Case 1: Domain 1 and Domain 2 are connected to the same service
provider network. This case is similar to section 6.1 provider network. This case is similar to section 6.1
Case 2: Domain 1 and Domain 2 are connected to different service Case 2: Domain 1 and Domain 2 are connected to different service
provider network. This case is similar to section 6.2 provider network. This case is similar to section 6.2
5.3.2. Managed DNS resolver used with multiple CDN vendors 7.2.2. Managed DNS with CDN-Provided Request Routing
In this Model, Managed DNS service can be used along with multiple It is also possible to utilize a Managed DNS service and still rely
CDN vendors where DNS resolver can redirect to different caches on a CDN's request routing. For example, this could be done if a
depending on the subdomain e.g. DNS resolver could have below network provider wishes to utilize a Managed DNS provider, but also
records wishes to integrate its own CDN using ALTO with DNS-based request
routing.
subdomain1.xyz.com CNAME cdn1.com 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.
subdomain2.xyz.com CNAME cdn2.com 8. Protocol Recommendations
In this case CDN DNS resolver needs to be an ALTO client. This In the previous sections, this document has taken the approach of
deployment will be similar to ones described in section 6.1 and providing information on existing CDN approaches and possible
section 6.2 earlier. 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.
6. Tracker Integration This section will be updated to track changes in the ALTO Protocol,
ALTO Server Discovery, and accompanying protocols.
In the case of P2P CDNs, the application tracker takes the role of 8.1. Necessary Additions
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 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.
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
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. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 10. Security Considerations
When the ALTO Server and Client are operated by different entities When the ALTO Server and Client are operated by different entities
the issue of trust and security comes forward. The exchange of the issue of trust and security comes forward. The exchange of
information could be done using the encryption methods already information could be done using the encryption methods already
present in HTTP but preventing unauthorized redistribution comes into present in HTTP but preventing unauthorized redistribution comes into
play. A further issue is if the ALTO information information is play. A further issue is if the ALTO information information is
transitive, which modifications are allowed. transitive, which modifications are allowed.
9. Acknowledgements 11. Acknowledgements
We would like to thank Richard Yang for valuable input and We would like to thank Mayuresh Bakshi for valuable input and
contributions to this draft. We would also like to thank Nabil contributions to this draft. We would also like to thank Nabil
Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry
Sutanto for their comments. Sutanto for their comments.
10. References 12. References
10.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 12.2. Informative References
[ARBOR] Labovitz, "Internet Traffic and Content Consolidation", [ARBOR] Labovitz, "Internet Traffic and Content Consolidation",
2009, <http://www.ietf.org/proceedings/10mar/slides/ 2009, <http://www.ietf.org/proceedings/10mar/slides/
plenaryt-4.pdf>. plenaryt-4.pdf>.
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-03 (work in progress), draft-ietf-alto-protocol-05 (work in progress), July 2010.
March 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. [P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A.
Silberschatz, "P4P: Provider Portal for (P2P) Silberschatz, "P4P: Provider Portal for (P2P)
Applications", March 2009. Applications", March 2009.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
skipping to change at page 19, line 14 skipping to change at page 21, line 14
Satish Raghunath Satish Raghunath
Juniper Networks Juniper Networks
Email: satishr@juniper.net Email: satishr@juniper.net
Jan Medved Jan Medved
Juniper Networks Juniper Networks
Email: jmedved@juniper.net Email: jmedved@juniper.net
Mayuresh Bakshi Richard Alimi
Juniper Networks Google
Email: mbakshi@juniper.net Email: ralimi@google.com
Richard Alimi Richard Yang
Yale University Yale University
Email: richard.alimi@yale.edu Email: yry@yale.edu
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 91 change blocks. 
349 lines changed or deleted 497 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/