idnits 2.17.00 (12 Aug 2021) /tmp/idnits5365/draft-bertrand-cdni-use-cases-01.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 28, 2011) is 4130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'I-D.jenkins-cdni-problem-statement' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-cdni-requirements' is defined on line 652, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-jenkins-cdni-problem-statement-01 == Outdated reference: A later version (-02) exists of draft-lefaucheur-cdni-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) -- Obsolete informational reference (is this intentional?): RFC 3570 (Obsoleted by RFC 6770) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Bertrand 3 Internet-Draft E. Stephan 4 Intended status: Informational France Telecom - Orange 5 Expires: August 1, 2011 G. Watson 6 T. Burbridge 7 P. Eardley 8 BT 9 January 28, 2011 11 Use Cases for Content Distribution Network Interconnection 12 draft-bertrand-cdni-use-cases-01 14 Abstract 16 Content Delivery Networks (CDNs) are commonly used for improving the 17 footprint and the end-user experience of a content delivery service, 18 at a reasonable cost. This document outlines real world use-cases 19 (not technical solutions) for interconnecting CDNs. The intention is 20 to motivate CDN Interconnection and to support the case for formation 21 of a Working Group, which would work on the definition of 22 standardized, inter-operable method(s) for interconnecting CDNs. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 1, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 73 2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 7 74 2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 8 75 2.1.1. Geographic Extension . . . . . . . . . . . . . . . . . 8 76 2.1.2. Country to Country Interconnection . . . . . . . . . . 8 77 2.1.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . 8 78 2.1.4. Geo-blocking . . . . . . . . . . . . . . . . . . . . . 9 79 2.1.5. Device and Network Technology Extension . . . . . . . 9 80 2.2. Offload Use Cases . . . . . . . . . . . . . . . . . . . . 10 81 2.2.1. Overload Handling and Dimensioning . . . . . . . . . . 10 82 2.2.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . 11 83 2.3. Technology and Vendor Interoperability . . . . . . . . . . 12 84 2.4. QoE and QoS improvement . . . . . . . . . . . . . . . . . 12 85 2.4.1. NSP CDSP Use Case . . . . . . . . . . . . . . . . . . 12 86 3. Experiments with Existing CDN Solutions and Lessons Learned . 12 87 3.1. France Telecom-Orange Experiments . . . . . . . . . . . . 12 88 3.2. Gaps in Existing Solutions and Need for Specifications . . 14 89 4. Discussion on Priorities for the Proposed Charter . . . . . . 14 90 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 96 Appendix A. CDN Interconnection Patterns . . . . . . . . . . . . 16 97 A.1. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . 16 98 A.2. Dual CDN with Direct Content Delivery . . . . . . . . . . 17 99 A.3. Intermediary CDN . . . . . . . . . . . . . . . . . . . . . 19 100 A.3.1. Option A - Recursive . . . . . . . . . . . . . . . . . 19 101 A.3.2. Option B - Iterative . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 This document now merges input from [I-D.watson-cdni-use-cases]. 108 Content Delivery Networks (CDNs) are commonly used for improving the 109 footprint and the end-user experience of a content delivery service, 110 at a reasonable cost. This document outlines real world use-cases 111 (not technical solutions) for interconnecting CDNs. The intention is 112 to motivate CDN Interconnection and to support the case for formation 113 of a Working Group, which would work on the definition of 114 standardized, inter-operable method(s) for interconnecting CDNs. 116 There are many possible combinations for the relationships between 117 the different parties (Network Service Provider (NSP), Content 118 Delivery Service Provider (CDSP), Content Service Provider (CSP), 119 etc.) involved in end-to-end content delivery. However, in the 120 context of interconnecting CDNs the key relationships are listed 121 below. 123 o How the CSP interacts with the CDN to publish and deliver content. 125 o How the End User interacts with the interconnected CDNs to request 126 and receive content. 128 o How the different CDSPs, operating their CDNs, interact with one 129 another to deliver the CSP's content to the End User. 131 Section 2 describes a number of use cases that motivate CDN 132 Interconnection. We also briefly describe some experiments with 133 existing CDN solutions (Section 4). 135 1.1. Terminology 137 Except for the terms defined below, we adopt the terminology 138 described in [RFC3466], [RFC3568], and [RFC3570]. 140 Problem statement draft [I-D.jenkins-cdni-problem-statement]defines a 141 set of terms. Below we recall only the terms used in the memo. 143 Content Service Provider (CSP): 145 Provides Content Services to Users. A CSP may own the content made 146 available as part of the Content Service, or may license content 147 rights from another party. 149 Content Service: 151 The service offered by a CSP. The Content Service encompasses the 152 complete service which may be wider than just the delivery of items 153 of Content, e.g. the Content Service also includes any middle-ware, 154 key distribution, program guide, etc. which may not require any 155 direct interaction with the CDN. 157 Content Distribution Network (CDN) / Content Delivery Network (CDN): 159 A type of network in which the components are arranged for more 160 effective delivery of content to User Agents. 162 Content Delivery Service 164 Set of services offered to CSPs for delivering their contents through 165 a single Content Delivery Network or interconnections of Content 166 Delivery Networks. 168 CDN Service Provider (CDSP): 170 An administrative entity who operates a CDN over a NSP or over the 171 Internet. 173 Authoritative CDN (aCDN): 175 The CDSP contracted by the CSP for delivery of content by this CDN or 176 by its downstream CDNs. 178 Downstream CDN (dCDN): 180 A CDSP which is contracted by an aCDN to achieve the delivery of 181 content to users. 183 Access CDN 185 A CDN that is connected to the end-user's access and has information 186 about the end-user's profile and access capabilities. 188 Delivering CDN 190 The CDN that delivers the requested content asset to the end-user. 191 In particular, the delivering CDN can be an access CDN. 193 CDN Interconnection (CDNI): 195 Relationship between two CDNs that enables a CDN to provide content 196 delivery services on behalf of another CDN. It relies on a set of 197 interfaces over which two CDNs communicate in order to achieve the 198 delivery of content to end-users by one CDN (the downstream CDN) on 199 behalf of another CDN (the upstream CDN). 201 CDN peering: A business relation between two CDSPs based on one or 202 more CDN interconnections. 204 Recursive request routing: 206 Recursive: Where a process is repeated, but embedded within the 207 original process. In the case of Request Routing, this means that 208 the initial request received by the Authoritative CDN is processed 209 downstream from one CDN to another and that the responses are send 210 back upstream to the Authoritative CDN which then replies to the 211 initial request. 213 Iterative request routing 215 Iterative: Where a process is repeated multiple times to make 216 progress towards a goal. In the case of Request Routing, this means 217 that the initial request is received by the Authoritative CDN, which 218 replies it with a redirection directive to a dowstream CDN. When the 219 end-user sends its request to the downstream CDN, the same process is 220 repeated, until the request arrives to the delivering CDN. 222 1.2. Abbreviations 224 [Ed. Note: List of abbreviations to be updated later and sorted 225 alphabetically] 227 o ISP 229 o NSP 231 o STB 233 o PC 235 o QoS 237 o QoE 239 o SLA 241 o VoD 243 o WiFi 245 o 3G 247 2. High Level Use Cases for Multi-CDN Systems 249 The prevalent use cases for CDNI are presented according to a CDSP's 250 main motivation for interconnecting its CDN. They are classified 251 according to their level of priority for the CDSP: 253 o CDN Footprint Extension Use Cases 255 o CDN Offload Use Cases 257 o Technology and vendor interoperability 259 o QoE and QoS improvement 261 "CSPs have a desire to be able to get (some of their) content to very 262 large number of users and/or over many/all geographies and/or with a 263 high quality of experience, all without having to maintain direct 264 business relationships with many different CDN providers" 265 [draft-jenkins-cdni-problem-statement]. 267 In order to minimize the number of direct business relationships 268 between a CSP and a set of interconnected CDNs, it is assumed that a 269 CSP will only be required/ desire to have a direct relationship with 270 a single CDN, although relationships with more than one CDN are not 271 precluded. A CDN selected by the CSP is referred to as an 272 "Authoritative CDN" in this document. When receiving requests from 273 User Agents, the Authoritative CDN will select an appropriate 274 Surrogate in its own CDN or will decide to delegate the delivery to 275 another CDN, to which a CDN interconnection can be established. 277 The CDNI model enables Content Delivery Networks to collaborate, 278 allowing Content Delivery Service Providers to offer consistent 279 delivery services throughout the CDN Interconnection 281 The CDNI model helps enables Content Delivery Networks that 282 collaborate to provide Content Service Providers with delivery 283 services throughout CDN Interconnections. 285 Let's take an example. CDSP-A and CDSP-B respectively operate CDN-A 286 and CDN-B. They establish a CDN peering for building the CDN 287 interconnections from CDN-A to CDN-B and from CDN-B to CDN-A. The 288 content service provider CSP-A reaches an agreement with CDSP-A. 289 CDSP-A services rely on the CDN-A and on the interconnection from 290 CDN-A to CDN-B. Meanwhile, the content service provider CSP-B 291 reaches an agreement with CDSP-B. These services rely on the CDN-A 292 and on the interconnection from CDN-A to CDN-B. 294 [Ed. Note: Figure to be added to help the reader understand the 295 example] 297 2.1. Footprint Extension Use Cases 299 Footprint extension is a major use case for CDN interconnection. 301 2.1.1. Geographic Extension 303 In this use case, the CDSP is concerned with extending the geographic 304 distribution that it can offer to the CSP without overly compromising 305 the quality of delivery and without attracting transit and other 306 network costs by serving from geographically or topologically remote 307 surrogates. For example, several CDSPs have a geographically limited 308 footprint (e.g., a country), or do not serve all end-users in a 309 geographic area. Interconnecting CDNs enables CDSPs to provide their 310 services beyond their own footprint by relying on other CDNs. 312 As an example, a French CSP that distributes TV series wants to 313 distribute them to end-users located in various countries in Europe 314 and North Africa. It asks a French CDSP to deliver the series to 315 several countries. The French CDSP makes an agreement with an 316 external CDSP that covers North Africa , so that overall the French 317 CDSP provides a CDN service for both France and North Africa. 319 This use case applies to other types of contents such as automatic 320 software updates (browser updates, operating system patches, or virus 321 database update, etc). 323 2.1.2. Country to Country Interconnection 325 There is a specific scenario where a large content delivery service 326 provider (CDSP) operates the CDNs of a set of subsidiaries from 327 different countries. These CDNs can rely on different CDN solutions. 328 Such a situation may occur due to independent regional operations, or 329 through mergers and acquisitions. In certain circumstances, the CDSP 330 needs to make its CDNs interoperate to provide a consistent service 331 to its customers on its whole footprint. 333 [Ed. Note: FIGURE TO BE INCLUDED 334 Figure 1 336 2.1.3. Nomadic Users 338 Another scenario is nomadic situation. In this scenario a CSP wishes 339 to allow users who move to other geographic regions to continue to 340 access their content. The motivation in this case is to allow 341 nomadic users to maintain access, rather than to allow all residents 342 within a region access to the content. 344 2.1.4. Geo-blocking 346 Currently, the distribution of some content is restricted. For 347 instance, distribution rights for audiovisual content are often 348 negotiated per country. 350 The selection of the Authoritative CDN is influenced by policies 351 which may include "geo-blocking" rules that specify 353 o the geographic regions where content can be delivered from (i.e. 354 the location of the Surrogates), 356 o geographic locations where content can be delivered to (i.e. the 357 location of the End Users), 359 o or quality of service policies specifying how the content is to be 360 delivered. 362 Hence, the exchange through the CDN interconnection of information 363 for controlling the footprint of the delivery is an important use 364 case. 366 2.1.5. Device and Network Technology Extension 368 In this use case the CDSP may have the geographic and end-user 369 coverage that it requires, but wishes to support the delivery of 370 content to alternative end devices. These devices may sit on remote 371 networks (such as smartphones connected to a mobile network) and may 372 also require unique delivery capabilities in the CDN. In this case 373 the CDSP may federate with another CDSP that offers service to these 374 devices. 376 As depicted in Figure 2, an end-user can use its tablet to download a 377 VoD through WiFi (1) from CDN1 and then switch to 3G network (2), 378 which is served by CDN2. The end user should be able to reach the 379 selected VoD content through any access network technology. 380 Consequently, every considered CDN must have access to this VoD 381 content. One way to proceed consists in having an ingestion 382 interface among the CDNs to access the content. Replication of the 383 requested VoD content in the CDN serving the terminal (a) enables 384 controlling the QoS (e.g. screen size, bitrate) of the VoD 385 distribution to the terminal used by the end-user. In another 386 situation, the serving of the VoD without replication (b) will save 387 storage resources. The end-user's experience improves thanks to an 388 increase of the number of situations where the end-user can access 389 the service. 391 -------------- -------------- 392 / CDN1 \ / CDN2 \ 393 | Fixed | | Mobile | 394 | ,---. | | ,---. | 395 +---+ | . ) | (a) | . ) | 396 |CSP|****| |`---'| |''''`---------.....>|`---'| | 397 +---+ | | | -.. Acquisition | | | | 398 | ( ) | `-.._ | ( ) | 399 | `---' | `-.. | `---' | 400 |,------------.| (b) ``-._ |,------------.| 401 ||Delivery || `->. Delivery || 402 \`------------'/ \`------------'/ 403 ----------+--- -----*--+----- 404 : * | 405 : * | 406 +........+ +--------+ 407 : Tablet : (1) | Tablet |(2) 408 +........+ +--------+ 410 Figure 2: Fixed-Mobile CDN Inter-connection 412 .: This use case is similar to use case in Section 2.3. 414 2.2. Offload Use Cases 416 Offload is a major use case of CDN interconnection. 418 2.2.1. Overload Handling and Dimensioning 420 The support of prime-time traffic load requires over-dimensioning the 421 CDN capacity. In addition unexpected spikes in content popularity 422 may drive load beyond the expected peak. As prime time and peaks of 423 content distribution may differ between two CDNs, a CDN may 424 interconnect with another CDN to increase its effective peak 425 capacity. Similarly, two CDNs may benefit from dimensioning savings 426 by using the resources of each other during their peaks of activity. 428 The profile of activity peaks (time, duration ...) differ not only 429 from a country to another but also according to the kind of CDNs. 430 Therefore, CDN interconnect will be required since the additional 431 capacity is likely to be provided by alternative technology. 433 Offload also applies to planned situation where a CDSP needs CDN 434 capacities in a particular region during a short period of time. For 435 example, during a specific maintenance operation or for covering the 436 distribution of a special event, such as an international sport 437 competition. 439 2.2.2. Resiliency 441 It is important for CDNs to be able to guarantee service continuity 442 during partial failures (e.g., failure of a set of surrogates). In 443 partial failure scenarios, a CDSP could redirect some requests toward 444 another CDN. This downstream CDN must be able to serve the 445 redirected requests or, depending on traffic management policies, to 446 forward these requests to the CSP origin server. 448 Resiliency may also be required against failure to ingest content 449 from the CSP. In these cases the content may be available from 450 another CDSP. 452 -------------- -------------- 453 / CDN1 \ / CDN2 \ 454 | ,---. | | ,---. | 455 +---+ | . ) | | . ) | 456 |CSP|*******| |`---'| |__________________| |`---'| | 457 +---+ | | | | Acquisition | | | | 458 | ( ) | | ( ) | 459 | `---' | | `---' | 460 |+-----------+ | |,------------.| 461 ||Req-Routing| | .|Delivery || 462 \+-----------+ / \`------------'/ 463 ------------ .-'----------- 464 | .-' 465 | --------------- > .-' 466 | Redirect .-' 467 | .-' 468 | .-' 469 | .-' 470 | .-' 471 | .-' 472 +-----+ 473 | User| 474 +-----+ 476 Figure 3: Example of CDN Interconnection for failure resiliency 478 2.3. Technology and Vendor Interoperability 480 ISPs have deployed platforms per service or per network technology. 481 They are deploying CDNs or enhancing existing platforms to CDN. It 482 is desirable in certain circumstances to share the content or the 483 resources among these internal CDNs. A CDSP may wish to operate a 484 multi-vendor strategy for its CDN. Currently, operating a single 485 controller for such multi-vendor CDNs is problematic. This problem 486 can be alleviated by a CDN interconnection that allows the automation 487 of some operations among these CDNs. 489 2.4. QoE and QoS improvement 491 Some existing CDNs make the decision to work with ISPs to deploy 492 surrogates closer to the end users. Compared to alternatives such as 493 adding capacity at major peering points, this method offers better 494 experience to the end users. Some CSPs are willing to pay a premium 495 for such enhanced service rather than just using the CDSP to mitigate 496 their server and network access costs. Improved experience may be 497 provided by closer proximity to the end users. It could also involve 498 network characteristics, such as provisioning or QoS, and specific 499 delivery techniques such as encoding for constant Quality of 500 Experience. 502 2.4.1. NSP CDSP Use Case 504 In a interconnection use case, CDSP-A is likely to offer an SLA to 505 the CSP including performance or other quality metrics. If it cannot 506 meet the SLA it will push content via the interconnection to a CDSP-B 507 with CDN capabilities that are in a position to guaranty the SLA, and 508 redirect users appropriately to CDSP-B. CDSP-A may not be able to, 509 or may not wish to deploy its own CDN capabilities to meet the SLA 510 requirements for only a subset of its CSP customers. The ability to 511 offer stringent delivery quality SLAs is a differentiator against 512 other CDSPs and can be sold as a premium service. 514 Although this use case has similarities to extending geographic 515 reach, in this case it is expected that the CDSP does have a CDN 516 deployed which could effectively serve content to the end-users, but 517 wishes to increase experience for specific CSPs. 519 3. Experiments with Existing CDN Solutions and Lessons Learned 521 3.1. France Telecom-Orange Experiments 523 As depicted in Figure 1, we have interconnected two CDNs (CDN A and 524 CDN B) operated by different subsidiaries of a large CDSP. The CDNs 525 cover two different countries, henceforth referred to as Country A 526 and Country B and they rely on CDN solutions from two different 527 equipment vendors (Vendor A and Vendor B). The CDNI experiment 528 supported the services of two CSPs (CSP A and CSP B). 530 +-------+ : +-------+ 531 | CSP A | : | CSP B | 532 +------- : +------- 533 | : | 534 ,--,--,--. : ,--,--,--. 535 ,-' CDN A `-. : ,-' CDN B `-. 536 ( (Vendor A) )==:==( (Vendor B) ) 537 `-. ,-' : `-. ,-' 538 `--'--'--' : `--'--'--' 539 : 540 COUNTRY A : COUNTRY B 542 === CDN Interconnect 544 Experiment configuration 546 Figure 1 548 We have run several experiments in the configuration represented in 549 Figure 2. In these experiments, CSP A has an agreement with CDSP A 550 for content delivery to end-users located in Country A and Country B. 551 However, CDSP A operates a CDN (CDN A), whose footprint does not 552 include country B. Therefore, CDSP A has an agreement with CDSP B, so 553 that CDN A can delegate to CDN B the delivery of some content. More 554 specifically, CDN A is allowed to delegate to CDN B the handling of 555 requests sent by end-users located in Country B for CSP A's content. 557 When CDN A receives a content request related to CSP A and from an 558 end-user in Country B, it redirects the end-user to the appropriate 559 content on CDN B. If CDN B does not have a local copy of the 560 requested content yet (cache miss), CDN B ingests the content from 561 CDN A (or from the CSP's origin servers, depending on the test 562 scenario); if CDN A also does not have a local copy of the requested 563 content, it requests this asset from the CSP's origin servers before 564 sending the asset to CDN B. 566 +-------+ : 567 | CSP A | : 568 +-------+ : 569 | : 570 ,--,--,--. : ,--,--,--. 571 ,-' CDN A `-. : ,-' CDN B `-. 572 ( (Vendor A) )==:==( (Vendor B) ) 573 `-. CDSP A ,-' : `-. CDSP B ,-' 574 `--'--'--' : `--'--'--' 575 : | 576 : +------+ 577 : | EU B | 578 : +------+ 579 : 580 COUNTRY A : COUNTRY B 582 === CDN Interconnect 584 Test scenario with heterogeneous solutions 586 Figure 2 588 3.2. Gaps in Existing Solutions and Need for Specifications 590 Our experiments have shown that the current CDN technologies suffer 591 from the following limitations. 593 o The content management policies must be defined manually, so that 594 the end-user's request triggers content delivery from the most 595 appropriate CDN (e.g., a CDN in the country of the end-user, or a 596 CDN that serves the type of files requested by the end-user). 598 o The target URLs for the request redirection must also be defined 599 manually, so that the authoritative CDN provides to the end-user a 600 valid URI on the downstream CDN. 602 o The content ingestion from an upstream CDN worked only in pull 603 mode. 605 To address more sophisticated scenarios, we consider that common 606 interfaces are required for request routing among interconnected CDNs 607 and for the exchange of content distribution metadata. 609 4. Discussion on Priorities for the Proposed Charter 611 This section will be worked out later according to the discussions on 612 the mailing list. 614 5. Acknowledgments 616 The authors would like to thank Francois Le Faucheur and Ben Niven- 617 Jenkins for lively discussions. 619 They also thank the contributors of the EU FP7 OCEAN and ETICS 620 projects for valuable inputs. 622 6. IANA Considerations 624 This memo includes no request to IANA. 626 7. Security Considerations 628 CDN interconnect, as described in this document, has a wide variety 629 of security issues that should be considered. For example, every 630 interconnected CDN should be able to assess if it must serve a 631 delegated request or if this request is delegated by a non-allowed 632 CDN. The CDNs should also be protected so as to avoid being 633 overwhelmed by delegated requests. This document focuses on the 634 motivational use cases for CDN interconnect, and therefore, does not 635 analyze the threats in detail. 637 8. References 639 8.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 8.2. Informative References 646 [I-D.jenkins-cdni-problem-statement] 647 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 648 Distribution Network Interconnection (CDNI) Problem 649 Statement", draft-jenkins-cdni-problem-statement-01 (work 650 in progress), January 2011. 652 [I-D.lefaucheur-cdni-requirements] 653 Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee, 654 "Content Distribution Network Interconnection (CDNI) 655 Requirements", draft-lefaucheur-cdni-requirements-00 (work 656 in progress), January 2011. 658 [I-D.watson-cdni-use-cases] 659 Watson, G., "CDN Interconnect Use Cases", 660 draft-watson-cdni-use-cases-00 (work in progress), 661 January 2011. 663 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 664 for Content Internetworking (CDI)", RFC 3466, 665 February 2003. 667 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 668 Content Network (CN) Request-Routing Mechanisms", 669 RFC 3568, July 2003. 671 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 672 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 674 Appendix A. CDN Interconnection Patterns 676 In this section we attempt to pull out the generic CDN 677 interconnection patterns that may result from the use cases detailed 678 previously. We find little difference between the use cases in the 679 generic interconnection patterns that occur, and these are presented 680 below. However, differences do occur due to the the business 681 concerns of the different parties operating the components in each 682 use case. This will result in different technical requirements at a 683 more detailed level (for example in reporting and accounting 684 mechanisms). 686 A.1. Single CDN 688 This section outlines an illustrative model for content delivery via 689 a single CDN where there is no interconnection with other CDNs. It 690 does not describe all the details and variations but rather the high 691 level interactions between the different Actors (CSP, CDN, End User) 692 which can be used as a point of comparison with the CDN 693 Interconnection patterns described in subsequent sections. 695 +-------+ 696 | CSP-1 | 697 +-------+ 698 | 699 ,---------. 700 ,-' `-. 701 ( CDN-A ) 702 `-. ,-' 703 `---------' 704 | 705 ,---------. 706 ,-' 0 or `-. 707 ( more other ) 708 `-. networks ,-' 709 / `---------' \ 710 / \ 711 ,---------. ,---------. 712 ,-' `-. ,-' `-. 713 ( NSP-X ) ( NSP-Y ) 714 `-. ,-' `-. ,-' 715 `---------' `---------' 716 | | 717 +-------+ +-------+ 718 | UA-X | | UA-Y | 719 +-------+ +-------+ 721 A.2. Dual CDN with Direct Content Delivery 723 Taking the above use cases into account the base pattern for CDN 724 Interconnection is shown in the diagram below. To simplify the 725 diagram the cloud showing "zero or more other networks" has been 726 excluded and NSPs are shown as though they are directly attached to 727 CDNs. This is not intended to imply any direct relationships or to 728 exclude the case where one or more networks may exist between the NSP 729 illustrated and the CDN. 731 +-------+ 732 | CSP-1 | 733 +-------+ 734 | 735 ,---------. ,---------. 736 ,-' `-. ,-' `-. 737 ( CDN-A )==I==( CDN-B ) 738 `-. ,-' /`-. ,-' 739 `---------' / `---------' 740 | ___/ | 741 | / | 742 ,---------. / ,---------. 743 ,-' `-. ,-' `-. 744 ( NSP-X ) ( NSP-Y ) 745 `-. ,-' `-. ,-' 746 `---------' `---------' 747 | | 748 +-------+ +-------+ 749 | UA-X | | UA-Y | 750 +-------+ +-------+ 752 ==I== CDN Intercon 754 As shown in the diagram CSP-1 maintains a direct relationship with 755 CDN-A and so CDN-A is the Authoritative CDN for CSP-1. CDN-A 756 maintains a CDN Interconnect with CDN-B. CDN-A may decide to 757 delegate to CDN-B the delivery of contentto a UA/NSP. How CDN-A 758 makes such a decision is out of scope for this document, although the 759 motivations for doing so are captured in the above use cases. Let us 760 assume that an End User, at User Agent Y, wishes to use CSP-1's 761 service and that CDN-A decides to delegate the delivery of the 762 content to CDN-B and that CDN-B is willing to perform the delegated 763 delivery. In order for EU-Y to receive content the following 764 illustrative interactions occur: 766 1. UA-Y selects a piece of content (as directed by EU-Y) from 767 CSP-1's service. 769 2. CSP-1 returns a URL, URL-A, for the selected content which 770 resolve to the Request Router in CDN-A, the Authoritative CDN for 771 CSP-1. 773 3. CDN-A's Request Router makes a decision to delegate the delivery 774 to CDN-B. 776 4. CDN-A makes a request to CDN-B to deliver the content on behalf 777 of CDN-A and CDN-B responds with details of how CDN-A's Request 778 Router should respond to the request. 780 5. CDN-A's Request Router returns the appropriate response to UA-Y 781 or another device acting on its behalf (such as a DNS resolver). 783 6. UA-Y will connect to CDN-B and request the content. At this 784 point there are several possible variations: 786 a. The content request is directed to the Request Router of CDN-B. 787 In this manner the UA can be iteratively passed between CDNs. The 788 Request Router of CDN-B may identify a surrogate in CDN-B, or may 789 identify another CDN (as elaborated in the Intermediary Pattern 790 below). 792 b. The content request is directed to a surrogate in CDN-B. 794 7. UA-Y receives the content from the surrogate in CDN-B. Again 795 there are a couple of options: 797 a. The content already exists in the chosen surrogate and is 798 delivered to the UA. 800 b. The content is not stored within the chosen surrogate and is 801 dynamically transferred to the surrogate and sequentially delivered 802 to the UA. 804 8. CDN-B may link the content to URL-B. In this manner another 805 service may use URL-B to preferentially serve the content from CDN-B 806 directly rather than being directed through CDN-A. 808 A.3. Intermediary CDN 810 This use case extends the dual CDN pattern by allowing CDN-B to 811 accept a delegated content delivery from CDN-A and then delegate the 812 delivery to CDN-C. There are a couple of options for this pattern. 814 A.3.1. Option A - Recursive 816 Steps 1 to 3 proceed as for the dual CDN pattern. 818 4. CDN-A makes a request to CDN-B to deliver the content on behalf 819 of CDN-A. CDN-B instead decides to delegate this request to CDN-C, 820 as permiited by its CDN peering agreement with CDN-A. Thus, the 821 Request Router of CDN-B refers the request to the Request Router of 822 CDN-C. CDN-C responds to CDN-B and in turn CDN-A's Request Router 823 with details of how to respond to UA-Y 825 Steps 5 to 8 proceed as for the dual CDN pattern with the exception 826 that CDN-B is replaced by CDN-C. 828 A.3.2. Option B - Iterative 830 Steps 1 to 5 proceed as for the dual CDN pattern. 832 6. UA-Y will connect to CDN-B and request the content. The content 833 request is directed to the Request Router of CDN-B. The Request 834 Router of CDN-B identifies that the request should be serviced by 835 CDN-C. 837 The pattern then proceeds from step 4 of the dual CDN pattern with 838 CDN-A replaced by CDN-B and CDN-B replaced by CDN-C. 840 +-------+ 841 | CSP-1 | 842 +-------+ 843 | 844 ,---------. ,---------. ,---------. 845 ,-' `-. ,-' `-. ,-' `-. 846 ( CDN-A )====( CDN-B )====( CDN-C ) 847 `-. ,-' `-. ,-' `-. ,-' 848 `---------' `---------' `---------' 849 | 850 | 851 ,---------. 852 ,-' `-. 853 ( NSP-Z ) 854 `-. ,-' 855 `---------' 856 | 857 +-------+ 858 | UA-Z | 859 +-------+ 861 ==== CDN Interconnect 863 Authors' Addresses 865 Gilles Bertrand 866 France Telecom - Orange 867 38-40 rue du General Leclerc 868 Issy les moulineaux, 92130 869 FR 871 Phone: +33 1 45 29 89 46 872 Email: gilles.bertrand@orange-ftgroup.com 874 Stephan Emile 875 France Telecom - Orange 876 2 avenue Pierre Marzin 877 Lannion F-22307 878 France 880 Email: emile.stephan@orange-ftgroup.com 882 Grant Watson 883 BT 884 pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham 885 Ipswich, IP5 3RE 886 UK 888 Email: grant.watson@bt.com 890 Trevor Burbridge 891 BT 892 B54 Room 70, Adastral Park, Martlesham 893 Ipswich, IP5 3RE 894 UK 896 Email: trevor.burbridge@bt.com 898 Philip Eardley 899 BT 900 B54 Room 77, Adastral Park, Martlesham 901 Ipswich, IP5 3RE 902 UK 904 Email: philip.eardley@bt.com