One document matched: draft-green-cdnp-gen-arch-02.txt
Differences from draft-green-cdnp-gen-arch-01.txt
Network Working Group M. Green
Internet-Draft Entera
Expires: May 18, 2001 B. Cain
Mirror Image Internet
G. Tomlinson
Entera
S. Thomas
TransNexus
November 17, 2000
CDN Peering Architectural Overview
draft-green-cdnp-gen-arch-02.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 18, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Discussion List & Archives
This document and related documents are discussed on the cdn mailing
list. To join the list, send mail to cdn-request@ops.ietf.org. To
contribute to the discussion, send mail to cdn@ops.ietf.org. The
archives are at ftp://ops.ietf.org/pub/lists/cdn.*.
Green, et. al. Expires May 18, 2001 [Page 1]
Internet-Draft CDNP Architecture November 2000
Abstract
We present the general architecture and core building blocks used in
the peering of content distribution networks (CDNs). The term
"peering" used within this memo is defined as externally interfacing
with a CDN. CDN peering encompasses both coupling CDNs with content
providers as well as coupling multiple CDNs in order to build
inter-networks of CDNs. The scope of this work is limited to
external interconnections with CDNs and does not address internal
mechanisms used within CDNs, which for the purpose of the document
are considered to be black boxes. This work establishes an abstract
architectural framework to be used in the development of protocols,
interfaces, and system models for standardized CDN peering.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. CDN Peering System Architecture . . . . . . . . . . . . . 7
2.1 Conceptual View of Peered CDNs . . . . . . . . . . . . . . 7
2.2 CDN Peering Architectural Elements . . . . . . . . . . . . 9
3. Request-Routing Peering System . . . . . . . . . . . . . . 13
3.1 Request-Routing Overview . . . . . . . . . . . . . . . . . 13
3.2 Request Routing . . . . . . . . . . . . . . . . . . . . . 15
3.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Modified DNS Request-Routing Model . . . . . . . . . . . 16
3.4.2 DNS Request-Routing Model using NS records . . . . . . . . 17
3.4.3 DNS Request-Routing Model using CNAME records . . . . . . 18
3.4.4 Hybrid DNS & Content Aware Request-Routing Models . . . . 18
3.4.4.1 Server-side Request-Routing Model . . . . . . . . . . . . 18
3.4.4.2 Client-side Request-Routing Model . . . . . . . . . . . . 19
3.5 Request-Routing Problems to Solve . . . . . . . . . . . . 19
4. Distribution Peering System . . . . . . . . . . . . . . . 21
4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 21
4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 23
4.3 Distribution Components . . . . . . . . . . . . . . . . . 24
4.4 Distribution Requirements . . . . . . . . . . . . . . . . 24
4.4.1 Replication Requirements . . . . . . . . . . . . . . . . . 24
4.4.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 25
4.4.3 Advertising Requirements . . . . . . . . . . . . . . . . . 25
4.5 Distribution Problems to Solve . . . . . . . . . . . . . . 26
4.5.1 General Problems . . . . . . . . . . . . . . . . . . . . . 26
4.5.2 Replication Problems . . . . . . . . . . . . . . . . . . . 26
4.5.3 Signaling Problems . . . . . . . . . . . . . . . . . . . . 27
4.5.4 Advertising Problems . . . . . . . . . . . . . . . . . . . 27
5. Accounting Peering System . . . . . . . . . . . . . . . . 28
5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 28
5.2 Accounting Models, Requirements and Problems to Solve . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . 31
Green, et. al. Expires May 18, 2001 [Page 2]
Internet-Draft CDNP Architecture November 2000
6.1 Threats to CDN Peering . . . . . . . . . . . . . . . . . . 31
6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 31
6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 31
6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 31
6.1.1.3 Delivery of Bad CONTENT . . . . . . . . . . . . . . . . . 32
6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 32
6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 32
6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 32
6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 32
6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 32
6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 32
6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 33
6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 33
6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 33
6.1.3 Threats to a CDN . . . . . . . . . . . . . . . . . . . . . 33
6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 33
6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 33
6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 35
References . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . 39
Green, et. al. Expires May 18, 2001 [Page 3]
Internet-Draft CDNP Architecture November 2000
1. Introduction
Terms in ALL CAPS, except those qualified with explicit citations
are defined in [13].
[Editor Note:
The term CONTENT has been deemed too vague for general use within
this document. The general observation revolves around its lack
of adequately addressing resource entities and entity variants.
Upon settling on disambiguated terminology for CONTENT, this
document will be edited with the new terminology.]
In a typical (non-peered) CDN [13], a single service provider
operates the REQUEST-ROUTING SYSTEM and the DISTRIBUTION SYSTEM. In
addition, that service provider has the commercial relationship with
the content source (operating the origin server). Typically, the
value that this CDN presents to a PUBLISHER is based on the scale
and reach of its combined systems.
There are practical limits to the scale and reach of any single
network. Increasing either scale or reach is ultimately limited by
the cost of equipment, the space available for deploying equipment,
and/or the demand for that scale/reach of infrastructure. Sometimes
a particular audience is tied to a single service provider or a
small set of providers by constraints of technology, economics, or
law.
CDN peering allows multiple CDN resources to be combined so as to
provide larger scale and/or reach to participants than any single
CDN could achieve by itself. Although this peering is similar in
concept to IP [2] peering between autonomous systems using BGP [5],
it differs fundamentally in that it involves the peering of
application gateways as opposed to packet routers.
This memo describes the overall architectural structure and the
fundamental building blocks used in the composition of CDN peering.
Consult [13] for a description of, and the vocabulary used in, this
application domain. A key requirement of the architecture itself is
that it be able to address each of the CDN peering scenarios
enumerated in [14]. The scope of this work is limited to external
interconnections between CDNs (i.e. INTER-CDN) and does not address
internal mechanisms used within CDNs (i.e. INTRA-CDN), which for the
purposes of the document are considered to be black boxes. INTER-CDN
peering as specified in this architecture includes both CDN to CDN
as well as content provider to CDN interactions. This work is
intended to establish an abstract architectural framework to be used
in the development of protocols, interfaces and system models for
standardized, interoperable peering among CDNs.
Green, et. al. Expires May 18, 2001 [Page 4]
Internet-Draft CDNP Architecture November 2000
We first present the architecture as an abstract system. Then we
develop a more concrete system architecture. For each architectural
element, we first present known requirements followed by problems
that need further investigation. The assumptions and scenarios
constraining the architecture is explained in [14]. We intend that
the architecture should support a wide variety of business models.
At the core of CDN peering are three principal architectural
elements that constitute the building blocks of the CDN peering
system. These elements are the REQUEST-ROUTING PEERING SYSTEM,
DISTRIBUTION PEERING SYSTEM, and ACCOUNTING PEERING SYSTEM.
Collectively, they control selection of the delivery CDN, content
distribution between peering CDNs, and usage accounting, including
billing settlement among the peering CDNs.
This work takes into consideration relevant IETF RFCs and IETF
works-in-progress. In particular, it is mindful of the end-to-end
nature [6][10] of the Internet, the current taxonomy of web
replication and caching [11], and the accounting, authorization and
authentication framework [12]
Green, et. al. Expires May 18, 2001 [Page 5]
Internet-Draft CDNP Architecture November 2000
2. CDN Peering System Architecture
2.1 Conceptual View of Peered CDNs
Before developing the system architecture, a conceptual view of
peered CDNs is presented to frame the problem space. CDNs are
comprised principally of four core system elements [13], the
REQUEST-ROUTING SYSTEM, the DISTRIBUTION SYSTEM, the ACCOUNTING
SYSTEM, and SURROGATES. In order for CDNs to peer with one another,
it is necessary to interconnect several of the core system elements
of individual CDNs. The interconnection of CDN core system elements
occurs through network elements called CDN Peering Gateways (CPG).
Namely, the CDN core system elements that need to be interconnected
are the REQUEST-ROUTING SYSTEM, the DISTRIBUTION SYSTEM, and the
ACCOUNTING SYSTEM.
Figure 1 contains a conceptual peered CDN diagram.
Green, et. al. Expires May 18, 2001 [Page 6]
Internet-Draft CDNP Architecture November 2000
+---------------+ +---------------+
| CDN A | | CDN B |
|...............| +---------+ +---------+ |.......... ....+
|REQUEST-ROUTING|<=>| |<=>| |<=>|REQUEST-ROUTING|
|...............| | CDN | | CDN | |...............|
| DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION |
|...............| | GATEWAY | | GATEWAY | |...............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
|---------------| +---------+ +---------+ +---------------+
| ^ \^ \^ \^ ^/ ^/ ^/ | ^
v | \\ \\ \\ // // // v |
+---------------+ \\ \\ \\ // // // +---------------+
| SURROGATEs | \\ v\ v\ /v /v // | SURROGATEs |
+---------------+ \\+---------+// +---------------+
^ | v| |v ^ |
| | | CDN | | |
| | | PEERING | | |
| | | GATEWAY | | |
| | | | | |
| | +---------+ | |
| | ^| ^| ^| | |
| | || || || | |
| | |v |v |v | |
| | +------------- -+ | |
| | | CDN C | | |
| | |...............| | |
| | |REQUEST-ROUTING| | |
| | |...............| | |
\ \ | DISTRIBUTION | / /
\ \ |...............| / /
\ \ | ACCOUNTING | / /
\ \ |---------------| / /
\ \ | ^ / /
\ \ v | / /
\ \ +---------------+ / /
\ \ | SURROGATEs | / /
\ \ +---------------+ / /
\ \ | ^ / /
\ \ | | / /
\ \ v | / /
\ \ +---------+ / /
\ \--->| CLIENTs |---/ /
\-----| |<---/
+---------+
Figure 1 Conceptual View of Peered CDNs
Green, et. al. Expires May 18, 2001 [Page 7]
Internet-Draft CDNP Architecture November 2000
This conceptual view illustrates the peering of three CDNs; CDN A,
CDN B, and CDN C. The CDNs are peered through interconnection at
CDN Peering Gateways. The result is presented as a virtual CDN to
CLIENTs for the DELIVERY of CONTENT by the aggregated set of
SURROGATES.
2.2 CDN Peering Architectural Elements
The system architecture revolves around the general premise that
individual CDNs are wholly contained within an administrative domain
[3] that is composed of either autonomous systems [1] (physical
networks) or overlay networks (virtual networks). For the purpose
of this memo, an overlay network is defined as a set of connected
CDN network elements layered onto existing underlying networks, and
present the result as a virtual application layer to both CLIENTs
and ORIGINs. The system architecture for CDN peering accommodates
this premise by assuring that the information and controls are
available for inter-CDN-domain administration . CDN peering
involves the interconnection of the individual CDN administrative
domains through gateway protocols and mechanisms loosely modeled
after BGP [5].
The system architecture depends on the following assumptions:
1. The URI [8] name space is the basis of PUBLISHER object
identifiers.
2. PUBLISHERs delegate authority of their object URI name space
being distributed by peering CDNs to the REQUEST-ROUTING
PEERING SYSTEM.
3. Peering CDNs use a common convention for encoding CDN
metadata into the URI name space.
Figure 2 contains a system architecture diagram of the core elements
involved in CDN peering.
Green, et. al. Expires May 18, 2001 [Page 8]
Internet-Draft CDNP Architecture November 2000
+---------------+ 1
/-------------|REQUEST-ROUTING|<----\
/ 4 | PEERING | 7 |
/ /------------->| SYSTEM* |<-\ |
/ / +---------------+ | |
/ / ^ | |
/ / |3 | |
/ / | | |
/ / +--------------+ | |
5| | | DISTRIBUTION | 2| |
V | __| PEERING |<-\ |
+--------+ 6 +-----------+ 3 / | SYSTEM* | |\ | +---------+
| |<---| |<-/ +--------------+ | \ \_| |
| CLIENT | | SURROGATE | | \__| ORIGIN |
| |--->| |-\ +--------------+ | /-->| |
+--------+ +-----------+ \ 7 | ACCOUNTING |--// 7 +---------+
\->| PEERING |--/
| SYSTEM* |--\ +---------+
+--------------+ \ 7 | BILLING |
\-->| ORG. |
| |
+---------+
Note: * represents core elements of CDN peering
Figure 2 System Architecture Elements of a CDN Peering System
The System Architecture is comprised of 7 major elements, 3 of which
constitute the CDN peering system itself. The peering elements are
REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM, and
ACCOUNTING PEERING SYSTEM. Correspondingly, the system architecture
is a system of systems:
1. The ORIGIN delegates its URI name space for objects to be
distributed and delivered by the peering CDNs to the
REQUEST-ROUTING PEERING SYSTEM.
2. The ORIGIN publishes CONTENT that is to distributed and
delivered by the peering CDNs into the DISTRIBUTION PEERING
SYSTEM.
Note:
CONTENT which is to be pre-populated (pushed) within the
peering CDNs is pro-actively published, while CONTENT
which is to be pulled on demand is published at the time
the object is being requested for DELIVERY.
Green, et. al. Expires May 18, 2001 [Page 9]
Internet-Draft CDNP Architecture November 2000
3. The DISTRIBUTION PEERING SYSTEM moves content between CDN
DISTRIBUTION SYSTEMs. Additionally this system interacts with
the REQUEST-ROUTING PEERING SYSTEM via feedback
ADVERTISEMENTs to assist in the peered CDN selection process
for CLIENT requests.
4. The CLIENT requests CONTENT from what it perceives to be the
ORIGIN, however due to URI name space delegation, the request
is actually made to the REQUEST-ROUTING PEERING SYSTEM.
5. The REQUEST-ROUTING PEERING SYSTEM routes the request to a
suitable SURROGATE in a peering CDN. REQUEST-ROUTING PEERING
SYSTEMs interact with one another via feedback ADVERTISEMENTs
in order to keep request-routing tables current.
6. The selected SURROGATE delivers the requested content to the
CLIENT. Additionally, the SURROGATE sends accounting
information for delivered content to the ACCOUNTING PEERING
SYSTEM.
7. The ACCOUNTING PEERING SYSTEM aggregates and distills the
accounting information into statistics and content detail
records for use by the ORIGIN and BILLING ORGANIZATION.
Statistics are also used as feedback to the REQUEST-ROUTING
PEERING SYSTEM.
8. The BILLING ORGANIZATION uses the content detail records to
settle with each of the parties involved in the content
distribution and delivery process.
This process has been described in its simplest form in order to
present the CDN peering architecture in the most abstract way
possible. In reality, this process is more complex when applied to
policies, business models and service level agreements that span
multiple peering CDNs. The orthogonal core peering systems are
discussed in greater depth in Section 3, Section 4 and Section 5
respectively.
Note:
Figure 2 simplifies the presentation of the core CDN peering
elements as single boxes, when in fact they represent a
collection of CPGs and interconnected individual CDN core system
elements. This has been done to introduce the system
architecture at its meta level.
The system architecture does not impose any administrative domain
[3] restrictions on the core peering elements (REQUEST-ROUTING
PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM and ACCOUNTING PEERING
SYSTEM). The only requirement is that they be authorized by the
Green, et. al. Expires May 18, 2001 [Page 10]
Internet-Draft CDNP Architecture November 2000
principal parties (ORIGIN and peering CDNs) to act in their behalf.
Thus, it is possible for each of the core elements to be provided by
a different organization.
It is important to note that the REQUEST-ROUTING PEERING SYSTEM is
the only mandatory element for CDN peering to function. A
DISTRIBUTION PEERING SYSTEM is needed when the PUBLISHER does not
have a NEGOTIATED RELATIONSHIP with every peering CDN.
Additionally, an ACCOUNTING PEERING SYSTEM is needed when
statistical and usage information is needed in order to satisfy
PUBLISHER and/or BILLING ORGANIZATION requirements.
Green, et. al. Expires May 18, 2001 [Page 11]
Internet-Draft CDNP Architecture November 2000
3. Request-Routing Peering System
The REQUEST-ROUTING PEERING SYSTEM represents the request-routing
function of the CDN peering system. It is responsible for routing
CLIENT requests to an appropriate peered CDN for the delivery of
content.
Note:
When the DISTRIBUTION PEERING SYSTEM and/or the ACCOUNTING
PEERING SYSTEM is present, it is highly desirable to utilize
content location information within the peered CDNs and/or system
load information in the selection of appropriate peered CDNs in
the routing of requests.
3.1 Request-Routing Overview
REQUEST-ROUTING SYSTEMs route CLIENT requests to a suitable
SURROGATE, which is able to service a client request. Many
request-routing systems route users to the surrogate that is
"closest" to the requesting user, or to the "least loaded"
surrogate. However, the only requirement of the request-routing
system is that it route users to a surrogate that can serve the
requested content.
REQUEST-ROUTING PEERING is the interconnection of two or more
REQUEST-ROUTING SYSTEMs so as to increase the number of REACHABLE
SURROGATEs for at least one of the interconnected systems.
In order for a PUBLISHER's CONTENT to be delivered by multiple
peering CDNs, it is necessary to federate each CDN REQUEST-ROUTING
SYSTEM under the URI name space of the PUBLISHER object. This
federation is accomplished by first delegating authority of the
PUBLISHER URI name space to an AUTHORITATIVE REQUEST-ROUTING SYSTEM.
The AUTHORITATIVE REQUEST-ROUTING SYSTEM subsequently splices each
peering CDN REQUEST-ROUTING SYSTEM into this URI name space and
transitively delegates URI name space authority to them for their
participation in request-routing. Figure 3 is a diagram of the
entities involved in the REQUEST-ROUTING PEERING SYSTEM.
Green, et. al. Expires May 18, 2001 [Page 12]
Internet-Draft CDNP Architecture November 2000
+---------------+
| CLIENT |
+---------------+
|
(Request-Routing Tree Root) +---------------+
| AUTHORITATIVE |
|REQUEST-ROUTING|
| SYSTEM |
+---------------+
| | INTER-CDN Request-Routing
/----------------/ \-----------------\
| |
(1st Level) +---------------+ +---------------+
.........|REQUEST-ROUTING|.......... .........|REQUEST-ROUTING|.........
. CDN A | CPG | . . CDN B | CPG | .
. +---------------+ . . +---------------+ .
. | . . | .
. +---------------+ . . +---------------+ .
. |REQUEST-ROUTING| . . |REQUEST-ROUTING| .
. | SYSTEM | . . | SYSTEM | .
. +---------------+ . . +---------------+ .
. | | . . | | .
. /---/ \-------\ . . /-----/ \----\ .
. | | . . | | .
. +---------------+ | . . | | .
. |REQUEST-ROUTING| +------------+ . . +-----------+ +------------+ .
..| CPG |.| SURROGATEs |.. ..| SURROGATE |....| SURROGATES |..
+---------------+ +------------+ +-----------+ +------------+
| INTER-CDN Recursive Request-Routing
\------\
|
(2nd Level) +---------------+
.........|REQUEST-ROUTING|..........
. CDN C | CPG | .
. +---------------+ .
, | .
. +---------------+ .
. |REQUEST-ROUTING| .
. | SYSTEM | .
. +---------------+ .
. | | .
. /----/ \-----\ .
. | | .
. +-----------+ +------------+ .
..| SURROGATE |....| SURROGATEs |...
+-----------+ +------------+
Figure 3 REQUEST-ROUTING PEERING SYSTEM Architecture
Green, et. al. Expires May 18, 2001 [Page 13]
Internet-Draft CDNP Architecture November 2000
The REQUEST-ROUTING PEERING SYSTEM is hierarchical in nature. There
exists exactly one request-routing tree for each PUBLISHER URI. The
AUTHORITATIVE REQUEST-ROUTING SYSTEM is the root of the
request-routing tree. There may be only one AUTHORITATIVE
REQUEST-ROUTING SYSTEM for a URI request-routing tree. Subordinate
to the AUTHORITATIVE REQUEST-ROUTING SYSTEM are the REQUEST-ROUTING
SYSTEMs of the first level peering CDNs. There may exist recursive
subordinate REQUEST-ROUTING SYSTEMs of additional level peering CDNs.
Note:
A PUBLISHER object may have more than one URI associated with it
and therefore be present in more than one request-routing tree.
3.2 Request Routing
The actual "routing" of a client request is through REQUEST-ROUTING
CPGs. The AUTHORITATIVE REQUEST-ROUTING CPG receives the CLIENT
request and forwards the REQUEST to an appropriate DISTRIBUTING CDN.
This process of INTER-CDN request-routing may occur multiple times
in a recursive manner between REQUEST-ROUTING CPGs until the
REQUEST-ROUTING SYSTEM arrives at an appropriate DISTRIBUTING CDN to
deliver the content.
Note:
The Client request may be for resolution of a URI component and
not the content of the URI itself. This is the case when DNS is
being utilized in the request-routing process to resolve the URI
server component.
Request-Routing systems explicitly peer but do not have "interior"
knowledge of surrogates from other CDNs. Each CDN operates its
internal request-routing system. In this manner, request-routing
systems peer very much like IP network layer peering.
3.3 Requirements
We assume that there is a peering relationship between
REQUEST-ROUTING CPGs. This peering relationship at a minimum must
exchange a set of CLIENT IP addresses that can be serviced, and a
set of information about the DISTRIBUTION SYSTEMs, for which they
are performing request-routing.
Request-Routing Requirements
1. Normalized canonical URI name space structure for peered CDN
distribution of PUBLISHER objects. The default in the absence
of encoded meta data is the standard components as defined by
[8]. Encoded meta data must conform to the conform to the
syntactical grammar defined in [7].
Green, et. al. Expires May 18, 2001 [Page 14]
Internet-Draft CDNP Architecture November 2000
2. Single AUTHORITATIVE REQUEST-ROUTING SYSTEM for PUBLISHER object
URI name space.
3. Use of a URI name space based request-routing mechanism. The
request-routing mechanism is allowed to use as much of the URI
name space as it needs to select the proper SURROGATE. For
example, DNS based mechanisms utilize only the host
subcomponent, while content aware mechanisms utilize use
multiple components.
4. Assure that the request-routing tree remains a tree -- i.e., has
no cycles.
5. Assure that adjacent request-routing systems from different
administrative domains (different CDNs) use a compatible
request-routing mechanism.
6. Assure that adjacent request-routing systems from different
administrative domains (different CDNs) agree to forward
requests for the CONTENT in question.
3.4 Example
In order to provide a greater understanding of the REQUEST-ROUTING
PEERING SYSTEM, the following four examples are described. While
these don't represent all implementations, they are considered to be
representative of the most common implementations deployed today.
It is important to remember the INTRA-CDN REQUEST-ROUTING SYSTEM is
opaque to the CDN peering architecture, since it is within the CDN
black box. The following examples contain known INTRA-CDN
implementations in order to present the reader with a complete
scenario of REQUEST-ROUTING PEERING.
3.4.1 Modified DNS Request-Routing Model
This example describes a DNS request-routing model that utilizes
protocol extensions for proxies between peered REQUEST-ROUTING CPGs.
Exclusively the AUTHORITATIVE REQUEST-ROUTING SYSTEM utilizes DNS
for INTER-CDN request-routing and exclusively by the CDN
REQUEST-ROUTING SYSTEM for INTRA-CDN request-routing.
We assume in this example that the CDN DIRECTION SYSTEM R2 has a
INTER-CDN peering relationship with the AUTHORITATIVE DIRECTION
SYSTEM R1 and has informed R1 via a peering protocol of its
willingness to service REQUESTS for a set of URIs'. We also assume
the URI being requested is contained within a name space
authoritatively serviced by R1. When the CLIENT contacts the
authoritative DNS server R1 to resolve the URI domain name, R1
Green, et. al. Expires May 18, 2001 [Page 15]
Internet-Draft CDNP Architecture November 2000
determines that the peering R2 needs to perform the INTRA-CDN
request-routing to one of its SURROGATES for service of the
forthcoming CLIENT request. Since, R2 cannot return the NS record,
R1 proxies R2 with an DNS protocol extension carrying both the
CLIENT address and the domain name of the URI.
At this point the request-routing process has been delegated to the
proper peering CDN for INTRA-CDN request-routing. R2 runs its
request-routing computation as though the CLIENT had directly
contacted it, and returns the result of the selected SURROGATE to
R1, which in turn passes it on to the CLIENT. At this point the
CLIENT has the correct SURROGATE to connect with for DELIVERY of the
CONTENT.
3.4.2 DNS Request-Routing Model using NS records
This example describes a pure DNS request-routing model. DNS is
utilized exclusively by the AUTHORITATIVE REQUEST-ROUTING SYSTEM for
INTER-CDN request-routing and exclusively by the CDN REQUEST-ROUTING
SYSTEM for INTRA-CDN request-routing.
We assume in this example that the CDN REQUEST-ROUTING SYSTEM R2 has
a INTER-CDN peering relationship with the AUTHORITATIVE
REQUEST-ROUTING SYSTEM R1. We also assume that the DNS name used by
the PUBLISHER contains at least as many name levels as the INTER-CDN
request-routing tree is deep. In our case, for example, using only
R1 and R2 the name could be foo2.foo1.com.
When the CLIENT requests CONTENT, the DNS resolution request will
contain the domain name foo2.foo1.com. To resolve this domain name
the client site DNS server will first contact the REQUEST-ROUTING
SYSTEM of R1 since it is authoritative for the domain foo1.com. The
REQUEST-ROUTING SYSTEM R1 has to decide now if it wants to serve the
content from one of its own SURROGATEs or if the content should be
served from the CDN with REQUEST-ROUTING SYSTEM R2. If R1 wants to
serve the content it returns an A record with the IP address of the
appropriate SURROGATE. If R1 decides R2 should serve the content, it
returns a NS record to the client site DNS server, denying a
recursive resolution and pointing the client site DNS server to the
REQUEST-ROUTING SYSTEM of R2. R2 can now decide which SURROGATE to
use and returns an appropriate A record. At this point, the CLIENT
has the correct SURROGATE to connect with for DELIVERY of the
CONTENT.
Green, et. al. Expires May 18, 2001 [Page 16]
Internet-Draft CDNP Architecture November 2000
3.4.3 DNS Request-Routing Model using CNAME records
This example describes a pure DNS request-routing model. DNS is
utilized exclusively by the AUTHORITATIVE REQUEST-ROUTING SYSTEM for
INTER-CDN request-routing and exclusively by the CDN REQUEST-ROUTING
SYSTEM for INTRA-CDN request-routing.
We assume in this example that the CDN REQUEST-ROUTING SYSTEM R2 has
a INTER-CDN peering relationship with the AUTHORITATIVE SYSTEM R1.
When the CLIENT requests CONTENT, the DNS resolution request will
first be made to REQUEST-ROUTING SYSTEM R1 since it is the
authoritative REQUEST-ROUTING SYSTEM. The REQUEST-ROUTING SYSTEM R1
has to decide now if it wants to serve the content from one of its
own SURROGATEs or if the content should be served from the CDN with
REQUEST-ROUTING SYSTEM R2. If R1 wants to serve the content it
returns an A record with the IP address of the appropriate
SURROGATE. If R1 decides R2 should serve the content it returns a
CNAME record to the CLIENT site DNS server denying a recursive
resolution. In this case the AUTHORITATIVE REQUEST-ROUTING SYSTEM
for the CNAME (not the original name requested by the CLIENT) has to
be R2. R2 can now decide which SURROGATE to use and returns an
appropriate A record. At this point, the CLIENT has the correct
SURROGATE to connect with for DELIVERY of the CONTENT.
This scheme allows for an easier introduction of additional
request-routing levels as the NS scheme described in Section 3.4.2.
3.4.4 Hybrid DNS & Content Aware Request-Routing Models
These examples describes hybrid DNS/Content-aware request-routing
models: server-side and client-side request-routing models.
3.4.4.1 Server-side Request-Routing Model
In the server-side request-routing model, DNS is used in the initial
SURROGATE selection process by the CDN REQUEST-ROUTING SYSTEM while
content-aware request-routing is employed to further forward the
CLIENT request to a better SURROGATE based upon the content
requested in the CLIENT request itself. Since there is more semantic
information contained within the CLIENT request than was present in
the DNS lookup, it is possible to more finely target the
request-routing to a suitable SURROGATE.
We assume the same R1 and R2 relationship that was present in the
previous modified DNS REQUEST-ROUTING MODEL. We also assume the same
process that caused R1 to determine R2 needs to perform the
INTRA-CDN request-routing. However, in this case, R2 does not
perform the request-routing computation, but rather selects a
Green, et. al. Expires May 18, 2001 [Page 17]
Internet-Draft CDNP Architecture November 2000
content-aware request-routing network element. R2 returns the result
of the content-aware request-routing network element to R1 which in
turn passes it on to the CLIENT.
3.4.4.2 Client-side Request-Routing Model
In the client-side request-routing model, a content-aware network
element is in the path between the client and the CDN
REQUEST-ROUTING SYSTEM and performs CDN selection based on the
content requested in the CLIENT request.
In this case, the client is within R1's administration and R2
exchanges peering information with R1 that includes URI level
information that enables R1 to proxy or forward content requests
towards R2.
In both cases, the CLIENT connects to the content-aware
request-routing network element and sends the CLIENT request. This
network element performs a content-aware request-routing computation
and may either send an application level redirects such as an HTTP
[9] or RTSP [7] 302 reply to the CLIENT; or proxy the CLIENT request
to a remote SURROGATE. At this point, the CLIENT has the correct
SURROGATE for the CONTENT.
While the examples above provide a summary of request-routing
systems, they are just that, a summary. Consult [16] for in-depth
information on these request-routing systems.
3.5 Request-Routing Problems to Solve
Specific problems in request-routing needing further investigation
include:
1. What is the aggregated granularity of CLIENT IP address being
serviced by a peering CDN's DISTRIBUTION SYSTEM?
2. How do DNS request-routing systems forward a request? If a
given CDN is peered with many other CDNs, what are the criteria
that forwards a request to another CDN?
3. How do content-aware request-routing systems forward a request?
If a given CDN is peered with many other CDNs, what are the
criteria that forwards a request to another CDN?
4. What are the merits of designing a generalized content routing
protocol, rather than relying on request-routing mechanisms.
5. What is the normalized canonical URI name space for
request-routing? Because request-routing is federated across
Green, et. al. Expires May 18, 2001 [Page 18]
Internet-Draft CDNP Architecture November 2000
multiple CDNs, it is necessary to have agreed upon standards for
the encoding of meta data in URIs. There are many potential
elements, which may be encoded. Some of these elements are:
authoritative agent domain, publisher domain, content type,
content length, etc.
6. How are policies communicated between the REQUEST-ROUTING SYSTEM
and the DISTRIBUTION ADVERTISEMENT SYSTEM? A given CDN may wish
to serve only a given content type or a particular set of users.
These types of policies must be communicated between CDNs.
7. What are the request-routing protocols in DNS? When a request is
routed to a particular REQUEST-ROUTING CPG, a clear set of DNS
rules and policies must be followed in order to have a workable
and predictable system.
8. How do we protect the REQUEST-ROUTING SYSTEM against denial of
service attacks?
9. How do we select the appropriate peering CDN for DELIVERY?
The selection process must to consider the distribution
policies involved in Section 4. Investigation into other
policy "work in progress" within the IETF is needed to
understand the relationship of policies developed within
CDN peering.
[Editor Note:
Detailed requirements concerning the information exchange between
REQUEST-ROUTING CPGs needs to be developed in order to begin work
on a REQUEST-ROUTING peering protocol.]
Green, et. al. Expires May 18, 2001 [Page 19]
Internet-Draft CDNP Architecture November 2000
4. Distribution Peering System
The DISTRIBUTION PEERING SYSTEM represents the content distribution
function of the CDN peering system. It is responsible for moving
content from one DISTRIBUTION CPG to another DISTRIBUTION CPG and
for supplying content location information to the REQUEST-ROUTING
PEERING SYSTEM.
4.1 Distribution Overview
One goal of the CDN peering system is to move content closer to the
CLIENT. Typically this is accomplished by copying content from its
ORIGIN to SURROGATEs. The SURROGATEs then have the CONTENT
available when it is requested by a CLIENT. Even with a single
PUBLISHER and single CDN, the copying of CONTENT to a SURROGATE may
traverse a number of links, some in the PUBLISHER's network, some in
the CDN's network, and some between those two networks. For
DISTRIBUTION PEERING, we consider only the communication "between"
two networks, and ignore the mechanisms for copying CONTENT within a
network.
In the above example the last server on the content provider's
network in the path, and the first server on the CDN's network in
the path, must contain DISTRIBUTION CPGs which communicate directly
with each other. The DISTRIBUTION CPGs could be located in the
ORIGIN server and the SURROGATE server. Thus in the simplest form
the ORIGIN server is in direct contact with the SURROGATE. However
the DISTRIBUTION CPG in the content provider's network could
aggregate content from multiple ORIGIN servers and the DISTRIBUTION
CPG in the CDN's network could represent multiple SURROGATEs. These
DISTRIBUTION CPGs could then be co-located in an exchange facility.
In fact, given the common practice of independently managed IP
peering co-location exchange facilities for layer 3, there exists
the distinct opportunity to create similar exchanges for CPGs.
Figure 4 is a diagram of the entities involved in the DISTRIBUTION
PEERING SYSTEM.
Green, et. al. Expires May 18, 2001 [Page 20]
Internet-Draft CDNP Architecture November 2000
+--------+
| ORIGIN |
+--------+
| | ORIGIN DISTRIBUTION PEERING
/------------------/ \----------------\
| |
+--------------+ +--------------+
.........| DISTRIBUTION |........... ...........| DISTRIBUTION |........
. CDN A | CPG | . . CDN B | CPG | .
. +--------------+ . . +--------------+ .
. | . . | .
. +--------------+ . . +--------------+ .
. | DISTRIBUTION | . . | DISTRIBUTION | .
. | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ .
. | | . . | | .
. /-----/ \-------\ . . /-----/ \----\ .
. | | . . | | .
. | +--------------+ . . +--------------+ | .
. +------------+ | DISTRIBUTION | . . | DISTRIBUTION | +------------+ .
..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |..
+------------+ +--------------+ +--------------+ +------------+
| | | |
| \-----------------/ |
\----------\ /-----------/
| | INTER-CDN DISTRIBUTION PEERING
| |
+--------------+
.........| DISTRIBUTION |...........
. CDN C | CPG | .
. +--------------+ .
. | .
. +--------------+ .
. | DISTRIBUTION | .
. | SYSTEM | .
. +--------------+ .
. | | .
. /-----/ \-------\ .
. | | .
. | | .
. +-----------+ +------------+ .
..| SURROGATE |.....| SURROGATEs |..
+-----------+ +------------+
Figure 4 DISTRIBUTION PEERING SYSTEM Architecture
Green, et. al. Expires May 18, 2001 [Page 21]
Internet-Draft CDNP Architecture November 2000
While CDN peering in general relates to interfacing with CDNs, there
are two CDN distribution peering relationships we expect to be
common; INTER-CDN distribution peering and ORIGIN distribution
peering. INTER-CDN distribution peering involves distributing
CONTENT between individual CDNs in a inter-network of peered CDNs.
ORIGIN distribution peering involves the publishing of CONTENT
directly into multiple CDNs by ORIGINs.
Note:
It is not necessary for an ORIGIN to peer directly with multiple
CDNs in order to participate in CDN peering. ORIGINs
participating in a single home CDN will be indirectly peered by
their home CDN with the inter-network of CDNs the home CDN is a
member of.
4.2 Distribution Models
Replication ADVERTISEMENTs may take place in a model similar to the
way IP routing table updates are done between BGP routers.
DISTRIBUTION CPGs could take care of exterior content replication
between content providers and CDNs, while at the same time
performing content replication interior to their networks in an
independent manner. If this model is used then the internal
structure of the networks is hidden and the only knowledge of other
networks is the locations of DISTRIBUTION CPGs.
Replication of content may take place using a push model, or a pull
model, or a combination of both. Use initiated replication, where
SURROGATEs, upon getting a cache miss, retrieve CONTENT from the
DISTRIBUTION SYSTEM, represents the pull model. ORIGIN initiated
replication of CONTENT to SURROGATEs represents the push model.
DISTRIBUTION CPGs may be located at various points in these models
depending on the topologies of the networks involved.
With CDN peering it may be desirable to replicate content through a
network, which has no internal SURROGATEs. For example add a
exchange network between the content provider network and the CDN
network to the example above. The exchange network could have a
DISTRIBUTION CPG co-located with the content provider's DISTRIBUTION
CPG, which acts as a proxy for the CDN. The exchange network could
also have a DISTRIBUTION CPG co-located with the CDN's DISTRIBUTION
CPG, which acts as a proxy for the content provider. In a
consolidated example, the exchange network could have a single
DISTRIBUTION CPG that acts as a proxy for both the content provider
and the CDN.
Replication of CONTINUOUS MEDIA that is not to be cached on
SURROGATEs takes place in a different model from content that is to
be persistently stored, such as live streaming broadcasts.
Green, et. al. Expires May 18, 2001 [Page 22]
Internet-Draft CDNP Architecture November 2000
Replication in this case, typically takes the form of splitting the
live streaming data at various points in the network. In CDN
peering, DISTRIBUTION CPGs may support CONTINUOUS MEDIA splitting
replication, as they likely provide ideal network topologic points
for application layer multicasting.
4.3 Distribution Components
The three main components of DISTRIBUTION PEERING are replication,
signaling and advertising.
The first component of content distribution is replication.
Replication involves moving the content from an ORIGIN server to
SURROGATE servers. The immediate goal in CDN peering is moving the
content between DISTRIBUTION CPGs.
The second component of content distribution is content signaling.
Content signaling is the propagation of content meta-data. This
meta-data may include such information such as the immediate
expiration of content or a change in the expiration time of CONTENT.
The immediate goal in signaling is exchanging signals between
DISTRIBUTION CPGs.
The third component of content distribution is content advertising.
Content providers must be able to advertise content that can be
distributed by CDNs and its associated terms. It is important that
the advertising of content must be able to aggregate content
information. The immediate goal in advertising is exchanging
advertisements between DISTRIBUTION CPGs.
4.4 Distribution Requirements
Replication systems must have a peering relationship. This peering
relationship must exchange sets of aggregated content and its
meta-data. Meta-data may change over time independently of the
content data and must be exchanged independently as well.
4.4.1 Replication Requirements
The specific requirements in content replication are:
1. A common protocol for the replication of content.
2. A common format for the actual content data in the protocol.
3. A common format for the content meta-data in the protocol.
4. Security mechanisms (see Section 6).
Green, et. al. Expires May 18, 2001 [Page 23]
Internet-Draft CDNP Architecture November 2000
5. Scalable distribution of the content.
4.4.2 Signaling Requirements
The specific requirements in content signaling are:
1. Signals for (at least) "flush" and "expiration time update".
2. Security mechanisms (see Section 6).
3. Scalable distribution of the signals on a large scale.
Editor Note:
We have to start being quantitative about what we mean by
"large scale". Are we thinking in terms of the number of
content items, the number of networks, or the number of
signals? For each of those, how big is "large scale"?
4. Content location and serviced CLIENT IP aggregate address
exchanges with REQUEST-ROUTING CPGs.
4.4.3 Advertising Requirements
The specific requirements in CONTENT ADVERTISEMENT are:
1. A common protocol for the ADVERTISEMENT of CONTENT.
2. A common format for the actual ADVERTISEMENTs in the protocol.
Editor Note:
The following requirements need further discussion. As it
stands now, there isn't sufficient information to
substantiate them.
3. A well-known state machine.
4. Use of TCP or SCTP (because soft-state protocols will not scale).
5. Well-known error codes to diagnose protocols between different
networks.
6. Capability negotiation.
7. Ability to represent policy.
Green, et. al. Expires May 18, 2001 [Page 24]
Internet-Draft CDNP Architecture November 2000
4.5 Distribution Problems to Solve
Some of the problems in distribution revolve around supporting both
a push model and a pull model for replication of content in that
they are not symmetric. The push model is used for pre-loading of
content and the pull model is used for on-demand fetching and
pre-fetching of content. These models are not symmetric in that the
amount of available resources in which to place the content on the
target server must be known. In the fetching cases the server that
pulls the content knows the available resources on the target
server, itself. In the pre-loading case the server that pushes the
content must find out the available resources from the target server
before pushing the data.
4.5.1 General Problems
General problems in distribution peering needing further
investigation include:
1. How would a single distribution peering protocol adequately
support replication, signaling and advertising?
2. Should a single distribution peering protocol be considered,
rather than separate protocols for each component?
3. How do we prevent looping of distribution updates? That is to
say, detect and stop propagating replication, signaling and
advertisement of events a DISTRIBUTION CPG has already issued.
Looping here has the possibility of becoming infinite, if not
bounded by the protocol(s). IP route updating and forwarding
has faced similar issues and has solved them.
4.5.2 Replication Problems
Specific problems in replication needing further investigation
include:
1. How do replication systems forward a request?
2. How do we keep pull based replication serviced within the
DISTRIBUTION CPGs in order to prevent it from inadvertently
bleeding out into REQUEST-ROUTING SYSTEM and potentially getting
into a recursive loop?
3. How are policies communicated between the replication systems?
4. What are the replication protocols?
5. Does replication only take place between CPGs?
Green, et. al. Expires May 18, 2001 [Page 25]
Internet-Draft CDNP Architecture November 2000
4.5.3 Signaling Problems
Specific problems in content signaling needing further investigation
include:
1. How do we represent a content signal?
2. What content meta-data needs to be signaled?
3. How do we represent aggregates of meta-data in a concise and
compressed manner?
4. What protocol(s) should be used for content signals?
5. What is a scalable architecture for delivering content signals?
6. Do content signals need a virtual distribution system of their
own?
4.5.4 Advertising Problems
Specific problems in CONTENT ADVERTISEMENT needing further
investigation include:
1. How do we represent aggregates of content to be distributed in a
concise and compressed manner?
2. What protocol(s) should be used for the aggregation of this data?
3. What are the issues involved in the creation of CPG exchanges?
This is actually a broader question than just for distribution,
but needs to be considered for all forms of CPGs
{REQUEST-ROUTING, DISTRIBUTION, ACCOUNTING}.
Green, et. al. Expires May 18, 2001 [Page 26]
Internet-Draft CDNP Architecture November 2000
5. Accounting Peering System
The ACCOUNTING PEERING SYSTEM represents the accounting data
collection function of the CDN peering system. It is responsible for
moving accounting data from one ACCOUNTING CPG to another ACCOUNTING
CPG.
5.1 Accounting Overview
CDN peering must provide the ability for the content provider to
collect data regarding the delivery of their CONTENT by the peered
CDNs. ACCOUNTING CPGs exchange the data collected by the interior
ACCOUNTING SYSTEMS. This interior data may be collected from the
SURROGATEs by ACCOUNTING CPGs using SNMP or FTP, for example.
ACCOUNTING CPGs may transfer the data to exterior neighboring
ACCOUNTING CPGs on request (push), in an asynchronous manner (push),
or a combination of both. Accounting data may also be aggregated
before it is transferred.
Figure 5 is a diagram of the entities involved in the ACCOUNTING
PEERING SYSTEM.
Green, et. al. Expires May 18, 2001 [Page 27]
Internet-Draft CDNP Architecture November 2000
+---------+
| BILLING | +--------+
| ORG. | | ORIGIN |
+---------+ +--------+
BILLING | | ACCOUNTING PEERING | | ORIGIN ACCOUNTING PEERING
/-----/ \-----------------------|-|----\
| /-----------------------------/ \----|-\
| | | |
+--------------+ +--------------+
.........| ACCOUNTING |........... ...........| ACCOUNTING |........
. CDN A | CPG | . . CDN B | CPG | .
. +--------------+ . . +--------------+ .
. | . . | .
. +--------------+ . . +--------------+ .
. | ACCOUNTING | . . | ACCOUNTING | .
. | SYSTEM | . . | SYSTEM | .
. +--------------+ . . +--------------+ .
. | | . . | | .
. /-----/ \-------\ . . /-----/ \----\ .
. | | . . | | .
. | +--------------+ . . +--------------+ | .
. +------------+ | ACCOUNTING | . . | ACCOUNTING | +------------+ .
..| SURROGATEs |.| CPG |... ..| CPG |.| SURROGATEs |..
+------------+ +--------------+ +--------------+ +------------+
| | | |
| \-----------------/ |
\----------\ /-----------/
| | INTER-CDN ACCOUNTING PEERING
| |
+--------------+
.........| ACCOUNTING |...........
. CDN C | CPG | .
. +--------------+ .
. | .
. +--------------+ .
. | ACCOUNTING | .
. | SYSTEM | .
. +--------------+ .
. | | .
. /-----/ \-------\ .
. | | .
. | | .
. +-----------+ +------------+ .
..| SURROGATE |.....| SURROGATEs |..
+-----------+ +------------+
Figure 5 ACCOUNTING Peering system Architecture
Green, et. al. Expires May 18, 2001 [Page 28]
Internet-Draft CDNP Architecture November 2000
There are three CDN accounting peering relationships we expect to be
common; INTER-CDN accounting peering, BILLING ORGANIZATION
accounting peering and ORIGIN accounting peering. INTER-CDN
accounting peering involves exchanging accounting information
between individual CDNs in a inter-network of peered CDNs. BILLING
ORGANIZATION peering involves exchanging to accounting information
between CDNs and a billing organization. ORIGIN accounting peering
involves the exchanging of accounting information between CDNs and
ORIGINs.
Note:
It is not necessary for an ORIGIN to peer directly with multiple
CDNs in order to participate in CDN peering. ORIGINs
participating in a single home CDN will be indirectly peered by
their home CDN with the inter-network of CDNs the home CDN is a
member of. Nor is it necessary to have a BILLING ORGANIZATION
peer, since this function may also be provided by the home CDN.
However, ORIGINs that directly peer for ACCOUNTING may have
access to greater accounting detail. Also, through the use of
ACCOUNTING peering, 3rd party billing can be provided.
5.2 Accounting Models, Requirements and Problems to Solve
Detailed information pertaining to CDN accounting peering models,
requirements, and problems to be solved is in "CDN Peering
Authentication, Authorization, and Accounting Requirements" [15].
Green, et. al. Expires May 18, 2001 [Page 29]
Internet-Draft CDNP Architecture November 2000
6. Security Considerations
Security concerns with respect to CDN Peering can be generally
categorized into trust within the system and protection of the
system from threats. The trust model utilized with CDN peering is
predicated largely on transitive trust between the ORIGIN,
REQUEST-ROUTING PEERING SYSTEM, DISTRIBUTION PEERING SYSTEM,
ACCOUNTING PEERING SYSTEM and SURROGATES. Network elements within
the CDN Peering system are considered to be "insiders" and therefore
trusted.
6.1 Threats to CDN Peering
The following sections document key threats to CLIENTs, PUBLISHERs,
and CDNs. The threats are classified according to the party that
they most directly harm, but, of course, a threat to any party is
ultimately a threat to all. (For example, having a credit card
number stolen may most directly affect a CLIENT; however, the
resulting dissatisfaction and publicity will almost certainly cause
some harm to the PUBLISHER and CDN, even if the harm is only to
those organizations' reputations.)
6.1.1 Threats to the CLIENT
6.1.1.1 Defeat of CLIENT's Security Settings
Because the SURROGATE's location may differ from that of the ORIGIN,
the use of a SURROGATE may inadvertently or maliciously defeat any
location-based security settings employed by the CLIENT. And since
the SURROGATE's location is generally transparent to the CLIENT, the
CLIENT may be unaware that its protections are no longer in force.
For example, a CDN may relocate CONTENT from a Internet Explorer
user's "Internet Web Content Zone" to that user's "Local Intranet
Web Content Zone." If the relocation is visible to the Internet
Explorer browser but otherwise invisible to the user, the browser
may be employing less stringent security protections than the user
is expecting for that CONTENT. (Note that this threat differs, at
least in degree, from the substitution of security parameters threat
below, as Web Content Zones can control whether or not, for example,
the browser executes unsigned active content.)
6.1.1.2 Delivery of Bad Accounting Information
In the case of CONTENT with value, CLIENTs may be inappropriately
charged for viewing content that they did not successfully access.
Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
CONTENT (e.g. programs that "pay" users to surf the Web). Should a
CDN fail to deliver appropriate accounting information, the CLIENT
may not receive appropriate credit for viewing the required CONTENT.
Green, et. al. Expires May 18, 2001 [Page 30]
Internet-Draft CDNP Architecture November 2000
6.1.1.3 Delivery of Bad CONTENT
A CDN that does not deliver the appropriate CONTENT may provide the
user misleading information (either maliciously or inadvertently).
This threat can be manifested as a failure of either the
DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate
SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to
inappropriate SURROGATEs, even though they may have appropriate
CONTENT), or both. A REQUEST-ROUTING SYSTEM may also fail by
forwarding the CLIENT request when no forwarding is appropriate, or
by failing to forward the CLIENT request when forwarding is
appropriate.
6.1.1.4 Denial of Service
A CDN that does not forward the CLIENT appropriately may deny the
CLIENT access to CONTENT.
6.1.1.5 Exposure of Private Information
CDNs may inadvertently or maliciously expose private information
(passwords, buying patterns, page views, credit card numbers) as it
transits from SURROGATEs to ORIGINs and/or PUBLISHERs.
6.1.1.6 Substitution of Security Parameters
If a SURROGATE does not duplicate completely the security facilities
of the ORIGIN (e.g. encryption algorithms, key lengths, certificate
authorities) CONTENT delivered through the SURROGATE may be less
secure than the CLIENT expects.
6.1.1.7 Substitution of Security Policies
If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CLIENT's private information may be
treated with less care than the CLIENT expects. For example, the
operator of a SURROGATE may not have as rigorous protection for the
CLIENT's password as does the operator of the ORIGIN server. This
threat may also manifest itself if the legal jurisdiction of the
SURROGATE differs from that of the ORIGIN, should, for example,
legal differences between the jurisdictions require or permit
different treatment of the CLIENT's private information.
6.1.2 Threats to the PUBLISHER
6.1.2.1 Delivery of Bad Accounting Information
If a CDN does not deliver accurate accounting information, the
PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or
Green, et. al. Expires May 18, 2001 [Page 31]
Internet-Draft CDNP Architecture November 2000
it may reward CLIENTs inappropriately. Inaccurate accounting
information may also cause a PUBLISHER to pay for services (e.g.
content distribution) that were not actually rendered.) Invalid
accounting information may also effect PUBLISHERs indirectly by, for
example, undercounting the number of site visitors (and, thus,
reducing the PUBLISHER's advertising revenue).
6.1.2.2 Denial of Service
A CDN that does not distribute CONTENT appropriately may deny
CLIENTs access to CONTENT.
6.1.2.3 Substitution of Security Parameters
If a SURROGATE does not duplicate completely the security services
of the ORIGIN (e.g. encryption algorithms, key lengths, certificate
authorities, client authentication) CONTENT stored on the SURROGATE
may be less secure than the PUBLISHER prefers.
6.1.2.4 Substitution of Security Policies
If a SURROGATE does not employ the same security policies and
procedures as the ORIGIN, the CONTENT may be treated with less care
than the PUBLISHER expects. This threat may also manifest itself if
the legal jurisdiction of the SURROGATE differs from that of the
ORIGIN, should, for example, legal differences between the
jurisdictions require or permit different treatment of the CONTENT.
6.1.3 Threats to a CDN
6.1.3.1 Bad Accounting Information
If a CDN is unable to collect or receive accurate accounting
information, it may be unable to collect compensation for its
services from PUBLISHERs.
6.1.3.2 Denial of Service
Misuse of a CDN may make that CDN's facilities unavailable, or
available only at reduced functionality, to legitimate customers or
the CDN provider itself. Denial of service attacks can be targeted
at a CDN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or
REQUEST-ROUTING SYSTEM.
Green, et. al. Expires May 18, 2001 [Page 32]
Internet-Draft CDNP Architecture November 2000
6.1.3.3 Transitive Threats
To the extent that a CDN acts as either a CLIENT or a PUBLISHER
(such as, for example, in transitive implementations) such a CDN may
be exposed to any or all of the threats described above for both
roles.
Green, et. al. Expires May 18, 2001 [Page 33]
Internet-Draft CDNP Architecture November 2000
7. Acknowledgements
The authors would like to acknowledge the contributions and comments
of Mark Day (Cisco), Fred Douglis (AT&T), Patrik Falstrom (Cisco),
Don Gilletti (Entera), Barron Housel (Cisco) John Martin (Network
Appliance), Raj Nair (Cisco), Hilarie Orman (Novell), Doug Potter
(Cisco), John Scharber (Entera), and Oliver Spatscheck (AT&T).
Green, et. al. Expires May 18, 2001 [Page 34]
Internet-Draft CDNP Architecture November 2000
References
[1] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", BCP
6, March 1996,
<URL:http://www.rfc-editor.org/rfc/bcp/bcp6.txt>.
[2] Postel, J., "Internet Protocol, DARPA Internet Program
Protocol Specification", RFC 791, September 1981,
<URL:http://www.rfc-editor.org/rfc/rfc791.txt>.
[3] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains A Model for Routing in the Internet", RFC 1136,
December 1989,
<URL:http://www.rfc-editor.org/rfc/rfc1136.txt>.
[4] Postel, J., "Domain Name Structure and Delegation", RFC 1591,
March 1994,
<URL:http://www.rfc-editor.org/rfc/rfc1591.txt>.
[5] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995,
<URL:http://www.rfc-editor.org/rfc/rfc1771.txt>.
[6] Carpenter, B., "Architecture Principles of the Internet", RFC
1958, June 1996,
<URL:http://www.rfc-editor.org/rfc/rfc1958.txt>.
[7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol", RFC 2326, April 1998,
<URL:http://www.rfc-editor.org/rfc/rfc2326.txt>.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998,
<URL:http://www.rfc-editor.org/rfc/rfc2396.txt>.
[9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999,
<URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.
[10] Carpenter, B., "Internet Transparency", RFC 2775, February
2000,
<URL:http://www.rfc-editor.org/rfc/rfc2775.txt>.
[11] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy",
draft-ietf-wrec-taxonomy-04.txt (work in progress), June 2000,
Green, et. al. Expires May 18, 2001 [Page 35]
Internet-Draft CDNP Architecture November 2000
<URL:http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxono
my-04.txt>.
[12] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence,
"AAA Authorization Framework",
draft-ietf-aaa-authz-arch-00.txt (work in progress), October
1999,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-aaa-authz-a
rch-00.txt>.
[13] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
draft-day-cdnp-model-03.txt (work in progress), November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-model-0
3.txt>.
[14] Day, M. and D. Gilletti, "Content Distribution Network Peering
Scenarios", draft-day-cdnp-scenarios-02.txt (work in
progress), November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-scenari
os-02.txt>.
[15] Gilletti, D., Nair, R. and J. Scharber, "CDN Peering
Authentication, Authorization, and Accounting Requirements",
draft-gilletti-cdnp-aaa-reqs-00.txt (work in progress),
November 2000,
<URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aa
a-reqs-00.txt>.
[16] Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R.,
Potter, D. and O. Spatscheck, "Known CDN Request-Routing
Mechanisms", draft-cain-cdnp-known-req-route-00.txt (work in
progress), November 2000.
Authors' Addresses
Mark Green
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA 94538
US
Phone: +1 510 770 5268
EMail: markg@entera.com
Green, et. al. Expires May 18, 2001 [Page 36]
Internet-Draft CDNP Architecture November 2000
Brad Cain
Mirror Image Internet
49 Dragon Court
Woburn, MA 01801
US
Phone: +1 781 276 1904
EMail: brad.cain@mirror-image.com
Gary Tomlinson
Entera, Inc.
40971 Encyclopedia Circle
Fremont, CA 94538
US
Phone: +1 510 580 3726
EMail: garyt@entera.com
Stephen Thomas
TransNexus, Inc.
430 Tenth Street NW Suite N204
Atlanta, GA 30318
US
Phone: +1 404 872 4887
EMail: stephen.thomas@transnexus.com
Green, et. al. Expires May 18, 2001 [Page 37]
Internet-Draft CDNP Architecture November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Green, et. al. Expires May 18, 2001 [Page 38]
| PAFTECH AB 2003-2026 | 2026-04-24 01:44:49 |