idnits 2.17.1 draft-ietf-cdni-use-cases-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2012) is 4329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-00 == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-06 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-03 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Bertrand, Ed. 3 Internet-Draft E. Stephan 4 Obsoletes: 3570 (if approved) France Telecom - Orange 5 Intended status: Informational T. Burbridge 6 Expires: December 20, 2012 P. Eardley 7 BT 8 K. Ma 9 Azuki Systems, Inc. 10 G. Watson 11 Alcatel-Lucent (Velocix) 12 June 18, 2012 14 Use Cases for Content Delivery Network Interconnection 15 draft-ietf-cdni-use-cases-08 17 Abstract 19 Content Delivery Networks (CDNs) are commonly used for improving the 20 End User experience of a content delivery service, at a reasonable 21 cost. This document focuses on use cases that correspond to 22 identified industry needs and that are expected to be realized once 23 open interfaces and protocols supporting interconnection of CDNs are 24 specified and implemented. The document can be used to guide the 25 definition of the requirements to be supported by CDN Interconnection 26 (CDNI) interfaces. It obsoletes RFC 3570. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 20, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 4 66 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6 67 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6 68 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6 69 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7 70 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 73 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2.1. Failure of Content Delivery Resources . . . . . . . . 9 75 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 76 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 10 77 4.1. Device and Network Technology Extension . . . . . . . . . 11 78 4.2. Technology and Vendor Interoperability . . . . . . . . . . 11 79 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 80 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 85 Appendix A. Content Service Providers' Delivery Policies . . . . 13 86 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 13 87 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 88 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 Content Delivery Networks (CDNs) are commonly used for improving the 94 End User experience of a content delivery service, at a reasonable 95 cost. This document focuses on use cases that correspond to 96 identified industry needs and that are expected to be realized once 97 open interfaces and protocols supporting interconnection of CDNs are 98 specified and implemented. The document can be used to guide the 99 definition of the requirements (as documented in 100 [I-D.ietf-cdni-requirements]) to be supported by the set of CDN 101 Interconnection (CDNI) interfaces defined in 102 [I-D.ietf-cdni-problem-statement]. 104 RFC 3570 described slightly different terminologies and models for 105 "Content Internetworking (CDI)". The present document obsoletes RFC 106 3570 to avoid confusion. 108 This document identifies the main motivations for a CDN Provider to 109 interconnect its CDN: 111 o CDN Footprint Extension Use Cases (Section 2) 113 o CDN Offload Use Cases (Section 3) 115 o CDN Capability Use Cases (Section 4) 117 Then, the document highlights the need for interoperability in order 118 to exchange and enforce content delivery policies (Section 5). 120 1.1. Terminology 122 We adopt the terminology described in 123 [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-framework]. 125 We extend this terminology with the following terms. 127 Access CDN: 129 A CDN that includes Surrogates in the same administrative network as 130 the end-user. Such CDN can use accurate information on the End 131 User's network context to provide valued-added Content Delivery 132 Services to Content Service Providers. 134 1.2. Abbreviations 136 o CDN: Content Delivery Network also known as Content Distribution 137 Network 139 o CSP: Content Service Provider 141 o dCDN: downstream CDN 143 o DNS: Domain Name System 145 o DRM: Digital Rights Management 147 o EU: End User 149 o ISP: Internet Service Provider 151 o NSP: Network Service Provider 153 o QoE: Quality of Experience 155 o QoS: Quality of Service 157 o uCDN: upstream CDN 159 o URL: Uniform Resource Locator 161 o WiFi: Wireless Fidelity 163 1.3. Rationale for Multi-CDN Systems 165 Content Delivery Networks (CDNs) are used to deliver content because 166 they can: 168 o improve the experience for the End User; for instance delivery has 169 lower latency (decreased round-trip-time and higher throughput 170 between the user and the delivery server) and better robustness 171 (ability to use multiple delivery servers), 173 o reduce the network operator's costs; for instance, lower delivery 174 cost (reduced bandwidth usage) for cacheable content, 176 o reduce the Content Service Provider's (CSP) internal costs, such 177 as datacenter capacity, space, and electricity consumption, as 178 popular content is delivered externally through the CDN rather 179 than through the CSP's own servers. 181 Indeed, many Network Service Providers (NSPs) and enterprise service 182 providers are deploying or have deployed their own CDNs. Despite the 183 potential benefits of interconnecting CDNs, today each CDN is a 184 standalone network. The objective of CDN Interconnection is to 185 overcome this restriction: the interconnected CDNs should be able to 186 collectively behave as a single delivery infrastructure. 188 An example is depicted in Figure 1, where two CDN Providers establish 189 a CDN Interconnection. The Content Service Provider CSP-1 reaches an 190 agreement with CDN Provider 'A' for the delivery of its content. 191 Independently, CDN Provider 'A' and CDN Provider 'B' agree to 192 interconnect their CDNs. 194 When a given User Agent requests content from CSP-1, CDN-A may 195 consider that delivery by CDN-B is appropriate, for instance, because 196 CDN-B is an Access CDN and the user is directly attached to it. 197 Through the CDN Interconnection arrangements put in place between 198 CDN-A and CDN-B (as a result of the CDN Interconnection agreement 199 established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can 200 redirect the request to CDN-B and the content is actually delivered 201 to the User Agent by CDN-B. 203 The End User benefits from this arrangement through a better Quality 204 of Experience (QoE), because the content is delivered from a nearby 205 Surrogate. CDN Provider 'A' benefits because it does not need to 206 deploy such an extensive CDN, whilst CDN Provider 'B' may receive 207 some compensation for the delivery. CSP-1 benefits because it only 208 needs to make one business agreement and one technical arrangement 209 with CDN Provider 'A', but its End Users get a service quality as 210 though CSP-1 had also gone to the trouble of making a business 211 agreement and technical arrangement with CDN Provider 'B'. 213 +-------+ +-------+ 214 | CSP-1 | | CSP-2 | 215 +-------+ +-------+ 216 | | 217 ,--,--,--./ ,--,--,--. 218 ,-' `-. ,-' `-. 219 (CDN Provider 'A')=====(CDN Provider 'B') 220 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 221 `--'--'--' `--'--'--' 222 | 223 +------------+ 224 | User Agent | 225 +------------+ 226 === CDN Interconnection 228 Figure 1 230 To extend the example, another Content Service Provider, CSP-2, may 231 also reach an agreement with CDN Provider 'A'. However, CSP-2 may 232 not want its content to be distributed by CDN Provider B; for 233 example, CSP-2 may not have distribution rights in the country where 234 CDN Provider 'B' operates. This example illustrates that policy 235 considerations are an important part of CDNI. 237 2. Footprint Extension Use Cases 239 Footprint extension is expected to be a major use case for CDN 240 Interconnection. 242 2.1. Geographic Extension 244 In this use case, the CDN Provider wants to extend the geographic 245 distribution that it can offer to its CSPs: 247 o without compromising the quality of delivery, 249 o without incurring additional transit and other network costs that 250 would result from serving content from geographically or 251 topologically remote Surrogates, 253 o without incurring the cost of deploying and operating Surrogates 254 and the associated CDN infrastructure that may not be justified in 255 the corresponding geographic region (e.g., because of relatively 256 low delivery volume, or conversely because of the high investments 257 that would be needed to satisfy the high volume). 259 If there are several CDN Providers that have a geographically limited 260 footprint (e.g., restricted to one country), or do not serve all End 261 Users in a geographic area, then interconnecting their CDNs enables 262 these CDN Providers to provide their services beyond their own 263 footprint. 265 As an example, suppose a French CSP wants to distribute its TV 266 programs to End Users located in France and various countries in 267 North Africa. It asks a French CDN Provider to deliver the content. 268 The French CDN Provider's network only covers France, so it makes an 269 agreement with another CDN Provider that covers North Africa. 270 Overall, from the CSP's perspective the French CDN Provider provides 271 a CDN service for both France and North Africa. 273 In addition to video, this use case applies to other types of content 274 such as automatic software updates (browser updates, operating system 275 patches, virus database update, etc). 277 2.2. Inter-Affiliates Interconnection 279 The previous section describes the case of geographic extension 280 between CDNs operated by different entities. A large CDN Provider 281 may have several subsidiaries that also each operate their own CDN 282 (which may rely on different CDN technologies, see Section 4.2). In 283 certain circumstances, the CDN Provider needs to make these CDNs 284 interoperate to provide a consistent service to its customers on the 285 whole collective footprint. 287 2.3. ISP Handling of Third-Party Content 289 Consider an ISP carrying to its subscribers a lot of content that 290 comes from a third party CSP and that is injected into the ISP's 291 network by an Authoritative CDN Provider. There are mutual benefits 292 to the ISP (acting as an Access CDN), the Authoritative CDN, and the 293 CSP that would make a case for establishing a CDNI agreement. For 294 example: 296 o Allow the CSP to offer improved QoE and QoE services to 297 subscribers, for example, reduced content startup time or 298 increased video quality and resolution of adaptive streaming 299 content. 301 o Allow the Authoritative CDN to reduce hardware capacity and 302 footprint, by using the ISP caching and delivery capacity. 304 o Allow the ISP to reduce traffic load on some segments of the 305 network by caching inside of the ISP network. 307 o Allow the ISP to influence and/or control the traffic ingestion 308 points. 310 o Allow the ISP to derive some incremental revenue for transport of 311 the traffic and to monetize QoE services. 313 2.4. Nomadic Users 315 In this scenario, a CSP wishes to allow End Users who move between 316 access networks to continue to access their content. The motivation 317 of this case is to allow nomadic End Users to maintain access to 318 content with a consistent QoE, across a range of devices and/or 319 geographic regions. 321 This use case covers situations like: 323 o End Users moving between different access networks, which may be 324 located within the same geographic region or different geographic 325 regions, 327 o End Users switching between different devices or delivery 328 technologies, as discussed in Section 4. 330 Consider the following example, illustrated in Figure 2: End User A 331 has subscription to a broadband service from NSP A, her "home NSP". 332 NSP A hosts CDN-A. Ordinarily, when End User A accesses content via 333 NSP A (her "home NSP") the content is delivered from CDN-A, which in 334 this example is within NSP A's network. 336 However, while End User A is not connected to NSP A's network, for 337 example, because it is connected to a WiFi provider or mobile 338 network, End User A can also access the same content. In this case, 339 End User A may benefit from accessing the same content but delivered 340 by an alternate CDN (CDN-B), in this case, hosted in the network of 341 the WiFi or mobile provider (NSP B), rather than from CDN-A in NSP 342 A's network. 344 +-------+ 345 |Content| 346 +-------+ 347 | 348 ,--,--,--. ,--,--,--. 349 ,-' NSP A `-. ,-' NSP B `-. 350 ( (CDN-A) )=====( (CDN-B) ) 351 `-. ,-' `-. ,-' 352 `--'--'--' `--'--'--' 353 | | 354 +------------+ +---------------+ 355 + EU A (home)| | EU A (nomadic)| 356 +------------+ +---------------+ 357 === CDN Interconnection 359 Figure 2 361 The alternate CDN (CDN-B) is allowed to distribute the content of CSP 362 A to End User A; however, no other End Users (e.g., End User B) in 363 the region of CDN-B are allowed to retrieve the content unless they 364 too have such an agreement for nomadic access to content. Note that 365 the mechanism on how to enforce that End User A is allowed to 366 retrieve the content but End User B is not, is not part of the 367 discussion in this memo. 369 Depending on CSP's content delivery policies (see Appendix A.1), a 370 user moving to a different geographic region may be subject to geo- 371 blocking content delivery restrictions. In this case, he/she may not 372 be allowed to access some pieces of content. 374 3. Offload Use Cases 376 3.1. Overload Handling and Dimensioning 378 A CDN is likely to be dimensioned to support an expected maximum 379 traffic load. However, unexpected spikes in content popularity 380 (flash crowd) may drive load beyond the expected peak. The prime 381 recurrent time peaks of content distribution may differ between two 382 CDNs. Taking advantage of the different traffic peak times, a CDN 383 may interconnect with another CDN to increase its effective capacity 384 during the peak of traffic. This brings dimensioning savings to the 385 CDNs as they can use the resources of each other during their 386 respective peaks of activity. 388 Offload also applies to planned situations where a CDN Provider needs 389 CDN capacity in a particular region during a short period of time. 390 For example, a CDN can offload traffic to another CDN during a 391 specific maintenance operation or for covering the distribution of a 392 special event. For instance, consider a TV-channel which has 393 exclusive distribution rights on a major event, such as a 394 celebrities' wedding, or a major sport competition. The CDNs that 395 the TV-channel uses for delivering the content related to this event 396 are likely to experience a flash crowd during the event and to need 397 offloading traffic, while other CDNs will support a more usual 398 traffic load and be able to handle the offloaded traffic. 400 In this use case, the Delivering CDN on which requests are offloaded 401 should be able to handle the offloaded requests. Therefore, the uCDN 402 might require information on the dCDNs to be aware of the amount of 403 traffic it can offload to every dCDN. 405 3.2. Resiliency 407 3.2.1. Failure of Content Delivery Resources 409 It is important for CDNs to be able to guarantee service continuity 410 during partial failures (e.g., failure of some Surrogates). In 411 partial failure scenarios, a CDN Provider has at least three options: 413 1. if possible, use internal mechanisms to redirect traffic on 414 surviving equipment, 416 2. depending on traffic management policies, forward some requests 417 to the CSP's origin servers, and 419 3. redirect some requests toward another CDN, which must be able to 420 serve the redirected requests. 422 The last option is a use case for CDNI. 424 3.2.2. Content Acquisition Resiliency 426 Source content acquisition may be handled in one of two ways: 428 o CSP origin, where a CDN acquires content directly from the CSP's 429 origin server, or 431 o CDN origin, where a downstream CDN acquires content from a 432 Surrogate within an upstream CDN. 434 The ability to support content acquisition resiliency, is an 435 important use case for interconnected CDNs. When the content 436 acquisition source fails, the CDN might switch to another content 437 acquisition source. Similarly, when several content acquisition 438 sources are available, a CDN might balance the load between these 439 multiple sources. 441 Though other server and/or DNS load balancing techniques may be 442 employed in the network, interconnected CDNs may have a better 443 understanding of origin server availability and be better equipped to 444 both distribute load between origin servers and attempt content 445 acquisition from alternate content sources when acquisition failures 446 occur. When normal content acquisition fails, a CDN may need to try 447 other content source options, e.g.: 449 o an upstream CDN may acquire content from an alternate CSP origin 450 server, 452 o a downstream CDN may acquire content from an alternate Surrogate 453 within an upstream CDN, 455 o a downstream CDN may acquire content from an alternate upstream 456 CDN, or 458 o a downstream CDN may acquire content directly from the CSP's 459 origin server. 461 Though content acquisition protocols are beyond the scope of CDNI, 462 the selection of content acquisition sources should be considered and 463 facilitated. 465 4. CDN Capability Use Cases 466 4.1. Device and Network Technology Extension 468 In this use case, the CDN Provider may have the right geographic 469 footprint, but may wish to extend the supported range of devices and 470 User Agents or the supported range of delivery technologies. In this 471 case, a CDN Provider may interconnect with a CDN that offers 472 services: 474 o that the CDN Provider is not willing to provide or, 476 o that its own CDN is not able to support. 478 The following examples illustrate this use case: 480 1. CDN-A cannot support a specific delivery protocol. For instance, 481 CDN-A may interconnect with CDN-B to serve a proportion of its 482 traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's 483 footprint (which may overlap with its own) to deliver HTTPS 484 without needing to deploy its own infrastructure. This case 485 could also be true of other formats, delivery protocols (RTMP, 486 RTSP, etc.) and features (specific forms of authorization such as 487 tokens, per session encryption, etc.). 489 2. CDN-A has footprint covering traditional fixed line broadband and 490 wants to extend coverage to mobile devices. In this case, CDN-A 491 may contract and interconnect with CDN-B who has both: 493 * physical footprint inside the mobile network, 495 * the ability to deliver content over a protocol that is 496 required by specific mobile devices. 498 These cases can apply to many CDN features that a given CDN Provider 499 may not be able to support or not be willing to invest in, and thus, 500 that the CDN Provider would delegate to another CDN. 502 4.2. Technology and Vendor Interoperability 504 A CDN Provider may deploy a new CDN to run alongside its existing 505 CDN, as a simple way of migrating its CDN service to a new 506 technology. In addition, a CDN Provider may have a multi-vendor 507 strategy for its CDN deployment. Finally, a CDN Provider may want to 508 deploy a separate CDN for a particular CSP or a specific network. In 509 all these circumstances, CDNI benefits the CDN Provider, as it 510 simplifies or automates some inter-CDN operations (e.g., migrating 511 the request routing function progressively). 513 4.3. QoE and QoS Improvement 515 Some CSPs are willing to pay a premium for enhanced delivery of 516 content to their End Users. In some cases, even if the CDN Provider 517 could deliver the content to the End Users, it cannot meet the CSP's 518 service level requirements. As a result, the CDN Provider may 519 establish a CDN Interconnection agreement with another CDN Provider 520 that can provide the expected QoE to the End User, e.g., via an 521 Access CDN able to deliver content from Surrogates located closer to 522 the End User and with the required service level. 524 5. Enforcement of Content Delivery Policy 526 An important aspect common to all the above use cases is that CSPs 527 typically want to enforce content delivery policies. A CSP may want 528 to define content delivery policies that specify when, how, and/or to 529 whom the CDN delivers content. These policies apply to all 530 interconnected CDNs (uCDNs and dCDNs) in the same or similar way that 531 a CSP can define content delivery policies for content delivered by a 532 single, non-interconnected CDN. Appendix A provides examples of CSP 533 defined policies. 535 6. Acknowledgments 537 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 538 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 539 for their reviews and comments on the mailing list. 541 They also thank the contributors of the EU FP7 OCEAN and ETICS 542 projects for valuable inputs. 544 7. IANA Considerations 546 This memo includes no request to IANA. 548 8. Security Considerations 550 This document focuses on the motivational use cases for CDN 551 Interconnection, and does not analyze the associated threats. Those 552 are discussed in [I-D.ietf-cdni-problem-statement]. 554 9. Informative References 556 [I-D.ietf-cdni-framework] 557 Peterson, L. and B. Davie, "Framework for CDN 558 Interconnection", draft-ietf-cdni-framework-00 (work in 559 progress), April 2012. 561 [I-D.ietf-cdni-problem-statement] 562 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 563 Distribution Network Interconnection (CDNI) Problem 564 Statement", draft-ietf-cdni-problem-statement-06 (work in 565 progress), May 2012. 567 [I-D.ietf-cdni-requirements] 568 Leung, K. and Y. Lee, "Content Distribution Network 569 Interconnection (CDNI) Requirements", 570 draft-ietf-cdni-requirements-03 (work in progress), 571 June 2012. 573 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 575 Appendix A. Content Service Providers' Delivery Policies 577 CSPs commonly apply different delivery policies to given sets of 578 content assets delivered through CDNs. Interconnected CDNs need to 579 support these policies. This annex presents examples of CSPs' 580 delivery policies and their consequences on CDNI operations. 582 A.1. Content Delivery Policy Enforcement 584 The content distribution policies that a CSP attaches to a content 585 asset may depend on many criteria. For instance, distribution 586 policies for audiovisual content often combine constraints of varying 587 levels of complexity and sophistication, e.g.: 589 o temporal constraints (e.g., available for 24 hours, available 28 590 days after DVD release, etc.), 592 o user agent platform constraints (e.g., mobile device platforms, 593 desktop computer platforms, set-top-box platforms, etc.), 595 o resolution-based constraints (e.g., high definition vs. standard 596 definition encodings), 598 o user agent identification or authorization, 599 o access network constraints (e.g., per NSP), and 601 o geolocation-based constraints (e.g., per country). 603 CSPs may use sophisticated policies in accordance to their business 604 model. However, the enforcement of those policies does not 605 necessarily require that the delivery network understand the policy 606 rationales or how policies apply to specific content assets. Content 607 delivery policies may indeed be distilled into simple rules which can 608 be commonly enforced across all dCDNs. These rules may influence 609 dCDN delegation and Surrogate selection decisions, for instance, to 610 ensure that the specific rules (e.g. time-window, geo-blocking, pre- 611 authorization validation) can indeed be enforced by the delivering 612 CDN. In turn, this can guarantee to the CSP that content license 613 violations can be prevented, including prevention of premature access 614 to pre-positioned content or enforcement of geo-blocking policies. 616 +-----+ 617 | CSP | Policies driven by business (e.g., available 618 +-----+ only in UK and only from July 1st to September 1st) 619 \ 620 \ Translate policies into 621 \simple rules (e.g., provide an authorization token) 622 \ 623 V 624 +-----+ 625 | CDN | Apply simple rules (e.g., check an 626 +-----+ authorization token and enforce geoblocking) 627 \ 628 \ Distribute simple rules 629 V 630 +-----+ 631 | CDN | Apply simple rules 632 +-----+ 634 Figure 3 636 A.2. Secure Access 638 Many protocols exist for delivering content to End Users. CSPs may 639 dictate a specific protocol or set of protocols which are acceptable 640 for delivery of their content, especially in the case where content 641 protection or user authentication is required (e.g., must use HTTPS). 642 CSPs may also perform per-request authentication/authorization 643 decision and then have the CDNs enforce that decision (e.g., must 644 validate URL signing, etc.). 646 A.3. Branding 648 Preserving the branding of the CSP throughout delivery is often 649 important to the CSP. CSPs may desire to offer content services 650 under their own name, even when the associated CDN service involves 651 other CDN Providers. For instance, a CSP may desire to ensure that 652 content is delivered with URIs appearing to the End Users under the 653 CSP's own domain name, even when the content delivery involves 654 separate CDN Providers. The CSP may wish to prevent the delivery of 655 its content by specific dCDNs that lack support for such branding 656 preservation features. 658 Analogous cases exist when the uCDN wants to offer CDN services under 659 its own branding even if dCDNs are involved. Similarly, a CDN 660 Provider might wish to restrict the delivery delegation to a chain 661 that preserves its brand visibility. 663 Authors' Addresses 665 Gilles Bertrand (editor) 666 France Telecom - Orange 667 38-40 rue du General Leclerc 668 Issy les Moulineaux, 92130 669 FR 671 Phone: +33 1 45 29 89 46 672 Email: gilles.bertrand@orange.com 674 Stephan Emile 675 France Telecom - Orange 676 2 avenue Pierre Marzin 677 Lannion F-22307 678 France 680 Email: emile.stephan@orange.com 682 Trevor Burbridge 683 BT 684 B54 Room 70, Adastral Park, Martlesham 685 Ipswich, IP5 3RE 686 UK 688 Email: trevor.burbridge@bt.com 689 Philip Eardley 690 BT 691 B54 Room 77, Adastral Park, Martlesham 692 Ipswich, IP5 3RE 693 UK 695 Email: philip.eardley@bt.com 697 Kevin J. Ma 698 Azuki Systems, Inc. 699 43 Nagog Park 700 Acton, MA 01720 701 USA 703 Phone: +1 978-844-5100 704 Email: kevin.ma@azukisystems.com 706 Grant Watson 707 Alcatel-Lucent (Velocix) 708 3 Ely Road 709 Milton, Cambridge CB24 6AA 710 UK 712 Email: gwatson@velocix.com