One document matched: draft-green-cdnp-gen-arch-01.txt
Differences from draft-green-cdnp-gen-arch-00.txt
Network Working Group M. Green
Internet-Draft Entera
Expires: April 20, 2001 B. Cain
Mirror Image Internet
G. Tomlinson
Entera
October 20, 2000
CDN Peering Architectural Overview
draft-green-cdnp-gen-arch-01.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 April 20, 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 April 20, 2001 [Page 1]
Internet-Draft CDNP Architecture October 2000
Abstract
This memo presents the general architecture and core building blocks
used in the peering of content distribution networks (CDNs). This
involves the interconnection of CDNs to create larger virtual CDNs
with greater reach, while still retaining the same simple interface
to both content providers and viewers. The scope of this work is
limited to external interconnections between 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 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, and peering of CDNs
with content providers. The term "peering" used within this memo is
defined as the coupling and interaction between CDNs in order to
build internetworks of CDNs.
Green, et. al. Expires April 20, 2001 [Page 2]
Internet-Draft CDNP Architecture October 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. CDN Peering System Architecture . . . . . . . . . . . . . 7
3. Request Direction Peering System . . . . . . . . . . . . . 10
3.1 Request Direction Overview . . . . . . . . . . . . . . . . 10
3.2 Request Routing . . . . . . . . . . . . . . . . . . . . . 12
3.3 Request Direction Problems to Solve . . . . . . . . . . . 12
3.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.1 Modified DNS Redirection Model . . . . . . . . . . . . . 14
3.5.2 DNS Redirection Model using NS records . . . . . . . . . . 14
3.5.3 DNS Redirection Model using CNAME records . . . . . . . . 15
3.5.4 Hybrid DNS & Content Aware Redirection Models . . . . . . 16
3.5.4.1 Server-side direction model . . . . . . . . . . . . . . . 16
3.5.4.2 Client-side direction model . . . . . . . . . . . . . . . 16
4. Distribution Peering System . . . . . . . . . . . . . . . 17
4.1 Distribution Overview . . . . . . . . . . . . . . . . . . 17
4.2 Distribution Models . . . . . . . . . . . . . . . . . . . 18
4.3 Distribution Components . . . . . . . . . . . . . . . . . 19
4.4 Distribution Problems to Solve . . . . . . . . . . . . . . 20
4.4.1 Replication Problems . . . . . . . . . . . . . . . . . . . 20
4.4.2 Signaling Problems . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Advertising Problems . . . . . . . . . . . . . . . . . . . 20
4.5 Distribution Requirements . . . . . . . . . . . . . . . . 21
4.5.1 Replication Requirements . . . . . . . . . . . . . . . . . 21
4.5.2 Signaling Requirements . . . . . . . . . . . . . . . . . . 21
4.5.3 Advertising Requirements . . . . . . . . . . . . . . . . . 22
5. Accounting Peering System . . . . . . . . . . . . . . . . 23
5.1 Accounting Overview . . . . . . . . . . . . . . . . . . . 23
5.2 Accounting Data Types . . . . . . . . . . . . . . . . . . 24
5.3 Accounting Models . . . . . . . . . . . . . . . . . . . . 25
5.4 Accounting Problems to Solve . . . . . . . . . . . . . . . 25
5.5 Accounting Requirements . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . 27
6.1 Threats to CDN Peering . . . . . . . . . . . . . . . . . . 27
6.1.1 Threats to the CLIENT . . . . . . . . . . . . . . . . . . 27
6.1.1.1 Defeat of CLIENT's Security Settings . . . . . . . . . . . 27
6.1.1.2 Delivery of Bad Accounting Information . . . . . . . . . . 27
6.1.1.3 Delivery of Bad CONTENT . . . . . . . . . . . . . . . . . 28
6.1.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . 28
6.1.1.5 Exposure of Private Information . . . . . . . . . . . . . 28
6.1.1.6 Substitution of Security Parameters . . . . . . . . . . . 28
6.1.1.7 Substitution of Security Policies . . . . . . . . . . . . 28
6.1.2 Threats to the PUBLISHER . . . . . . . . . . . . . . . . . 28
6.1.2.1 Delivery of Bad Accounting Information . . . . . . . . . . 28
6.1.2.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 29
6.1.2.3 Substitution of Security Parameters . . . . . . . . . . . 29
6.1.2.4 Substitution of Security Policies . . . . . . . . . . . . 29
Green, et. al. Expires April 20, 2001 [Page 3]
Internet-Draft CDNP Architecture October 2000
6.1.3 Threats to a CDN . . . . . . . . . . . . . . . . . . . . . 29
6.1.3.1 Bad Accounting Information . . . . . . . . . . . . . . . . 29
6.1.3.2 Denial of Service . . . . . . . . . . . . . . . . . . . . 29
6.1.3.3 Transitive Threats . . . . . . . . . . . . . . . . . . . . 29
7. Impact on the Internet Architecture . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31
References . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . 35
Green, et. al. Expires April 20, 2001 [Page 4]
Internet-Draft CDNP Architecture October 2000
1. Introduction
In a typical (non-peered) CDN [12], a single service provider
operates the DIRECTION 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 different CDNs to share resources so as to
provide larger scale and/or reach to participants than they could
otherwise achieve. Although this peering is similar in concept to
layer 3 peering between autonomous systems [1], it differs rather
fundamentally in that it involves the peering of content delivery
according to semantically rich application policies.
The context of "peering" used within this application domain
pertains to the interconnection of CDNs in order to build
internetworks of CDNs, which is quite different than the traditional
dictionary definition of a peer "one that is of equal standing with
another" [16]. Although this definition is conceptually derived from
its use in the interconnection of autonomous systems, it differs
significantly in that it doesn't presume a settlement-free basis
[17] business model. Through the use of CDN peering, complex
distribution topologies can be composed, including both hierarchical
and mesh.
This memo describes the overall architectural structure and the
fundamental building blocks used in the composition of CDN peering.
Consult [12] for a description of, and the vocabulary used in, this
application domain. A key requirement of the architecture itself, is
the it be able to address each of the CDN peering scenarios
enumerated in [13]. 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 April 20, 2001 [Page 5]
Internet-Draft CDNP Architecture October 2000
The architecture is presented first from an abstract system model in
order to establish a framework comprised of the most fundamental
elements. Using these architectural elements as building blocks, it
subsequently transitions into a system architecture constrained by
fundamental assumptions and scenario requirements. Through the use
of a broad set of usage scenarios as requirements, a cognizant
effort has been made to ensure the system architecture doesn't
unduly constrain business models and their associated value chains.
At the core of CDN peering are three principle architectural
elements that constitute the building blocks of the CDN peering
system. These elements are DIRECTION 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 [5][9] of the Internet, the current taxonomy of web
replication and caching [10], and the accounting, authorization and
authentication framework [11]
Terms in ALL CAPS are defined in [12].
Green, et. al. Expires April 20, 2001 [Page 6]
Internet-Draft CDNP Architecture October 2000
2. CDN Peering System Architecture
The system architecture revolves around the general premise that
individual CDNs are wholly contained within an administrative domain
[2] that is composed of either autonomous systems [1] or overlay
networks. The system architecture for CDN peering accommodates this
premise by assuring that the information and controls are available
for inter-domain administration. With this in mind, CDN peering
involves the interconnection of these administrative domains through
layer 5 exterior gateway protocols and machinery. The notion of
exterior gateway protocols and machinery has precedence in the IETF
in the form of the Border Gateway Protocol (BGP) [4], which serves
as a reference that this architecture is loosely modeled upon.
The system architecture is predicated upon the following fundamental
assumptions:
1. The URI [7] 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 DIRECTION PEERING
system.
3. There is a normalized canonical name space extension for CDN
meta data encapsulated within URIs being distributed by
peering CDNs.
Figure 1 contains a system architecture diagram of the core elements
involved in CDN peering.
Green, et. al. Expires April 20, 2001 [Page 7]
Internet-Draft CDNP Architecture October 2000
+--------------+
/--------------| DIRECTION |<----\
/ | PEERING | |
/ /-------------->| SYSTEM* |<-\ |
/ / +--------------+ | |
/ / ^ | |
/ / | | |
/ / | | |
/ / +--------------+ | |
| | | DISTRIBUTION | | |
V | __| PEERING |<-\ |
+--------+ +-----------+ / | SYSTEM* | |\ | +---------+
| |<---| |<-/ +--------------+ | \ \_| |
| CLIENT | | SURROGATE | | \__| ORIGIN |
| |--->| |-\ +--------------+ | /-->| |
+--------+ +-----------+ \ | ACCOUNTING |--// +---------+
\->| PEERING |--/
| SYSTEM* |--\ +---------+
+--------------+ \ | BILLING |
\-->| ORG. |
| |
+---------+
Note: * represents core elements of CDN peering
Figure 1 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
DIRECTION PEERING system, DISTRIBUTION PEERING system, and
ACCOUNTING PEERING system. Correspondingly, the system architecture
is a system of systems:
1. The ORIGIN publishes content into the DISTRIBUTION SYSTEM.
This process includes both the delegation of URI name space
to the DIRECTION PEERING system and delegation of delivery to
the DISTRIBUTION PEERING system.
2. The DISTRIBUTION PEERING system moves content between CDN
DISTRIBUTION SYSTEMs. Additionally this system interacts with
the DIRECTION PEERING system via feedback ADVERTISEMENTs to
assist in the peered CDN selection process for CLIENT
requests.
3. The CLIENT requests content from a SURROGATE.
Green, et. al. Expires April 20, 2001 [Page 8]
Internet-Draft CDNP Architecture October 2000
4. The DIRECTION PEERING system directs a REQUEST from a CLIENT
to a suitable SURROGATE in a peering CDN. DIRECTION PEERING
systems interact with one another via feedback ADVERTISEMENTs
in order to keep request routing tables current.
5. The selected SURROGATE delivers the requested content to the
CLIENT. Additionally, the SURROGATE sends accounting
information for delivered content to the ACCOUNTING PEERING
system.
6. 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 DIRECTION PEERING
system.
7. 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.
It is important to note that the DIRECTION 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.
Additionally, it is important to note that the core elements can be
provided by independent administrative domains [2] so long as they
have authorized peering relationships (i.e. affiliations) between
themselves.
Green, et. al. Expires April 20, 2001 [Page 9]
Internet-Draft CDNP Architecture October 2000
3. Request Direction Peering System
The DIRECTION PEERING system represents the request routing function
of the CDN peering system. It is responsible for binding CLIENTs to
peered CDNs for the delivery of content. It has a dependency upon
the DISTRIBUTION PEERING system for content location information
within the peered CDNs.
3.1 Request Direction Overview
DIRECTION systems direct CLIENT REQUESTs to a suitable SURROGATE,
which is able to service a client request. Many request direction
systems direct users to a surrogate that is "closest" to the user on
the "least loaded" surrogate. The only requirement of the request
direction system is that it directs users to a surrogate that can
serve the requested content. Request direction is commonly
performed via redirection mechanisms. Such redirection is
accomplished through a variety of connection hand-off mechanisms
including but not limited to DNS [3], HTTP [8], RTSP [6], etc
redirection.
DIRECTION PEERING is the interconnection of two or more DIRECTION
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 DIRECTION system
under the DNS name space of the PUBLISHER object. This federation
is accomplished by first delegating the PUBLISHER DNS name space to
an AUTHORITATIVE DIRECTION SYSTEM. The AUTHORITATIVE DIRECTION
SYSTEM subsequently splices each peering CDN DIRECTION SYSTEM into
this DNS name space. Figure 2 contains a architecture diagram of the
entities involved in the DIRECTION PEERING system.
Green, et. al. Expires April 20, 2001 [Page 10]
Internet-Draft CDNP Architecture October 2000
+---------------+
| CLIENT |
+---------------+
|
|
(Direction Tree Root) +---------------+
| AUTHORITATIVE |
| DIRECTION |
| SYSTEM |
+---------------+
| | INTER-CDN Direction
/----------------/ \-----------------\
| |
(1st Level) +--------------+ +--------------+
.........| DIRECTION |.......... .........| ********* |..........
. | CPG | . . | **** | .
. +--------------+ . . +--------------+ .
. INTRA-CDN | | | Direction . . | | .
. /----/ | \-----\ . . /------/ \-----\ .
. | | | . . | | .
. +-----------+ | +------------+ . . +------------+ +-----------+ .
..| SURROGATE |.|..| SURROGATEs |.. ..| ********** |....| ********* |..
+-----------+ | +------------+ +------------+ +-----------+
|
| INTER-CDN Recursive Direction
(2nd Level) +--------------+
.........| DIRECTION |..........
. | CPG | .
. +--------------+ .
. INTRA-CDN | | Direction .
. /----/ \-----\ .
. | | .
. +-----------+ +------------+ .
..| SURROGATE |....| SURROGATEs |..
+-----------+ +------------+
Figure 2 DIRECTION PEERING System Architecture
The DIRECTION PEERING system is hierarchical in nature. There exists
exactly one direction tree for each PUBLISHER URI. The
AUTHORITATIVE DIRECTION SYSTEM is the root of the direction tree.
There may be only one AUTHORITATIVE DIRECTION SYSTEM for a URI
direction tree. Subordinate to the AUTHORITATIVE DIRECTION SYSTEM
are the DIRECTION SYSTEMs of the first level peering CDNs. There may
exist recursive subordinate DIRECTION SYSTEMs of additional level
peering CDNs.
Green, et. al. Expires April 20, 2001 [Page 11]
Internet-Draft CDNP Architecture October 2000
Note: A PUBLISHER object may have more than one URI associated
with it and therefore be present in more than one direction
tree.
3.2 Request Routing
The actual "routing" of a client request is through DIRECTION
Content Peering Gateways (CPG). The AUTHORITATIVE DIRECTION CPG
receives the initial client request and redirects the request to an
appropriate DISTRIBUTING CDN. This process of INTER-CDN request
direction may occur multiple times in a recursive manner between
DIRECTION CPGs until the DIRECTION SYSTEM arrives at an appropriate
DISTRIBUTING CDN to deliver the content.
Direction systems explicitly peer but do not have "interior"
knowledge of surrogates from other CDNs. Each CDN operates its
internal request direction system. In this manner, request
direction systems peer very much like IP network layer peering.
3.3 Request Direction Problems to Solve
Specific problems in request direction needing further investigation
include:
1. How do DNS request direction systems redirect a request? If a
given CDN is peered with many other CDNs, what are the criteria
which redirects a request to another CDN?
2. How do Content-Aware direction systems redirect a request? If a
given CDN is peered with many other CDNs, what are the criteria
which redirects a request to another CDN?
3. What are the merits of designing a generalized content routing
protocol, rather than relying on redirection mechanisms.
4. What is the normalized canonical URI name space for request
direction? Because request direction is federated across
multiple CDNs, it is necessary to have agreed upon standards for
the encoding of 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.
5. How are policies communicated between the DIRECTION 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.
Green, et. al. Expires April 20, 2001 [Page 12]
Internet-Draft CDNP Architecture October 2000
6. What are the request direction protocols in DNS? When a request
is routed to a particular DIRECTION CPG, a clear set of DNS
rules and policies must be followed in order to have a workable
and predictable system.
7. How do we protect the DIRECTION SYSTEM against denial of service
attacks?
3.4 Requirements
DIRECTION SYSTEMs require some coupling to DISTRIBUTION SYSTEMs.
For example, a CDN may have a DIRECTION SYSTEM that makes use of its
own DISTRIBUTION SYSTEM. The DIRECTION SYSTEMs may also communicate
some information about the DISTRIBUTION SYSTEMs for which they are
performing redirection.
We assume that there is a peering relationship between DIRECTION
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
redirection.
Request Direction Requirements
1. Normalized canonical URI name space structure for peered CDN
distribution of PUBLISHER objects.
2. Single AUTHORITATIVE DIRECTION SYSTEM for PUBLISHER object URI
name space.
3. Use of a URI name space based direction mechanism. The
direction 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 the request direction tree does not become a cyclic
routing graph.
5. Assure that adjacent direction systems from different
administrative domains (different CDNs) use a compatible request
direction mechanism.
6. Assure that adjacent direction systems from different
administrative domains (different CDNs) agree to direct requests
for the CONTENT in question.
Green, et. al. Expires April 20, 2001 [Page 13]
Internet-Draft CDNP Architecture October 2000
3.5 Example
In order to provide a greater understanding of the DIRECTION 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 DIRECTION 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 DIRECTION
PEERING.
3.5.1 Modified DNS Redirection Model
This example describes a DNS redirection model that utilizes
protocol extensions for proxies between peered DIRECTION CPGs. DNS
is utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for
INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM
for INTRA-CDN redirection.
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, similar to BGP
but modified for content routing information, and that some set of
addresses including the address of the CLIENT, is in the
"redirection set" of R2. 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 determines that the peering R2 needs to perform
the INTRA-CDN redirection 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 redirection process has been delegated to the
proper peering CDN for INTRA-CDN redirection. 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.5.2 DNS Redirection Model using NS records
This example describes a pure DNS redirection model. DNS is
utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for
INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM
for INTRA-CDN redirection.
Green, et. al. Expires April 20, 2001 [Page 14]
Internet-Draft CDNP Architecture October 2000
We assume in this example that the CDN DIRECTION SYSTEM R2 has a
INTER-CDN peering relationship with the AUTHORITATIVE DIRECTION
SYSTEM R1. We also assume that the DNS name used by the PUBLISHER
contains at least as many name levels as the INTER-CDN redirection
tree is deep. In our case, for example, using only R1 and R2 the
name could be foo2.foo1.com.
When the CLIENT request's a URI, 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 DIRECTION SYSTEM
of R1 since it is authoritative for the domain foo1.com. The
DIRECTION 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 DIRECTION 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
DIRECTION 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.
3.5.3 DNS Redirection Model using CNAME records
This example describes a pure DNS redirection model. DNS is
utilized exclusively by the AUTHORITATIVE DIRECTION SYSTEM for
INTER-CDN redirection and exclusively by the CDN DIRECTION SYSTEM
for INTRA-CDN redirection.
We assume in this example that the CDN DIRECTION SYSTEM R2 has a
INTER-CDN peering relationship with the AUTHORITATIVE SYSTEM R1.
When the CLIENT request's a URI, the DNS resolution request will
first be made to DIRECTION SYSTEM R1 since it is the authoritative
DIRECTION SYSTEM. The DIRECTION 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 DIRECTION 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
DIRECTION 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
redirection levels as the NS scheme described in Section 3.5.2.
Green, et. al. Expires April 20, 2001 [Page 15]
Internet-Draft CDNP Architecture October 2000
3.5.4 Hybrid DNS & Content Aware Redirection Models
These examples describes hybrid DNS/Content-Aware direction models:
server-side and client-side direction models.
3.5.4.1 Server-side direction model
In the server-side direction model, DNS is used in the initial
SURROGATE selection process by the CDN DIRECTION SYSTEM while
Content-Aware redirection is employed to further direct 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 direction to a
suitable SURROGATE.
We assume the same R1 and R2 relationship that was present in the
previous modified DNS DIRECTION MODEL. We also assume the same
process that caused R1 to determine R2 needs to perform the
INTRA-CDN direction. However, in this case, R2 does not perform the
request routing computation, but rather selects a virtual SURROGATE
that is in fact a Content-Aware redirection network element. R2
returns the result of the virtual SURROGATE to R1 which in turns
passes it on to the CLIENT.
3.5.4.2 Client-side direction model
In the client-side direction model, a content-aware network element
is in the path between the client and the CDN DIRECTION 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 redirect content requests
towards R2.
In both cases, the CLIENT connects to the virtual SURROGATE and
sends the CLIENT REQUEST. The virtual SURROGATE performs a
Content-Aware request routing computation and may either send an
application level redirects such as an HTTP [8] or RTSP [6] 302
reply to the CLIENT; or proxy the CLIENT REQUEST to a remote
DELIVERY NODE. At this point, the CLIENT has the correct DELIVERY
NODE for the CONTENT.
While the examples above provide a summary of conformant request
direction systems, they are just that, a summary. Consult [15] for
in-depth information on these request direction systems.
Green, et. al. Expires April 20, 2001 [Page 16]
Internet-Draft CDNP Architecture October 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 DIRECTION 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 replicating content from
ORIGIN servers to SURROGATEs which are then used to deliver the
content directly to the CLIENT. For example this content replication
path may traverse links internal to a content provider's network,
then external links to reach the CDN and then links internal to the
CDN's network to finally arrive at the surrogate. For the purposes
of the CDN peering system we consider only the path between the two
networks.
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.
Figure 3 contains a architecture diagram of the entities involved in
the DISTRIBUTION PEERING system.
Green, et. al. Expires April 20, 2001 [Page 17]
Internet-Draft CDNP Architecture October 2000
.................................. ..................
. Peering CDN . . Peering CDN .
+-------+ . +----------+ +------------+ . . +------------+ . +------+
|CLIENT |---|SURROGATE |----|DISTRIBUTION|------|DISTRIBUTION|---|ORIGIN|
+-------+ . +----------+ /--| CPG | . /--| CPG | . +------+
. | +------------+ . |. +------------+ .
+-------+ . +----------+ | . |..................
|CLIENTs|---|SURROGATEs|-/ . |
+-------+ . +----------+ . |
. . |
.................................. |
|
.................................. |
. Peering CDN . |
+-------+ . +----------+ +------------+ . |
|CLIENT |---|SURROGATE |----|DISTRIBUTION|---/
+-------+ . +----------+ /--| CPG | .
. | +------------+ .
+-------+ . +----------+ | .
|CLIENTs|---|SURROGATEs|-/ .
+-------+ . +----------+ .
. .
..................................
Figure 3 DISTRIBUTION PEERING system Architecture
4.2 Distribution Models
Replication advertisement may take place in a layer 5 model similar
to the way BGP is used today at layer 3. 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. Hierarchical caching, where
SURROGATEs, upon getting a cache miss, retrieve CONTENT from a cache
higher up the chain, represents the pull model. Replication of
CONTENT from ORIGIN servers to replica origin servers represents the
push model. Replication of CONTENT from ORIGIN servers to
SURROGATEs, in order to pre-populate the caches, also represents the
push model. A combination of the two models would be a cache
hierarchy that has a replica origin server as its root. DISTRIBUTION
CPGs may be located at various points in these models depending on
the topologies of the networks involved.
Green, et. al. Expires April 20, 2001 [Page 18]
Internet-Draft CDNP Architecture October 2000
With CDN peering it may be necessary to replicate content through a
network, which has no internal SURROGATEs. On one hand it may be
possible to do this transparently with no DISTRIBUTION CPGs on the
transit network. On the other hand it may be desirable for the
transit network to have DISTRIBUTION CPGs. For example add a transit
network between the content provider network and the CDN network to
the example above. The transit network could have a DISTRIBUTION CPG
co-located with the content provider's DISTRIBUTION CPG which acts
as a proxy for the CDN. The transit 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 simpler example the
transit network could have a single DISTRIBUTION CPG which acts as a
proxy for both the content provider and the CDN.
Replication of CONTINUOUS MEDIA takes place in a different model
from content which has a fixed length CONTENT DATA UNIT, especially
in the case of live streaming data. Replication in this case
typically takes the form of splitting the live streaming data at
various points in the network. In the CDN peering system
DISTRIBUTION CPGs could perform this function. In this sense the
collection of DISTRIBUTION CPGs would constitute an application
layer multicast overlay network.
4.3 Distribution Components
The three main components of distribution are replication, signaling
and advertising. Each of these is utilized between DISTRIBUTION CPGs
belonging to content providers and CDNs. They may also be used
between CDNs.
The final goal of replication involves moving the content from an
ORIGIN server to SURROGATE delivery 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 a given
CONTENT DATA UNIT.
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.
Green, et. al. Expires April 20, 2001 [Page 19]
Internet-Draft CDNP Architecture October 2000
4.4 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.4.1 Replication Problems
Specific problems in replication needing further investigation
include:
1. How do replication systems direct a request?
2. How are policies communicated between the replication systems?
3. What are the replication protocols?
4. Does replication only take place between CPGs?
4.4.2 Signaling Problems
Specific problems in content signaling needing further investigation
include:
1. How do we represent a content signal?
2. What protocols should be used for content signals?
3. What is a scalable manner for delivering content signals?
4. Do content signals need a virtual distribution system of their
own?
4.4.3 Advertising Problems
Specific problems in content advertisement needing further
investigation include:
1. How do we represent a collection of meta-data in a concise and
compressed manner?
Green, et. al. Expires April 20, 2001 [Page 20]
Internet-Draft CDNP Architecture October 2000
2. How do we represent aggregates of meta-data?
3. What protocols to use for the aggregation of this data?
4. How distributed of an approach should be used for this problem?
5. How do we prevent looping?
4.5 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.
Replication systems may require some coupling to redirection
systems. It is possible that when fetching content as opposed to
pushing content that sessions between replication peering systems
may be directed by the redirection system.
4.5.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.
5. Scalable distribution of the content.
4.5.2 Signaling Requirements
The specific requirements in content signaling are:
1. Minimum support for a "flush" and an "expiration time update"
signal.
2. Security mechanisms.
3. Scalable distribution of the signals on a large scale.
Green, et. al. Expires April 20, 2001 [Page 21]
Internet-Draft CDNP Architecture October 2000
4.5.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.
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 April 20, 2001 [Page 22]
Internet-Draft CDNP Architecture October 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 from surrogates that are delivering their content
directly to clients. ACCOUNTING CPGs retrieve the data from
SURROGATEs that collect and store the data locally. This interior
data may be collected from the SURROGATEs by ACCOUNTING CPGs using
SNMP or FTP, for example. ACCOUNTING CPGs transfer the data to
exterior neighboring ACCOUNTING CPGs on request or in an
asynchronous manner. This architecture is only concerned with the
latter exchange. Accounting data may also be aggregated before it is
transferred.
Figure 4 contains a architecture diagram of the entities involved in
the ACCOUNTING PEERING system.
Green, et. al. Expires April 20, 2001 [Page 23]
Internet-Draft CDNP Architecture October 2000
..................................... ....................
. Peering CDN . . Peering CDN .
. +-----------+ +--------------+ . . +--------------+ . +---------+
. | SURROGATE |----| ACCOUNTING |-------| ACCOUNTING |-----| ORIGIN |
. +-----------+ /--| CPG | . ---| CPG |---\ +---------+
. | +--------------+ . / . +--------------+ . |
. +-----------+ | . | . . | +---------+
. | SURROGATEs|-/ . | .................... \-| BILLING |
. +-----------+ . | | ORG. |
. . | +---------+
..................................... |
|
..................................... |
. Peering CDN . |
. +-----------+ +--------------+ . |
. | SURROGATE |----| ACCOUNTING |--/
. +-----------+ /--| CPG | .
. | +--------------+ .
. +-----------+ | .
. | SURROGATEs|-/ .
. +-----------+ .
. .
.....................................
Figure 4 ACCOUNTING PEERING system Architecture
In addition information needs to be exchanged between ACCOUNTING
CPGs in order for SURROGATEs to be able to provide authentication,
authorization, and policy enforcement as specified by the content
provider. It is possible that this meta-data could be included with
the content replicated by the DISTRIBUTION PEERING system. However
these types of data are grouped together in the work of the
Authentication, Authorization and Accounting (AAA) working group in
the IETF. This work as well as the work of the Authentication
Authorization Accounting Architecture (AAAARCH) research group in
the IRTF should be examined to determine their applicability to CDN
peering accounting.
5.2 Accounting Data Types
Accounting data generally falls into the network or system
management, policy, and settlement categories, which are gathered to
collect information about the use of the content. Network and system
management data allows for the monitoring of resources in order to
perform load balancing and to observe the conformance to Service
Level Agreements (SLAs). Policy information allows for the
enforcement of authentication and authorization. Data needed for
settlement includes statistics such as proxy hits and misses,
Green, et. al. Expires April 20, 2001 [Page 24]
Internet-Draft CDNP Architecture October 2000
information from log files, and session detail records for
CONTINUOUS MEDIA.
5.3 Accounting Models
In one model a third-party BILLING ORGANIZATION must be able to
receive the information necessary to bill the appropriate party. In
another model this function may be performed by the PUBLISHER or
AUTHORITATIVE DIRECTION SYSTEM. Consult [14] for detailed
information on CDN peering billing models.
Accounting data may be requested by an ACCOUNTING CPG or supplied
asynchronously by another ACCOUNTING CPG. Asynchronous data may be
subscribed to or sent in an solicited manner. Guidelines should be
set on the amount of accounting data traffic which should be allowed
in proportion to the content data and how aggregation of accounting
data is performed.
Some accounting data may be sensitive to time. Four categories of
time sensitive management data have been identified. The first is
real-time data that consists of events that require immediate action
or attention. The second is data that is needed within 5 seconds of
generation such as resource loading or diagnostic data. The third is
data that is needed in 5-minute intervals such as statistics. The
fourth is data that is needed on a 24 hour or less basis such as
logs or billing data.
5.4 Accounting Problems to Solve
There are several problems with data retrieval that need to be
solved. These include latency, overhead, and large data size. The
core set of facilities must provide solutions to these and must
consist of collection of data on the server, controlled access to
the data, and the aggregation and archival of the data on ACCOUNTING
CPGs.
Specific problems in accounting data exchange needing further
investigation include:
1. How do we represent accounting info for a given object?
2. How do we represent accounting for many media types?
3. How do we aggregate this information?
4. How do we signal upload place or type?
5. How do we aggregate this information "hop-by-hop" back to the
BILLING ORGANIZATION?
Green, et. al. Expires April 20, 2001 [Page 25]
Internet-Draft CDNP Architecture October 2000
5.5 Accounting Requirements
The complexity of CDN peering requires that a method be created for
the exchange of accounting information. This information must be
accurately logged, aggregated and ultimately collected at the
BILLING entity for each PUBLISHER.
The specific requirements for accounting data exchange are:
1. Simple methods for representing accounting information.
2. Simple methods for aggregating this accounting information.
3. Agreed upon protocols for the uploading and distribution of this
information.
4. Agreed upon standardized accounting records.
Green, et. al. Expires April 20, 2001 [Page 26]
Internet-Draft CDNP Architecture October 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, DIRECTION
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 April 20, 2001 [Page 27]
Internet-Draft CDNP Architecture October 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 REDIRECTION SYSTEM (redirection to inappropriate
SURROGATEs, even though they may have appropriate CONTENT), or both.
A REDIRECTION SYSTEM may also fail by redirecting the CLIENT when no
redirection is appropriate, or by failing to redirect the CLIENT
when redirection is appropriate.
6.1.1.4 Denial of Service
A CDN that does not redirect 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
it may reward CLIENTs inappropriately. Inaccurate accounting
Green, et. al. Expires April 20, 2001 [Page 28]
Internet-Draft CDNP Architecture October 2000
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 REDIRECTION
SYSTEM.
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 April 20, 2001 [Page 29]
Internet-Draft CDNP Architecture October 2000
7. Impact on the Internet Architecture
On the face of it, the architectural framework proposed in this
paper for adding intermediate DISTRIBUTION systems to Internet
infrastructure looks like a major change in the end-to-end model [5]
that has been so successful in the Internet. However, in this model,
the SURROGATEs are delegated by ORIGIN servers to act in their
behalf, and thus are the terminating servers for CLIENTs in the
end-to-end model. Conceptually, there are multiple end-to-end
relationships introduced by peering CDNs, each being linked together
by intermediary DIRECTION SYSTEMs, DISTRIBUTION SYSTEMs, and
ACCOUNTING SYSTEMs, duly authorized by the parties involved to
provide intermediate services. This model has precedence in the
Internet, with the Domain Name Service [3] being a classic example.
The value of the end to end model is that the network is simple and
transparent [9], so it is easy to add services, and easy to diagnose
problems when they occur. With the end to end model, there are only
two active entities that count, the CLIENT and the ORIGIN (or
requesting peer and replying peer in peer-to-peer services). As
previously stated, the end to end model is still in effect for the
client and server relationship, thus, preserving transparency in the
rendering of services by DIRECTION SYSTEMs and SURROGATEs to CLIENTs.
Green, et. al. Expires April 20, 2001 [Page 30]
Internet-Draft CDNP Architecture October 2000
8. Acknowledgements
The authors would like to acknowledge the contributions and comments
of Mark Day (Cisco), Fred Douglis (AT&T), Don Gilletti (Entera),
John Martin (Network Appliance), Raj Nair (Cisco), Doug Potter
(Cisco), John Scharber (Entera), Oliver Spatscheck (AT&T) and
Stephen Thomas (TransNexus).
Green, et. al. Expires April 20, 2001 [Page 31]
Internet-Draft CDNP Architecture October 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] 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>.
[3] Postel, J., "Domain Name Structure and Delegation", RFC 1591,
March 1994,
<URL:http://www.rfc-editor.org/rfc/rfc1591.txt>.
[4] 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>.
[5] Carpenter, B., "Architecture Principles of the Internet", RFC
1958, June 1996,
<URL:http://www.rfc-editor.org/rfc/rfc1958.txt>.
[6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol", RFC 2326, April 1998,
<URL:http://www.rfc-editor.org/rfc/rfc2326.txt>.
[7] 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>.
[8] 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>.
[9] Carpenter, B., "Internet Transparency", RFC 2775, February
2000,
<URL:http://www.rfc-editor.org/rfc/rfc2775.txt>.
[10] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy",
draft-ietf-wrec-taxonomy-04.txt (work in progress), June 2000,
<URL:http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxono
my-04.txt>.
[11] Volbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
Green, et. al. Expires April 20, 2001 [Page 32]
Internet-Draft CDNP Architecture October 2000
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>.
[12] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
draft-day-cdnp-model-02.txt (work in progress), October 2000,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-model-0
2.txt>.
[13] Day, M. and D. Gilletti, "Content Distribution Network Peering
Scenarios", draft-day-cdnp-scenarios-01.txt (work in
progress), October 2000,
<URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-scenari
os-01.txt>.
[14] Gilletti, D., Nair, R. and J. Scharber, "Accounting Models for
CDN Peering", draft-gilletti-cdnp-accounting-models-02.txt
(work in progress), October 2000,
<URL:http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-ac
counting-models-02.txt>.
[15] Douglis, F., Nair, R., Spatscheck, O. and M. Green, "Known CDN
Redirection Mechanisms",
draft-douglis-cdnp-rdir-known-mechs-00.txt, not yet published
(work in progress), October 2000.
[16] G. & C. Merriam Co., "Webster's New Collegiate Dictionary",
1977.
[17] CUKIER, K., "Peering and Fearing: ISP Interconnection and
Regulatory Issues", March 1998,
<URL:http://www.ksg.harvard.edu/iip/iicompol/Papers/Cukier.html
>.
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 April 20, 2001 [Page 33]
Internet-Draft CDNP Architecture October 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
Green, et. al. Expires April 20, 2001 [Page 34]
Internet-Draft CDNP Architecture October 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 April 20, 2001 [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-24 03:06:42 |