idnits 2.17.1 draft-ietf-cdni-use-cases-05.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 (May 23, 2012) is 4356 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 553, but no explicit reference was found in the text == 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-02 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Intended status: Informational France Telecom - Orange 5 Expires: November 24, 2012 T. Burbridge 6 P. Eardley 7 BT 8 K. Ma 9 Azuki Systems, Inc. 10 G. Watson 11 Alcatel-Lucent (Velocix) 12 May 23, 2012 14 Use Cases for Content Delivery Network Interconnection 15 draft-ietf-cdni-use-cases-05 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. 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 November 24, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 10 78 4.2. Technology and Vendor Interoperability . . . . . . . . . . 11 79 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11 80 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Appendix A. Content Service Providers' Delivery Policies . . . . 13 88 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 13 89 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15 90 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 Content Delivery Networks (CDNs) are commonly used for improving the 96 End User experience of a content delivery service, at a reasonable 97 cost. This document focuses on use cases that correspond to 98 identified industry needs and that are expected to be realized once 99 open interfaces and protocols supporting interconnection of CDNs are 100 specified and implemented. The document can be used to guide the 101 definition of the requirements (as documented in 102 [I-D.ietf-cdni-requirements]) to be supported by the set of CDN 103 Interconnection (CDNI) interfaces defined in 104 [I-D.ietf-cdni-problem-statement]. 106 This document identifies the main motivations for a CDN Provider to 107 interconnect its CDN: 109 o CDN Footprint Extension Use Cases (Section 2) 111 o CDN Offload Use Cases (Section 3) 113 o CDN Capability Use Cases (Section 4) 115 Then, the document highlights the need for interoperability in order 116 to exchange and enforce content delivery policies (Section 5). 118 1.1. Terminology 120 We adopt the terminology described in 121 [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], 122 [RFC3466], and [RFC3568]. 124 We extend this terminology with the following terms. 126 Access CDN: 128 A CDN that includes Surrogates in the same administrative network as 129 the end-user. Such CDN can use accurate information on the End 130 User's network context to provide valued-added Content Delivery 131 Services to Content Service Providers. 133 1.2. Abbreviations 135 o CDN: Content Delivery Network also known as Content Distribution 136 Network 138 o CSP: Content Service Provider 139 o dCDN: downstream CDN 141 o DNS: Domain Name System 143 o DRM: Digital Rights Management 145 o EU: End User 147 o ISP: Internet Service Provider 149 o NSP: Network Service Provider 151 o QoE: Quality of Experience 153 o QoS: Quality of Service 155 o uCDN: upstream CDN 157 o URL: Uniform Resource Locator 159 o WiFi: Wireless Fidelity 161 1.3. Rationale for Multi-CDN Systems 163 Content Delivery Networks (CDNs) are used to deliver content because 164 they can: 166 o improve the experience for the End User; for instance delivery has 167 lower latency (decreased round-trip-time and higher throughput 168 between the user and the delivery server) and better robustness 169 (ability to use multiple delivery servers), 171 o reduce the network operator's costs; for instance, lower delivery 172 cost (reduced bandwidth usage) for cacheable content, 174 o reduce the Content Service Provider's (CSP) internal costs, such 175 as datacenter capacity, space, and electricity consumption, as 176 popular content is delivered externally through the CDN rather 177 than through the CSP's own servers. 179 Indeed, many Network Service Providers (NSPs) and enterprise service 180 providers are deploying or have deployed their own CDNs. Despite the 181 potential benefits of interconnecting CDNs, today each CDN is a 182 standalone network. The objective of CDN Interconnection is to 183 overcome this restriction: the interconnected CDNs should be able to 184 collectively behave as a single delivery infrastructure. 186 An example is depicted in Figure 1, where two CDN Providers establish 187 a CDN Interconnection. The Content Service Provider CSP-1 reaches an 188 agreement with CDN Provider 'A' for the delivery of its content. 189 Independently, CDN Provider 'A' and CDN Provider 'B' agree to 190 interconnect their CDNs. 192 When a given User Agent requests content from CSP-1, CDN-A may 193 consider that delivery by CDN-B is appropriate, for instance, because 194 CDN-B is an Access CDN and the user is directly attached to it. 195 Through the CDN Interconnection arrangements put in place between 196 CDN-A and CDN-B (as a result of the CDN Interconnection agreement 197 established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can 198 redirect the request to CDN-B and the content is actually delivered 199 to the User Agent by CDN-B. 201 The End User benefits from this arrangement through a better Quality 202 of Experience (QoE), because the content is delivered from a nearby 203 Surrogate. CDN Provider 'A' benefits because it does not need to 204 deploy such an extensive CDN, whilst CDN Provider 'B' may receive 205 some compensation for the delivery. CSP-1 benefits because it only 206 needs to make one business agreement and one technical arrangement 207 with CDN Provider 'A', but its End Users get a service quality as 208 though CSP-1 had also gone to the trouble of making a business 209 agreement and technical arrangement with CDN Provider 'B'. 211 +-------+ +-------+ 212 | CSP-1 | | CSP-2 | 213 +-------+ +-------+ 214 | | 215 ,--,--,--./ ,--,--,--. 216 ,-' `-. ,-' `-. 217 (CDN Provider 'A')=====(CDN Provider 'B') 218 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 219 `--'--'--' `--'--'--' 220 | 221 +------------+ 222 | User Agent | 223 +------------+ 224 === CDN Interconnection 226 Figure 1 228 To extend the example, another Content Service Provider, CSP-2, may 229 also reach an agreement with CDN Provider 'A'. However, CSP-2 may 230 not want its content to be distributed by CDN Provider B; for 231 example, CSP-2 may not have distribution rights in the country where 232 CDN Provider 'B' operates. This example illustrates that policy 233 considerations are an important part of CDNI. 235 2. Footprint Extension Use Cases 237 Footprint extension is expected to be a major use case for CDN 238 Interconnection. 240 2.1. Geographic Extension 242 In this use case, the CDN Provider wants to extend the geographic 243 distribution that it can offer to its CSPs: 245 o without compromising the quality of delivery, 247 o without incurring additional transit and other network costs that 248 would result from serving content from geographically or 249 topologically remote Surrogates, 251 o without incurring the cost of deploying and operating Surrogates 252 and the associated CDN infrastructure that may not be justified in 253 the corresponding geographic region (e.g., because of relatively 254 low delivery volume, or conversely because of the high investments 255 that would be needed to satisfy the high volume). 257 If there are several CDN Providers that have a geographically limited 258 footprint (e.g., restricted to one country), or do not serve all End 259 Users in a geographic area, then interconnecting their CDNs enables 260 these CDN Providers to provide their services beyond their own 261 footprint. 263 As an example, suppose a French CSP wants to distribute its TV 264 programs to End Users located in France and various countries in 265 North Africa. It asks a French CDN Provider to deliver the content. 266 The French CDN Provider's network only covers France, so it makes an 267 agreement with another CDN Provider that covers North Africa. 268 Overall, from the CSP's perspective the French CDN Provider provides 269 a CDN service for both France and North Africa. 271 In addition to video, this use case applies to other types of content 272 such as automatic software updates (browser updates, operating system 273 patches, virus database update, etc). 275 2.2. Inter-Affiliates Interconnection 277 The previous section describes the case of geographic extension 278 between CDNs operated by different entities. A large CDN Provider 279 may have several subsidiaries that also each operate their own CDN 280 (which may rely on different CDN technologies, see Section 4.2). In 281 certain circumstances, the CDN Provider needs to make these CDNs 282 interoperate to provide a consistent service to its customers on the 283 whole collective footprint. 285 2.3. ISP Handling of Third-Party Content 287 Consider an ISP carrying to its subscribers a lot of content that 288 comes from a third party CSP and that is injected into the ISP's 289 network by an Authoritative CDN Provider. There are mutual benefits 290 to the ISP (acting as an Access CDN), the Authoritative CDN, and the 291 CSP that would make a case for establishing a CDNI agreement. For 292 example: 294 o Allow the CSP to offer improved QoE and QoE services to 295 subscribers, for example, reduced content startup time or 296 increased video quality and resolution of adaptive streaming 297 content. 299 o Allow the Authoritative CDN to reduce hardware capacity and 300 footprint, by using the ISP caching and delivery capacity. 302 o Allow the ISP to reduce traffic load on some segments of the 303 network by caching inside of the ISP network. 305 o Allow the ISP to influence and/or control the traffic ingestion 306 points. 308 o Allow the ISP to derive some incremental revenue for transport of 309 the traffic and to monetize QoE services. 311 2.4. Nomadic Users 313 In this scenario, a CSP wishes to allow End Users who move between 314 access networks to continue to access their content. The motivation 315 of this case is to allow nomadic End Users to maintain access to 316 content with a consistent QoE, across a range of devices and/or 317 geographic regions. 319 This use case covers situations like: 321 o End Users moving between different access networks, which may be 322 located within the same geographic region or different geographic 323 regions, 325 o End Users switching between different devices or delivery 326 technologies, as discussed in Section 4. 328 Consider the following example, illustrated in Figure 2: End User A 329 has subscription to a broadband service from NSP A, her "home NSP". 330 NSP A hosts CDN-A. Ordinarily, when End User A accesses content via 331 NSP A (her "home NSP") the content is delivered from CDN-A, which in 332 this example is within NSP A's network. 334 However, while End User A is not connected to NSP A's network, for 335 example, because it is connected to a WiFi provider or mobile 336 network, End User A can also access the same content. In this case, 337 End User A may benefit from accessing the same content but delivered 338 by an alternate CDN (CDN-B), in this case, hosted in the network of 339 the WiFi or mobile provider (NSP B), rather than from CDN-A in NSP 340 A's network. 342 +-------+ 343 |Content| 344 +-------+ 345 | 346 ,--,--,--. ,--,--,--. 347 ,-' NSP A `-. ,-' NSP B `-. 348 ( (CDN-A) )=====( (CDN-B) ) 349 `-. ,-' `-. ,-' 350 `--'--'--' `--'--'--' 351 | | 352 +------------+ +---------------+ 353 + EU A (home)| | EU A (nomadic)| 354 +------------+ +---------------+ 355 === CDN Interconnection 357 Figure 2 359 The alternate CDN (CDN-B) is allowed to distribute the content of CSP 360 A to End User A; however, no other End Users in the region of CDN-B 361 are allowed to retrieve the content unless they too have such an 362 agreement for nomadic access to content. 364 Depending on CSP's content delivery policies (see Appendix A.1), a 365 user moving to a different geographic region may be subject to geo- 366 blocking content delivery restrictions. In this case, he/she may not 367 be allowed to access some pieces of content. 369 3. Offload Use Cases 370 3.1. Overload Handling and Dimensioning 372 A CDN is likely to be dimensioned to support an expected maximum 373 traffic load. However, unexpected spikes in content popularity 374 (flash crowd) may drive load beyond the expected peak. The prime 375 recurrent time peaks of content distribution may differ between two 376 CDNs. Taking advantage of the different traffic peak times, a CDN 377 may interconnect with another CDN to increase its effective capacity 378 during the peak of traffic. This brings dimensioning savings to the 379 CDNs as they can use the resources of each other during their 380 respective peaks of activity. 382 Offload also applies to planned situations where a CDN Provider needs 383 CDN capacity in a particular region during a short period of time. 384 For example, a CDN can offload traffic to another CDN during a 385 specific maintenance operation or for covering the distribution of a 386 special event. For instance, consider a TV-channel which has 387 exclusive distribution rights on a major event, such as a 388 celebrities' wedding, or a major sport competition. The CDNs that 389 the TV-channel uses for delivering the content related to this event 390 are likely to experience a flash crowd during the event and to need 391 offloading traffic, while other CDNs will support a more usual 392 traffic load and be able to handle the offloaded traffic. 394 In this use case, the Delivering CDN on which requests are offloaded 395 should be able to handle the offloaded requests. Therefore, the uCDN 396 might require information on the dCDNs to be aware of the amount of 397 traffic it can offload to every dCDN. 399 3.2. Resiliency 401 3.2.1. Failure of Content Delivery Resources 403 It is important for CDNs to be able to guarantee service continuity 404 during partial failures (e.g., failure of some Surrogates). In 405 partial failure scenarios, a CDN Provider has at least three options: 407 1. if possible, use internal mechanisms to redirect traffic on 408 surviving equipment, 410 2. depending on traffic management policies, forward some requests 411 to the CSP's origin servers, and 413 3. redirect some requests toward another CDN, which must be able to 414 serve the redirected requests. 416 The last option is a use case for CDNI. 418 3.2.2. Content Acquisition Resiliency 420 Source content acquisition may be handled in one of two ways: 422 o CSP origin, where a CDN acquires content directly from the CSP's 423 origin server, or 425 o CDN origin, where a downstream CDN acquires content from a 426 Surrogate within an upstream CDN. 428 The ability to support content acquisition resiliency, is an 429 important use case for interconnected CDNs. When the content 430 acquisition source fails, the CDN might switch to another content 431 acquisition source. Similarly, when several content acquisition 432 sources are available, a CDN might balance the load between these 433 multiple sources. 435 Though other server and/or DNS load balancing techniques may be 436 employed in the network, interconnected CDNs may have a better 437 understanding of origin server availability and be better equipped to 438 both distribute load between origin servers and attempt content 439 acquisition from alternate content sources when acquisition failures 440 occur. When normal content acquisition fails, a CDN may need to try 441 other content source options, e.g.: 443 o an upstream CDN may acquire content from an alternate CSP origin 444 server, 446 o a downstream CDN may acquire content from an alternate Surrogate 447 within an upstream CDN, 449 o a downstream CDN may acquire content from an alternate upstream 450 CDN, or 452 o a downstream CDN may acquire content directly from the CSP's 453 origin server. 455 Though content acquisition protocols are beyond the scope of CDNI, 456 the selection of content acquisition sources should be considered and 457 facilitated. 459 4. CDN Capability Use Cases 461 4.1. Device and Network Technology Extension 463 In this use case, the CDN Provider may have the right geographic 464 footprint, but may wish to extend the supported range of devices and 465 User Agents or the supported range of delivery technologies. In this 466 case, a CDN Provider may interconnect with a CDN that offers 467 services: 469 o that the CDN Provider is not willing to provide or, 471 o that its own CDN is not able to support. 473 The following examples illustrate this use case: 475 1. CDN-A cannot support a specific delivery protocol. For instance, 476 CDN-A may interconnect with CDN-B to serve a proportion of its 477 traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's 478 footprint (which may overlap with its own) to deliver HTTPS 479 without needing to deploy its own infrastructure. This case 480 could also be true of other formats, delivery protocols (RTMP, 481 RTSP, etc.) and features (specific forms of authorization such as 482 tokens, per session encryption, etc.). 484 2. CDN-A has footprint covering traditional fixed line broadband and 485 wants to extend coverage to mobile devices. In this case, CDN-A 486 may contract and interconnect with CDN-B who has both: 488 * physical footprint inside the mobile network, 490 * the ability to deliver content over a protocol that is 491 required by specific mobile devices. 493 These cases can apply to many CDN features that a given CDN Provider 494 may not be able to support or not be willing to invest in, and thus, 495 that the CDN Provider would delegate to another CDN. 497 4.2. Technology and Vendor Interoperability 499 A CDN Provider may deploy a new CDN to run alongside its existing 500 CDN, as a simple way of migrating its CDN service to a new 501 technology. In addition, a CDN Provider may have a multi-vendor 502 strategy for its CDN deployment. Finally, a CDN Provider may want to 503 deploy a separate CDN for a particular CSP or a specific network. In 504 all these circumstances, CDNI benefits the CDN Provider, as it 505 simplifies or automates some inter-CDN operations (e.g., migrating 506 the request routing function progressively). 508 4.3. QoE and QoS Improvement 510 Some CSPs are willing to pay a premium for enhanced delivery of 511 content to their End Users. In some cases, even if the CDN Provider 512 could deliver the content to the End Users, it cannot meet the CSP's 513 service level requirements. As a result, the CDN Provider may 514 establish a CDN Interconnection agreement with another CDN Provider 515 that can provide the expected QoE to the End User, e.g., via an 516 Access CDN able to deliver content from Surrogates located closer to 517 the End User and with the required service level. 519 5. Enforcement of Content Delivery Policy 521 An important aspect common to all the above use cases is that CSPs 522 typically want to enforce content delivery policies. A CSP may want 523 to define content delivery policies that specify when, how, and/or to 524 whom the CDN delivers content. These policies apply to all 525 interconnected CDNs (uCDNs and dCDNs) in the same or similar way that 526 a CSP can define content delivery policies for content delivered by a 527 single, non-interconnected CDN. Appendix A provides examples of CSP 528 defined policies. 530 6. Acknowledgments 532 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 533 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 534 for their reviews and comments on the mailing list. 536 They also thank the contributors of the EU FP7 OCEAN and ETICS 537 projects for valuable inputs. 539 7. IANA Considerations 541 This memo includes no request to IANA. 543 8. Security Considerations 545 This document focuses on the motivational use cases for CDN 546 Interconnection, and does not analyze the associated threats. Those 547 are discussed in [I-D.ietf-cdni-problem-statement]. 549 9. References 551 9.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 9.2. Informative References 558 [I-D.davie-cdni-framework] 559 Davie, B. and L. Peterson, "Framework for CDN 560 Interconnection", draft-davie-cdni-framework-01 (work in 561 progress), October 2011. 563 [I-D.ietf-cdni-problem-statement] 564 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 565 Distribution Network Interconnection (CDNI) Problem 566 Statement", draft-ietf-cdni-problem-statement-06 (work in 567 progress), May 2012. 569 [I-D.ietf-cdni-requirements] 570 Leung, K. and Y. Lee, "Content Distribution Network 571 Interconnection (CDNI) Requirements", 572 draft-ietf-cdni-requirements-02 (work in progress), 573 December 2011. 575 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 577 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 578 for Content Internetworking (CDI)", RFC 3466, 579 February 2003. 581 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 582 Content Network (CN) Request-Routing Mechanisms", 583 RFC 3568, July 2003. 585 Appendix A. Content Service Providers' Delivery Policies 587 CSPs commonly apply different delivery policies to given sets of 588 content assets delivered through CDNs. Interconnected CDNs need to 589 support these policies. This annex presents examples of CSPs' 590 delivery policies and their consequences on CDNI operations. 592 A.1. Content Delivery Policy Enforcement 594 The content distribution policies that a CSP attaches to a content 595 asset may depend on many criteria. For instance, distribution 596 policies for audiovisual content often combine constraints of varying 597 levels of complexity and sophistication, e.g.: 599 o temporal constraints (e.g., available for 24 hours, available 28 600 days after DVD release, etc.), 602 o user agent platform constraints (e.g., mobile device platforms, 603 desktop computer platforms, set-top-box platforms, etc.), 605 o resolution-based constraints (e.g., high definition vs. standard 606 definition encodings), 608 o user agent identification or authorization, 610 o access network constraints (e.g., per NSP), and 612 o geolocation-based constraints (e.g., per country). 614 CSPs may use sophisticated policies in accordance to their business 615 model. However, the enforcement of those policies does not 616 necessarily require that the delivery network understand the policy 617 rationales or how policies apply to specific content assets. Content 618 delivery policies may indeed be distilled into simple rules which can 619 be commonly enforced across all dCDNs. These rules may influence 620 dCDN delegation and Surrogate selection decisions, for instance, to 621 ensure that the specific rules (e.g. time-window, geo-blocking, pre- 622 authorization validation) can indeed be enforced by the delivering 623 CDN. In turn, this can guarantee to the CSP that content license 624 violations can be prevented, including prevention of premature access 625 to pre-positioned content or enforcement of geo-blocking policies. 627 +-----+ 628 | CSP | Policies driven by business (e.g., available 629 +-----+ only in UK and only from July 1st to September 1st) 630 \ 631 \ Translate policies into 632 \simple rules (e.g., provide an authorization token) 633 \ 634 V 635 +-----+ 636 | CDN | Apply simple rules (e.g., check an 637 +-----+ authorization token and enforce geoblocking) 638 \ 639 \ Distribute simple rules 640 V 641 +-----+ 642 | CDN | Apply simple rules 643 +-----+ 645 Figure 3 647 A.2. Secure Access 649 Many protocols exist for delivering content to End Users. CSPs may 650 dictate a specific protocol or set of protocols which are acceptable 651 for delivery of their content, especially in the case where content 652 protection or user authentication is required (e.g., must use HTTPS). 653 CSPs may also perform per-request authentication/authorization 654 decision and then have the CDNs enforce that decision (e.g., must 655 validate URL signing, etc.). 657 A.3. Branding 659 Preserving the branding of the CSP throughout delivery is often 660 important to the CSP. CSPs may desire to offer content services 661 under their own name, even when the associated CDN service involves 662 other CDN Providers. For instance, a CSP may desire to ensure that 663 content is delivered with URIs appearing to the End Users under the 664 CSP's own domain name, even when the content delivery involves 665 separate CDN Providers. The CSP may wish to prevent the delivery of 666 its content by specific dCDNs that lack support for such branding 667 preservation features. 669 Analogous cases exist when the uCDN wants to offer CDN services under 670 its own branding even if dCDNs are involved. Similarly, a CDN 671 Provider might wish to restrict the delivery delegation to a chain 672 that preserves its brand visibility. 674 Authors' Addresses 676 Gilles Bertrand (editor) 677 France Telecom - Orange 678 38-40 rue du General Leclerc 679 Issy les Moulineaux, 92130 680 FR 682 Phone: +33 1 45 29 89 46 683 Email: gilles.bertrand@orange.com 685 Stephan Emile 686 France Telecom - Orange 687 2 avenue Pierre Marzin 688 Lannion F-22307 689 France 691 Email: emile.stephan@orange.com 692 Trevor Burbridge 693 BT 694 B54 Room 70, Adastral Park, Martlesham 695 Ipswich, IP5 3RE 696 UK 698 Email: trevor.burbridge@bt.com 700 Philip Eardley 701 BT 702 B54 Room 77, Adastral Park, Martlesham 703 Ipswich, IP5 3RE 704 UK 706 Email: philip.eardley@bt.com 708 Kevin J. Ma 709 Azuki Systems, Inc. 710 43 Nagog Park 711 Acton, MA 01720 712 USA 714 Phone: +1 978-844-5100 715 Email: kevin.ma@azukisystems.com 717 Grant Watson 718 Alcatel-Lucent (Velocix) 719 3 Ely Road 720 Milton, Cambridge CB24 6AA 721 UK 723 Email: gwatson@velocix.com