idnits 2.17.1 draft-ietf-cdni-use-cases-10.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 (August 9, 2012) is 4271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 2 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: February 10, 2013 P. Eardley 7 BT 8 K. Ma 9 Azuki Systems, Inc. 10 G. Watson 11 Alcatel-Lucent (Velocix) 12 August 9, 2012 14 Use Cases for Content Delivery Network Interconnection 15 draft-ietf-cdni-use-cases-10 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 motivate 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 February 10, 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 CDN Interconnection . . . . . . . . . . . . 4 67 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6 68 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6 69 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 76 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 77 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 78 4.1. Device and Network Technology Extension . . . . . . . . . 11 79 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 80 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 81 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Appendix A. Content Service Providers' Delivery Policies . . . . 14 89 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14 90 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15 91 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 Content Delivery Networks (CDNs) are commonly used for improving the 97 End User experience of a content delivery service while keeping cost 98 at a reasonable level. This document focuses on use cases that 99 correspond to identified industry needs and that are expected to be 100 realized once open interfaces and protocols supporting 101 interconnection of CDNs are specified and implemented. The document 102 can be used to motivate the definition of the requirements (as 103 documented in [I-D.ietf-cdni-requirements]) to be supported by the 104 set of CDN Interconnection (CDNI) interfaces defined in 105 [I-D.ietf-cdni-problem-statement]. 107 RFC 3570 described slightly different terminologies and models for 108 "Content Internetworking (CDI)". The present document obsoletes RFC 109 3570 to avoid confusion. 111 This document identifies the main motivations for a CDN Provider to 112 interconnect its CDN: 114 o CDN Footprint Extension Use Cases (Section 2) 116 o CDN Offload Use Cases (Section 3) 118 o CDN Capability Use Cases (Section 4) 120 Then, the document highlights the need for interoperability in order 121 to exchange and enforce content delivery policies (Section 5). 123 1.1. Terminology 125 In this document, the first letter of each CDNI-specific term is 126 capitalized. We adopt the terminology described in 127 [I-D.ietf-cdni-problem-statement]. 129 We extend this terminology with the following terms. 131 Access CDN: 133 A CDN that includes Surrogates in the same administrative network as 134 the end-user. Such CDN can use accurate information on the End 135 User's network context to provide valued-added Content Delivery 136 Services to Content Service Providers. 138 1.2. Abbreviations 139 o CDN: Content Delivery Network also known as Content Distribution 140 Network 142 o CSP: Content Service Provider 144 o dCDN: downstream CDN 146 o DNS: Domain Name System 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 local area network (WLAN) based on IEEE 802.11 164 1.3. Rationale for CDN Interconnection 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 178 infrastructure costs, such as datacenter capacity, space, and 179 electricity consumption, as popular content is delivered 180 externally through the CDN rather than through the CSP's own 181 servers. 183 Indeed, many Network Service Providers (NSPs) and enterprise service 184 providers are deploying or have deployed their own CDNs. Despite the 185 potential benefits of interconnecting CDNs, today each CDN is a 186 standalone network. The objective of CDN Interconnection is to 187 overcome this restriction: the interconnected CDNs should be able to 188 collectively behave as a single delivery infrastructure. 190 An example is depicted in Figure 1, where two CDN Providers establish 191 a CDN Interconnection. The Content Service Provider CSP-1 reaches an 192 agreement with CDN Provider 'A' for the delivery of its content. 193 Independently, CDN Provider 'A' and CDN Provider 'B' agree to 194 interconnect their CDNs. 196 When a given User Agent requests content from CSP-1, CDN-A may 197 consider that delivery by CDN-B is appropriate, for instance, because 198 CDN-B is an Access CDN and the user is directly attached to it. 199 Through the CDN Interconnection arrangements put in place between 200 CDN-A and CDN-B (as a result of the CDN Interconnection agreement 201 established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can 202 redirect the request to CDN-B and the content is actually delivered 203 to the User Agent by CDN-B. 205 The End User benefits from this arrangement through a better Quality 206 of Experience (QoE, see [RFC6390]), because the content is delivered 207 from a nearby Surrogate (e.g., lower latency, bottlenecks avoided). 208 CDN Provider 'A' benefits because it does not need to deploy such an 209 extensive CDN, whilst CDN Provider 'B' may receive some compensation 210 for the delivery. CSP-1 benefits because it only needs to make one 211 business agreement and one technical arrangement with CDN Provider 212 'A', but its End Users get a service quality as though CSP-1 had also 213 gone to the trouble of making a business agreement and technical 214 arrangement with CDN Provider 'B'. 216 +-------+ +-------+ 217 | CSP-1 | | CSP-2 | 218 +-------+ +-------+ 219 | | 220 ,--,--,--./ ,--,--,--. 221 ,-' `-. ,-' `-. 222 (CDN Provider 'A')=====(CDN Provider 'B') 223 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 224 `--'--'--' `--'--'--' 225 | 226 +----------+ 227 | End User | 228 +----------+ 229 === CDN Interconnection 231 Figure 1 233 To extend the example, another Content Service Provider, CSP-2, may 234 also reach an agreement with CDN Provider 'A'. However, CSP-2 may 235 not want its content to be distributed by CDN Provider B; for 236 example, CSP-2 may not want to distribute its content in the area 237 where CDN Provider 'B' operates. This example illustrates that 238 policy considerations are an important part of CDNI. 240 2. Footprint Extension Use Cases 242 Footprint extension is expected to be a major use case for CDN 243 Interconnection. 245 2.1. Geographic Extension 247 In this use case, the CDN Provider wants to extend the geographic 248 distribution that it can offer to its CSPs: 250 o without compromising the quality of delivery, 252 o without incurring additional transit and other network costs that 253 would result from serving content from geographically or 254 topologically remote Surrogates, 256 o without incurring the cost of deploying and operating Surrogates 257 and the associated CDN infrastructure that may not be justified in 258 the corresponding geographic region (e.g., because of relatively 259 low delivery volume, or conversely because of the high investments 260 that would be needed to satisfy the high volume). 262 If there are several CDN Providers that have a geographically limited 263 footprint (e.g., restricted to one country), or do not serve all End 264 Users in a geographic area, then interconnecting their CDNs enables 265 these CDN Providers to provide their services beyond their own 266 footprint. 268 As an example, suppose a French CSP wants to distribute its TV 269 programs to End Users located in France and various countries in 270 North Africa. It asks a French CDN Provider to deliver the content. 271 The French CDN Provider's network only covers France, so it makes an 272 agreement with another CDN Provider that covers North Africa. 273 Overall, from the CSP's perspective the French CDN Provider provides 274 a CDN service for both France and North Africa. 276 In addition to video, this use case applies to other types of content 277 such as automatic software updates (browser updates, operating system 278 patches, virus database update, etc). 280 2.2. Inter-Affiliates Interconnection 282 The previous section describes the case of geographic extension 283 between CDNs operated by different entities. A large CDN Provider 284 may have several subsidiaries that also each operate their own CDN 285 (which may rely on different CDN technologies, see Section 4.2). In 286 certain circumstances, the CDN Provider needs to make these CDNs 287 interoperate to provide a consistent service to its customers on the 288 whole collective footprint. 290 2.3. ISP Handling of Third-Party Content 292 Consider an ISP carrying to its subscribers a lot of content that 293 comes from a third party CSP and that is injected into the ISP's 294 network by an Authoritative CDN Provider. There are mutual benefits 295 to the ISP (acting as an Access CDN), the Authoritative CDN, and the 296 CSP that would make a case for establishing a CDNI agreement. For 297 example: 299 o Allow the CSP to offer improved QoE and QoE services to 300 subscribers, for example, reduced content startup time or 301 increased video quality and resolution of adaptive streaming 302 content. 304 o Allow the Authoritative CDN to reduce hardware capacity and 305 footprint, by using the ISP caching and delivery capacity. 307 o Allow the ISP to reduce traffic load on some segments of the 308 network by caching inside of the ISP network. 310 o Allow the ISP to influence and/or control the traffic ingress 311 points. 313 o Allow the ISP to derive some incremental revenue for transport of 314 the traffic and to monetize QoE services. 316 2.4. Nomadic Users 318 In this scenario, a CSP wishes to allow End Users who move between 319 access networks to continue to access their content. The motivation 320 of this case is to allow nomadic End Users to maintain access to 321 content with a consistent QoE, across a range of devices and/or 322 geographic regions. 324 This use case covers situations like: 326 o End Users moving between different access networks, which may be 327 located within the same geographic region or different geographic 328 regions, 330 o End Users switching between different devices or delivery 331 technologies, as discussed in Section 4. 333 Consider the following example, illustrated in Figure 2: End User A 334 has subscription to a broadband service from ISP A, her "home ISP". 335 ISP A hosts CDN-A. Ordinarily, when End User A accesses content via 336 ISP A (her "home ISP") the content is delivered from CDN-A, which in 337 this example is within ISP A's network. 339 However, while End User A is not connected to ISP A's network, for 340 example, because it is connected to a WiFi provider or mobile 341 network, End User A can also access the same content. In this case, 342 End User A may benefit from accessing the same content but delivered 343 by an alternate CDN (CDN-B), in this case, hosted in the network of 344 the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP 345 A's network. 347 +-------+ 348 |Content| 349 +-------+ 350 | 351 ,--,--,--. ,--,--,--. 352 ,-' NSP A `-. ,-' NSP B `-. 353 ( (CDN-A) )=====( (CDN-B) ) 354 `-. ,-' `-. ,-' 355 `--'--'--' `--'--'--' 356 | | 357 +------------+ +---------------+ 358 + EU A (home)| | EU A (nomadic)| 359 +------------+ +---------------+ 360 === CDN Interconnection 362 Figure 2 364 Though the content of CSP A is not accessible by typical End Users of 365 CDN-B, End User A is able to gain access to their "home" content 366 (i.e., the content of CSP A) through the alternate CDN (CDN-B). 368 Depending on CSP's content delivery policies (see Appendix A.1), a 369 user moving to a different geographic region may be subject to geo- 370 blocking content delivery restrictions. In this case, he/she may not 371 be allowed to access some pieces of content. 373 3. Offload Use Cases 375 3.1. Overload Handling and Dimensioning 377 A CDN is likely to be dimensioned to support an expected maximum 378 traffic load. However, unexpected spikes in content popularity 379 (flash crowd) may drive load beyond the expected peak. The prime 380 recurrent time peaks of content distribution may differ between two 381 CDNs. Taking advantage of the different traffic peak times, a CDN 382 may interconnect with another CDN to increase its effective capacity 383 during the peak of traffic. This brings dimensioning savings to the 384 CDNs as they can use the resources of each other during their 385 respective peaks of activity. 387 Offload also applies to planned situations where a CDN Provider needs 388 CDN capacity in a particular region during a short period of time. 389 For example, a CDN can offload traffic to another CDN during a 390 specific maintenance operation or for covering the distribution of a 391 special event, as in the scenario depicted in Figure 3. For 392 instance, consider a TV-channel which is the distributor for a major 393 event, such as a celebrities' wedding, or a major sport competition 394 and this TV-channel has contracted particular CDNs for the delivery. 395 The CDNs (CDN-A and CDN-B) that the TV-channel uses for delivering 396 the content related to this event are likely to experience a flash 397 crowd during the event and to need offloading traffic, while other 398 CDNs (CDN-C) will support a more usual traffic load and be able to 399 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 +------------+ 407 | TV Channel | 408 +------------+ 409 | \ 410 ,-,--,-. \ ,-,--,-. ,-,--,-. 411 ,' `. ,' `. ,' CDN-C `. 412 ( CDN-A ) ( CDN-B )==( offload ) 413 `. ,' `. ,' `. ,' 414 `-'--'-' `-'--'-' `-'--'-' 416 === CDN Interconnection 418 Figure 3 420 3.2. Resiliency 422 3.2.1. Failure of Content Delivery Resources 424 It is important for CDNs to be able to guarantee service continuity 425 during partial failures (e.g., failure of some Surrogates). In 426 partial failure scenarios, a CDN Provider has at least three options: 428 1. if possible, use internal mechanisms to redirect traffic on 429 surviving equipment, 431 2. depending on traffic management policies, forward some requests 432 to the CSP's origin servers, and 434 3. redirect some requests toward another CDN, which must be able to 435 serve the redirected requests. 437 The last option is a use case for CDNI. 439 3.2.2. Content Acquisition Resiliency 441 Source content acquisition may be handled in one of two ways: 443 o CSP origin, where a CDN acquires content directly from the CSP's 444 origin server, or 446 o CDN origin, where a downstream CDN acquires content from a 447 Surrogate within an upstream CDN. 449 The ability to support content acquisition resiliency, is an 450 important use case for interconnected CDNs. When the content 451 acquisition source fails, the CDN might switch to another content 452 acquisition source. Similarly, when several content acquisition 453 sources are available, a CDN might balance the load between these 454 multiple sources. 456 Though other server and/or DNS load balancing techniques may be 457 employed in the network, interconnected CDNs may have a better 458 understanding of origin server availability and be better equipped to 459 both distribute load between origin servers and attempt content 460 acquisition from alternate content sources when acquisition failures 461 occur. When normal content acquisition fails, a CDN may need to try 462 other content source options, e.g.: 464 o an upstream CDN may acquire content from an alternate CSP origin 465 server, 467 o a downstream CDN may acquire content from an alternate Surrogate 468 within an upstream CDN, 470 o a downstream CDN may acquire content from an alternate upstream 471 CDN, or 473 o a downstream CDN may acquire content directly from the CSP's 474 origin server. 476 Though content acquisition protocols are beyond the scope of CDNI, 477 the selection of content acquisition sources should be considered and 478 facilitated. 480 4. CDN Capability Use Cases 482 4.1. Device and Network Technology Extension 484 In this use case, the CDN Provider may have the right geographic 485 footprint, but may wish to extend the supported range of devices and 486 User Agents or the supported range of delivery technologies. In this 487 case, a CDN Provider may interconnect with a CDN that offers 488 services: 490 o that the CDN Provider is not willing to provide or, 492 o that its own CDN is not able to support. 494 The following examples illustrate this use case: 496 1. CDN-A cannot support a specific delivery protocol. For instance, 497 CDN-A may interconnect with CDN-B to serve a proportion of its 498 traffic that requires HTTPS [RFC2818]. CDN-A may use CDN-B's 499 footprint (which may overlap with its own) to deliver HTTPS 500 without needing to deploy its own infrastructure. This case 501 could also be true of other formats, delivery protocols (RTMP, 502 RTSP, etc.) and features (specific forms of authorization such as 503 tokens, per session encryption, etc.). 505 2. CDN-A has footprint covering traditional fixed line broadband and 506 wants to extend coverage to mobile devices. In this case, CDN-A 507 may contract and interconnect with CDN-B who has both: 509 * physical footprint inside the mobile network, 511 * the ability to deliver content over a protocol that is 512 required by specific mobile devices. 514 3. CDN-A only supports IPv4 within its infrastructure but wants to 515 deliver content over IPv6. CDN-B supports both IPv4 and IPv6 516 within its infrastructure. CDN-A interconnects with CDN-B to 517 serve out its content over native IPv6 connections. 519 These cases can apply to many CDN features that a given CDN Provider 520 may not be able to support or not be willing to invest in, and thus, 521 that the CDN Provider would delegate to another CDN. 523 4.2. Technology and Vendor Interoperability 525 A CDN Provider may deploy a new CDN to run alongside its existing 526 CDN, as a simple way of migrating its CDN service to a new 527 technology. In addition, a CDN Provider may have a multi-vendor 528 strategy for its CDN deployment. Finally, a CDN Provider may want to 529 deploy a separate CDN for a particular CSP or a specific network. In 530 all these circumstances, CDNI benefits the CDN Provider, as it 531 simplifies or automates some inter-CDN operations (e.g., migrating 532 the request routing function progressively). 534 4.3. QoE and QoS Improvement 536 Some CSPs are willing to pay a premium for enhanced delivery of 537 content to their End Users. In some cases, even if the CDN Provider 538 could deliver the content to the End Users, it cannot meet the CSP's 539 service level requirements. As a result, the CDN Provider may 540 establish a CDN Interconnection agreement with another CDN Provider 541 that can provide the expected QoE to the End User, e.g., via an 542 Access CDN able to deliver content from Surrogates located closer to 543 the End User and with the required service level. 545 5. Enforcement of Content Delivery Policy 547 An important aspect common to all the above use cases is that CSPs 548 typically want to enforce content delivery policies. A CSP may want 549 to define content delivery policies that specify when, how, and/or to 550 whom the CDN delivers content. These policies apply to all 551 interconnected CDNs (uCDNs and dCDNs) in the same or similar way that 552 a CSP can define content delivery policies for content delivered by a 553 single, non-interconnected CDN. Appendix A provides examples of CSP 554 defined policies. 556 6. Acknowledgments 558 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 559 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 560 for their reviews and comments on the mailing list. 562 They also thank the contributors of the EU FP7 OCEAN and ETICS 563 projects for valuable inputs. 565 Finally, the authors acknowledge the work of the former CDI working 566 group, which is now obsoleted to avoid confusion. 568 7. IANA Considerations 570 This memo includes no request to IANA. 572 8. Security Considerations 574 This document focuses on the motivational use cases for CDN 575 Interconnection, and does not analyze the associated threats. Those 576 are discussed in [I-D.ietf-cdni-problem-statement]. Appendix A.2 577 provides example security policies that CSPs might impose on CDNs to 578 mitigate the threats. 580 9. References 582 9.1. Normative References 584 [I-D.ietf-cdni-problem-statement] 585 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 586 Distribution Network Interconnection (CDNI) Problem 587 Statement", draft-ietf-cdni-problem-statement-08 (work in 588 progress), June 2012. 590 9.2. Informative References 592 [I-D.ietf-cdni-requirements] 593 Leung, K. and Y. Lee, "Content Distribution Network 594 Interconnection (CDNI) Requirements", 595 draft-ietf-cdni-requirements-03 (work in progress), 596 June 2012. 598 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 600 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 601 Performance Metric Development", BCP 170, RFC 6390, 602 October 2011. 604 Appendix A. Content Service Providers' Delivery Policies 606 CSPs commonly apply different delivery policies to given sets of 607 content assets delivered through CDNs. Interconnected CDNs need to 608 support these policies. This annex presents examples of CSPs' 609 delivery policies and their consequences on CDNI operations. 611 A.1. Content Delivery Policy Enforcement 613 The content distribution policies that a CSP attaches to a content 614 asset may depend on many criteria. For instance, distribution 615 policies for audiovisual content often combine constraints of varying 616 levels of complexity and sophistication, e.g.: 618 o temporal constraints (e.g., available for 24 hours, available 28 619 days after DVD release, etc.), 621 o user agent platform constraints (e.g., mobile device platforms, 622 desktop computer platforms, set-top-box platforms, etc.), 624 o resolution-based constraints (e.g., high definition vs. standard 625 definition encodings), 627 o user agent identification or authorization, 629 o access network constraints (e.g., per NSP), and 631 o IP geo-blocking constraints (e.g., for a given coverage area). 633 CSPs may use sophisticated policies in accordance to their business 634 model. However, the enforcement of those policies does not 635 necessarily require that the delivery network understand the policy 636 rationales or how policies apply to specific content assets. Content 637 delivery policies may indeed be distilled into simple rules which can 638 be commonly enforced across all dCDNs. These rules may influence 639 dCDN delegation and Surrogate selection decisions, for instance, to 640 ensure that the specific rules (e.g. time-window, geo-blocking, pre- 641 authorization validation) can indeed be enforced by the delivering 642 CDN. In turn, this can guarantee to the CSP that content delivery 643 policies are properly applied. 645 +-----+ 646 | CSP | Policies driven by business (e.g., available 647 +-----+ only in UK and only from July 1st to September 1st) 648 \ 649 \ Translate policies into 650 \simple rules (e.g., provide an authorization token) 651 \ 652 V 653 +-----+ 654 | CDN | Apply simple rules (e.g., check an 655 +-----+ authorization token and enforce geo-blocking) 656 \ 657 \ Distribute simple rules 658 V 659 +-----+ 660 | CDN | Apply simple rules 661 +-----+ 663 Figure 4 665 A.2. Secure Access 667 Many protocols exist for delivering content to End Users. CSPs may 668 dictate a specific protocol or set of protocols which are acceptable 669 for delivery of their content, especially in the case where a secured 670 content transmission is required (e.g., must use HTTPS). CSPs may 671 also perform per-request authentication/authorization decision and 672 then have the CDNs enforce that decision (e.g., must validate URL 673 signing, etc.). 675 A.3. Branding 677 Preserving the branding of the CSP throughout delivery is often 678 important to the CSP. CSPs may desire to offer content services 679 under their own name, even when the associated CDN service involves 680 other CDN Providers. For instance, a CSP may desire to ensure that 681 content is delivered with URIs appearing to the End Users under the 682 CSP's own domain name, even when the content delivery involves 683 separate CDN Providers. The CSP may wish to prevent the delivery of 684 its content by specific dCDNs that lack support for such branding 685 preservation features. 687 Analogous cases exist when the uCDN wants to offer CDN services under 688 its own branding even if dCDNs are involved. Similarly, a CDN 689 Provider might wish to restrict the delivery delegation to a chain 690 that preserves its brand visibility. 692 Authors' Addresses 694 Gilles Bertrand (editor) 695 France Telecom - Orange 696 38-40 rue du General Leclerc 697 Issy les Moulineaux, 92130 698 FR 700 Phone: +33 1 45 29 89 46 701 Email: gilles.bertrand@orange.com 703 Stephan Emile 704 France Telecom - Orange 705 2 avenue Pierre Marzin 706 Lannion F-22307 707 France 709 Email: emile.stephan@orange.com 711 Trevor Burbridge 712 BT 713 B54 Room 70, Adastral Park, Martlesham 714 Ipswich, IP5 3RE 715 UK 717 Email: trevor.burbridge@bt.com 719 Philip Eardley 720 BT 721 B54 Room 77, Adastral Park, Martlesham 722 Ipswich, IP5 3RE 723 UK 725 Email: philip.eardley@bt.com 727 Kevin J. Ma 728 Azuki Systems, Inc. 729 43 Nagog Park 730 Acton, MA 01720 731 USA 733 Phone: +1 978-844-5100 734 Email: kevin.ma@azukisystems.com 735 Grant Watson 736 Alcatel-Lucent (Velocix) 737 3 Ely Road 738 Milton, Cambridge CB24 6AA 739 UK 741 Email: gwatson@velocix.com