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