draft-ietf-cdni-framework-11.txt   draft-ietf-cdni-framework-12.txt 
Network Working Group L. Peterson Network Working Group L. Peterson
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Obsoletes: 3466 (if approved) B. Davie Obsoletes: 3466 (if approved) B. Davie
Intended status: Informational VMware, Inc. Intended status: Informational VMware, Inc.
Expires: November 6, 2014 R. van Brandenburg, Ed. Expires: November 27, 2014 R. van Brandenburg, Ed.
TNO TNO
May 5, 2014 May 26, 2014
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-11 draft-ietf-cdni-framework-12
Abstract Abstract
This document presents a framework for Content Distribution Network This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of interfaces CDNs. CDN Interconnection requires the specification of interfaces
and mechanisms to address issues such as request routing, and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange distribution metadata exchange, and logging information exchange
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2014. This Internet-Draft will expire on November 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 12 skipping to change at page 4, line 12
Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for
the purposes of communication with a peer CDN, but which is not found the purposes of communication with a peer CDN, but which is not found
in client requests. Such CDN-Domains may be used for inter-CDN in client requests. Such CDN-Domains may be used for inter-CDN
acquisition, or as redirection targets, and enable a CDN to acquisition, or as redirection targets, and enable a CDN to
distinguish a request from a peer CDN from an end-user request. distinguish a request from a peer CDN from an end-user request.
Delivering CDN: the CDN that ultimately delivers a piece of content Delivering CDN: the CDN that ultimately delivers a piece of content
to the end-user. The last in a potential sequence of downstream to the end-user. The last in a potential sequence of downstream
CDNs. CDNs.
Recursive CDNI Request Redirection: When an upstream CDN elects to
redirect a request towards a downstream CDN, the upstream CDN can
query the downstream CDN Request Routing system via the CDNI Request
Routing Redirection Interface (or use information cached from earlier
similar queries) to find out how the downstream CDN wants the request
to be redirected, which allows the upstream CDN to factor in the
downstream CDN response when redirecting the user agent. This
approach is referred to as "Recursive" CDNI Request Redirection.
Note that the downstream CDN may elect to have the request redirected
directly to a Surrogate inside the downstream CDN, to the Request
Routing System of the downstream CDN, to another CDN, or to whatever
system is necessary to handle the redirected request appropriately.
Iterative CDNI Request Redirection: When an upstream CDN elects to Iterative CDNI Request Redirection: When an upstream CDN elects to
redirect a request towards a downstream CDN, the upstream CDN can redirect a request towards a downstream CDN, the upstream CDN can
base its redirection purely on a local decision (and without base its redirection purely on a local decision (and without
attempting to take into account how the downstream CDN may in turn attempting to take into account how the downstream CDN may in turn
redirect the user agent). In that case, the upstream CDN redirects redirect the user agent). In that case, the upstream CDN redirects
the request to the request routing system in the downstream CDN, the request to the request routing system in the downstream CDN,
which in turn will decide how to redirect that request: this approach which in turn will decide how to redirect that request: this approach
is referred to as "Iterative" CDNI Request Redirection. is referred to as "Iterative" CDNI Request Redirection.
Recursive CDNI Request Redirection: When an upstream CDN elects to
redirect a request towards a downstream CDN, the upstream CDN can
query the downstream CDN Request Routing system via the CDNI Request
Routing Redirection Interface (or use information cached from earlier
similar queries) to find out how the downstream CDN wants the request
to be redirected. This allows the upstream CDN to factor in the
downstream CDN response when redirecting the user agent. This
approach is referred to as "Recursive" CDNI Request Redirection.
Note that the downstream CDN may elect to have the request redirected
directly to a Surrogate inside the downstream CDN, or to any other
element in the downstream CDN (or in another CDN) to handle the
redirected request appropriately.
Synchronous CDNI operations: operations between CDNs that happen Synchronous CDNI operations: operations between CDNs that happen
during the process of servicing a user request, i.e. between the time during the process of servicing a user request, i.e. between the time
that the user agent begins its attempt to obtain content and the time that the user agent begins its attempt to obtain content and the time
at which that request is served. at which that request is served.
Asynchronous CDNI operations: operations between CDNs that happen Asynchronous CDNI operations: operations between CDNs that happen
independently of any given user request, such as advertisement of independently of any given user request, such as advertisement of
footprint information or pre-positioning of content for later footprint information or pre-positioning of content for later
delivery. delivery.
Trigger Interface: a subset of the CDNI Control interface that Trigger Interface: a subset of the CDNI Control interface that
includes operations to pre-position, revalidate, and purge both includes operations to pre-position, revalidate, and purge both
metadata and content. These operations are typically called in metadata and content. These operations are typically called in
response to some action (Trigger) by the CSP on the upstream CDN. response to some action (Trigger) by the Content Service Provider
(CSP) on the upstream CDN.
We also sometimes use uCDN and dCDN as shorthand for upstream CDN and We also sometimes use uCDN and dCDN as shorthand for upstream CDN and
downstream CDN, respectively. downstream CDN (see [RFC6707]), respectively.
At various points in this document, the concept of a CDN footprint is At various points in this document, the concept of a CDN footprint is
used. For a discussion on what constitutes a CDN footprint, the used. For a discussion on what constitutes a CDN footprint, the
reader is referred to reader is referred to
[I-D.ietf-cdni-footprint-capabilities-semantics]. [I-D.ietf-cdni-footprint-capabilities-semantics].
1.2. Reference Model 1.2. Reference Model
This document uses the reference model in Figure 1, which expands the This document uses the reference model in Figure 1, which expands the
reference model originally defined in [RFC6707]. (The difference is reference model originally defined in [RFC6707]. (The difference is
skipping to change at page 14, line 18 skipping to change at page 14, line 18
makes a request for URL makes a request for URL
http://cdn.csp.example/...rest of url... http://cdn.csp.example/...rest of url...
It may well be the case that cdn.csp.example is just a CNAME for some It may well be the case that cdn.csp.example is just a CNAME for some
other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP
request in the examples that follow is assumed to be for the example request in the examples that follow is assumed to be for the example
URL above. URL above.
Our goal is to enable content identified by the above URL to be Our goal is to enable content identified by the above URL to be
served by the CDN of operator B. In the following sections we will served by the CDN of operator B. In the following sections we will
walk through some scenarios in which content is served, as well as walk through some scenarios in which content is served, as well as
other CDNI operations such as the removal of content from a other CDNI operations such as the removal of content from a
downstream CDN. downstream CDN.
3.2. Iterative HTTP Redirect Example 3.2. Iterative HTTP Redirect Example
In this section we walk through a simple, illustrative example using In this section we walk through a simple, illustrative example using
HTTP redirection from uCDN to dCDN. The example also assumes the use HTTP redirection from uCDN to dCDN. The example also assumes the use
of HTTP redirection inside uCDN and dCDN; however, this is of HTTP redirection inside uCDN and dCDN; however, this is
independent of the choice of redirection approach across CDNs, so an independent of the choice of redirection approach across CDNs, so an
skipping to change at page 15, line 17 skipping to change at page 15, line 17
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The content provider is configured to make operator A the o The content provider is configured to make operator A the
authoritative DNS server for cdn.csp.example (or to return a CNAME authoritative DNS server for cdn.csp.example (or to return a CNAME
for cdn.csp.example for which operator A is the authoritative DNS for cdn.csp.example for which operator A is the authoritative DNS
server). server).
o Operator A is configured so that a DNS request for o Operator A is configured so that a DNS request for
op-b-acq.op-a.example returns a request router in Operator A. op-b-acq.op-a.example returns a request router in Operator A.
o Operator B is configured so that a DNS request for o Operator B is configured so that a DNS request for peer-a.op-b
peer-a.op-b.example/cdn.csp.example returns a request router in .example/cdn.csp.example returns a request router in Operator B.
Operator B.
Figure 3 illustrates how a client request for Figure 3 illustrates how a client request for
http://cdn.csp.example/...rest of url... http://cdn.csp.example/...rest of url...
is handled. is handled.
End-User Operator B Operator A End-User Operator B Operator A
|DNS cdn.csp.example | | |DNS cdn.csp.example | |
|-------------------------------------------------->| |-------------------------------------------------->|
skipping to change at page 17, line 7 skipping to change at page 17, line 4
recognizes that the end-user is best served by another CDN, recognizes that the end-user is best served by another CDN,
specifically one provided by Operator B, and so it returns a 302 specifically one provided by Operator B, and so it returns a 302
redirect message for a new URL constructed by "stacking" redirect message for a new URL constructed by "stacking"
Operator B's distinguished CDN-Domain (peer-a.op-b.example) on Operator B's distinguished CDN-Domain (peer-a.op-b.example) on
the front of the original URL. (Note that more complex URL the front of the original URL. (Note that more complex URL
manipulations are possible, such as replacing the initial CDN- manipulations are possible, such as replacing the initial CDN-
Domain by some opaque handle.) Domain by some opaque handle.)
3. The end-user does a DNS lookup using Operator B's distinguished 3. The end-user does a DNS lookup using Operator B's distinguished
CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the
IP address of a request router for Operator B. Note that if IP address of a request router for Operator B. Note that if
request routing within dCDN was performed using DNS instead of request routing within dCDN was performed using DNS instead of
HTTP redirection, B's DNS resolver would also behave as the HTTP redirection, B's DNS resolver would also behave as the
request router and directly return the IP address of a delivery request router and directly return the IP address of a delivery
node. node.
4. The request router for Operator B processes the HTTP request and 4. The request router for Operator B processes the HTTP request and
selects a suitable delivery node to serve the end-user request, selects a suitable delivery node to serve the end-user request,
and returns a 302 redirect message for a new URL constructed by and returns a 302 redirect message for a new URL constructed by
replacing the hostname with a subdomain of the Operator B's replacing the hostname with a subdomain of the Operator B's
distinguished CDN-Domain that points to the selected delivery distinguished CDN-Domain that points to the selected delivery
skipping to change at page 23, line 48 skipping to change at page 23, line 48
redirection for request redirection from uCDN to dCDN (as well as for redirection for request redirection from uCDN to dCDN (as well as for
request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- request routing inside dCDN and uCDN). As noted in Section 2.1, DNS-
based redirection has certain advantages over HTTP-based redirection based redirection has certain advantages over HTTP-based redirection
(notably, it is transparent to the end-user) as well as some (notably, it is transparent to the end-user) as well as some
drawbacks (notably the client IP address is not visible to the drawbacks (notably the client IP address is not visible to the
request router). request router).
As before, Operator A has to learn the set of requests that dCDN is As before, Operator A has to learn the set of requests that dCDN is
willing or able to serve (e.g. which client IP address prefixes or willing or able to serve (e.g. which client IP address prefixes or
geographic regions are part of the dCDN footprint). We assume geographic regions are part of the dCDN footprint). We assume
Operator has and makes known to operator A some unique identifier Operator B has and makes known to Operator A some unique identifier
that can be used for the construction of a distinguished CDN-Domain, that can be used for the construction of a distinguished CDN-Domain,
as shown in more detail below. (This identifier strictly needs only as shown in more detail below. (This identifier strictly needs only
to be unique within the scope of Operator A, but a globally unique to be unique within the scope of Operator A, but a globally unique
identifier, such as an AS number assigned to B, is one easy way to identifier, such as an AS number assigned to B, is one easy way to
achieve that.) Also, Operator A obtains the NS records for Operator achieve that.) Also, Operator A obtains the NS records for Operator
B's externally visible redirection servers. Also, as before, a B's externally visible redirection servers. Also, as before, a
distinguished CDN-Domain, such as op-b-acq.op-a.example, must be distinguished CDN-Domain, such as op-b-acq.op-a.example, must be
assigned for inter-CDN acquisition. assigned for inter-CDN acquisition.
We assume DNS is configured in the following way: We assume DNS is configured in the following way:
o The CSP is configured to make Operator A the authoritative DNS o The CSP is configured to make Operator A the authoritative DNS
server for cdn.csp.example (or to return a CNAME for server for cdn.csp.example (or to return a CNAME for
cdn.csp.example for which operator A is the authoritative DNS cdn.csp.example for which operator A is the authoritative DNS
server). server).
o When uCDN sees a request best served by dCDN, it returns CNAME and o When uCDN sees a request best served by dCDN, it returns CNAME and
NS records for "b.cdn.csp.example", where "b" is the unique NS records for "b.cdn.csp.example", where "b" is the unique
identifier assigned to Operator B. (It may, for example, be an AS identifier assigned to Operator B. (It may, for example, be an AS
number assigned to Operator B.) number assigned to Operator B.)
o dCDN is configured so that a request for "b.cdn.csp.example" o dCDN is configured so that a request for "b.cdn.csp.example"
returns a delivery node in dCDN. returns a delivery node in dCDN.
o uCDN is configured so that a request for "op-b-acq.op-a.example" o uCDN is configured so that a request for "op-b-acq.op-a.example"
returns a delivery node in uCDN. returns a delivery node in uCDN.
Figure 5 depicts the exchange of DNS and HTTP requests. The main Figure 5 depicts the exchange of DNS and HTTP requests. The main
differences from Figure 3 are the lack of HTTP redirection and differences from Figure 3 are the lack of HTTP redirection and
skipping to change at page 27, line 47 skipping to change at page 27, line 47
and return it together with the associated pre-generated signature. and return it together with the associated pre-generated signature.
Note: In the latter case maintaining the serial and signature of SOA Note: In the latter case maintaining the serial and signature of SOA
might be an issue since technically it should change every time a might be an issue since technically it should change every time a
different CNAME is used. However, since in practice direct SOA different CNAME is used. However, since in practice direct SOA
queries are relatively rare, a uCDN could defer incrementing the queries are relatively rare, a uCDN could defer incrementing the
serial and resigning the SOA until it is queried and then do it on- serial and resigning the SOA until it is queried and then do it on-
the-fly. the-fly.
Note also that the NS record and the glue AAAA/A records used in step Note also that the NS record and the glue AAAA/A records used in step
2 in the previous section should generally be identical to those of 2 in the previous section should generally be identical to those of
their authoritative zone managed by Operator B. Even if they differ, their authoritative zone managed by Operator B. Even if they differ,
this will not make the DNS resolution process fail, but the client this will not make the DNS resolution process fail, but the client
DNS server will prefer the authoritative data in its cache and use it DNS server will prefer the authoritative data in its cache and use it
for subsequent queries. Such inconsistency is a general operational for subsequent queries. Such inconsistency is a general operational
issue of DNS, but it may be more important for this architecture issue of DNS, but it may be more important for this architecture
because the uCDN (operator A) would rely on the consistency to make because the uCDN (operator A) would rely on the consistency to make
the resulting redirection work as intended. In general, it is the the resulting redirection work as intended. In general, it is the
administrator's responsibility to make them consistent. administrator's responsibility to make them consistent.
3.5. Dynamic Footprint Discovery Example 3.5. Dynamic Footprint Discovery Example
skipping to change at page 29, line 42 skipping to change at page 29, line 42
| |------------------------>| | |------------------------>|
| | |(5) | | |(5)
| |Data | | |Data |
| |<------------------------| | |<------------------------|
|Data | | |Data | |
|<------------------------| | |<------------------------| |
Figure 6: Message Flow for Dynamic Footprint Discovery Figure 6: Message Flow for Dynamic Footprint Discovery
This example differs from the one in Figure 5 only in the addition of This example differs from the one in Figure 5 only in the addition of
a FCI request (step 2) and corresponding response (step 3). The RI a RI request (step 2) and corresponding response (step 3). The RI
REQ could be a message such as "Can you serve clients from this IP REQ could be a message such as "Can you serve clients from this IP
Prefix?" or it could be "Provide the list of client IP prefixes you Prefix?" or it could be "Provide the list of client IP prefixes you
can currently serve". In either case the response might be cached by can currently serve". In either case the response might be cached by
operator A to avoid repeatedly asking the same question. operator A to avoid repeatedly asking the same question.
Alternatively, or in addition, Operator B may spontaneously advertise Alternatively, or in addition, Operator B may spontaneously advertise
to Operator A information (or changes) on the set of requests it is to Operator A information (or changes) on the set of requests it is
willing and able to serve on behalf of operator A; in that case, willing and able to serve on behalf of operator A; in that case,
Operator B may spontaneously issue RR/RI REPLY messages that are not Operator B may spontaneously issue RR/RI REPLY messages that are not
in direct response to a corresponding RR/RI REQ message. (Note that in direct response to a corresponding RR/RI REQ message. (Note that
the issues of determining the client's subnet from DNS requests, as the issues of determining the client's subnet from DNS requests, as
skipping to change at page 30, line 24 skipping to change at page 30, line 24
3.6. Content Removal Example 3.6. Content Removal Example
The following example illustrates how the CDNI Control interface may The following example illustrates how the CDNI Control interface may
be used to achieve pre-positioning of an item of content in the dCDN. be used to achieve pre-positioning of an item of content in the dCDN.
In this example, user requests for a particular content, and In this example, user requests for a particular content, and
corresponding redirection of such requests from Operator A to corresponding redirection of such requests from Operator A to
Operator B CDN, may (or may not) have taken place earlier. Then, at Operator B CDN, may (or may not) have taken place earlier. Then, at
some point in time, the uCDN (for example, in response to a some point in time, the uCDN (for example, in response to a
corresponding Trigger from the Content Provider) uses the CI to corresponding Trigger from the Content Provider) uses the CI to
request that content identified by a particular URL be removed from request that content identified by a particular URL be removed from
dCDN. The following diagram illustrates the operation. dCDN. The following diagram illustrates the operation. It should be
noted that a uCDN will typically not know whether a dCDN has cached a
given content item, however, it may send the content removal request
to make sure no cached versions remain to satisfy any contractual
obligations it may have.
End-User Operator B Operator A End-User Operator B Operator A
| |CI purge cdn.csp.example/... | |CI purge cdn.csp.example/...
| |<------------------------| | |<------------------------|
| | | | | |
| |CI OK | | |CI OK |
| |------------------------>| | |------------------------>|
| | | | | |
Figure 7: Message Flow for Content Removal Figure 7: Message Flow for Content Removal
skipping to change at page 34, line 12 skipping to change at page 34, line 12
4. Operator A replies with the requested metadata. This document 4. Operator A replies with the requested metadata. This document
does not constrain how the CDNI metadata information is actually does not constrain how the CDNI metadata information is actually
represented. For the purposes of this example, we assume that represented. For the purposes of this example, we assume that
Operator A provides CDNI metadata to Operator B indicating that: Operator A provides CDNI metadata to Operator B indicating that:
* this CDNI Metadata is applicable to any content referenced by * this CDNI Metadata is applicable to any content referenced by
some CDN-Domain. some CDN-Domain.
* this CDNI metadata consists of a distribution policy * this CDNI metadata consists of a distribution policy
requiring enforcement by the delivery node of a specific per- requiring enforcement by the delivery node of a specific per-
request authorization mechanism (e.g. URI signature or token request authorization mechanism (e.g. URI signature or token
validation). validation).
5. A Content Request occurs as usual. 5. A Content Request occurs as usual.
6. A CDNI Request Routing Redirection request (RI REQ) is issued by 6. A CDNI Request Routing Redirection request (RI REQ) is issued by
operator A CDN, as discussed in Section 3.3. Operator B's operator A CDN, as discussed in Section 3.3. Operator B's
request router can access the CDNI Metadata that are relevant to request router can access the CDNI Metadata that are relevant to
the requested content and that have been pre-positioned as per the requested content and that have been pre-positioned as per
Steps 1-4, which may or may not affect the response. Steps 1-4, which may or may not affect the response.
skipping to change at page 48, line 10 skipping to change at page 48, line 10
candidate CDN providers; In this case the content provider may be candidate CDN providers; In this case the content provider may be
modeled as the combination of a CSP and of a special, restricted case modeled as the combination of a CSP and of a special, restricted case
of a CDN. In that case, as illustrated in Figure 13, the CDNI of a CDN. In that case, as illustrated in Figure 13, the CDNI
Request Routing interfaces can be used between the restricted CDN Request Routing interfaces can be used between the restricted CDN
operated by the content provider Organization and the CDN operated by operated by the content provider Organization and the CDN operated by
the full CDN organization acting as a dCDN in the request routing the full CDN organization acting as a dCDN in the request routing
control plane. Interfaces outside the scope of the CDNI work can be control plane. Interfaces outside the scope of the CDNI work can be
used between the CSP functional entities of the content provider used between the CSP functional entities of the content provider
organization and the CDN operated by the full CDN organization acting organization and the CDN operated by the full CDN organization acting
as a uCDN) in the CDNI control planes other than the request routing as a uCDN) in the CDNI control planes other than the request routing
plane (i.e. Control, Distribution, Logging). plane (i.e. Control, Distribution, Logging).
##################################### ################## ##################################### ##################
# # # # # # # #
# Organization A # # Organization B # # Organization A # # Organization B #
# # # # # # # #
# -------- ------------- # # ----------- # # -------- ------------- # # ----------- #
# / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ #
# | | | +----+ | # # | +----+ | # # | | | +----+ | # # | +----+ | #
# | |*****| | RR |==========CDNI=====>| RR | | # # | |*****| | RR |==========CDNI=====>| RR | | #
# | | | +----+ | # RR # | +----+ | # # | | | +----+ | # RR # | +----+ | #
skipping to change at page 50, line 52 skipping to change at page 50, line 52
-------------- --------------
<=CDNI RR=> CDNI Request Routing Interface <=CDNI RR=> CDNI Request Routing Interface
<=CDNI M==> CDNI Metadata Interface <=CDNI M==> CDNI Metadata Interface
<=CDNI C==> CDNI Control Interface <=CDNI C==> CDNI Control Interface
<=CDNI L==> CDNI Logging Interface <=CDNI L==> CDNI Logging Interface
Figure 14: CDNI Deployment Model: CDN Exchange Figure 14: CDNI Deployment Model: CDN Exchange
Note that a CDN exchange may alternatively support a different set of Note that a CDN exchange may alternatively support a different set of
functionality (e.g. Logging only, or Logging and full request functionality (e.g. Logging only, or Logging and full request
routing, or all the functionality of a CDN including content routing, or all the functionality of a CDN including content
distribution). All these options are expected to be allowed by the distribution). All these options are expected to be allowed by the
IETF CDNI specifications. IETF CDNI specifications.
6. Trust Model 6. Trust Model
There are a number of trust issues that need to be addressed by a There are a number of trust issues that need to be addressed by a
CDNI solution. Many of them are in fact similar or identical to CDNI solution. Many of them are in fact similar or identical to
those in a simple CDN without interconnection. In a standard CDN those in a simple CDN without interconnection. In a standard CDN
environment (without CDNI), the CSP places a degree of trust in a environment (without CDNI), the CSP places a degree of trust in a
 End of changes. 19 change blocks. 
32 lines changed or deleted 36 lines changed or added

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