idnits 2.17.00 (12 Aug 2021) /tmp/idnits5839/draft-bertrand-cdni-use-cases-00.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 13, 2011) is 4145 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 410, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-jenkins-cdni-problem-statement-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 (~~), 4 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: July 17, 2011 January 13, 2011 7 Use Cases for Content Distribution Network Interconnection 8 draft-bertrand-cdni-use-cases-00 10 Abstract 12 This document depicts use cases for content delivery network (CDN) 13 interconnection based on Orange experiments. The use cases are 14 divided in the two following categories. Category 1 use cases 15 present situations that require a footprint extension for existing 16 CDNs. Category 2 use cases include additional situations where CDN 17 interconnection would be desirable in a longer term. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 17, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. High Level Use Cases for Multi-CDN Systems . . . . . . . . . . 5 69 2.1. Footprint Extension Use Cases . . . . . . . . . . . . . . 5 70 2.1.1. CDN Interconnection inside one CDSP . . . . . . . . . 5 71 2.1.2. CDN Interconnection between CDSPs . . . . . . . . . . 5 72 2.2. Additional Potential Use Cases . . . . . . . . . . . . . . 6 73 2.2.1. CDN Interconnection for CDN Overload Handling . . . . 6 74 2.2.2. CDN Interconnection for CDN Resiliency . . . . . . . . 6 75 2.2.3. Inter-Silos CDN Interconnection inside one CDSP . . . 7 76 3. Experiment with Existing CDN Solutions and Lessons Learned . . 8 77 3.1. Description of the Experiments . . . . . . . . . . . . . . 8 78 3.2. Gaps in Existing Solutions and Need for Specifications . . 9 79 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 This document depicts use cases for content delivery network (CDN) 90 interconnection based on Orange experiments. The use cases are 91 divided in the two following categories. Category 1 use cases 92 present situations that require a footprint extension for existing 93 CDNs. Category 2 use cases include additional situations where CDN 94 interconnection would be desirable in a longer term. 96 The present document complements [I-D.watson-cdni-use-cases]. The 97 two drafts will be merged during the next weeks. 99 1.1. Terminology 101 Except for the terms defined below, we adopt the terminology 102 described in [RFC3466], [RFC3568], and [RFC3570]. 104 Problem statement draft [I-D.jenkins-cdni-problem-statement] defines 105 a set of terms. Below we recall only the terms used in the memo. 107 Content Service Provider (CSP): 109 Provides Content Services to Users. A CSP may own the content made 110 available as part of the Content Service, or may license content 111 rights from another party. 113 Content Service: 115 The service offered by a CSP. The Content Service encompasses the 116 complete service which may be wider than just the delivery of items 117 of Content, e.g. the Content Service also includes any middle-ware, 118 key distribution, program guide, etc. which may not require any 119 direct interaction with the CDN. 121 Content Distribution Network (CDN) / Content Delivery Network (CDN): 123 A type of network in which the components are arranged for more 124 effective delivery of content to User Agents. 126 Content Delivery Service 128 Set of services offered to CSPs for delivering their contents through 129 a single Content Delivery Network or a federation of Content Delivery 130 Networks. 132 CDN Service Provider (CDSP): 134 An administrative entity who operates a CDN over a NSP or over the 135 Internet. 137 CDN federation 139 Set of CDNs that maintain a CDNI relationship to one another. The 140 federation of CDNs can interconnect CDNs operated by the same CDSP or 141 operated by distinct CDSPs. 143 Authoritative CDN (aCDN): 145 The CDSP contracted by the CSP for delivery of contents by this CDN 146 or by its downstream dCDNs. 148 Downstream CDN (dCDN): 150 A CDSP which is contacted by an aCDN to achieve the delivery of 151 content to users. 153 Access CDN 155 A CDN that is the connected to the end-user's access and has 156 information about the end-user's access capabilities and profile. 158 Delivering CDN 160 The CDN that delivers the requested content asset to the end-user. 161 In particular, the delivering CDN can be an access CDN. 163 CDN Interconnection(CDNI): 165 Relationship between two CDNs that enables a CDN to provide content 166 delivery services on behalf of another CDN. It relies on a set of 167 interfaces over which two CDNs communicate in order to achieve the 168 delivery of content to users by one CDN (the downstream CDN) on 169 behalf of another CDN (the upstream CDN). 171 1.2. Acronyms 173 [Ed. Note: List of acronyms to be updated later ] 175 o ISP 177 o NSP 179 o STB 181 o PC 182 o QoS QoE VoD WiFi 3G 184 2. High Level Use Cases for Multi-CDN Systems 186 The prevalent use cases for CDNI are presented according to the CDSPs 187 main reason for interconnecting their CDNs. They are classified 188 according to their level of priority for the CDSPs. 190 The CDNI model helps at building a federation of Content Delivery 191 Networks that collaborate, allowing Content Delivery Service 192 Providers to offer Content Service Providers a set of consistent 193 delivery services throughout the CDN Federation. Let's take an 194 example. CDSP A and B respectively operate CDNa and CDNb. They 195 establish a CDNI relationship for building a CDN federation CDNa-b 196 that consists of CDNa and CDNb. CDSP A reaches an agreement with 197 content service provider CSPa. CDSPa services rely on the CDN 198 federation CDNa-b. Meanwhile, CDSP B reaches an agreement with 199 content service provider CSPb. These services also rely on the CDN 200 federation CDNa-b. 202 2.1. Footprint Extension Use Cases 204 2.1.1. CDN Interconnection inside one CDSP 206 A Large Content delivery service provider (CDSP) operates the CDNs of 207 a set of subsidiaries from different countries, and these CDNs can 208 rely on different CDN solutions. To provide a consistent service to 209 his customers on its whole footprint, in certain circumstances, the 210 CDSP needs to make its CDNs interoperate. 212 Note that currently, the distribution of some content is restricted. 213 For instance, distribution rights for audiovisual content are often 214 negotiated per country. 216 [Ed. Note: FIGURE TO BE INCLUDED] 218 Figure 1: [Ed. Note: Legend to be added ] 220 2.1.2. CDN Interconnection between CDSPs 222 Several CDSPs have a geographically limited footprint (e.g., a 223 country), or do not serve all end-users in a geographic area. 224 Interconnecting CDNs enables CDSPs to provide their services beyond 225 their own footprint by relying on other CDNs. 227 End-users in various countries access TV shows episodes. The CSP 228 that distributes the TV show asks a French CDSP to deliver the serie 229 to several countries. The French CDSP make an agreement with an 230 external CDSP that covers North Africa to provide a CDN service for 231 France and North Africa. 233 This use case applies to other types of contents like automatic 234 software updates (browser updates, operating system patches, or virus 235 database update...). 237 2.2. Additional Potential Use Cases 239 2.2.1. CDN Interconnection for CDN Overload Handling 241 The support of prime time traffic load requires overdimensioning the 242 CDNs. However, prime time of content distribution may differ between 243 two CDNs. Therefore, two CDNs may benefit from dimensioning savings 244 by using resources of the other CDN during the prime time. 246 During a traffic peak, a CDSP redirects some traffic load toward 247 another CDSP (for instance, geographically close). 249 2.2.2. CDN Interconnection for CDN Resiliency 251 It is important for CDNs to be able to guarantee service continuity 252 during partial failures (e.g., failure of a set of surrogates). In 253 partial failure scenarios, a CDSP could redirect some requests toward 254 another CDN. This downstream CDN must be able to serve the 255 redirected requests or, depending on traffic management policies, to 256 forward these requests to the CSP origin server. 258 -------------- -------------- 259 / CDN1 \ / CDN2 \ 260 | ,---. | | ,---. | 261 +---+ | . ) | | . ) | 262 |CSP|*******| |`---'| |__________________| |`---'| | 263 +---+ | | | | Acquisition | | | | 264 | ( ) | | ( ) | 265 | `---' | | `---' | 266 |+-----------+ | |,------------.| 267 ||Req-Routing| | .|Delivery || 268 \+-----------+ / \`------------'/ 269 ------------ .-'----------- 270 | .-' 271 | --------------- > .-' 272 | Redirect .-' 273 | .-' 274 | .-' 275 | .-' 276 | .-' 277 | .-' 278 +-----+ 279 | User| 280 +-----+ 282 Figure 3: Example of CDN Interconnection for failure resiliency 284 2.2.3. Inter-Silos CDN Interconnection inside one CDSP 286 ISPs deployed platforms per service or per network technology. They 287 are deploying CDNs or enhancing existing platforms to CDN. It is 288 desirable in certain circumstances to share the content or the 289 resources among these CDNs. 291 It is desirable to have the ability to provide content to different 292 terminals and through different access technologies, possibly served 293 by different CDNs. As depicted in Figure 2, an end-user can use his 294 tablet to download a VoD through WiFi (1) from CDN1 and then switch 295 to 3G network (2), which is served by CDN2. The end user should be 296 able to access the selected VoD content through any access network 297 technology. Consequently, every considered CDN must have access to 298 this VoD content. One way to proceed consists in having an ingestion 299 interface among the CDNs to access the content. 301 Replication of the requested VoD content in the CDN serving the 302 terminal (a) enables controlling the QoS of the VoD distribution to 303 the terminal used by the end-user. In another situation, the serving 304 of the CoD without replication (b) will save storage resources. 306 The end-user's experience improves thanks to an increase of the 307 number of situations where the end-user can access the service. 309 -------------- -------------- 310 / CDN1 \ / CDN2 \ 311 | Fixed | | Mobile | 312 | ,---. | | ,---. | 313 +---+ | . ) | (a) | . ) | 314 |CSP|****| |`---'| |''''`---------.....>|`---'| | 315 +---+ | | | -.. Acquisition | | | | 316 | ( ) | `-.._ | ( ) | 317 | `---' | `-.. | `---' | 318 |,------------.| (b) ``-._ |,------------.| 319 ||Delivery || `->. Delivery || 320 \`------------'/ \`------------'/ 321 ----------+--- -----*--+----- 322 : * | 323 : * | 324 +........+ +--------+ 325 : Tablet : (1) | Tablet |(2) 326 +........+ +--------+ 328 Figure 2: Example of Inter-Silos CDN Interconnection 330 3. Experiment with Existing CDN Solutions and Lessons Learned 332 3.1. Description of the Experiments 334 To illustrate the realism of the short term scenario described in 335 previous sections, we present here the summary of some of our CDNI 336 experiments. These experiments will be further detailed in a 337 separate draft. 339 We have interconnected two CDNs (CDN A and CDN B)operated by 340 different subsidiaries of a large CDSP. The CDNs cover two different 341 countries henceforth referred to as Country A and Country B. The CDNI 342 experiment supported the services of two CSPs (CSP A and CSP B). 344 In our first experiment, CSP A has an agreement with CDN A for 345 content delivery to end-users located in Country A and Country B. CDN 346 A has an agreement with CDN B, so that CDN A can delegate to CDN B 347 the delivery of content from CSP A to end-users located in Country B. 348 When CDN A receives a content request related to CSP A and from an 349 end-user in Country B, it redirects the end-user to the appropriate 350 content on CDN B. If CDN B does not have a local copy of the 351 requested content yet (cache miss), CDN B ingests the content from 352 CDN A. If CDN A does neither have a local copy of the requested 353 content, it requests it from the CSP's origin servers before sending 354 it to CDN B. 356 In our second experiment, CSP B has an agreement with CDN B for 357 content delivery to end-users located in Country A and Country B. CDN 358 B has an agreement with CDN A, so that CDN B can delegate to CDN A 359 the delivery of content from CSP B to end-users located in Country A. 360 When CDN B receives a content request related to CSP B and from an 361 end-user in Country A, it redirects the end-user to the appropriate 362 content on CDN A. If CDN A does not have a local copy of the 363 requested content yet (cache miss), it requests the content directly 364 from the CSP's origin servers. 366 The differences between the two experiments above are the ingestion 367 operations and the roles of CDN A and B, which rely on CDN solutions 368 from different vendors. 370 3.2. Gaps in Existing Solutions and Need for Specifications 372 Our experiments have shown that the current CDN technologies suffer 373 from the following limitations. 375 o The content management policies must be defined manually. 377 o The target URLs for the request redirection must also be defined 378 manually. 380 o The content ingestion worked only in pull mode... 382 To address more sophisticated scenarios, we consider that common 383 interfaces are required for request routing among interconnected CDNs 384 and for the exchange of content distribution metadata. 386 4. Acknowledgments 388 The authors would like to thank the contributors of the EU FP7 OCEAN 389 project for valuable input and discussions. 391 5. IANA Considerations 393 This memo includes no request to IANA. 395 6. Security Considerations 397 CDN interconnect, as described in this document, has a wide variety 398 of security issues that should be considered. For example, every 399 interconnected CDN should be able to assess if it must serve a 400 delegated request or if this request is delegated by a non-allowed 401 CDN. The CDNs should also be protected so as to avoid being 402 overwhelmed by delegated requests. This document focuses on the 403 technical use cases for CDN interconnect, and therefore, does not 404 analyze the threats in details. 406 7. References 408 7.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 7.2. Informative References 415 [I-D.jenkins-cdni-problem-statement] 416 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 417 Distribution Network Interconnection (CDNI) Problem 418 Statement", draft-jenkins-cdni-problem-statement-00 (work 419 in progress), December 2010. 421 [I-D.watson-cdni-use-cases] 422 Watson, G., "CDN Interconnect Use Cases", 423 draft-watson-cdni-use-cases-00 (work in progress), 424 January 2011. 426 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 427 for Content Internetworking (CDI)", RFC 3466, 428 February 2003. 430 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 431 Content Network (CN) Request-Routing Mechanisms", 432 RFC 3568, July 2003. 434 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 435 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 437 Authors' Addresses 439 Gilles Bertrand 440 France Telecom - Orange 441 38-40 rue du General Leclerc 442 Issy les moulineaux, 92130 443 FR 445 Phone: +33 1 45 29 89 46 446 Email: gilles.bertrand@orange-ftgroup.com 448 Stephan Emile 449 France Telecom - Orange 450 2 avenue Pierre Marzin 451 Lannion F-22307 452 France 454 Email: emile.stephan@orange-ftgroup.com