Network Working Group F. Douglis
Internet-Draft AT&T Labs
Expires: May 9, 2002 I. Chaudhri
PanteraTech, Inc.
P. Rzewski
Inktomi
Nov 8, 2001
Known Mechanisms for Content Internetworking
draft-douglis-cdi-known-mech-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
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 May 9, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Content Networks provide infrastructure, at layers 4 through 7, to
get content to end users in a scalable, reliable, and cost-effective
fashion. Content Internetworking is the interconnection of multiple
content networks. This document describes some existing technologies
for content internetworking.
Douglis, et al. Expires May 9, 2002 [Page 1]
Internet-Draft CDI Known Mechanisms Nov 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Content Bridge . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Authentication, Authorization, and Accounting . . . . . . . . 7
2.5 Request-Routing . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Operator roles . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. CiRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 How CiRouter Works . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Content-Provisioning . . . . . . . . . . . . . . . . . . . . . 12
3.4 Content Publishing . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Content-Routing . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Content-Billing . . . . . . . . . . . . . . . . . . . . . . . 13
3.7 Content-Reporting . . . . . . . . . . . . . . . . . . . . . . 14
4. IDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Request-Routing . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Authentication, Authorization, and Accounting . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
B. Intellectual Property Rights . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
Douglis, et al. Expires May 9, 2002 [Page 2]
Internet-Draft CDI Known Mechanisms Nov 2001
1. Introduction
Content Networks provide infrastructure, at layers 4 through 7, to
get content to end users in a scalable, reliable, and cost-effective
fashion. Content Internetworking is the interconnection of multiple
content networks [7]. For somewhat historical reasons, "Content
Internetworking" is also referred to as "Content Distribution
Internetworking" and abbreviated "CDI". As of this writing, CDI is
under consideration as an IETF working group.
There are a number of existing documents that cover various aspects
of content networks and CDI. These include:
o The "models" document [7] provides an overview of CDI and defines
some terminology.
o The "scenarios" document [8] discusses ways in which CDI might be
used in general.
o The "known request-routing mechanisms" document [2] covers
existing techniques for request-routing in content networks (not
necessarily CDI).
o The "architectural overview" [10] establishes an abstract
architectural framework for CDI.
o Finally, there are several requirements documents relating to CDI,
including "request-routing requirements" [4], "distribution
requirements" [1], and "AAA requirements" [11].
This document attempts to bridge a gap between the scenarios draft
and the requirements drafts, by surveying existing request-routing,
distribution, and AAA mechanisms for CDI. The reader is assumed to
be familiar with all aforementioned CDI-related documentation.
This document encompasses three existing systems. To offer
information about additional systems, contact the editor.
Content Bridge. Content Bridge [5] is an arrangement for content
providers to gain some control over existing, deployed HTTP
caching proxies in access networks. Content providers are able to
send signals of content changes to those proxies in order to keep
them consistent with origin servers. The content providers may
also retrieve accounting information associated with their content
from those proxies. An "operator" assists in the distribution of
content signals and the aggregation of accounting data.
CiRouter The Content Internetworking Router, CiRouter, in conjunction
Douglis, et al. Expires May 9, 2002 [Page 3]
Internet-Draft CDI Known Mechanisms Nov 2001
with CiAdmin allows CDN providers to provision, publish, route,
track performance and gather billing usage data from the partner
CDNs. The CiRouter directs browsers to retrieve web site content
from the best source, where best is defined by a combination of
price, performance, specific CDN accounts, and Internet regions
set by the CiAdmin. CiRouter [9] uses URL rewriting (akin to the
Content Modification approach described in Section 4.2 of the
"known CDN request-routing mechanisms" document [2], to direct
clients to one of a set of CDNs.
IDNS. AT&T has a DNS-based redirection system, called Intelligent
DNS (IDNS), to direct clients to one of a set of CDNs [3]. Each
CDN then does its own DNS redirection to a particular cache within
its own network. IDNS has similarities to the DNS-based multi-
level request-routing resolution described in Section 2.3 of the
"known CDN request-routing mechanisms" document [2], but it
typically redirects to a completely different CDN with its own
internal request-routing system.
Douglis, et al. Expires May 9, 2002 [Page 4]
Internet-Draft CDI Known Mechanisms Nov 2001
2. Content Bridge
[EDITOR'S NOTE: The order and content of the following subsections
vary. Does this matter?]
2.1 Overview
[EDITOR'S NOTE: the text in this section describes Content Bridge
circa autumn, 2000. The author of this text is not employed by the
company that currently operates Content Bridge, and therefore is not
privy to updated knowledge of the current state of Content Bridge.
However, this text has been written with the consent of a current
Content Bridge spokesperson. Corrections and updates are solicited.]
Content Bridge was created as a service that would allow content
providers to gain some control over deployed HTTP caching proxies in
access networks. These proxies were typically already deployed by
the access networks in a "forward" manner, implying they were used by
clients through such methods such as explicit (browser) configuration
or interception [6]. Therefore, a content provider's content was
already being stored in these caching proxies based on user demand.
In this situation, the only way for the content provider to control
freshness of objects in these proxies would be through setting HTTP
expiry times or "No-Cache" headers when objects were served from an
origin. Similarly, a typical way to gather accounting data in this
scenario would be through setting HTTP headers to ensure If-Modified-
Since requests were made to the origin each time the proxy received a
client request. A primary goal of Content Bridge was to make
freshness control and the gathering of accounting more efficient than
this.
2.2 Architecture
Because Content Bridge consisted of both distribution internetworking
and accounting internetworking, there were separate architectures for
each.
Douglis, et al. Expires May 9, 2002 [Page 5]
Internet-Draft CDI Known Mechanisms Nov 2001
The distribution architecture is shown in the following diagram:
Origin CDN/Hoster Operator Access
Provider
---------- --------- --------- --------- --------
|content | |content| |content| |content| |access|
|injector|-->| relay |-->| relay |-->| relay |-->| cache|
---------- --------- --------- --------- --------
(many) (several) (few) (several) (many)
Content signals (e.g. invalidation messages) would originate at a
point of origin, controlled by a content provider. These signals
would be received by a CDN or hosting company that provided Content
Bridge service to the content providers. These CDNs and Hosters
played the role of aggregating these content signals. Once
aggregated, these signals would be passed to a central Operator, who
would then relay them out to the various access networks that were
contractually entitled to receive the signals. The Operator's
primary role in this case was to ensure that signals were relayed
between "peer" networks. Once signals were received by an access
network, they would be relayed to potentially many caching proxies
deployed internally.
Note that, when an access cache receives and acts on content signals
in this manner, it now doubles as a "surrogate", because it is now "a
gateway [...] delegated the authority to operate on behalf of, and
typically working in close co-operation with, one or more origin
servers" [6].
The accounting architecture is shown in the following diagram:
CDN/Hoster Operator Access
Provider
------------ ------------ ------------ --------
|accounting| |accounting| |accounting| |access|
| relay |<--| relay |<--| relay |<--| cache|
------------ ------------ ------------ --------
(several) (few) (several) (many)
For each content provider affiliated with a "peer" CDN/Hoster, the
caching proxies in the access networks would be responsible for
maintaining a separate log per domain. Periodically, these logs
would be sent up to an aggregation box controlled by the access
provider that would create summary logs. The summaries of each
access provider would be aggregated yet again when passed up to the
Douglis, et al. Expires May 9, 2002 [Page 6]
Internet-Draft CDI Known Mechanisms Nov 2001
central Operator. Once fully aggregated, these logs could be used
for settlement and then made available to CDN/Hoster for eventual
passing back to the content provider.
An overall design goal of Content Bridge was to re-use as many
existing standards (e.g. HTTP methods) and common data formats (e.g.
log file layout) as possible.
2.3 Distribution
The only supported content signal in Content Bridge was
"invalidation", which was provided using the HTTP DELETE method.
Starting with the injector (controlled by the content provider), HTTP
DELETE operations would be relayed, eventually being received by the
caching proxies in the access networks. When received, a caching
proxy would naturally act on an HTTP DELETE by invalidating the
referenced object(s) from its cache.
In some access provider networks, their content relays would often
contain caches as well. This gave them the option to react to an
HTTP DELETE by proactively doing an HTTP GET of the referenced
objects, effectively "pre-loading" the cache with a fresh copy of the
object. To allow for this to be specifically addressed by Content
Bridge, an additional "pre-load" header would be included when an
Injector originated an HTTP DELETE request, and peer access networks
would pre-load based on the presence of this header (in exchange for
additional funding).
Note that, once participating in Content Bridge, any requests by
access provider clients for content of "peered" domains could be
treated in a special manner. Specifically, the access provider could
choose to ignore any HTTP expiration headers on the objects stored in
its caching proxies, since the distribution system of Content Bridge
ensured that an invalidation message would be sent in the event that
any objects in that domain were to expire.
2.4 Authentication, Authorization, and Accounting
The typical accounting mechanism provided by Content Bridge was
effectively a unique summary format, but designed to be similar to
SQUID. For each URL accessed via a caching proxy, a summary line
would appear that included the total number of hits for the object,
average client access time across all his, total number of non-hits
for the object, etc. If a content provider wanted more granular
data, full SQUID logs could also be made available (typically at
additional cost). All logs would be kept by the access provider in
separate files based on domain, allowing them to be easily divided up
for eventual delivery to content providers.
Douglis, et al. Expires May 9, 2002 [Page 7]
Internet-Draft CDI Known Mechanisms Nov 2001
Log data would typically be stored in the access provider's caching
proxies for a small time period (e.g. several minutes) before being
forwarded to an accounting relay for aggregation. Each accounting
relay in line toward the content provider would similarly aggregate
just a few minutes of data before passing to the next party. This
prevented the need for periodic, massive log file pushes, and also
allowed content providers to see their utilization data with minimal
delays.
The method of relaying log file data was through an HTTP POST
operation.
There were no special provisions for Authentication and Authorization
in Content Bridge. Rather, since the participating "surrogates" were
actually HTTP caching proxies, normal HTTP rules applied (i.e. no
caching of responses to requests that required HTTP authentication,
etc.)
2.5 Request-Routing
Because the access provider participants had already chosen to deploy
their caching proxies in a "forward" manner, Content Bridge
participants had no ability to affect the request-routing decisions
for content requests. Rather, the request-routing was already
statically set: The client request would go to a caching proxy of the
access provider's choosing. In the event of a "miss", the request
would then possibly go through a content relay that also contains a
cache (acting as an HTTP parent), and then directly to an origin
server.
Whereas the content provider did not have any technical control over
the request-routing path, the contractual nature of the peering
relationship was effectively an endorsement of this request routing:
The peering relationship requested that the access provider to route
all its clients' content requests for the content provider's domains
to the very same caching proxies that were receiving the content
signals and aggregating the accounting data for the content
provider's objects.
2.6 Operator roles
Much like NAP operators eased peering configuration and data exchange
in the early days of bandwidth peering, the central Operator had an
analogous role in Content Bridge.
By providing centralized content relays and accounting relays,
peering between content networks could be accomplished with minimal
technical configuration. For example, if a content provider decided
Douglis, et al. Expires May 9, 2002 [Page 8]
Internet-Draft CDI Known Mechanisms Nov 2001
it wanted its content signals distributed to several access
providers, it could state this goal to the Operator, and the Operator
would take the responsibility of ensuring that the messages were
relayed to the correct access providers.
Another benefit of providing centralized accounting is the ability to
provide settlement between networks. Content Bridge was primarily
used for the distribution of "ad-revenue based" content. In other
words, content providers wanted to have their content distributed as
widely and efficiently as possible in the interest of increasing the
number of page views. As a result, these content providers would pay
an amount proportional to the quantity of data served by the access
providers' caching proxies, and this traffic would be reflected in
the logs. As a neutral third party, the Operator had the
responsibility to collect funds based on these logs and distribute
payments.
By acting as the central authority for settlement, the Operator could
potentially play even more roles. For example, when performing
accounting based on logs, there is naturally a fear of fraud (e.g.
by fabricating log data). Analytical "fraud detection" tools do
exist, but naturally there is a cost with owning and operating the
tools. By providing this as a central service, the Operator could
give peace of mind to participants without requiring each of them to
operate their own instances of fraud detection software.
2.7 Security
Because the control signals and accounting data were transported over
standard HTTP sessions, common HTTP security methods could be used to
ensure the integrity of data. This could include SSL encryption
and/or certificates.
Douglis, et al. Expires May 9, 2002 [Page 9]
Internet-Draft CDI Known Mechanisms Nov 2001
3. CiRouter
3.1 Overview
The CiRouter provides a turnkey meta-CDN solution for managing
content routing through multiple content delivery networks. The
CiRouter is deployed by Service Providers (SPs) who wish to become a
CDN by utilizing the minimum amount of network infrastructure to form
a primary network. The end-to-end meta-CDN solution includes content
provisioning, content publishing, content routing, content billing
and content reporting. A web based application allows network
administrators to provision sites. Content publishing provides
capability of dynamic translation to multiple CDNs per viewer basis.
Content routing directs browsers to retrieve web site content from
the best source, where best is defined by a combination of price,
performance, specific CDN accounts, and Internet regions. Content
billing aggregates the CDN usage per site or per customer basis.
Content reporting provides different views of the CDN usage.
Douglis, et al. Expires May 9, 2002 [Page 10]
Internet-Draft CDI Known Mechanisms Nov 2001
The following figure shows how to enable Service Providers to become
a CDN and manage the amount of traffic that is routed through each of
the peered networks.
.....................................................................
. .
. --------------- .
. +------> | Publisher's |-------- .
. | |own CDN account| | .
. ----+----- --------------- V .
. | | ------- .
. | Hosting | | | .
. |CiRouter | --------------- | | .
. | |->| Regional |--->| | .
. ----------- | CDN | | CDN | | | .
. | Publisher | |Selection | --------------- |Viewer | .
. | Server |---> | Criteria | | | .
. | | | | | | .
. ----------- | | --------------- | | .
. | |->| Specialty |--->| | .
. | | | CDN | | | .
. | | --------------- | | .
. | | ------- .
. -----+---- /\ .
. | | .
. v | .
. ---------- | .
. | Hosting |---------------------------+ .
. | Caches | .
. ---------- .
. .
.....................................................................
3.2 How CiRouter Works
......................................................................
. .
. .
. 2. CiRouter dynamically translates.
Douglis, et al. Expires May 9, 2002 [Page 11]
Internet-Draft CDI Known Mechanisms Nov 2001
. 3. Viewer's browser content for selected source CDN.
. fetches objects and inserts performance code .
. from selected sources HTML .
. +---------------------------------------+ . .
. | | .
. | | .
. +-----V---+ Content +--------+ .
. | |<------------------------------| | .
. | | Content | | +--------+ .
. | |<------------------------------| |<-| Web | .
. | Viewer | |CiRouter| |Hosting | .
. | | | | +--------+ .
. | | Content ___ Content | | /\ .
. | |<-------- / \ <--------------| | | .
. | | |CDNs |__ | | +---+----+ .
. +---------+ \___/ \ +-------+ |Content | .
. | | | | /\ /\ |Provider| .
. | | \ __ / | | +--------+ .
. | +----------------------------------------+ | .
. | 1. Initial Web site | .
. | Request www.publisher.com +-+----------------+.
. | (DNS resolution) |Populate CiRouter |.
. | |proximity DB |.
. +------------------------------------------->|with network |.
. 4. Browser provides performance |performance data |.
. feedback for each CDN |and/or business |.
. |rules |.
. +------------------+.
......................................................................
3.3 Content-Provisioning
The CiAdmin enables transparent content delivery network (CDN)
peering, by providing the ability to provision, securely publish,
report usage, and report performance of content delivery on multiple
CDNs. The CiAdmin is a web-based real-time content provisioning and
reporting system for CiRouters that allows business rules based
acceleration of web sites giving one control over the delivery of the
content. CiAdmin is also capable of providing billing system ready
usage data from all partner CDNs. The CiAdmin:
1. Provisions websites through a real-time web-based administration
interface
Douglis, et al. Expires May 9, 2002 [Page 12]
Internet-Draft CDI Known Mechanisms Nov 2001
2. Gathers and provides usage information from all partner CDNs to a
billing system
3. Provides reports that analyze system performance and usage across
all partner CDNs
4. Provides actual viewer performance improvement for each
accelerated website
3.4 Content Publishing
CiRouter determines the best CDN to deliver the content through for
embedded objects. Content is cached in the CDN caches based on pull-
based HTTP requests. On a cache miss, the CDN retrieves the content
from the CiRouter's primary network. On a cache miss on the primary
network, the primary network retrieves the content from the origin
server.
3.5 Content-Routing
Content Delivery with the CiRouter using internal and peered CDNs:
1. The end-user enters Web site URL to request page from Web site
2. The browser is directed to a CiRouter via DNS
3. A price/performance based algorithm determines "best" delivery
method for serving the content to that particular end-user
4. The CiRouter delivers HTML content by rewriting the URLs of the
embedded objects to point to the best CDN and by inserting
instructions to the end-user's browser to test several delivery
alternatives the service provider has included in its portfolio.
The CiRouter also tags the content to allow for publisher
identification from raw logs.
5. The selected node (internal CDN or peered CDN) delivers embedded
objects and the full page with objects displays on the browser
6. The browser provides performance feedback to CiRouter
3.6 Content-Billing
Content Billing provides the following capabilities:
1. Collects all primary network logs
Douglis, et al. Expires May 9, 2002 [Page 13]
Internet-Draft CDI Known Mechanisms Nov 2001
2. Collects peered network logs
3. Splits the logs based on publisher account and collates logs from
all sources per publisher
4. Generates per-publisher billing-ready usage reports for internal
CiRouters
5. Generates per-publisher billing ready usage reports for all
networks
3.7 Content-Reporting
Content reporting has the following features:
1. Service providers can use reports to understand how the content
is being routed and what performance was delivered
2. Publishers can get insight into performance improvement delivered
by the service provider
3. Different reporting metrics are used, e.g.: Gbytes, Hits, Mbps,
top URLs
4. The browser provides performance feedback to CiRouter
Douglis, et al. Expires May 9, 2002 [Page 14]
Internet-Draft CDI Known Mechanisms Nov 2001
4. IDNS
4.1 Overview
The "Intelligent DNS" (IDNS) system uses a DNS server to redirect,
typically via the DNS CNAME response, to a DNS server within a
selected CDN. The brokering DNS server monitors the load of other
CDNs within a set of predefined "regions" (e.g., individual
countries). Using the IP address of the DNS server making a request,
IDNS maps the DNS server to a region and selects the CDN that serves
that region "best" based on various metrics.
IDNS uses CNAME or NS redirection to other CDNs, or it can forward
the DNS request directly to a CDN that will respond to the request
directly:
Origin Server
+-------+
-->| |
---- | |
---- +-------*
---- \ CDN H
+- -------- \
| ---//---------\\-- \ ----------
| // \ \ /// +---+ \\\
| / CDN B \\\ \ || |***| ||
| \ \ | +++---+ |
/| \ \ | oo +---+ |
| | (IDNS) | \ || ++ |***| ||
| | +---+ ++ Brokering | \ \\\ +---+///
| | |***| oo DNS | \ ----------
| | +---+ ++ \ | \
| | | \\ ++ ++ | \
| | | \XX XX | \
| v | ++ ++ | \
| +---+ ++ | | \
| |***| oo | ^| | \
\ +---+ ++ | || / \
\ ^ . 2|| 3 / ------\---
\\ \ .. | || // /-------- \ \\\
\\ \ .. | || // ||++ +---+ \ ||
\--\. |-++/ |--oo |***| +---+ |
..\------+ || >+ ++ +---+ |***| |
.. \ ||V -- || +---+ ||
. \ | NS or \\\ / ///
.. \ ++ --CNAME ---//-----
Douglis, et al. Expires May 9, 2002 [Page 15]
Internet-Draft CDI Known Mechanisms Nov 2001
.. \\ ||<-redirect /
. \ .|| / CDN G
Triangular Client DNS ++\ //
Redirection . \ \ / 5,6
. 5,6 1,4 /
. \ \ //
. \ \-- /
\ / \<
> |
| |
\ /
--- Client
+--------------------------------------------------+
| |
| +---+ |
| |***| Edge Server |
| +---+ |
| |
| ++ |
| || ++ ++ |
| || oo XX DNS Servers |
| ++ ++ ++ |
| |
| client CDN brokering |
+--------------------------------------------------+
Here, a client (1) contacts its local DNS server, which (2) contacts
the brokering DNS server. This server (3) returns either a CNAME or
NS record redirecting to another CDN, or an A record for a server
within CDN B. (The latter is called a "triangular resolution".)
Eventually, (4) an IP address is returned to the client, which (5)
requests and (6) receives the actual content.
4.2 Architecture
Douglis, et al. Expires May 9, 2002 [Page 16]
Internet-Draft CDI Known Mechanisms Nov 2001
The IDNS architecture looks like this:
DNS/control agent
interface interface
| |
.................... | ...........................................
. . | . | .
. . | . | ____________ .
. . | . | | config | .
. . | . | | | .
. . | . V /| agent | .
. . | . / |____________| .
. . | . / .
. ____________ . | . ____________ / ____________ .
. | DNS | . V . | Control | <--' | management | .
. | |<--------------| | <-------| | .
. | Engine | . . | Component | | agent | .
. |____________| . . |____________| <--- |____________| .
. . . \ .
. . . \ ____________ .
. . . \ | load | .
. . . \| | .
. . . | agent | .
. . . |____________| .
. . . .
.................... ...........................................
DNS Element Control Element
The "DNS Engine" is a customized DNS server, which is driven by
tables that are set through the DNS/control interface. The DNS
Engine maps the IP address of the requesting host, usually a local
DNS server acting on behalf of a client, and maps that address into a
"region". Using its tables, it selects the best CDN to which the
client should be directed. This selection is probabilistic; for
instance, a client in a particular region may be sent to one CDN with
probability X and a second CDN with probability (1-X). These
probabilities are updated by the "Control Element" based on its
initial configuration (which defines such things as regions), a run-
time GUI-based management agent for dynamic modification of these
policies, and load agents that accept information from the brokered
CDNs.
4.3 Request-Routing
Known mechanisms for CDN request-routing include DNS-level
redirection via "CNAME" or "NS" responses, as well as explicit "A"
responses with IP addresses (see section 2.3 of [2]). IDNS supports
Douglis, et al. Expires May 9, 2002 [Page 17]
Internet-Draft CDI Known Mechanisms Nov 2001
each of these responses, but primarily relies on the CNAME response
to redirect to a DNS server for another CDN.
Domain names are mapped by explicit agreement between the brokering
DNS system and any CDN providing content. For example, A.EXAMPLE.COM
might be mapped by the broker B into a DNS name in the namespace of
another CDN, G, as A.EXAMPLE.COM.B.G.COM. G would find anything in
the domain B.G.COM as a brokered domain. The "Host" header in the
HTTP request would tell G what original host was requested, and G
would statically map requests for A.EXAMPLE.COM to some origin server
such as ORIGIN-A.EXAMPLE.COM.
4.4 Distribution
IDNS relies on the content distribution functions of individual CDNs.
For static content such as images, content is not prepopulated into
CDNs. Content may be invalidated using any mechanism an individual
CDN provides for invalidation. On a cache miss, the CDN retrieves
content from the origin server (not from the brokering CDN).
4.5 Authentication, Authorization, and Accounting
IDNS relies on the AAA mechanisms of individual CDNs, and expects
cooperating CDNs to bill each other as though they were customers of
one another.
Douglis, et al. Expires May 9, 2002 [Page 18]
Internet-Draft CDI Known Mechanisms Nov 2001
5. Security Considerations
There are no security-related issues related to the systems described
in this document, beyond the detailed discussion of those issues in
"Content Internetworking Architectural Overview" [10].
Douglis, et al. Expires May 9, 2002 [Page 19]
Internet-Draft CDI Known Mechanisms Nov 2001
6. Conclusion
Content Internetworking is still in its earliest stages. These three
examples of known existing mechanisms that predate standardization
efforts within the IETF may help to guide those efforts through their
protocols, implementation experiences, and running code.
Douglis, et al. Expires May 9, 2002 [Page 20]
Internet-Draft CDI Known Mechanisms Nov 2001
References
[1] Amini, L., Thomas, S. and O. Spatscheck, "Distribution
Requirements for Content Internetworking", draft-amini-cdi-
distribution-reqs-01 (work in progress), July 2001,
<http://www.ietf.org/internet-drafts/draft-amini-cdi-
distribution-reqs-01.txt>.
[2] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, M.,
Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request-
Routing Mechanisms", draft-cain-cdnp-known-request-routing-
03.txt (work in progress), Nov 2001,
<http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-
request-routing-03.txt>.
[3] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal,
S., Spatscheck, O. and W. Sturm, "CDN Brokering", Workshop on
Web Caching and Content Distribution
http://www.cs.bu.edu/pub/wcw01, June 2001,
<http://www.cs.bu.edu/techreports/2001-017-wcw01-
proceedings/106_biliris.pdf>.
[4] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request-
Routing Requirements for Content Internetworking", draft-cain-
request-routing-req-02.txt (work in progress), July 2001,
<http://www.ietf.org/internet-drafts/draft-cain-request-
routing-req-02.txt>.
[5] "Content Bridge", September 2001, <http://www.content-
bridge.org/>.
[6] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[7] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
CDN Peering", draft-day-cdnp-model-08.txt (work in progress),
Oct 2001, <http://www.ietf.org/internet-drafts/draft-day-cdnp-
model-08.txt>.
[8] Day, M., Gilletti, D. and P. Rzewski, "Content Internetworking
Scenarios", draft-day-cdnp-scenarios-03.txt (work in progress),
March 2001, <http://www.ietf.org/internet-drafts/draft-day-
cdnp-scenarios-03.txt>.
[9] Chaudhri, I., "CiRouter Whitepaper", July 2001.
[10] Green, M., Cain, B., Tomlinson, G., Thomas, S., Rzewski, P. and
S. Thomas, "Content Internetworking Architectural Overview",
Douglis, et al. Expires May 9, 2002 [Page 21]
Internet-Draft CDI Known Mechanisms Nov 2001
draft-green-cdnp-gen-arch-03.txt (work in progress), March
2001, <http://www.ietf.org/internet-drafts/draft-green-cdnp-
gen-arch-03.txt>.
[11] Nair, R., Gilletti, D., Scharber, J. and J. Guha, "Content
Internetworking (CDI)Authentication,Authorization, and
Accounting Requirements", draft-gilletti-cdnp-aaa-reqs-01 (work
in progress), June 2001, <http://www.ietf.org/internet-
drafts/draft-gilletti-cdnp-aaa-reqs-01.txt>.
[12] <http://www.ietf.org/ipr.html>
Authors' Addresses
Fred Douglis
AT&T Labs
180 Park Ave, Bldg 103
Florham Park, NJ 07932
US
Phone: +1 973-360-8775
EMail: douglis@research.att.com
URI: http://www.research.att.com/~douglis/
Imran Chaudhri
PanteraTech, Inc.
2070 Chain Bridge Road, Suite 150
Vienna, VA 22182
US
Phone:
EMail: imran@chaudhri.net
Phil Rzewski
Inktomi
4100 East Third Avenue
MS FC2-4
Foster City, CA 94404
US
Phone: +1 650-653-2487
EMail: philr@inktomi.com
Douglis, et al. Expires May 9, 2002 [Page 22]
Internet-Draft CDI Known Mechanisms Nov 2001
Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of the following
persons for comments on this document and/or contributions to text
included herein: Alex Biliris, Chuck Cranor, Mark Day, Arthur Huston,
Ken Lee, Kent Lockhart, Michael Rabinovich, Sandeep Sibal, Oliver
Spatscheck, and Walter Sturm.
Douglis, et al. Expires May 9, 2002 [Page 23]
Internet-Draft CDI Known Mechanisms Nov 2001
Appendix B. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights, at [12].
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
Douglis, et al. Expires May 9, 2002 [Page 24]
Internet-Draft CDI Known Mechanisms Nov 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Douglis, et al. Expires May 9, 2002 [Page 25]