idnits 2.17.1 draft-ietf-cdni-use-cases-03.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 (January 30, 2012) is 4469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 684, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-experiments-01 == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-03 == 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: August 2, 2012 G. Watson 6 T. Burbridge 7 P. Eardley 8 BT 9 K. Ma 10 Azuki Systems 11 January 30, 2012 13 Use Cases for Content Delivery Network Interconnection 14 draft-ietf-cdni-use-cases-03 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 outlines real world use cases (not technical 21 solutions) for interconnecting CDNs. It focuses on use cases that 22 correspond to identified industry needs and that are expected to be 23 realized once a CDN Interconnection (CDNI) solution is available. 24 This document can be used to provide guidance to the CDNI WG about 25 the interconnection arrangements to be supported and to validate the 26 requirements of the various CDNI interfaces. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 2, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 77 1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5 78 1.4. The Need for CDN Interconnection Standards . . . . . . . . 7 79 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7 80 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7 81 2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8 82 2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 8 83 2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8 84 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 85 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 86 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.2.1. Failure of Content Delivery Resources . . . . . . . . 10 88 3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 11 89 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11 90 4.1. Device and Network Technology Extension . . . . . . . . . 12 91 4.2. Technology and Vendor Interoperability . . . . . . . . . . 12 92 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 13 93 5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13 94 5.1. Content Delivery Restrictions . . . . . . . . . . . . . . 13 95 5.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14 96 5.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 Content Delivery Networks (CDNs) are commonly used for improving the 108 End User experience of a content delivery service, at a reasonable 109 cost. This document outlines real world use cases (not technical 110 solutions) for interconnecting CDNs. It focuses on use cases that 111 correspond to identified industry needs and that are expected to be 112 realized once a CDNI solution is available. This document can be 113 used to provide guidance to the CDNI WG about the interconnection 114 arrangements to be supported and to validate the requirements of the 115 various CDNI interfaces. 117 This document identifies the main motivations for a CDN Provider to 118 interconnect its CDN: 120 o CDN Footprint Extension Use Cases (Section 2) 122 o CDN Offload Use Cases (Section 3) 124 o CDN Capability Use Cases (Section 4) 126 Then, the document highlights the need for interoperability to 127 exchange and enforce content delivery policies (Section 5). 129 1.1. Terminology 131 We adopt the terminology described in 132 [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework], 133 [RFC3466], and [RFC3568]. 135 We extend this terminology with the following terms. 137 Access CDN: 139 A CDN that is directly connected to the End User's access. An Access 140 CDN may have specific information about the End User and the network, 141 for instance, End User's profile and access capabilities. 143 Delivering CDN: 145 The CDN that delivers the requested piece of content to the End User. 146 In particular, the Delivering CDN can be an Access CDN. 148 1.2. Abbreviations 150 o CDN: Content Delivery Network also known as Content Distribution 151 Network 153 o CSP: Content Service Provider 155 o dCDN: downstream CDN 157 o DNS: Domain Name System 159 o DRM: Digital Rights Management 161 o EU: End User 163 o ISP: Internet Service Provider 165 o NSP: Network Service Provider 167 o QoE: Quality of Experience 169 o QoS: Quality of Service 171 o uCDN: upstream CDN 173 o URL: Uniform Resource Locator 175 o WiFi: Wireless Fidelity 177 1.3. Rationale for Multi-CDN Systems 179 Content Delivery Networks (CDNs) are used to deliver content because 180 they can: 182 o improve the experience for the End User; for instance delivery has 183 lower latency (decreased round-trip-time between the user and the 184 delivery server) and better robustness, 186 o reduce the network operator's costs; for instance, lower delivery 187 cost (reduced bandwidth usage) for cacheable content, 189 o reduce the Content Service Provider's (CSP) costs, such as 190 datacenter capacity, space, and electricity consumption, as 191 popular content is delivered through the CDN rather than through 192 the CSP's servers. 194 Indeed, many Network Service Providers (NSPs) and enterprise service 195 providers are deploying or have deployed their own CDNs. Despite the 196 potential benefits of interconnecting CDNs, today each CDN is a 197 standalone network. The objective of CDN Interconnection is to 198 overcome this restriction: the interconnected CDNs should be able to 199 collectively behave as a single delivery infrastructure. 201 An example is depicted in Figure 1. Two CDN Providers establish a 202 CDN Interconnection. The Content Service Provider CSP-1 reaches an 203 agreement with CDN Provider 'A' for the delivery of its content. CDN 204 Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs. 206 When a User Agent requests content from CSP-1, CDN-A considers that 207 delivery by CDN-B is appropriate, for instance, because CDN-B is an 208 Access CDN and the user is directly attached to it. CDN-A has 209 delegated the handling of requests for CSP-1's content through the 210 CDN Interconnection agreement, thus, the content is actually 211 delivered from CDN-B. 213 The End User benefits from this arrangement through a better Quality 214 of Experience (QoE), because the content is delivered from a nearby 215 Surrogate. CDN Provider 'A' benefits because it does not need to 216 deploy such an extensive CDN, whilst CDN Provider 'B' may receive 217 some compensation for the delivery. CSP-1 benefits because it only 218 needs to make one business agreement and one physical connection, 219 with CDN Provider 'A', but its End Users get a service quality as 220 though CSP-1 had also gone to the trouble of making a business 221 agreement with CDN Provider 'B'. 223 +-------+ +-------+ 224 | CSP-1 | | CSP-2 | 225 +-------+ +-------+ 226 | | 227 ,--,--,--./ ,--,--,--. 228 ,-' `-. ,-' `-. 229 (CDN Provider 'A')=====(CDN Provider 'B') 230 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 231 `--'--'--' `--'--'--' 232 | 233 +------------+ 234 | User Agent | 235 +------------+ 236 === CDN Interconnection 238 Figure 1 240 To extend the example, another Content Service Provider, CSP-2, may 241 also reach an agreement with CDN Provider 'A'. But it does not want 242 its content to be distributed by CDN Provider B; for example, CSP-2 243 may not have distribution rights in the country where CDN Provider 244 'B' operates. This example illustrates that policy considerations 245 are an important part of CDNI. 247 1.4. The Need for CDN Interconnection Standards 249 The problem statement draft [I-D.ietf-cdni-problem-statement] 250 describes extensively the CDNI problem space and explains why CDNI 251 standards are required. 253 Existing CDN interfaces are proprietary and have often been designed 254 for intra-CDN/intra-domain operations. Consequently, an external CDN 255 typically cannot use these interfaces, especially if the two CDNs to 256 be interconnected rely on different implementations. Nevertheless, 257 [I-D.bertrand-cdni-experiments] shows that some level of CDN 258 Interconnection can be achieved experimentally without standardized 259 interfaces between the CDNs. However, the methods used in these 260 experiments are hardly usable in an operational context, because they 261 suffer from several limitations in terms of functionalities, 262 scalability, and security level. 264 The aim of IETF CDNI WG's solution is, therefore, to overcome such 265 shortcomings; a full list of requirements is being developed in 266 [I-D.ietf-cdni-requirements]. 268 2. Footprint Extension Use Cases 270 Footprint extension is expected to be a major use case for CDN 271 Interconnection. 273 2.1. Geographic Extension 275 In this use case, the CDN Provider wants to extend the geographic 276 distribution that it can offer to its CSPs: 278 o without compromising the quality of delivery, 280 o without incurring additional transit and other network costs that 281 would result from serving content from geographically or 282 topologically remote Surrogates. 284 If there are several CDN Providers that have a geographically limited 285 footprint (e.g., restricted to one country), or do not serve all End 286 Users in a geographic area, then interconnecting their CDNs enables 287 these CDN Providers to provide their services beyond their own 288 footprint. 290 As an example, suppose a French CSP wants to distribute its TV 291 programs to End Users located in France and various countries in 292 North Africa. It asks a French CDN Provider to deliver the content. 293 The French CDN Provider's network only covers France, so it makes an 294 agreement with another CDN Provider that covers North Africa. 295 Overall, from the CSP's perspective the French CDN Provider provides 296 a CDN service for both France and North Africa. 298 In addition to video, this use case applies to other types of content 299 such as automatic software updates (browser updates, operating system 300 patches, virus database update, etc). 302 2.2. Inter-Affiliates Interconnection 304 In the previous section, we have described the case of geographic 305 extension between CDNs operated by different entities. A large CDN 306 Provider may also operate CDNs from several subsidiaries (which may 307 rely on different CDN solutions, see Section 4.2). In certain 308 circumstances, the CDN Provider needs to make its CDNs interoperate 309 to provide a consistent service to its customers on its whole 310 footprint. For example, the CDN Provider might want to expose a 311 single set of interfaces to the CSPs. 313 2.3. ISP Handling of Third-Party Content 315 Consider an ISP carrying to its subscribers a lot of content that 316 comes from a third party CSP and that is injected into the access 317 network by an Authoritative CDN Provider. There are mutual benefits 318 to the Access CDN, the Authoritative CDN, and the CSP that would make 319 a case for establishing a CDNI agreement. For example: 321 o Allow the CSP to offer improved QoE and QoE services to 322 subscribers, for example, QoS and reduced round trip time. 324 o Allow the Authoritative CDN to reduce hardware capacity and 325 footprint, by using the ISP caching and delivery capacity. 327 o Allow the ISP to reduce traffic load on some segments of the 328 network by caching inside of the ISP network. 330 o Allow the ISP to influence and/or control the traffic ingestion 331 points. 333 o Allow the ISP to derive some incremental revenue for transport of 334 the traffic and to monetize QoE services. 336 2.4. Nomadic Users 338 In this scenario, a CSP wishes to allow End Users who move between 339 CDNs to continue to access their content. The motivation of this 340 case is to allow nomadic End Users to maintain access to content with 341 a consistent QoE, across a range of devices and/or geographic 342 regions. 344 This use case covers situations like: 346 o End Users moving between different CDN Providers, which may reside 347 within the same geographic region or different geographic regions, 349 o End Users switching between different devices or delivery 350 technologies, as discussed in Section 4. 352 The term "Nomadic" does not necessarily relate to geographic roaming. 354 Consider the following example, illustrated in Figure 2: End User A 355 has subscription to a broadband service from NSP A, her "home NSP". 356 NSP A hosts CDN-A. Ordinarily, when End User A accesses content via 357 NSP A (her "home NSP") the content is delivered from CDN-A, which in 358 this example is within NSP A's network. 360 However, while End User A is not connected to NSP A's network, for 361 example, because it is connected to a WiFi provider or mobile 362 network, End User A can also access the same content. In this case, 363 End User A may benefit from accessing the same content but delivered 364 by an alternate CDN (CDN-B), in this case, hosted in the network of 365 the WiFi or mobile provider, rather than from CDN-A in NSP A's 366 network. 368 +-------+ 369 |Content| 370 +-------+ 371 | 372 ,--,--,--. ,--,--,--. 373 ,-' NSP A `-. ,-' NSP B `-. 374 ( (CDN-A) )=====( (CDN-B) ) 375 `-. ,-' `-. ,-' 376 `--'--'--' `--'--'--' 377 | | 378 +------------+ +---------------+ 379 + EU A (home)| | EU A (nomadic)| 380 +------------+ +---------------+ 381 === CDN Interconnection 383 Figure 2 385 The alternate CDN (CDN-B) is allowed to distribute the content of CSP 386 A to End User A; however, no other End Users in the region of CDN B 387 are allowed to retrieve the content unless they too have such an 388 agreement for nomadic access to content. 390 Depending on CSP's content delivery policies (see Section 5.1), a 391 user moving to a different geographic region may be subject to geo- 392 blocking content delivery restrictions. In this case, he/she may not 393 be allowed to access some pieces of content. 395 3. Offload Use Cases 397 3.1. Overload Handling and Dimensioning 399 A CDN is likely to be dimensioned to support an expected maximum 400 traffic load. However, unexpected spikes in content popularity 401 (flash crowd) may drive load beyond the expected peak. The prime 402 recurrent time peaks of content distribution may differ between two 403 CDNs. Taking advantage of the different traffic peak times, a CDN 404 may interconnect with another CDN to increase its effective capacity 405 during the peak of traffic. This brings dimensioning savings to the 406 CDNs as they can use the resources of each other during their 407 respective peaks of activity. 409 Offload also applies to planned situations where a CDN Provider needs 410 CDN capacities in a particular region during a short period of time. 411 For example, a CDN can offload traffic to another CDN during a 412 specific maintenance operation or for covering the distribution of a 413 special event. For instance, consider a TV-channel which has 414 exclusive distribution rights on a major event, such as a 415 celebrities' wedding, or a major sport competition. The CDNs that 416 the TV-channel uses for delivering the content related to this event 417 are likely to experience a flash crowd during the event and to need 418 offloading traffic, while other CDNs will support a more usual 419 traffic load and be able to handle the offloaded traffic. 421 In this use case, the Delivering CDN on which requests are offloaded 422 should be able to handle the offloaded requests. Therefore, the uCDN 423 might require information on the dCDNs to be aware of the amount of 424 traffic it can offload to every dCDN. 426 3.2. Resiliency 428 3.2.1. Failure of Content Delivery Resources 430 It is important for CDNs to be able to guarantee service continuity 431 during partial failures (e.g., failure of some Surrogates). In 432 partial failure scenarios, a CDN Provider has at least two options: 433 (1) depending on traffic management policies, forward some requests 434 to the CSP's origin servers, and (2) redirect some requests toward 435 another CDN, which must be able to serve the redirected requests. 436 The second option is a use case for CDNI. 438 3.2.2. Content Acquisition Resiliency 440 Source content acquisition may be handled in one of two ways: 442 o CSP origin, where a CDN acquires content directly from the CSP's 443 origin server, or 445 o CDN origin, where a downstream CDN acquires content from a 446 Surrogate within an upstream CDN. 448 The ability to support content acquisition resiliency, is an 449 important use case for interconnected CDNs. When the content 450 acquisition source fails, the CDN might switch to another content 451 acquisition source. Similarly, when several content acquisition 452 sources are available, a CDN might balance the load between these 453 multiple sources. 455 Though other server and/or DNS load balancing techniques may be 456 employed in the network, interconnected CDNs may have a better 457 understanding of origin server availability and be better equipped to 458 both distribute load between origin servers and attempt content 459 acquisition from alternate origin servers when acquisition failures 460 occur. When normal content acquisition fails, a CDN may need to try 461 other origin server options, e.g.: 463 o an upstream CDN may acquire content from an alternate CSP origin 464 server, 466 o a downstream CDN may acquire content from an alternate Surrogate 467 within an upstream CDN, 469 o a downstream CDN may acquire content from an alternate upstream 470 CDN, or 472 o a downstream CDN may acquire content directly from the CSP's 473 origin server. 475 Though content acquisition protocols are beyond the scope of CDNI, 476 the selection of content acquisition sources should be considered. 478 4. CDN Capability Use Cases 479 4.1. Device and Network Technology Extension 481 In this use case, the CDN Provider may have the right geographic 482 footprint, but may wish to extend the supported range of devices and 483 User Agents or the supported range of delivery technologies. In this 484 case, a CDN Provider may interconnect with a CDN that offers 485 services: 487 o that the CDN Provider is not willing to provide or, 489 o that its own CDN is not able to support 491 The following examples illustrate this use case: 493 1. CDN-A cannot support a specific delivery protocol. For instance, 494 CDN-A may interconnect with CDN-B to serve a proportion of its 495 traffic that requires HTTPS. CDN-A may use CDN-B's footprint 496 (which may overlap with its own) to deliver HTTPS without needing 497 to deploy its own infrastructure. This case could also be true 498 of other formats, delivery protocols (RTMP, RTSP, etc.) and 499 features (specific forms of authorization such as tokens, per 500 session encryption, etc.). 502 2. CDN-A has footprint covering traditional fixed line broadband and 503 wants to extend coverage to mobile devices. In this case, CDN-A 504 may contract and interconnect with CDN-B who has both: 506 * physical footprint inside the mobile network, 508 * the ability to deliver content over a protocol that is 509 required by specific mobile devices. 511 These cases can apply to many CDN features that a given CDN Provider 512 may not be able to support or not be willing to invest in, and thus, 513 that the CDN Provider would delegate to another CDN. 515 4.2. Technology and Vendor Interoperability 517 A CDN Provider may deploy a new CDN to run alongside its existing 518 CDN, as a simple way of migrating its CDN service to a new 519 technology. In addition, a CDN Provider may have a multi-vendor 520 strategy for its CDN deployment. Finally, a CDN Provider may want to 521 deploy a separate CDN for a particular CSP or a specific network. In 522 all these circumstances, CDNI benefits the CDN Provider, as it 523 simplifies or automates some inter-CDN operations (e.g., migrating 524 the request routing function progressively). 526 4.3. QoE and QoS Improvement 528 Some CSPs are willing to pay a premium for enhanced delivery of 529 content to their End Users. In some cases, even if the CDN Provider 530 could deliver the content to the End Users, it cannot meet the CSP's 531 service level requirements. As a result, the CDN Provider may 532 establish a CDN Interconnection agreement with another CDN Provider 533 that can provide the expected QoE to the End User, e.g., via an 534 Access CDN able to deliver content from Surrogates located closer to 535 the End User and with the required service level. 537 5. Enforcement of Content Delivery Policy 539 CSPs commonly require the ability to place delivery restriction on 540 sets of content, which are provided by existing CDNs. The ability to 541 support such delivery restrictions across interconnected CDNs is 542 desirable, but depends on the capabilities of the involved CDNs. 543 Thus, it is important to be able to detect and define when these 544 features cannot be enforced. 546 5.1. Content Delivery Restrictions 548 The content distribution policies that a CSP attaches to a piece of 549 content depend on many criteria. For instance, distribution policies 550 for audiovisual content often combine: 552 o temporal constraints (e.g., available for 24 hours, available 28 553 days after DVD release, etc.), 555 o resolution-based constraints (e.g., high definition vs. standard 556 definition), and 558 o geolocation-based constraints (e.g., per country). 560 CSPs may require from their CDN Providers that they translate some of 561 the above requirements into content delivery policies for their CDNs. 562 For instance, CDNs might implement "geo-blocking" rules specifying: 564 o geographic locations to which content can be delivered (i.e., the 565 location of the End Users), or 567 o the geographic regions from where content can be delivered (i.e., 568 the location of the Surrogates). 570 Similarly, an uCDN might implement some temporal constraints on 571 content availability. For example, it could restrict access to pre- 572 positioned content prior to the opening of the availability window or 573 disable the delivery of content from the dCDNs (e.g., through 574 purging) after the availability window has closed. 576 5.2. Secure Access 578 Many protocols exist for delivering content to End Users. CSPs may 579 often wish to dictate a specific protocol or set of protocols which 580 are acceptable for delivery of their content, especially in the case 581 where content protection or user authentication is required (e.g., 582 must use HTTPS). CSPs may also wish to perform per-request 583 authentication/authorization decision and then have the CDNs enforce 584 that decision (e.g., must validate URL signing, etc.). 586 An uCDN needs to be able to exclude dCDNs which lack support for the 587 secure access features requested by the CSP. 589 5.3. Branding 591 Preserving the branding of the CSP throughout delivery is often 592 important to the CSP. CSPs may desire to offer content services 593 under their own name, even when the associated CDN service involves 594 other CDN Providers. For instance, a CSP may desire to ensure that 595 content is delivered with URIs appearing to the End Users under the 596 CSP's own domain name, even when the content delivery involves 597 separate CDN Providers. The CSP may wish to forbid the delivery of 598 its content by specific dCDNs that lack support for such branding 599 preservation features. 601 Analogous restrictions may exist when the uCDN wants to offer CDN 602 services under its own branding even if dCDNs are involved. 603 Similarly, a CDN Provider might not want the brand of an intermediary 604 in the CDN delegation chain to be visible, even if the intermediary 605 is involved in the content delivery call flow. 607 6. Acknowledgments 609 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 610 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 611 for their reviews and comments on the mailing list. 613 They also thank the contributors of the EU FP7 OCEAN and ETICS 614 projects for valuable inputs. 616 7. IANA Considerations 618 This memo includes no request to IANA. 620 8. Security Considerations 622 CDN Interconnection, as described in this document, has a wide 623 variety of security issues that should be considered. 625 In addition to the security considerations within the uCDN and dCDN, 626 four contexts involve security and trust issues: 628 a. The relationship between the CSP and the uCDN: the main contract 629 arrangement for distribution, which authorizes the uCDN to 630 acquire content on CSP's origin servers and to deliver it, 631 potentially with content delivery restrictions. 633 b. The relationship between the uCDN and dCDN: the transitive trust 634 relationship that extends the contract defined in (a) above and 635 that authorizes the dCDN to acquire content on uCDN's or CSP's 636 origin servers and to deliver it, potentially with content 637 delivery restrictions. 639 c. The relationship between the End User and dCDN: the recognition 640 of right to download predicated on (b) above. 642 d. The relationship between the End User and the CSP: the contract 643 that authorizes the End User to access the content. 645 CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to 646 negotiate a security method or a method for confirming authorization 647 along the chain of trust (CSP -> uCDN -> dCDN -> End User). 649 The security issues fall into three general categories: 651 o CSP Trust: where the CSP may have negotiated service level 652 agreements for delivery quality of service with the uCDN, and/or 653 configured distribution policies (e.g., geo-restrictions, 654 availability windows, or other licensing restrictions), which it 655 assumes will be upheld by dCDNs to which the uCDN delegates 656 requests. Furthermore, billing and accounting information must be 657 aggregated from dCDNs with which the CSP may have no direct 658 business relationship. These situations where trust is delegated 659 must be handled in a secure fashion to ensure CSP confidence in 660 the CDN interconnection. 662 o Client Transparency: where the client device or application which 663 connects to the CDN must be able to interact with any dCDN using 664 its existing security and DRM protocols (e.g., cookies, 665 certificate-based authentication, custom DRM protocols, URL 666 signing algorithms, etc.) in a transparent fashion. 668 o CDN Infrastructure Protection: where the dCDNs must be able to 669 identify and validate delegated requests, in order to prevent 670 unauthorized use of the network and to be able to properly bill 671 for delivered content. A dCDN may not wish to advertise that it 672 has access to or is carrying content for the uCDN or CSP, 673 especially if that information may be used to enhance denial of 674 service attacks. CDNI interfaces and protocols should attempt to 675 minimize overhead for dCDNs. 677 This document focuses on the motivational use cases for CDN 678 Interconnection, and does not analyze these threats in detail. 680 9. References 682 9.1. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 9.2. Informative References 689 [I-D.bertrand-cdni-experiments] 690 Bertrand, G., Faucheur, F., and L. Peterson, "Content 691 Distribution Network Interconnection (CDNI) Experiments", 692 draft-bertrand-cdni-experiments-01 (work in progress), 693 August 2011. 695 [I-D.davie-cdni-framework] 696 Davie, B. and L. Peterson, "Framework for CDN 697 Interconnection", draft-davie-cdni-framework-01 (work in 698 progress), October 2011. 700 [I-D.ietf-cdni-problem-statement] 701 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 702 Distribution Network Interconnection (CDNI) Problem 703 Statement", draft-ietf-cdni-problem-statement-03 (work in 704 progress), January 2012. 706 [I-D.ietf-cdni-requirements] 707 Leung, K. and Y. Lee, "Content Distribution Network 708 Interconnection (CDNI) Requirements", 709 draft-ietf-cdni-requirements-02 (work in progress), 710 December 2011. 712 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 713 for Content Internetworking (CDI)", RFC 3466, 714 February 2003. 716 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 717 Content Network (CN) Request-Routing Mechanisms", 718 RFC 3568, July 2003. 720 Authors' Addresses 722 Gilles Bertrand (editor) 723 France Telecom - Orange 724 38-40 rue du General Leclerc 725 Issy les Moulineaux, 92130 726 FR 728 Phone: +33 1 45 29 89 46 729 Email: gilles.bertrand@orange.com 731 Stephan Emile 732 France Telecom - Orange 733 2 avenue Pierre Marzin 734 Lannion F-22307 735 France 737 Email: emile.stephan@orange.com 739 Grant Watson 740 BT 741 pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham 742 Ipswich, IP5 3RE 743 UK 745 Email: grant.watson@bt.com 747 Trevor Burbridge 748 BT 749 B54 Room 70, Adastral Park, Martlesham 750 Ipswich, IP5 3RE 751 UK 753 Email: trevor.burbridge@bt.com 754 Philip Eardley 755 BT 756 B54 Room 77, Adastral Park, Martlesham 757 Ipswich, IP5 3RE 758 UK 760 Email: philip.eardley@bt.com 762 Kevin Ma 763 Azuki Systems 764 43 Nagog Park 765 Acton, MA 01720 766 USA 768 Phone: +1 978 844 5100 769 Email: kevin.ma@azukisystems.com