draft-ietf-cdni-use-cases-03.txt   draft-ietf-cdni-use-cases-04.txt 
Internet Engineering Task Force G. Bertrand, Ed. Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft E. Stephan Internet-Draft E. Stephan
Intended status: Informational France Telecom - Orange Intended status: Informational France Telecom - Orange
Expires: August 2, 2012 G. Watson Expires: September 27, 2012 G. Watson
T. Burbridge T. Burbridge
P. Eardley P. Eardley
BT BT
K. Ma K. Ma
Azuki Systems Azuki Systems
January 30, 2012 March 26, 2012
Use Cases for Content Delivery Network Interconnection Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-03 draft-ietf-cdni-use-cases-04
Abstract Abstract
Content Delivery Networks (CDNs) are commonly used for improving the Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service, at a reasonable End User experience of a content delivery service, at a reasonable
cost. This document outlines real world use cases (not technical cost. This document focuses on use cases that correspond to
solutions) for interconnecting CDNs. It focuses on use cases that identified industry needs and that are expected to be realized once
correspond to identified industry needs and that are expected to be open interfaces and protocols supporting interconnection of CDNs are
realized once a CDN Interconnection (CDNI) solution is available. specified and implemented. The document can be used to guide the
This document can be used to provide guidance to the CDNI WG about definition of the requirements to be supported by CDNI interfaces.
the interconnection arrangements to be supported and to validate the
requirements of the various CDNI interfaces.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 2, 2012. This Internet-Draft will expire on September 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5
1.4. The Need for CDN Interconnection Standards . . . . . . . . 7
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7
2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8
3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10
3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 11 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 12 4.1. Device and Network Technology Extension . . . . . . . . . 11
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 13 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
5.1. Content Delivery Restrictions . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Content Service Providers' Delivery Policies . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Content Delivery Networks (CDNs) are commonly used for improving the Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service, at a reasonable End User experience of a content delivery service, at a reasonable
cost. This document outlines real world use cases (not technical cost. This document focuses on use cases that correspond to
solutions) for interconnecting CDNs. It focuses on use cases that identified industry needs and that are expected to be realized once
correspond to identified industry needs and that are expected to be open interfaces and protocols supporting interconnection of CDNs are
realized once a CDNI solution is available. This document can be specified and implemented. The document can be used to guide the
used to provide guidance to the CDNI WG about the interconnection definition of the requirements to be supported by the various CDNI
arrangements to be supported and to validate the requirements of the interfaces defined in [I-D.ietf-cdni-problem-statement].
various CDNI interfaces.
This document identifies the main motivations for a CDN Provider to This document identifies the main motivations for a CDN Provider to
interconnect its CDN: interconnect its CDN:
o CDN Footprint Extension Use Cases (Section 2) o CDN Footprint Extension Use Cases (Section 2)
o CDN Offload Use Cases (Section 3) o CDN Offload Use Cases (Section 3)
o CDN Capability Use Cases (Section 4) o CDN Capability Use Cases (Section 4)
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Figure 1 Figure 1
To extend the example, another Content Service Provider, CSP-2, may To extend the example, another Content Service Provider, CSP-2, may
also reach an agreement with CDN Provider 'A'. But it does not want also reach an agreement with CDN Provider 'A'. But it does not want
its content to be distributed by CDN Provider B; for example, CSP-2 its content to be distributed by CDN Provider B; for example, CSP-2
may not have distribution rights in the country where CDN Provider may not have distribution rights in the country where CDN Provider
'B' operates. This example illustrates that policy considerations 'B' operates. This example illustrates that policy considerations
are an important part of CDNI. are an important part of CDNI.
1.4. The Need for CDN Interconnection Standards
The problem statement draft [I-D.ietf-cdni-problem-statement]
describes extensively the CDNI problem space and explains why CDNI
standards are required.
Existing CDN interfaces are proprietary and have often been designed
for intra-CDN/intra-domain operations. Consequently, an external CDN
typically cannot use these interfaces, especially if the two CDNs to
be interconnected rely on different implementations. Nevertheless,
[I-D.bertrand-cdni-experiments] shows that some level of CDN
Interconnection can be achieved experimentally without standardized
interfaces between the CDNs. However, the methods used in these
experiments are hardly usable in an operational context, because they
suffer from several limitations in terms of functionalities,
scalability, and security level.
The aim of IETF CDNI WG's solution is, therefore, to overcome such
shortcomings; a full list of requirements is being developed in
[I-D.ietf-cdni-requirements].
2. Footprint Extension Use Cases 2. Footprint Extension Use Cases
Footprint extension is expected to be a major use case for CDN Footprint extension is expected to be a major use case for CDN
Interconnection. Interconnection.
2.1. Geographic Extension 2.1. Geographic Extension
In this use case, the CDN Provider wants to extend the geographic In this use case, the CDN Provider wants to extend the geographic
distribution that it can offer to its CSPs: distribution that it can offer to its CSPs:
skipping to change at page 8, line 17 skipping to change at page 7, line 44
In addition to video, this use case applies to other types of content In addition to video, this use case applies to other types of content
such as automatic software updates (browser updates, operating system such as automatic software updates (browser updates, operating system
patches, virus database update, etc). patches, virus database update, etc).
2.2. Inter-Affiliates Interconnection 2.2. Inter-Affiliates Interconnection
In the previous section, we have described the case of geographic In the previous section, we have described the case of geographic
extension between CDNs operated by different entities. A large CDN extension between CDNs operated by different entities. A large CDN
Provider may also operate CDNs from several subsidiaries (which may Provider may also operate CDNs from several subsidiaries (which may
rely on different CDN solutions, see Section 4.2). In certain rely on different CDN technologies, see Section 4.2). In certain
circumstances, the CDN Provider needs to make its CDNs interoperate circumstances, the CDN Provider needs to make its CDNs interoperate
to provide a consistent service to its customers on its whole to provide a consistent service to its customers on its whole
footprint. For example, the CDN Provider might want to expose a footprint. For example, the CDN Provider might want to expose a
single set of interfaces to the CSPs. single set of interfaces to the CSPs.
2.3. ISP Handling of Third-Party Content 2.3. ISP Handling of Third-Party Content
Consider an ISP carrying to its subscribers a lot of content that Consider an ISP carrying to its subscribers a lot of content that
comes from a third party CSP and that is injected into the access comes from a third party CSP and that is injected into the access
network by an Authoritative CDN Provider. There are mutual benefits network by an Authoritative CDN Provider. There are mutual benefits
skipping to change at page 9, line 48 skipping to change at page 9, line 29
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
| | | |
+------------+ +---------------+ +------------+ +---------------+
+ EU A (home)| | EU A (nomadic)| + EU A (home)| | EU A (nomadic)|
+------------+ +---------------+ +------------+ +---------------+
=== CDN Interconnection === CDN Interconnection
Figure 2 Figure 2
The alternate CDN (CDN-B) is allowed to distribute the content of CSP The alternate CDN (CDN-B) is allowed to distribute the content of CSP
A to End User A; however, no other End Users in the region of CDN B A to End User A; however, no other End Users in the region of CDN-B
are allowed to retrieve the content unless they too have such an are allowed to retrieve the content unless they too have such an
agreement for nomadic access to content. agreement for nomadic access to content.
Depending on CSP's content delivery policies (see Section 5.1), a Depending on CSP's content delivery policies (see Appendix A.1), a
user moving to a different geographic region may be subject to geo- user moving to a different geographic region may be subject to geo-
blocking content delivery restrictions. In this case, he/she may not blocking content delivery restrictions. In this case, he/she may not
be allowed to access some pieces of content. be allowed to access some pieces of content.
3. Offload Use Cases 3. Offload Use Cases
3.1. Overload Handling and Dimensioning 3.1. Overload Handling and Dimensioning
A CDN is likely to be dimensioned to support an expected maximum A CDN is likely to be dimensioned to support an expected maximum
traffic load. However, unexpected spikes in content popularity traffic load. However, unexpected spikes in content popularity
skipping to change at page 12, line 14 skipping to change at page 11, line 40
4.1. Device and Network Technology Extension 4.1. Device and Network Technology Extension
In this use case, the CDN Provider may have the right geographic In this use case, the CDN Provider may have the right geographic
footprint, but may wish to extend the supported range of devices and footprint, but may wish to extend the supported range of devices and
User Agents or the supported range of delivery technologies. In this User Agents or the supported range of delivery technologies. In this
case, a CDN Provider may interconnect with a CDN that offers case, a CDN Provider may interconnect with a CDN that offers
services: services:
o that the CDN Provider is not willing to provide or, o that the CDN Provider is not willing to provide or,
o that its own CDN is not able to support o that its own CDN is not able to support.
The following examples illustrate this use case: The following examples illustrate this use case:
1. CDN-A cannot support a specific delivery protocol. For instance, 1. CDN-A cannot support a specific delivery protocol. For instance,
CDN-A may interconnect with CDN-B to serve a proportion of its CDN-A may interconnect with CDN-B to serve a proportion of its
traffic that requires HTTPS. CDN-A may use CDN-B's footprint traffic that requires HTTPS. CDN-A may use CDN-B's footprint
(which may overlap with its own) to deliver HTTPS without needing (which may overlap with its own) to deliver HTTPS without needing
to deploy its own infrastructure. This case could also be true to deploy its own infrastructure. This case could also be true
of other formats, delivery protocols (RTMP, RTSP, etc.) and of other formats, delivery protocols (RTMP, RTSP, etc.) and
features (specific forms of authorization such as tokens, per features (specific forms of authorization such as tokens, per
skipping to change at page 13, line 18 skipping to change at page 12, line 42
content to their End Users. In some cases, even if the CDN Provider content to their End Users. In some cases, even if the CDN Provider
could deliver the content to the End Users, it cannot meet the CSP's could deliver the content to the End Users, it cannot meet the CSP's
service level requirements. As a result, the CDN Provider may service level requirements. As a result, the CDN Provider may
establish a CDN Interconnection agreement with another CDN Provider establish a CDN Interconnection agreement with another CDN Provider
that can provide the expected QoE to the End User, e.g., via an that can provide the expected QoE to the End User, e.g., via an
Access CDN able to deliver content from Surrogates located closer to Access CDN able to deliver content from Surrogates located closer to
the End User and with the required service level. the End User and with the required service level.
5. Enforcement of Content Delivery Policy 5. Enforcement of Content Delivery Policy
CSPs commonly require the ability to place delivery restriction on An important aspect of the above use cases is that CSPs commonly want
sets of content, which are provided by existing CDNs. The ability to to enforce content delivery policies. A CSP may want to define
support such delivery restrictions across interconnected CDNs is content delivery policies that specify when, how, and/or to whom the
desirable, but depends on the capabilities of the involved CDNs. CDN delivers content. These policies apply to all interconnected
Thus, it is important to be able to detect and define when these CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can
features cannot be enforced. define content delivery policies for content delivered by a single,
non-interconnected CDN. Appendix A provides examples of CSP defined
5.1. Content Delivery Restrictions policies.
The content distribution policies that a CSP attaches to a piece of
content depend on many criteria. For instance, distribution policies
for audiovisual content often combine:
o temporal constraints (e.g., available for 24 hours, available 28
days after DVD release, etc.),
o resolution-based constraints (e.g., high definition vs. standard
definition), and
o geolocation-based constraints (e.g., per country).
CSPs may require from their CDN Providers that they translate some of
the above requirements into content delivery policies for their CDNs.
For instance, CDNs might implement "geo-blocking" rules specifying:
o geographic locations to which content can be delivered (i.e., the
location of the End Users), or
o the geographic regions from where content can be delivered (i.e.,
the location of the Surrogates).
Similarly, an uCDN might implement some temporal constraints on
content availability. For example, it could restrict access to pre-
positioned content prior to the opening of the availability window or
disable the delivery of content from the dCDNs (e.g., through
purging) after the availability window has closed.
5.2. Secure Access
Many protocols exist for delivering content to End Users. CSPs may
often wish to dictate a specific protocol or set of protocols which
are acceptable for delivery of their content, especially in the case
where content protection or user authentication is required (e.g.,
must use HTTPS). CSPs may also wish to perform per-request
authentication/authorization decision and then have the CDNs enforce
that decision (e.g., must validate URL signing, etc.).
An uCDN needs to be able to exclude dCDNs which lack support for the
secure access features requested by the CSP.
5.3. Branding
Preserving the branding of the CSP throughout delivery is often
important to the CSP. CSPs may desire to offer content services
under their own name, even when the associated CDN service involves
other CDN Providers. For instance, a CSP may desire to ensure that
content is delivered with URIs appearing to the End Users under the
CSP's own domain name, even when the content delivery involves
separate CDN Providers. The CSP may wish to forbid the delivery of
its content by specific dCDNs that lack support for such branding
preservation features.
Analogous restrictions may exist when the uCDN wants to offer CDN
services under its own branding even if dCDNs are involved.
Similarly, a CDN Provider might not want the brand of an intermediary
in the CDN delegation chain to be visible, even if the intermediary
is involved in the content delivery call flow.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Kent Leung, Francois Le Faucheur, Ben The authors would like to thank Kent Leung, Francois Le Faucheur, Ben
Niven-Jenkins, and Scott Wainner for lively discussions, as well as Niven-Jenkins, and Scott Wainner for lively discussions, as well as
for their reviews and comments on the mailing list. for their reviews and comments on the mailing list.
They also thank the contributors of the EU FP7 OCEAN and ETICS They also thank the contributors of the EU FP7 OCEAN and ETICS
projects for valuable inputs. projects for valuable inputs.
skipping to change at page 16, line 26 skipping to change at page 14, line 40
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[I-D.bertrand-cdni-experiments]
Bertrand, G., Faucheur, F., and L. Peterson, "Content
Distribution Network Interconnection (CDNI) Experiments",
draft-bertrand-cdni-experiments-01 (work in progress),
August 2011.
[I-D.davie-cdni-framework] [I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in Interconnection", draft-davie-cdni-framework-01 (work in
progress), October 2011. progress), October 2011.
[I-D.ietf-cdni-problem-statement] [I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-03 (work in Statement", draft-ietf-cdni-problem-statement-04 (work in
progress), January 2012. progress), March 2012.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-02 (work in progress), draft-ietf-cdni-requirements-02 (work in progress),
December 2011. December 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
Appendix A. Content Service Providers' Delivery Policies
CSPs commonly apply different delivery policies to given sets of
content assets delivered through CDNs. Interconnected CDNs need to
support these policies. This annex presents examples of CSPs'
delivery policies and their consequences on CDNI operations.
A.1. Content Delivery Policy Enforcement
The content distribution policies that a CSP attaches to a content
asset may depend on many criteria. For instance, distribution
policies for audiovisual content often combine:
o temporal constraints (e.g., available for 24 hours, available 28
days after DVD release, etc.),
o resolution-based constraints (e.g., high definition vs. standard
definition), and
o geolocation-based constraints (e.g., per country).
dCDN delegation and Surrogate selection decisions are influenced by
these policies:
o dCDN delegation and/or Surrogates selection may fail if the
availability window for the requested content is not active,
o dCDN delegation may fail if the content resolution has been
specified by the CSP as being too high for distribution via the
dCDN,
o Surrogate selection may fail if the content resolution has been
specified by the CSP as being too high for distribution via the
current CDN,
o dCDN delegation may fail if the footprint of the dCDN is outside
of the delivery footprint for the requested content, or
o Surrogate selection may fail if the footprint of the current CDN
is outside of the delivery footprint for the requested content.
These policy considerations permit preventing premature access to
pre-positioned content, preventing content licensing violations, and
enforcing geo-blocking policies.
A.2. Secure Access
Many protocols exist for delivering content to End Users. CSPs may
dictate a specific protocol or set of protocols which are acceptable
for delivery of their content, especially in the case where content
protection or user authentication is required (e.g., must use HTTPS).
CSPs may also perform per-request authentication/authorization
decision and then have the CDNs enforce that decision (e.g., must
validate URL signing, etc.).
A.3. Branding
Preserving the branding of the CSP throughout delivery is often
important to the CSP. CSPs may desire to offer content services
under their own name, even when the associated CDN service involves
other CDN Providers. For instance, a CSP may desire to ensure that
content is delivered with URIs appearing to the End Users under the
CSP's own domain name, even when the content delivery involves
separate CDN Providers. The CSP may wish to prevent the delivery of
its content by specific dCDNs that lack support for such branding
preservation features.
Analogous cases exist when the uCDN wants to offer CDN services under
its own branding even if dCDNs are involved. Similarly, a CDN
Provider might wish to restrict the delivery delegation to a chain
that preserves its brand visibility.
Authors' Addresses Authors' Addresses
Gilles Bertrand (editor) Gilles Bertrand (editor)
France Telecom - Orange France Telecom - Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy les Moulineaux, 92130 Issy les Moulineaux, 92130
FR FR
Phone: +33 1 45 29 89 46 Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com Email: gilles.bertrand@orange.com
 End of changes. 21 change blocks. 
136 lines changed or deleted 119 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/