idnits 2.17.1 draft-ietf-cdni-use-cases-02.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 18, 2012) is 4481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 685, 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-02 == 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: July 21, 2012 G. Watson 6 T. Burbridge 7 P. Eardley 8 BT 9 K. Ma 10 Azuki Systems 11 January 18, 2012 13 Use Cases for Content Delivery Network Interconnection 14 draft-ietf-cdni-use-cases-02 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 July 21, 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, as directed by the upstream CDN's request 468 routing interface, 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. 479 4. CDN Capability Use Cases 480 4.1. Device and Network Technology Extension 482 In this use case, the CDN Provider may have the right geographic 483 footprint, but may wish to extend the supported range of devices and 484 User Agents or the supported range of delivery technologies. In this 485 case, a CDN Provider may interconnect with a CDN that offers 486 services: 488 o that the CDN Provider is not willing to provide or, 490 o that its own CDN is not able to support 492 The following examples illustrate this use case: 494 1. CDN-A cannot support a specific delivery protocol. For instance, 495 CDN-A may interconnect with CDN-B to serve a proportion of its 496 traffic that requires HTTPS. CDN-A may use CDN-B's footprint 497 (which may overlap with its own) to deliver HTTPS without needing 498 to deploy its own infrastructure. This case could also be true 499 of other formats, delivery protocols (RTMP, RTSP, etc.) and 500 features (specific forms of authorization such as tokens, per 501 session encryption, etc.). 503 2. CDN-A has footprint covering traditional fixed line broadband and 504 wants to extend coverage to mobile devices. In this case, CDN-A 505 may contract and interconnect with CDN-B who has both: 507 * physical footprint inside the mobile network, 509 * the ability to deliver content over a protocol that is 510 required by specific mobile devices. 512 These cases can apply to many CDN features that a given CDN Provider 513 may not be able to support or not be willing to invest in, and thus, 514 that the CDN Provider would delegate to another CDN. 516 4.2. Technology and Vendor Interoperability 518 A CDN Provider may deploy a new CDN to run alongside its existing 519 CDN, as a simple way of migrating its CDN service to a new 520 technology. In addition, a CDN Provider may have a multi-vendor 521 strategy for its CDN deployment. Finally, a CDN Provider may want to 522 deploy a separate CDN for a particular CSP or a specific network. In 523 all these circumstances, CDNI benefits the CDN Provider, as it 524 simplifies or automates some inter-CDN operations (e.g., migrating 525 the request routing function progressively). 527 4.3. QoE and QoS Improvement 529 Some CSPs are willing to pay a premium for enhanced delivery of 530 content to their End Users. In some cases, even if the CDN Provider 531 could deliver the content to the End Users, it cannot meet the CSP's 532 service level requirements. As a result, the CDN Provider may 533 establish a CDN Interconnection agreement with another CDN Provider 534 that can provide the expected QoE to the End User, e.g., via an 535 Access CDN able to deliver content from Surrogates located closer to 536 the End User and with the required service level. 538 5. Enforcement of Content Delivery Policy 540 CSPs commonly require the ability to place delivery restriction on 541 sets of content, which are provided by existing CDNs. The ability to 542 support such delivery restrictions across interconnected CDNs is 543 desirable, but depends on the capabilities of the involved CDNs. 544 Thus, it is important to be able to detect and define when these 545 features cannot be enforced. 547 5.1. Content Delivery Restrictions 549 The content distribution policies that a CSP attaches to a piece of 550 content depend on many criteria. For instance, distribution policies 551 for audiovisual content often combine: 553 o temporal constraints (e.g., available for 24 hours, available 28 554 days after DVD release, etc.), 556 o resolution-based constraints (e.g., high definition vs. standard 557 definition), and 559 o geolocation-based constraints (e.g., per country). 561 CSPs may require from their CDN Providers that they translate some of 562 the above requirements into content delivery policies for their CDNs. 563 For instance, CDNs might implement "geo-blocking" rules specifying: 565 o geographic locations to which content can be delivered (i.e., the 566 location of the End Users), or 568 o the geographic regions from where content can be delivered (i.e., 569 the location of the Surrogates). 571 Similarly, an uCDN might implement some temporal constraints on 572 content availability. For example, it could restrict access to pre- 573 positioned content prior to the opening of the availability window or 574 disable the delivery of content from the dCDNs (e.g., through 575 purging) after the availability window has closed. 577 5.2. Secure Access 579 Many protocols exist for delivering content to End Users. CSPs may 580 often wish to dictate a specific protocol or set of protocols which 581 are acceptable for delivery of their content, especially in the case 582 where content protection or user authentication is required (e.g., 583 must use HTTPS). CSPs may also wish to perform per-request 584 authentication/authorization decision and then have the CDNs enforce 585 that decision (e.g., must validate URL signing, etc.). 587 An uCDN needs to be able to exclude dCDNs which lack support for the 588 secure access features requested by the CSP. 590 5.3. Branding 592 Preserving the branding of the CSP throughout delivery is often 593 important to the CSP. CSPs may desire to offer content services 594 under their own name, even when the associated CDN service involves 595 other CDN Providers. For instance, a CSP may desire to ensure that 596 content is delivered with URIs appearing to the endusers under the 597 CSP's own domain name, even when the content delivery involves 598 separate CDN Providers. The CSP may wish to forbid the delivery of 599 its content by specific dCDNs that lack support for such branding 600 preservation features. 602 Similar restrictions may exist when the uCDN wants to offer CDN 603 services under its own branding even if dCDNs are involved. 604 Conversely, a CDN Provider might not want the brand of a CDN Exchange 605 to be visible, even if the CDN Exchange is involved in the content 606 delivery call flow. 608 6. Acknowledgments 610 The authors would like to thank Kent Leung, Francois Le Faucheur, Ben 611 Niven-Jenkins, and Scott Wainner for lively discussions, as well as 612 for their reviews and comments on the mailing list. 614 They also thank the contributors of the EU FP7 OCEAN and ETICS 615 projects for valuable inputs. 617 7. IANA Considerations 619 This memo includes no request to IANA. 621 8. Security Considerations 623 CDN Interconnection, as described in this document, has a wide 624 variety of security issues that should be considered. 626 In addition to the security considerations within the uCDN and dCDN, 627 four contexts involve security and trust issues: 629 a. The relationship between the CSP and the uCDN: the main contract 630 arrangement for distribution, which authorizes the uCDN to 631 acquire content on CSP's origin servers and to deliver it, 632 potentially with content delivery restrictions. 634 b. The relationship between the uCDN and dCDN: the transitive trust 635 relationship that extends the contract defined in (a) above and 636 that authorizes the dCDN to acquire content on uCDN's or CSP's 637 origin servers and to deliver it, potentially with content 638 delivery restrictions. 640 c. The relationship between the End User and dCDN: the recognition 641 of right to download predicated on (b) above. 643 d. The relationship between the End User and the CSP: the contract 644 that authorizes the End User to access to the content. 646 CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to 647 negotiate a security method or a method for confirming authorization 648 along the chain of trust (CSP -> uCDN -> dCDN -> End User). 650 The security issues fall into three general categories: 652 o CSP Trust: where the CSP may have negotiated service level 653 agreements for delivery quality of service with the uCDN, and/or 654 configured distribution policies (e.g., geo-restrictions, 655 availability windows, or other licensing restrictions), which it 656 assumes will be upheld by dCDNs to which the uCDN delegates 657 requests. Furthermore, billing and accounting information must be 658 aggregated from dCDNs with which the CSP may have no direct 659 business relationship. These situations where trust is delegated 660 must be handled in a secure fashion to ensure CSP confidence in 661 the CDN interconnection. 663 o Client Transparency: where the client device or application which 664 connects to the CDN must be able to interact with any dCDN using 665 its existing security and DRM protocols (e.g., cookies, 666 certificate-based authentication, custom DRM protocols, URL 667 signing algorithms, etc.) in a transparent fashion. 669 o CDN Infrastructure Protection: where the dCDNs must be able to 670 identify and validate delegated requests, in order to prevent 671 unauthorized use of the network and to be able to properly bill 672 for delivered content. A dCDN may not wish to advertise that it 673 has access to or is carrying content for the uCDN or CSP, 674 especially if that information may be used to enhance denial of 675 service attacks. CDNI interfaces and protocols should attempt to 676 minimize overhead for dCDNs. 678 This document focuses on the motivational use cases for CDN 679 Interconnection, and does not analyze these threats in detail. 681 9. References 683 9.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 9.2. Informative References 690 [I-D.bertrand-cdni-experiments] 691 Bertrand, G., Faucheur, F., and L. Peterson, "Content 692 Distribution Network Interconnection (CDNI) Experiments", 693 draft-bertrand-cdni-experiments-01 (work in progress), 694 August 2011. 696 [I-D.davie-cdni-framework] 697 Davie, B. and L. Peterson, "Framework for CDN 698 Interconnection", draft-davie-cdni-framework-01 (work in 699 progress), October 2011. 701 [I-D.ietf-cdni-problem-statement] 702 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 703 Distribution Network Interconnection (CDNI) Problem 704 Statement", draft-ietf-cdni-problem-statement-02 (work in 705 progress), January 2012. 707 [I-D.ietf-cdni-requirements] 708 Leung, K. and Y. Lee, "Content Distribution Network 709 Interconnection (CDNI) Requirements", 710 draft-ietf-cdni-requirements-02 (work in progress), 711 December 2011. 713 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 714 for Content Internetworking (CDI)", RFC 3466, 715 February 2003. 717 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 718 Content Network (CN) Request-Routing Mechanisms", 719 RFC 3568, July 2003. 721 Authors' Addresses 723 Gilles Bertrand (editor) 724 France Telecom - Orange 725 38-40 rue du General Leclerc 726 Issy les Moulineaux, 92130 727 FR 729 Phone: +33 1 45 29 89 46 730 Email: gilles.bertrand@orange.com 732 Stephan Emile 733 France Telecom - Orange 734 2 avenue Pierre Marzin 735 Lannion F-22307 736 France 738 Email: emile.stephan@orange.com 740 Grant Watson 741 BT 742 pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham 743 Ipswich, IP5 3RE 744 UK 746 Email: grant.watson@bt.com 748 Trevor Burbridge 749 BT 750 B54 Room 70, Adastral Park, Martlesham 751 Ipswich, IP5 3RE 752 UK 754 Email: trevor.burbridge@bt.com 755 Philip Eardley 756 BT 757 B54 Room 77, Adastral Park, Martlesham 758 Ipswich, IP5 3RE 759 UK 761 Email: philip.eardley@bt.com 763 Kevin Ma 764 Azuki Systems 765 43 Nagog Park 766 Acton, MA 01720 767 USA 769 Phone: +1 978 844 5100 770 Email: kevin.ma@azukisystems.com