idnits 2.17.1 draft-ietf-cdni-use-cases-04.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 26, 2012) is 4413 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 618, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-04 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-02 -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) Summary: 0 errors (**), 0 flaws (~~), 6 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 Intended status: Informational France Telecom - Orange 5 Expires: September 27, 2012 G. Watson 6 T. Burbridge 7 P. Eardley 8 BT 9 K. Ma 10 Azuki Systems 11 March 26, 2012 13 Use Cases for Content Delivery Network Interconnection 14 draft-ietf-cdni-use-cases-04 16 Abstract 18 Content Delivery Networks (CDNs) are commonly used for improving the 19 End User experience of a content delivery service, at a reasonable 20 cost. This document focuses on use cases that correspond to 21 identified industry needs and that are expected to be realized once 22 open interfaces and protocols supporting interconnection of CDNs are 23 specified and implemented. The document can be used to guide the 24 definition of the requirements to be supported by CDNI interfaces. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 27, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 75 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 76 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 77 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 78 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 7 79 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 80 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 81 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 9 83 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 85 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10 86 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 87 4.1. Device and Network Technology Extension . . . . . . . . . 11 88 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 89 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12 90 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12 91 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 97 Appendix A. Content Service Providers' Delivery Policies . . . . 15 98 A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 15 99 A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 16 100 A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 Content Delivery Networks (CDNs) are commonly used for improving the 106 End User experience of a content delivery service, at a reasonable 107 cost. This document focuses on use cases that correspond to 108 identified industry needs and that are expected to be realized once 109 open interfaces and protocols supporting interconnection of CDNs are 110 specified and implemented. The document can be used to guide the 111 definition of the requirements to be supported by the various CDNI 112 interfaces defined in [I-D.ietf-cdni-problem-statement]. 114 This document identifies the main motivations for a CDN Provider to 115 interconnect its CDN: 117 o CDN Footprint Extension Use Cases (Section 2) 119 o CDN Offload Use Cases (Section 3) 121 o CDN Capability Use Cases (Section 4) 123 Then, the document highlights the need for interoperability to 124 exchange and enforce content delivery policies (Section 5). 126 1.1. Terminology 128 We adopt the terminology described in 129 [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], 130 [RFC3466], and [RFC3568]. 132 We extend this terminology with the following terms. 134 Access CDN: 136 A CDN that is directly connected to the End User's access. An Access 137 CDN may have specific information about the End User and the network, 138 for instance, End User's profile and access capabilities. 140 Delivering CDN: 142 The CDN that delivers the requested piece of content to the End User. 143 In particular, the Delivering CDN can be an Access CDN. 145 1.2. Abbreviations 147 o CDN: Content Delivery Network also known as Content Distribution 148 Network 150 o CSP: Content Service Provider 152 o dCDN: downstream CDN 154 o DNS: Domain Name System 156 o DRM: Digital Rights Management 158 o EU: End User 160 o ISP: Internet Service Provider 162 o NSP: Network Service Provider 164 o QoE: Quality of Experience 166 o QoS: Quality of Service 168 o uCDN: upstream CDN 170 o URL: Uniform Resource Locator 172 o WiFi: Wireless Fidelity 174 1.3. Rationale for Multi-CDN Systems 176 Content Delivery Networks (CDNs) are used to deliver content because 177 they can: 179 o improve the experience for the End User; for instance delivery has 180 lower latency (decreased round-trip-time between the user and the 181 delivery server) and better robustness, 183 o reduce the network operator's costs; for instance, lower delivery 184 cost (reduced bandwidth usage) for cacheable content, 186 o reduce the Content Service Provider's (CSP) costs, such as 187 datacenter capacity, space, and electricity consumption, as 188 popular content is delivered through the CDN rather than through 189 the CSP's servers. 191 Indeed, many Network Service Providers (NSPs) and enterprise service 192 providers are deploying or have deployed their own CDNs. Despite the 193 potential benefits of interconnecting CDNs, today each CDN is a 194 standalone network. The objective of CDN Interconnection is to 195 overcome this restriction: the interconnected CDNs should be able to 196 collectively behave as a single delivery infrastructure. 198 An example is depicted in Figure 1. Two CDN Providers establish a 199 CDN Interconnection. The Content Service Provider CSP-1 reaches an 200 agreement with CDN Provider 'A' for the delivery of its content. CDN 201 Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs. 203 When a User Agent requests content from CSP-1, CDN-A considers that 204 delivery by CDN-B is appropriate, for instance, because CDN-B is an 205 Access CDN and the user is directly attached to it. CDN-A has 206 delegated the handling of requests for CSP-1's content through the 207 CDN Interconnection agreement, thus, the content is actually 208 delivered from CDN-B. 210 The End User benefits from this arrangement through a better Quality 211 of Experience (QoE), because the content is delivered from a nearby 212 Surrogate. CDN Provider 'A' benefits because it does not need to 213 deploy such an extensive CDN, whilst CDN Provider 'B' may receive 214 some compensation for the delivery. CSP-1 benefits because it only 215 needs to make one business agreement and one physical connection, 216 with CDN Provider 'A', but its End Users get a service quality as 217 though CSP-1 had also gone to the trouble of making a business 218 agreement with CDN Provider 'B'. 220 +-------+ +-------+ 221 | CSP-1 | | CSP-2 | 222 +-------+ +-------+ 223 | | 224 ,--,--,--./ ,--,--,--. 225 ,-' `-. ,-' `-. 226 (CDN Provider 'A')=====(CDN Provider 'B') 227 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 228 `--'--'--' `--'--'--' 229 | 230 +------------+ 231 | User Agent | 232 +------------+ 233 === CDN Interconnection 235 Figure 1 237 To extend the example, another Content Service Provider, CSP-2, may 238 also reach an agreement with CDN Provider 'A'. But it does not want 239 its content to be distributed by CDN Provider B; for example, CSP-2 240 may not have distribution rights in the country where CDN Provider 241 'B' operates. This example illustrates that policy considerations 242 are an important part of CDNI. 244 2. Footprint Extension Use Cases 246 Footprint extension is expected to be a major use case for CDN 247 Interconnection. 249 2.1. Geographic Extension 251 In this use case, the CDN Provider wants to extend the geographic 252 distribution that it can offer to its CSPs: 254 o without compromising the quality of delivery, 256 o without incurring additional transit and other network costs that 257 would result from serving content from geographically or 258 topologically remote Surrogates. 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 In the previous section, we have described the case of geographic 281 extension between CDNs operated by different entities. A large CDN 282 Provider may also operate CDNs from several subsidiaries (which may 283 rely on different CDN technologies, see Section 4.2). In certain 284 circumstances, the CDN Provider needs to make its CDNs interoperate 285 to provide a consistent service to its customers on its whole 286 footprint. For example, the CDN Provider might want to expose a 287 single set of interfaces to the CSPs. 289 2.3. ISP Handling of Third-Party Content 291 Consider an ISP carrying to its subscribers a lot of content that 292 comes from a third party CSP and that is injected into the access 293 network by an Authoritative CDN Provider. There are mutual benefits 294 to the Access CDN, the Authoritative CDN, and the CSP that would make 295 a case for establishing a CDNI agreement. For example: 297 o Allow the CSP to offer improved QoE and QoE services to 298 subscribers, for example, QoS and reduced round trip time. 300 o Allow the Authoritative CDN to reduce hardware capacity and 301 footprint, by using the ISP caching and delivery capacity. 303 o Allow the ISP to reduce traffic load on some segments of the 304 network by caching inside of the ISP network. 306 o Allow the ISP to influence and/or control the traffic ingestion 307 points. 309 o Allow the ISP to derive some incremental revenue for transport of 310 the traffic and to monetize QoE services. 312 2.4. Nomadic Users 314 In this scenario, a CSP wishes to allow End Users who move between 315 CDNs to continue to access their content. The motivation of this 316 case is to allow nomadic End Users to maintain access to content with 317 a consistent QoE, across a range of devices and/or geographic 318 regions. 320 This use case covers situations like: 322 o End Users moving between different CDN Providers, which may reside 323 within the same geographic region or different geographic regions, 325 o End Users switching between different devices or delivery 326 technologies, as discussed in Section 4. 328 The term "Nomadic" does not necessarily relate to geographic roaming. 330 Consider the following example, illustrated in Figure 2: End User A 331 has subscription to a broadband service from NSP A, her "home NSP". 332 NSP A hosts CDN-A. Ordinarily, when End User A accesses content via 333 NSP A (her "home NSP") the content is delivered from CDN-A, which in 334 this example is within NSP A's network. 336 However, while End User A is not connected to NSP A's network, for 337 example, because it is connected to a WiFi provider or mobile 338 network, End User A can also access the same content. In this case, 339 End User A may benefit from accessing the same content but delivered 340 by an alternate CDN (CDN-B), in this case, hosted in the network of 341 the WiFi or mobile provider, rather than from CDN-A in NSP A's 342 network. 344 +-------+ 345 |Content| 346 +-------+ 347 | 348 ,--,--,--. ,--,--,--. 349 ,-' NSP A `-. ,-' NSP B `-. 350 ( (CDN-A) )=====( (CDN-B) ) 351 `-. ,-' `-. ,-' 352 `--'--'--' `--'--'--' 353 | | 354 +------------+ +---------------+ 355 + EU A (home)| | EU A (nomadic)| 356 +------------+ +---------------+ 357 === CDN Interconnection 359 Figure 2 361 The alternate CDN (CDN-B) is allowed to distribute the content of CSP 362 A to End User A; however, no other End Users in the region of CDN-B 363 are allowed to retrieve the content unless they too have such an 364 agreement for nomadic access to content. 366 Depending on CSP's content delivery policies (see Appendix A.1), a 367 user moving to a different geographic region may be subject to geo- 368 blocking content delivery restrictions. In this case, he/she may not 369 be allowed to access some pieces of content. 371 3. Offload Use Cases 373 3.1. Overload Handling and Dimensioning 375 A CDN is likely to be dimensioned to support an expected maximum 376 traffic load. However, unexpected spikes in content popularity 377 (flash crowd) may drive load beyond the expected peak. The prime 378 recurrent time peaks of content distribution may differ between two 379 CDNs. Taking advantage of the different traffic peak times, a CDN 380 may interconnect with another CDN to increase its effective capacity 381 during the peak of traffic. This brings dimensioning savings to the 382 CDNs as they can use the resources of each other during their 383 respective peaks of activity. 385 Offload also applies to planned situations where a CDN Provider needs 386 CDN capacities in a particular region during a short period of time. 387 For example, a CDN can offload traffic to another CDN during a 388 specific maintenance operation or for covering the distribution of a 389 special event. For instance, consider a TV-channel which has 390 exclusive distribution rights on a major event, such as a 391 celebrities' wedding, or a major sport competition. The CDNs that 392 the TV-channel uses for delivering the content related to this event 393 are likely to experience a flash crowd during the event and to need 394 offloading traffic, while other CDNs will support a more usual 395 traffic load and be able to handle the offloaded traffic. 397 In this use case, the Delivering CDN on which requests are offloaded 398 should be able to handle the offloaded requests. Therefore, the uCDN 399 might require information on the dCDNs to be aware of the amount of 400 traffic it can offload to every dCDN. 402 3.2. Resiliency 404 3.2.1. Failure of Content Delivery Resources 406 It is important for CDNs to be able to guarantee service continuity 407 during partial failures (e.g., failure of some Surrogates). In 408 partial failure scenarios, a CDN Provider has at least two options: 409 (1) depending on traffic management policies, forward some requests 410 to the CSP's origin servers, and (2) redirect some requests toward 411 another CDN, which must be able to serve the redirected requests. 412 The second option is a use case for CDNI. 414 3.2.2. Content Acquisition Resiliency 416 Source content acquisition may be handled in one of two ways: 418 o CSP origin, where a CDN acquires content directly from the CSP's 419 origin server, or 421 o CDN origin, where a downstream CDN acquires content from a 422 Surrogate within an upstream CDN. 424 The ability to support content acquisition resiliency, is an 425 important use case for interconnected CDNs. When the content 426 acquisition source fails, the CDN might switch to another content 427 acquisition source. Similarly, when several content acquisition 428 sources are available, a CDN might balance the load between these 429 multiple sources. 431 Though other server and/or DNS load balancing techniques may be 432 employed in the network, interconnected CDNs may have a better 433 understanding of origin server availability and be better equipped to 434 both distribute load between origin servers and attempt content 435 acquisition from alternate origin servers when acquisition failures 436 occur. When normal content acquisition fails, a CDN may need to try 437 other origin server options, e.g.: 439 o an upstream CDN may acquire content from an alternate CSP origin 440 server, 442 o a downstream CDN may acquire content from an alternate Surrogate 443 within an upstream CDN, 445 o a downstream CDN may acquire content from an alternate upstream 446 CDN, or 448 o a downstream CDN may acquire content directly from the CSP's 449 origin server. 451 Though content acquisition protocols are beyond the scope of CDNI, 452 the selection of content acquisition sources should be considered. 454 4. CDN Capability Use Cases 456 4.1. Device and Network Technology Extension 458 In this use case, the CDN Provider may have the right geographic 459 footprint, but may wish to extend the supported range of devices and 460 User Agents or the supported range of delivery technologies. In this 461 case, a CDN Provider may interconnect with a CDN that offers 462 services: 464 o that the CDN Provider is not willing to provide or, 466 o that its own CDN is not able to support. 468 The following examples illustrate this use case: 470 1. CDN-A cannot support a specific delivery protocol. For instance, 471 CDN-A may interconnect with CDN-B to serve a proportion of its 472 traffic that requires HTTPS. CDN-A may use CDN-B's footprint 473 (which may overlap with its own) to deliver HTTPS without needing 474 to deploy its own infrastructure. This case could also be true 475 of other formats, delivery protocols (RTMP, RTSP, etc.) and 476 features (specific forms of authorization such as tokens, per 477 session encryption, etc.). 479 2. CDN-A has footprint covering traditional fixed line broadband and 480 wants to extend coverage to mobile devices. In this case, CDN-A 481 may contract and interconnect with CDN-B who has both: 483 * physical footprint inside the mobile network, 485 * the ability to deliver content over a protocol that is 486 required by specific mobile devices. 488 These cases can apply to many CDN features that a given CDN Provider 489 may not be able to support or not be willing to invest in, and thus, 490 that the CDN Provider would delegate to another CDN. 492 4.2. Technology and Vendor Interoperability 494 A CDN Provider may deploy a new CDN to run alongside its existing 495 CDN, as a simple way of migrating its CDN service to a new 496 technology. In addition, a CDN Provider may have a multi-vendor 497 strategy for its CDN deployment. Finally, a CDN Provider may want to 498 deploy a separate CDN for a particular CSP or a specific network. In 499 all these circumstances, CDNI benefits the CDN Provider, as it 500 simplifies or automates some inter-CDN operations (e.g., migrating 501 the request routing function progressively). 503 4.3. QoE and QoS Improvement 505 Some CSPs are willing to pay a premium for enhanced delivery of 506 content to their End Users. In some cases, even if the CDN Provider 507 could deliver the content to the End Users, it cannot meet the CSP's 508 service level requirements. As a result, the CDN Provider may 509 establish a CDN Interconnection agreement with another CDN Provider 510 that can provide the expected QoE to the End User, e.g., via an 511 Access CDN able to deliver content from Surrogates located closer to 512 the End User and with the required service level. 514 5. Enforcement of Content Delivery Policy 516 An important aspect of the above use cases is that CSPs commonly want 517 to enforce content delivery policies. A CSP may want to define 518 content delivery policies that specify when, how, and/or to whom the 519 CDN delivers content. These policies apply to all interconnected 520 CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can 521 define content delivery policies for content delivered by a single, 522 non-interconnected CDN. Appendix A provides examples of CSP defined 523 policies. 525 6. Acknowledgments 527 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 528 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 529 for their reviews and comments on the mailing list. 531 They also thank the contributors of the EU FP7 OCEAN and ETICS 532 projects for valuable inputs. 534 7. IANA Considerations 536 This memo includes no request to IANA. 538 8. Security Considerations 540 CDN Interconnection, as described in this document, has a wide 541 variety of security issues that should be considered. 543 In addition to the security considerations within the uCDN and dCDN, 544 four contexts involve security and trust issues: 546 a. The relationship between the CSP and the uCDN: the main contract 547 arrangement for distribution, which authorizes the uCDN to 548 acquire content on CSP's origin servers and to deliver it, 549 potentially with content delivery restrictions. 551 b. The relationship between the uCDN and dCDN: the transitive trust 552 relationship that extends the contract defined in (a) above and 553 that authorizes the dCDN to acquire content on uCDN's or CSP's 554 origin servers and to deliver it, potentially with content 555 delivery restrictions. 557 c. The relationship between the End User and dCDN: the recognition 558 of right to download predicated on (b) above. 560 d. The relationship between the End User and the CSP: the contract 561 that authorizes the End User to access the content. 563 CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to 564 negotiate a security method or a method for confirming authorization 565 along the chain of trust (CSP -> uCDN -> dCDN -> End User). 567 The security issues fall into three general categories: 569 o CSP Trust: where the CSP may have negotiated service level 570 agreements for delivery quality of service with the uCDN, and/or 571 configured distribution policies (e.g., geo-restrictions, 572 availability windows, or other licensing restrictions), which it 573 assumes will be upheld by dCDNs to which the uCDN delegates 574 requests. Furthermore, billing and accounting information must be 575 aggregated from dCDNs with which the CSP may have no direct 576 business relationship. These situations where trust is delegated 577 must be handled in a secure fashion to ensure CSP confidence in 578 the CDN interconnection. 580 o Client Transparency: where the client device or application which 581 connects to the CDN must be able to interact with any dCDN using 582 its existing security and DRM protocols (e.g., cookies, 583 certificate-based authentication, custom DRM protocols, URL 584 signing algorithms, etc.) in a transparent fashion. 586 o CDN Infrastructure Protection: where the dCDNs must be able to 587 identify and validate delegated requests, in order to prevent 588 unauthorized use of the network and to be able to properly bill 589 for delivered content. A dCDN may not wish to advertise that it 590 has access to or is carrying content for the uCDN or CSP, 591 especially if that information may be used to enhance denial of 592 service attacks. CDNI interfaces and protocols should attempt to 593 minimize overhead for dCDNs. 595 This document focuses on the motivational use cases for CDN 596 Interconnection, and does not analyze these threats in detail. 598 9. References 600 9.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 9.2. Informative References 607 [I-D.davie-cdni-framework] 608 Davie, B. and L. Peterson, "Framework for CDN 609 Interconnection", draft-davie-cdni-framework-01 (work in 610 progress), October 2011. 612 [I-D.ietf-cdni-problem-statement] 613 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 614 Distribution Network Interconnection (CDNI) Problem 615 Statement", draft-ietf-cdni-problem-statement-04 (work in 616 progress), March 2012. 618 [I-D.ietf-cdni-requirements] 619 Leung, K. and Y. Lee, "Content Distribution Network 620 Interconnection (CDNI) Requirements", 621 draft-ietf-cdni-requirements-02 (work in progress), 622 December 2011. 624 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 625 for Content Internetworking (CDI)", RFC 3466, 626 February 2003. 628 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 629 Content Network (CN) Request-Routing Mechanisms", 630 RFC 3568, July 2003. 632 Appendix A. Content Service Providers' Delivery Policies 634 CSPs commonly apply different delivery policies to given sets of 635 content assets delivered through CDNs. Interconnected CDNs need to 636 support these policies. This annex presents examples of CSPs' 637 delivery policies and their consequences on CDNI operations. 639 A.1. Content Delivery Policy Enforcement 641 The content distribution policies that a CSP attaches to a content 642 asset may depend on many criteria. For instance, distribution 643 policies for audiovisual content often combine: 645 o temporal constraints (e.g., available for 24 hours, available 28 646 days after DVD release, etc.), 648 o resolution-based constraints (e.g., high definition vs. standard 649 definition), and 651 o geolocation-based constraints (e.g., per country). 653 dCDN delegation and Surrogate selection decisions are influenced by 654 these policies: 656 o dCDN delegation and/or Surrogates selection may fail if the 657 availability window for the requested content is not active, 659 o dCDN delegation may fail if the content resolution has been 660 specified by the CSP as being too high for distribution via the 661 dCDN, 663 o Surrogate selection may fail if the content resolution has been 664 specified by the CSP as being too high for distribution via the 665 current CDN, 667 o dCDN delegation may fail if the footprint of the dCDN is outside 668 of the delivery footprint for the requested content, or 670 o Surrogate selection may fail if the footprint of the current CDN 671 is outside of the delivery footprint for the requested content. 673 These policy considerations permit preventing premature access to 674 pre-positioned content, preventing content licensing violations, and 675 enforcing geo-blocking policies. 677 A.2. Secure Access 679 Many protocols exist for delivering content to End Users. CSPs may 680 dictate a specific protocol or set of protocols which are acceptable 681 for delivery of their content, especially in the case where content 682 protection or user authentication is required (e.g., must use HTTPS). 683 CSPs may also perform per-request authentication/authorization 684 decision and then have the CDNs enforce that decision (e.g., must 685 validate URL signing, etc.). 687 A.3. Branding 689 Preserving the branding of the CSP throughout delivery is often 690 important to the CSP. CSPs may desire to offer content services 691 under their own name, even when the associated CDN service involves 692 other CDN Providers. For instance, a CSP may desire to ensure that 693 content is delivered with URIs appearing to the End Users under the 694 CSP's own domain name, even when the content delivery involves 695 separate CDN Providers. The CSP may wish to prevent the delivery of 696 its content by specific dCDNs that lack support for such branding 697 preservation features. 699 Analogous cases exist when the uCDN wants to offer CDN services under 700 its own branding even if dCDNs are involved. Similarly, a CDN 701 Provider might wish to restrict the delivery delegation to a chain 702 that preserves its brand visibility. 704 Authors' Addresses 706 Gilles Bertrand (editor) 707 France Telecom - Orange 708 38-40 rue du General Leclerc 709 Issy les Moulineaux, 92130 710 FR 712 Phone: +33 1 45 29 89 46 713 Email: gilles.bertrand@orange.com 715 Stephan Emile 716 France Telecom - Orange 717 2 avenue Pierre Marzin 718 Lannion F-22307 719 France 721 Email: emile.stephan@orange.com 723 Grant Watson 724 BT 725 pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham 726 Ipswich, IP5 3RE 727 UK 729 Email: grant.watson@bt.com 731 Trevor Burbridge 732 BT 733 B54 Room 70, Adastral Park, Martlesham 734 Ipswich, IP5 3RE 735 UK 737 Email: trevor.burbridge@bt.com 739 Philip Eardley 740 BT 741 B54 Room 77, Adastral Park, Martlesham 742 Ipswich, IP5 3RE 743 UK 745 Email: philip.eardley@bt.com 746 Kevin Ma 747 Azuki Systems 748 43 Nagog Park 749 Acton, MA 01720 750 USA 752 Phone: +1 978 844 5100 753 Email: kevin.ma@azukisystems.com