RFC 6770

Use Cases for Content Delivery Network Interconnection

📅 published November 2012, from ietf

RFC 6770: Use Cases for Content Delivery Network Interconnection 🎀

Okay bestie, this one is an Informational doc, not a Standards Track thing, so it's more of a "here's why this matters" vibe than a rulebook 📖. It came out in November 2012 from the IETF, with ISSN 2070-1721. The editor is G. Bertrand, and the rest of the squad is E. Stephan (France Telecom - Orange), T. Burbridge and P. Eardley (BT), K. Ma (Azuki Systems, Inc.), and G. Watson (Alcatel-Lucent, Velocix). It obsoletes RFC 3570 🫶

Abstract ✨

Okay so CDNs (Content Delivery Networks) are super popular because they make content feel fast for End Users without the bill going totally off the rails 💸. This doc is all about the use cases that people in the industry actually need, the ones we expect to become real once there are open interfaces and protocols for connecting CDNs together 🔌. It's meant to help motivate which requirements CDN Interconnection (CDNI) interfaces should support. It also obsoletes RFC 3570, which is giving "fresh start" 🦋

Status of This Memo 🌸

Quick reality check: this is not an Internet Standards Track spec. It's published just to share info 💅

It is still an IETF product, which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so see Section 2 of RFC 5741 if you want the deets 🧐

For the current status, errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc6770 🔗

The IETF Trust and the document authors own the copyright here, copyright (c) 2012, and all rights are reserved 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info. Those rules are the ones in effect on the publication date, so please read them carefully, because they spell out what you're allowed to do and what you're not 📜

If you pull any Code Components out of this document, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as the Simplified BSD License describes 💜

Table of Contents 🗺️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
  1.3.  Rationale for CDN Interconnection  . . . . . . . . . . . .  4
2.  Footprint Extension Use Cases  . . . . . . . . . . . . . . . .  6
  2.1.  Geographic Extension . . . . . . . . . . . . . . . . . . .  6
  2.2.  Inter-Affiliates Interconnection . . . . . . . . . . . . .  6
  2.3.  ISP Handling of Third-Party Content  . . . . . . . . . . .  7
  2.4.  Nomadic Users  . . . . . . . . . . . . . . . . . . . . . .  7
3.  Offload Use Cases  . . . . . . . . . . . . . . . . . . . . . .  8
  3.1.  Overload Handling and Dimensioning . . . . . . . . . . . .  8
  3.2.  Resiliency . . . . . . . . . . . . . . . . . . . . . . . .  9
    3.2.1.  Failure of Content Delivery Resources  . . . . . . . .  9
    3.2.2.  Content Acquisition Resiliency . . . . . . . . . . . . 10
4.  Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 11
  4.1.  Device and Network Technology Extension  . . . . . . . . . 11
  4.2.  Technology and Vendor Interoperability . . . . . . . . . . 12
  4.3.  QoE and QoS Improvement  . . . . . . . . . . . . . . . . . 12
5.  Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A.  Content Service Providers' Delivery Policies  . . . . 14
  A.1.  Content Delivery Policy Enforcement  . . . . . . . . . . . 14
  A.2.  Secure Access  . . . . . . . . . . . . . . . . . . . . . . 15
  A.3.  Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15

1. Introduction 💖

CDNs are used a lot because they make the End User experience way better while keeping costs chill 😌. This doc zooms in on use cases that match real industry needs, the ones we expect to happen once open interfaces and protocols for connecting CDNs are specified and implemented 🔥. This doc can help motivate which requirements, as documented in [CDNI-REQ], should be supported by the set of CDN Interconnection (CDNI) interfaces defined in [RFC6707] ✨

[RFC3570] describes slightly different terminology and models for "Content Internetworking (CDI)". To avoid confusion, this doc obsoletes RFC 3570 🫶

So what are the main reasons a CDN Provider would want to interconnect its CDN? Here's the lineup 👑

  • CDN Footprint Extension Use Cases (Section 2) 🗺️
  • CDN Offload Use Cases (Section 3) 🧚
  • CDN Capability Use Cases (Section 4) 🌈

Then the doc gets into why interoperability matters for exchanging and enforcing content delivery policies (Section 5) 📜

1.1. Terminology 🩷

Okay so in this doc, every CDNI-specific term gets a capital letter at the start of each word. We're using the terminology from [RFC6707], and we add one more term to the mix 💅

Access CDN:

A CDN that includes Surrogates in the same administrative network as the End User. This kind of CDN can use accurate info about the End User's network context to offer extra Content Delivery Services to Content Service Providers 🦋

1.2. Abbreviations 🍓

  • CDN: Content Delivery Network, also known as Content Distribution Network
  • CSP: Content Service Provider
  • dCDN: downstream CDN
  • DNS: Domain Name System
  • EU: End User
  • ISP: Internet Service Provider
  • NSP: Network Service Provider
  • QoE: Quality of Experience
  • QoS: Quality of Service
  • uCDN: upstream CDN
  • URL: Uniform Resource Locator
  • WiFi: Wireless local area network (WLAN) based on IEEE 802.11 📶

1.3. Rationale for CDN Interconnection 💜

Okay, why do we even use CDNs? Because they can:

  • improve the experience for the End User 🥹. Delivery gets lower latency (less round-trip-time and more throughput between the user and the delivery server) and better robustness (the ability to use multiple delivery servers) ⚡
  • reduce the network operator's costs 💰. For example, delivery is cheaper (less bandwidth usage) for content that can be cached 🧃
  • reduce the Content Service Provider's (CSP) internal infrastructure costs 🏢. Think data center capacity, space, and electricity consumption, because popular content gets delivered externally through the CDN instead of the CSP's own servers 🔌

Honestly, lots of Network Service Providers (NSPs) and Enterprise Service Providers are building or already have their own CDNs 🏗️. The catch is that interconnecting CDNs would be amazing, but today each CDN is its own stand-alone network 🙈. The goal of CDN Interconnection is to fix that, so the interconnected CDNs should be able to act together as one single delivery infrastructure 🤝

Here's an example in Figure 1 🎀. Two CDN Providers set up a CDN Interconnection. Content Service Provider CSP-1 makes a deal with CDN Provider 'A' to deliver its content. Separately, CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs 🫶

When a User Agent asks for content from CSP-1, CDN-A might decide that delivery by CDN-B makes more sense. For instance, that could be because CDN-B is an Access CDN and the user is directly attached to it 🧚. Thanks to the CDN Interconnection setup between CDN-A and CDN-B (which comes from the agreement between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request to CDN-B, and CDN-B is the one that actually delivers the content to the User Agent 🚀

The End User wins here with a better Quality of Experience (QoE, see [RFC6390]), because the content comes from a nearby Surrogate, so latency drops and bottlenecks get avoided 🥳. CDN Provider 'A' benefits because it doesn't have to build out such a massive CDN, and CDN Provider 'B' may get some compensation for the delivery 💸. CSP-1 also benefits, because it only needs one business agreement and one technical arrangement with CDN Provider 'A'. Its End Users still get a service quality as if CSP-1 had gone through the trouble of making a business agreement and technical arrangement with CDN Provider 'B' too 👑

    +-------+ +-------+
    | CSP-1 | | CSP-2 |
    +-------+ +-------+
        |         |
       ,--,--,--./            ,--,--,--.
    ,-'          `-.       ,-'          `-.
   (CDN Provider 'A')=====(CDN Provider 'B')
    `-.  (CDN-A) ,-'       `-. (CDN-B)  ,-'
       `--'--'--'             `--'--'--'
                                  |
                            +----------+
                            | End User |
                            +----------+
    === CDN Interconnection

Figure 1 📸

To extend the example, there's another Content Service Provider, CSP-2, who might also make a deal with CDN Provider 'A'. But CSP-2 might not want its content distributed by CDN Provider 'B'. For example, CSP-2 may not want its content delivered in the area where CDN Provider 'B' operates 🙅‍♀️. This shows that policy considerations are a big part of CDNI 💅

2. Footprint Extension Use Cases 🌍

Okay, the footprint extension is expected to be a major use case for CDN Interconnection 🦋

2.1. Geographic Extension 🌍

okay so in this use case, the CDN Provider wants to stretch its geographic reach for its CSPs 💅 and it wants to do that:

  • without compromising the quality of delivery. 💖
  • without incurring additional transit and other network costs that would result from serving content from geographically or topologically remote Surrogates. 💸
  • without incurring the cost of deploying and operating Surrogates and the associated CDN infrastructure that may not be justified in the corresponding geographic region (e.g., because of relatively low delivery volume, or conversely because of the high investments that would be needed to satisfy the high volume). 🙈

if there are several CDN Providers that have a geographically limited footprint (e.g., restricted to one country), or that don't serve all End Users in a geographic area, then interconnecting their CDNs lets these CDN Providers provide their services beyond their own footprint. it's giving teamwork 🫶

as an example, suppose a French CSP wants to distribute its TV programs to End Users located in France and various countries in North Africa. 📺 it asks a French CDN Provider to deliver the content. the French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. overall, from the CSP's perspective, the French CDN Provider provides a CDN service for both France and North Africa. ✨ main character energy for that French CDN Provider, honestly 👑

in addition to video, this use case applies to other types of content such as automatic software updates (browser updates, operating system patches, virus database update, etc.). 🧚

2.2. Inter-Affiliates Interconnection 🎀

okay the previous section describes the case of geographic extension between CDNs operated by different entities. 💜 a large CDN Provider may have several subsidiaries that each operate their own CDN (which may rely on different CDN technologies, see Section 4.2). in certain circumstances, the CDN Provider needs to make these CDNs interoperate so they can give its customers consistent service across the whole collective footprint. 🦋

2.3. ISP Handling of Third-Party Content 🌈

picture this: an ISP is carrying a lot of content to its subscribers that comes from a third-party CSP and gets injected into the ISP's network by an Authoritative CDN Provider. 📡 there are mutual benefits to the ISP (acting as an Access CDN), the Authoritative CDN, and the CSP that would make a case for establishing a CDNI agreement. for example:

  • allowing the CSP to offer improved QoE and QoE services to subscribers, for example, reduced content startup time or increased video quality and resolution of adaptive streaming content. 🔥
  • allowing the Authoritative CDN to reduce hardware capacity and footprint, by using the ISP caching and delivery capacity. 📉
  • allowing the ISP to reduce traffic load on some segments of the network by caching inside of the ISP network. 🧠
  • allowing the ISP to influence and/or control the traffic ingress points. 🚦
  • allowing the ISP to derive some incremental revenue for transport of the traffic and to monetize QoE services. 💰

2.4. Nomadic Users 🧳

in this scenario, a CSP wants to let End Users who move between access networks keep accessing their content. 🏃‍♀️ the motivation here is to let nomadic End Users maintain access to content with a consistent QoE across a range of devices and/or geographic regions. 💖

this use case covers situations like:

  • End Users moving between different access networks, which may be located within the same geographic region or different geographic regions. 🗺️
  • End Users switching between different devices or delivery technologies, as discussed in Section 4. 📱

okay, consider the following example, illustrated in Figure 2: End User A has a subscription to a broadband service from ISP A, her "home ISP". ISP A hosts CDN-A. ordinarily, when End User A accesses content via ISP A (her "home ISP"), the content is delivered from CDN-A, which in this example is within ISP A's network. 🏡

however, while End User A is not connected to ISP A's network, for example, because she is connected to a WiFi provider or mobile network, End User A can still access the same content. 📶 in this case, End User A may benefit from accessing the same content delivered by an alternate CDN (CDN-B), in this case hosted in the network of the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's network. 🫶

    +-------+
    |Content|
    +-------+
        |
    ,--,--,--.             ,--,--,--.
 ,-'  ISP A   `-.       ,-'  ISP B   `-.
(    (CDN-A)     )=====(    (CDN-B)     )
 `-.          ,-'       `-.          ,-'
    `--'--'--'             `--'--'--'
         |                     |
   +------------+      +---------------+
   + EU A (home)|      | EU A (nomadic)|
   +------------+      +---------------+
 === CDN Interconnection

                              Figure 2

even though the content of CSP A isn't accessible to typical End Users of CDN-B, End User A is able to get to her "home" content (i.e., the content of CSP A) through the alternate CDN (CDN-B). 🥰

depending on the CSP's content delivery policies (see Appendix A.1), a user moving to a different geographic region may be subject to geo-blocking content delivery restrictions. 🚫 in this case, he/she may not be allowed to access some pieces of content. 🙃

3. Offload Use Cases 🌊

3.1. Overload Handling and Dimensioning 📈

a CDN is likely to be dimensioned to support an expected maximum traffic load. 🧮 however, unexpected spikes in content popularity (flash crowd) may push load beyond the expected peak. 😱 the prime recurrent time peaks of content distribution may differ between two CDNs. taking advantage of those different traffic peak times, a CDN may interconnect with another CDN to increase its effective capacity during the peak of traffic. 🙌 this brings dimensioning savings to the CDNs, since they can use each other's resources during their respective peaks of activity. 💅

offload also applies to planned situations in which a CDN Provider needs CDN capacity in a particular region for a short period of time. 🗓️ for example, a CDN can offload traffic to another CDN for the duration of a specific maintenance operation or for the distribution of a special event, as in the scenario depicted in Figure 3. imagine a TV channel that is the distributor for a major event, such as a celebrity's wedding or a major sport competition, and this TV channel has contracted particular CDNs for the delivery. 💍🏆 the CDNs (CDN-A and CDN-B) that the TV channel uses for delivering the content related to this event are likely to experience a flash crowd during the event and will need to offload traffic, while other CDNs (CDN-C) will support a more typical traffic load and be able to handle the offloaded traffic. 🦸‍♀️

in this use case, the Delivering CDN that requests are offloaded to should be able to handle the offloaded requests. 💪 therefore, the uCDN might require information on the dCDNs so it knows how much traffic it can offload to each dCDN. 📊

  +------------+
  | TV Channel |
  +------------+
      |         \
   ,-,--,-.      \ ,-,--,-.        ,-,--,-.
 ,'        `.    ,'        `.    ,' CDN-C  `.
(   CDN-A    )  (   CDN-B    )==(  offload   )
 `.        ,'    `.        ,'    `.        ,'
   `-'--'-'        `-'--'-'        `-'--'-'

 === CDN Interconnection

                              Figure 3

3.2. Resiliency 🛟

3.2.1. Failure of Content Delivery Resources 🔧

it's really important for CDNs to be able to guarantee service continuity during partial failures (e.g., failure of some Surrogates). 🫡 in partial failure scenarios, a CDN Provider has at least three options:

  1. if possible, use internal mechanisms to redirect traffic onto surviving equipment,
  2. depending on traffic management policies, forward some requests to the CSP's origin servers, and/or
  3. redirect some requests toward another CDN, which must be able to serve the redirected requests.

the last option is a use case for CDNI. 🌟

3.2.2. Content Acquisition Resiliency 🪞

source content acquisition may be handled in one of two ways:

  • CSP origin, where a CDN acquires content directly from the CSP's origin server, or
  • CDN origin, where a downstream CDN acquires content from a Surrogate within an upstream CDN. 🔁

the ability to support content acquisition resiliency is an important use case for interconnected CDNs. 💖 when the content acquisition source fails, the CDN might switch to another content acquisition source. similarly, when several content acquisition sources are available, a CDN might balance the load between these multiple sources. ⚖️

though other server and/or DNS load-balancing techniques may be employed in the network, interconnected CDNs may have a better understanding of origin-server availability, and be better equipped both to distribute load between origin servers and to attempt content acquisition from alternate content sources when acquisition failures occur. 🧠✨ when normal content acquisition fails, a CDN may need to try other content source options, for example:

  • an upstream CDN may acquire content from an alternate CSP origin server,
  • a downstream CDN may acquire content from an alternate Surrogate within an upstream CDN,
  • a downstream CDN may acquire content from an alternate upstream CDN, or
  • a downstream CDN may acquire content directly from the CSP's origin server. 🎯

though content acquisition protocols are beyond the scope of CDNI, the selection of content acquisition sources should be considered and facilitated. 🫶

4. Capability Use Cases ✨

4.1. Device and Network Technology Extension ✨

Okay bestie, so here the CDN Provider already has the right geographic footprint 🌍, but it wants to stretch its supported range of devices and User Agents 📱, or the delivery technologies it can handle 🛠️. In that case, a CDN Provider can interconnect with a CDN that offers services that:

  • the CDN Provider is not willing to provide, or
  • its own CDN is not able to support.

Here are some examples, iykyk 💅:

  1. CDN-A can't support a specific delivery protocol, and that's a whole mood 😭. For instance, CDN-A can interconnect with CDN-B to serve the part of its traffic that needs HTTPS [RFC2818]. CDN-A can use CDN-B's footprint (which might overlap with its own) to deliver HTTPS without having to build its own infrastructure 🏗️. This could also be true for other formats, delivery protocols (e.g., the Real Time Messaging Protocol (RTMP), the Real Time Streaming Protocol (RTSP), etc.), and features (specific forms of authorization such as tokens, per session encryption, etc.) ✨.
  2. CDN-A has a footprint covering traditional fixed-line broadband and wants to extend its coverage to mobile devices 📱🦋. In this case, CDN-A can contract and interconnect with CDN-B, who has both:
    • a physical footprint inside the mobile network,
    • the ability to deliver content over a protocol that is required by specific mobile devices.
  3. CDN-A only supports IPv4 within its infrastructure, but it wants to deliver content over IPv6 🌐. CDN-B supports both IPv4 and IPv6 within its infrastructure. CDN-A interconnects with CDN-B to serve its content over native IPv6 connections 💜.

These cases can apply to lots of CDN features that a given CDN Provider may not be able to support, or isn't willing to invest in, so it would delegate those to another CDN. Main character delegation energy 👑.

4.2. Technology and Vendor Interoperability

A CDN Provider can deploy a new CDN to run alongside its existing one, which is a simple way to migrate its CDN service to a new technology 🚀. A CDN Provider can also have a multi-vendor strategy for its CDN deployment 🧩. And finally, a CDN Provider might want a separate CDN for a particular CSP or a specific network 🎀. In all of these situations, CDNI is a win for the CDN Provider, because it simplifies or automates some inter-CDN operations (e.g., progressively migrating the request routing function) 🙌.

4.3. QoE and QoS Improvement

Some CSPs are happy to pay a premium for enhanced delivery of content to their End Users 💰. Sometimes, even if the CDN Provider could deliver the content to the End Users, it still wouldn't meet the CSP's service-level requirements 😬. So the CDN Provider can set up a CDN Interconnection agreement with another CDN Provider that can deliver the expected QoE to the End User 💖, e.g., through an Access CDN that can deliver content from Surrogates located closer to the End User and with the required service level 🏃‍♀️💨.

5. Enforcement of Content Delivery Policy

One big thing that all of the above use cases have in common is that CSPs usually want to enforce content delivery policies 🔒. A CSP may want to define content delivery policies that specify when, how, and/or to whom the CDN delivers content ⏰. These policies apply to all interconnected CDNs (uCDNs and dCDNs) in the same or a similar way that a CSP can define policies for content delivered by a single, non-interconnected CDN 🫶. Appendix A has examples of CSP-defined policies 📖.

6. Acknowledgments

The authors want to thank Kent Leung, Francois Le Faucheur, Ben Niven-Jenkins, and Scott Wainner for the lively discussions 🗣️✨, as well as for their reviews and comments on the mailing list 💌.

They also thank the contributors of the EU FP7 OCEAN and ETICS projects for their valuable inputs 🌸.

Finally, the authors acknowledge the work of the former CDI working group 🫡. This document obsoletes [RFC3570] to avoid confusion 🧹.

7. Security Considerations

🚨 This document focuses on the motivational use cases for CDN Interconnection and does not analyze the associated threats. Those threats are discussed in [RFC6707]. Appendix A.2 of this document provides example security policies that CSPs might impose on CDNs to mitigate the threats. Don't skip these, bestie, they're serious 💀🔐.

8. References

8.1. Normative References

[RFC6707]   Niven-Jenkins, B., Le Faucheur, F., and N. Bitar,
            "Content Distribution Network Interconnection (CDNI)
            Problem Statement", RFC 6707, September 2012.

8.2. Informative References

[CDNI-REQ]  Leung, K. and Y. Lee, "Content Distribution Network
            Interconnection (CDNI) Requirements", Work in Progress,
            June 2012.

[RFC2818]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC3570]   Rzewski, P., Day, M., and D. Gilletti, "Content
            Internetworking (CDI) Scenarios", RFC 3570, July 2003.

[RFC6390]   Clark, A. and B. Claise, "Guidelines for Considering New
            Performance Metric Development", BCP 170, RFC 6390,
            October 2011.

Appendix A. Content Service Providers' Delivery Policies ✨

CSPs usually apply different delivery policies to different sets of content assets delivered through CDNs 🎬. Interconnected CDNs need to support these policies 💪. This appendix shows examples of CSPs' delivery policies and what they mean for CDNI operations 🧠.

A.1. Content Delivery Policy Enforcement

The content distribution policies a CSP attaches to a content asset can depend on a lot of criteria 🎯. For example, distribution policies for audiovisual content often mix constraints of varying complexity and sophistication, like:

  • temporal constraints (e.g., available for 24 hours, available 28 days after DVD release, etc.),
  • user agent platform constraints (e.g., mobile device platforms, desktop computer platforms, set-top-box platforms, etc.),
  • resolution-based constraints (e.g., high definition vs. standard definition encodings),
  • user agent identification or authorization,
  • access network constraints (e.g., per NSP), and
  • IP geo-blocking constraints (e.g., for a given coverage area).

CSPs can use sophisticated policies that match their business model 💼. But enforcing those policies doesn't necessarily require the delivery network to understand the reasoning behind them, or how they apply to specific content assets 🤷‍♀️. Content delivery policies can be distilled into simple rules that can be enforced across all dCDNs in a common way ✂️. These rules can influence dCDN delegation and Surrogate selection decisions, for instance, to make sure that rules like time-window, geo-blocking, or pre-authorization validation can actually be enforced by the Delivering CDN 🕵️‍♀️. In turn, this guarantees to the CSP that its content delivery policies are properly applied 🫶✅.

   +-----+
   | CSP |  Policies driven by business (e.g., available only
   +-----+  in the UK and only from July 1st to September 1st)
      \
       \ Translate policies into
        \simple rules (e.g., provide an authorization token)
         \
          V
        +-----+
        | CDN | Apply simple rules (e.g., check an
        +-----+ authorization token and enforce geo-blocking)
            \
             \ Distribute simple rules
              V
            +-----+
            | CDN | Apply simple rules
            +-----+

                                 Figure 4

A.2. Secure Access

Lots of protocols exist for delivering content to End Users 📡. CSPs may dictate a specific protocol, or a set of protocols, that is acceptable for delivering their content 🔐. This is especially true when secured content transmission is required (e.g., must use HTTPS) 🔒. CSPs may also make a per-request authentication/authorization decision and then have the CDNs enforce that decision (e.g., must validate URL signing, etc.) 🗝️.

A.3. Branding

Keeping the CSP's branding throughout delivery is often really important to the CSP 🎀. CSPs may want to offer content services under their own name, even when the associated CDN service involves other CDN Providers 🏷️. For instance, a CSP may want content delivered with URIs that appear to End Users under the CSP's own domain name, even when separate CDN Providers are involved in delivery 🌈. The CSP may also want to stop its content from being delivered by specific dCDNs that don't support these branding preservation features 🚫.

Similar cases come up when the uCDN wants to offer CDN services under its own branding even when dCDNs are involved. So it restricts the delivery delegation to a chain that keeps its brand visible 👑✨.

Authors' Addresses

Gilles Bertrand (editor)
France Telecom - Orange
38-40 rue du General Leclerc
Issy les Moulineaux,   92130
FR
Phone: +33 1 45 29 89 46
EMail: gilles.bertrand@orange.com

Stephan Emile
France Telecom - Orange
2 avenue Pierre Marzin
Lannion  F-22307
FR
EMail: emile.stephan@orange.com

Trevor Burbridge
BT
B54 Room 70, Adastral Park, Martlesham
Ipswich,   IP5 3RE
UK
EMail: trevor.burbridge@bt.com

Philip Eardley
BT
B54 Room 77, Adastral Park, Martlesham
Ipswich,   IP5 3RE
UK
EMail: philip.eardley@bt.com

Kevin J. Ma
Azuki Systems, Inc.
43 Nagog Park
Acton, MA  01720
USA
Phone: +1 978-844-5100
EMail: kevin.ma@azukisystems.com

Grant Watson
Alcatel-Lucent (Velocix)
3 Ely Road
Milton, Cambridge  CB24 6AA
UK
EMail: gwatson@velocix.com
📦 where this page comes from