idnits 2.17.00 (12 Aug 2021) /tmp/idnits4602/draft-bertrand-cdni-experiments-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 (February 16, 2011) is 4111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-cdni-requirements' is defined on line 818, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-use-cases-01 == 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, Ed. 3 Internet-Draft France Telecom R&D 4 Intended status: Informational F. Le Faucheur 5 Expires: August 20, 2011 Cisco Systems 6 L. Peterson 7 Verivue, Inc. 8 February 16, 2011 10 Content Distribution Network Interconnection (CDNI) Experiments 11 draft-bertrand-cdni-experiments-00 13 Abstract 15 This document reports studies and related experiments on CDN 16 interconnection performed by France Telecom-Orange Labs. The 17 document summarizes implications of CDN interconnection to CDN 18 service providers and lessons learned through CDNI experiments. 20 The main purpose of the experiments was to test the interconnection 21 of CDN solutions from two vendors (namely, Cisco and Verivue) and to 22 identify the gaps and needs for standardization work for CDN 23 interconnection. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 20, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. CDN Interconnection Experiments . . . . . . . . . . . . . . . 6 74 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 6 75 2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 2.4. Request Routing and Content Delivery . . . . . . . . . . . 7 78 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 8 79 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 10 80 2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 13 81 2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 13 82 2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 13 83 2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 13 84 2.6.2. Content Acquisition by CDN A Directly from CSP B . . . 15 85 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 16 87 3.1.1. Request-Routing Information and Policies . . . . . . . 16 88 3.1.2. Iterative and Recursive Redirection . . . . . . . . . 16 89 3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 17 90 3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 17 91 3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 18 92 3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 18 93 3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 18 94 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 102 1. Introduction 104 This document reports studies and related experiments on CDN 105 interconnection performed by France Telecom-Orange Labs. The 106 document summarizes implications of CDN interconnection to CDN 107 service providers and lessons learned through CDNI experiments. 109 The main purpose of the experiments was to test the interconnection 110 of CDN solutions from two vendors (namely, Cisco and Verivue) and to 111 identify the gaps and needs for standardization work for CDN 112 interconnection. 114 This study is not intended to explore the entire scope of CDNI, and 115 in fact, it purposely takes a minimalist approach. That is, we focus 116 on what's minimally required to interconnect two cooperating CDNs in 117 a "best effort" way. This provides a constructive foundation for 118 adding requirements and mechanisms only after they prove essential in 119 practice. 121 1.1. Terminology 123 Except for the terms defined below, we adopt the terminology 124 described in [RFC3466], [RFC3568], and [RFC3570]. 126 The problem statement draft [I-D.jenkins-cdni-problem-statement] and 127 the use cases draft [I-D.bertrand-cdni-use-cases] define a set of 128 terms. Below we recall only the terms used in the memo. 130 Content Service Provider (CSP): 132 Provides Content Services to Users. A CSP may own the content made 133 available as part of the Content Service, or may license content 134 rights from another party. 136 Content Service: 138 The service offered by a CSP. The Content Service encompasses the 139 complete service which may be wider than just the delivery of items 140 of Content, e.g., the Content Service also includes any middle-ware, 141 key distribution, program guide, etc., which may not require any 142 direct interaction with the CDN. 144 Content Distribution Network (CDN) / Content Delivery Network (CDN): 146 A type of network in which the components are arranged for more 147 effective delivery of content to User Agents. 149 Content Delivery Service 150 Set of services offered to CSPs for delivering their contents through 151 a single Content Delivery Network or interconnections of Content 152 Delivery Networks. 154 CDN Service Provider (CDSP): 156 An administrative entity who operates a CDN over a Network Service 157 Provider (NSP) or over the Internet. 159 Authoritative CDN (aCDN): 161 The CDSP contracted by the CSP for delivery of content by this CDN or 162 by its downstream CDNs. 164 Downstream CDN (dCDN): 166 A CDSP which is contracted by an aCDN to achieve the delivery of 167 content to users. 169 CDN Interconnection (CDNI): 171 Relationship between two CDNs that enables a CDN to provide content 172 delivery services on behalf of another CDN. It relies on a set of 173 interfaces over which two CDNs communicate in order to achieve the 174 delivery of content to end-users by one CDN (the downstream CDN) on 175 behalf of another CDN (the upstream CDN). 177 Recursive Request Routing: 179 Recursive: Where a process is repeated, but embedded within the 180 original process. In the case of Request Routing, this means that 181 the initial request received by the Authoritative CDN is processed 182 downstream from one CDN to another and that the responses are send 183 back upstream to the Authoritative CDN which then replies to the 184 initial request. 186 Iterative Request Routing: 188 Iterative: Where a process is repeated multiple times to make 189 progress towards a goal. In the case of Request Routing, this means 190 that the initial request is received by the Authoritative CDN, which 191 replies it with a redirection directive to a dowstream CDN. When the 192 end-user sends its request to the downstream CDN, the same process is 193 repeated, until the request arrives to the delivering CDN. 195 User-Agent (UA): 197 A client application acting as the end point of a communication 198 session. 200 2. CDN Interconnection Experiments 202 2.1. Experiment Configuration 204 The interconnection of two CDN solutions from different vendors has 205 been tested. These tests have been run with CDN solutions from Cisco 206 (hereafter referred to as Vendor A) and from Verivue/CoBlitz 207 (hereafter referred to as Vendor B). 209 As depicted in Figure 1, we have interconnected two experimental CDNs 210 (CDN A and CDN B) operated by different subsidiaries of a large CDSP. 211 The CDNs lab equipment were located in two different countries, 212 henceforth referred to as Country A and Country B and they relied on 213 CDN solutions from two different equipment vendors, namely, Vendor A 214 and Vendor B. The CDNI experiment supported the services of two 215 emulated CSPs (CSP A and CSP B). 217 +-------+ : +-------+ 218 | CSP A | : | CSP B | 219 +-------+ : +-------+ 220 | : | 221 ,--,--,--. : ,--,--,--. 222 ,-' CDN A `-. : ,-' CDN B `-. 223 ( (Vendor A) )=====( (Vendor B) ) 224 `-. ,-' : `-. ,-' 225 `--'--'--' : `--'--'--' 226 : 227 COUNTRY A : COUNTRY B 229 === CDN Interconnect 231 Figure 1 233 More precisely, we have run the experiments represented in Figure 2 234 and Figure 4. We base our description on Figure 2. In this 235 experiment, CSP A has an agreement with CDSP A for content delivery 236 to end-users located in Country A and Country B. However, CDSP A 237 operates a CDN (CDN A), whose footprint does not include country B. 238 Therefore, CDSP A has an agreement with CDSP B, so that CDN A can 239 delegate to CDN B the delivery of some content. More specifically, 240 CDN A is allowed to delegate to CDN B the handling of requests sent 241 by end-users located in Country B for CSP A's content. 243 When CDN A receives a content request related to CSP A and from an 244 end-user in Country B, it redirects the end-user to CDN B. If CDN B 245 does not have a local copy of the requested content yet (cache miss), 246 CDN B ingests the content from CDN A (or from the CSP origin servers, 247 depending on the test scenario); if CDN A also does not have a local 248 copy of the requested content, it requests this asset from the CSP 249 origin servers before sending the asset to CDN B. 251 There are several differences between the tests in Figure 2 and 252 Figure 4, in addition to the different role played by the two CDN 253 solutions. We list the main ones below. 255 o We have tested different content acquisition methods (see 256 Section 2.6). 258 o Specific URL schemes were involved in providing content 259 acquisition source information to the downstream CDN. As we have 260 tested different content acquisition methods, depending on which 261 solution played the role of dCDN, the two solutions have used 262 different URL schemes to address content. Therefore, the tests 263 required the configuration of different content delivery metadata 264 on the uCDN (see Section 2.4). 266 o The two solutions use different methods to identify the end-user's 267 geographic locations (see Section 2.4). 269 2.2. Control 271 The tested CDN solutions support control APIs but those are 272 proprietary, so that the tested CDN solutions do not support a common 273 inter-operable CDNI control interface. Therefore, we have not tested 274 CDNI control operations and we had to perform manually most 275 operations related to the configuration of the CDNI. 277 2.3. Logging 279 Proprietary mechanisms to export transaction logs were available in 280 the tested CDN solutions, but have not been covered by our tests. 282 2.4. Request Routing and Content Delivery 284 As defined in [I-D.bertrand-cdni-use-cases], two main types of 285 request-routing call flows can be used for CDNI: 287 1. iterative request-routing, 289 2. recursive request-routing. 291 Moreover, two main methods can be used for redirecting an end-user 292 from the authoritative CDN to the downstream CDN: 294 1. DNS-based redirection, 296 2. Service-level redirection, for example HTTP-based or RTSP-based. 298 We have focused our tests on iterative request-routing. Our tests 299 involved HTTP-based request redirection by the authoritative CDN, as 300 they focused on the delivery of large objects, such as movies. 302 The tested CDN solutions did not feature a CDNI request-routing 303 interface allowing exchange of "CDN routing" information among CDNs. 304 Therefore, we have manually configured appropriate policies on the 305 authoritative CDN to permit iterative request-routing (e.g., CDN A 306 redirects the end-user to CDN B request-routing system, cf. 307 Figure 3). 309 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B 311 This section describes the tested request routing and content 312 delivery features in the scenario depicted in Figure 2, with HTTP 313 redirection by CDN A and delivery by CDN B. 315 We have tested the selection of the downstream CDN based on the 316 content type in the client request and/or the geographic location of 317 the client. 319 o File-type based selection relied on static XML files where content 320 file extensions can be associated to a specific delivery CDN. 322 o The geographic location of the end-user was determined by an 323 external Geolocation server. 325 +-------+ : 326 | CSP A | : 327 +-------+ : 328 | : 329 ,--,--,--. : ,--,--,--. 330 ,-' CDN A `-. : ,-' CDN B `-. 331 ( (Vendor A) )=====( (Vendor B) ) 332 `-. CDSP A ,-' : `-. CDSP B ,-' 333 `--'--'--' : `--'--'--' 334 : | 335 : +------+ 336 : | EU B | 337 : +------+ 338 : 339 COUNTRY A : COUNTRY B 341 === CDN Interconnect 343 Figure 2 345 Figure 3 details the messages exchanged by the components involved in 346 the experiment. 348 End-User CSP A 349 served by contract with 350 CDN B DNS CDN A Geoloc CDN B SurgtB CDN A 351 | DNS REQ (1)| | | | | | 352 |----------->| | | | | | 353 | DNS REP (2)| | | | | | 354 |<-----------| | | | | | 355 | HTTP GET (3) | | | | | 356 |------------+------->| (3.1) | | | | 357 | | |------->| | | | 358 | | | (3.2) | | | | 359 | HTTP 302 (4) |<-------| | | | 360 |<-----------+--------| | | | | 361 | HTTP GET (5) | | | | | 362 |------------+--------+--------+------>| | | 363 | HTTP 302 (6) | | | | | 364 |<-----------+--------+--------+-------| | | 365 | HTTP GET (7) | | | | | 366 |------------+--------+--------+-------+----->| | 367 | HTTP 200 OK (8) | | | | | 368 |<-----------+--------+--------+-------+------| | 370 HTTP redirection by CDN A and delivery by CDN B 371 Figure 3 373 Message details 375 (1) The user-agent sends a DNS request to resolve the FQDN of the 376 content URI. 378 (2) The DNS answers with the IP address of a request-router in CDN A. 380 (3) The user-agent sends to CDN A request-router an HTTP GET request 381 for the content URI. 383 (3.1) CDN A request-router analyzes the request and queries a 384 geolocation database to identify the geographic location of the end- 385 user. 387 (3.2) The geolocation database answers with geolocation information 388 related to the end-user's IP address. The end-user is in country B; 389 thus, CDN A determines that the end-user's request must be served by 390 CDN B. 392 (4) CDN A request-router replies to the user-agent with an HTTP 302 393 redirection message, which provides the URI of the content on CDN B. 395 (5) If necessary, the user-agent resolves the FQDN on the redirection 396 URI (steps not represented in the figure), and thus, determines the 397 IP address of a request-router in CDN B. Then, it sends an HTTP GET 398 request to this request-router. 400 (6) CDN B request-router analyzes the request and replies to the 401 user-agent with an HTTP 302 redirection message that provides the URI 402 of the content on a surrogate in CDN B. 404 (7) If necessary, the user-agent resolves the FQDN of the redirection 405 URI (steps not represented in the figure), and thus, determines the 406 IP address of a surrogate in CDN B. Then, it sends an HTTP GET 407 request to the surrogate. 409 (8) The surrogate analyzes the request and delivers the requested 410 content to the end-user, through an HTTP 200 OK message. 412 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A 414 This section describes the tested request routing and content 415 delivery features in the scenario depicted in Figure 4, with HTTP 416 redirection by CDN B and delivery by CDN A. 418 We have tested the selection of the downstream CDN based on end- 419 user's geolocation. For these tests, the geolocation database had 420 been populated manually with the mapping of IP prefixes to countries. 421 Alternative solutions, such as geolocation based on BGP communities 422 or on the extraction of per country IP prefixes thanks to commercial 423 geoIP databases, exist but they have not been tested in this 424 experiment. 426 : +-------+ 427 : | CSP B | 428 : +-------+ 429 : | 430 ,--,--,--. : ,--,--,--. 431 ,-' CDN A `-. : ,-' CDN B `-. 432 ( (Vendor A) )=====( (Vendor B) ) 433 `-. CDSP A ,-' : `-. CDSP B ,-' 434 `--'--'--' : `--'--'--' 435 | : 436 +------+ : 437 | EU A | : 438 +------+ : 439 : 440 COUNTRY A : COUNTRY B 442 === CDN Interconnect 444 Figure 4 446 Figure 5 details the messages exchanged by the components involved in 447 the experiment. 449 End-User CSP B 450 served by contract with 451 CDN A DNS CDN A Srgt A CDN B CDN B 452 | DNS REQ (1)| | | | | 453 |----------->| | | | | 454 | DNS REP (2)| | | | | 455 |<-----------| | | | | 456 | HTTP GET (3) | | | | 457 |------------+--------+-------+------->| | 458 | HTTP 302 (4) | | | | 459 |<-----------+--------+-------+--------| | 460 | HTTP GET (5) | | | | 461 |------------+------->| | | | 462 | HTTP 302 (6) | | | | 463 |<-----------+--------| | | | 464 | HTTP GET (7) | | | | 465 |------------+--------+------>| | | 466 | HTTP 200 OK (8) | | | | 467 |<-----------+--------+-------| | | 469 HTTP redirection by CDN B and delivery by CDN A 471 Figure 5 473 Message details 475 (1) The user-agent sends a DNS request to resolve the FQDN of the 476 content URI. 478 (2) The DNS answers with the IP address of a request-router in CDN B. 480 (3) The user-agent sends to CDN B request-router an HTTP GET request 481 for the content URI. 483 (4) CDN B request-router analyzes the request. The end-user is in 484 country A; thus, CDN B determines that the end-user's request must be 485 served by CDN A. Consequently, CDN B replies to the user-agent with 486 an HTTP 302 redirection message that provides the URI of the content 487 on CDN A. 489 (5) If necessary, the user-agent resolves the FQDN on the redirection 490 URI (steps not represented in the figure), and thus, determines the 491 IP address of a request-router in CDN A. Then, it sends an HTTP GET 492 request to this request-router. 494 (6) CDN A request-router analyzes the request and replies to the 495 user-agent with an HTTP 302 redirection message, which provides the 496 URI of the content on a surrogate in CDN A. 498 (7) If necessary, the user-agent resolves the FQDN of the redirection 499 URI (steps not represented in the figure), and thus, determines the 500 IP address of a surrogate in CDN A. Then, it sends an HTTP GET 501 request to the surrogate. 503 (8) The surrogate analyzes the request and delivers the requested 504 content to the end-user, through an HTTP 200 OK message. 506 2.4.3. Test Result 508 HTTP redirection by the authoritative CDN was successful in the 509 tests: end-users were redirected to the CDN that served their 510 country. This guaranteed that: 512 o content from CSP A be delivered by CDN B to end-users in country 513 B, even if CSP A had no direct relationship with CDSP B; 515 o content from CSP B be delivered by CDN A to end-users in country 516 A, even if CSP B had no direct relationship with CDSP A. 518 2.5. Content Delivery Metadata 520 The tested CDN solutions feature proprietary Metadata APIs, but these 521 APIs have not been covered by the tests. We had to configure 522 distribution metadata consistently in the dCDN and the uCDN (e.g., 523 rules to determine upstream source for content acquisition). 525 Content pre-positioning in the dCDN has not been tested: only dynamic 526 content acquisition has been covered by the experiments. 528 Proprietary APIs were available for content purge, but those have not 529 been covered by tests. 531 2.6. Content Acquisition 533 We have used regular HTTP for Content Acquisition. We have relied on 534 HTTP custom headers to transfer trivial metadata such as content 535 integrity check (MD5 hash). 537 The correct acquisition and delivery of the requested file has been 538 tested for Adobe Flash and MS HTTP smooth-streaming files. 540 2.6.1. Content Acquisition by CDN B through CDN A 542 We describe here the content acquisition operations triggered in case 543 of cache miss, for the test scenario depicted in Figure 2 and 544 Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In 545 this scenario, the dCDN (CDN B) does not have the requested content 546 in cache and must request it to the uCDN (CDN A). 548 The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides 549 a summary (the involved internal entities of the uCDN are not 550 detailed) of the related content acquisition operations. 551 Section 3.1.3 provides more details on specific issues related to 552 this content acquisition mode. 554 End-User CSP A 555 served by contract with 556 CDN B DNS CDN A Geoloc CDN B CDN A 557 | | | | | | 558 | | | HTTP GET (7.1) | | 559 | | |<--------+-----------| | 560 | | | HTTP GET (7.2) | | 561 | | |---------+-----------+----------->| 562 | | | HTTP 200 OK (7.3) | | 563 | | |<--------+-----------+------------| 564 | | | HTTP 200 OK (7.4) | | 565 | | |---------+---------->| | 566 | | | | | | 568 Pull content acquisition by CDN B through CDN A in case of cache miss 569 (continuation of Figure 3) 571 Figure 6 573 Message details 575 (7.1) CDN B surrogate or parent cache sends a content acquisition 576 request to the uCDN (CDN A). In the tests, (7.1) was triggered by a 577 cache miss on delivery request. Stated differently, the tests 578 implemented dynamic acquisition, as opposed to content pre- 579 positioning. 581 (7.2) CDN A analyzes the request. In case of cache miss, it sends an 582 acquisition request to the CSP's origin servers. 584 (7.3) The CSP's origin server authorizes the request and delivers the 585 requested content to CDN A, through an HTTP 200 OK. 587 (7.4) CDN A delivers the requested content to CDN B surrogate or 588 parent cache, through an HTTP 200 OK. 590 2.6.2. Content Acquisition by CDN A Directly from CSP B 592 We describe here (Figure 7) the content acquisition operations 593 triggered in case of cache miss, for the test scenario with HTTP 594 redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5). 595 In this scenario, the dCDN (CDN A) does not have the requested 596 content in cache and must request it to CSP B. 598 End-User CSP B 599 served by contract with 600 CDN A DNS CDN A CDN B CDN B 601 | | | | | 602 | | |HTTP GET (7.1) | 603 | | |-------------+----------->| 604 | | |HTTP 200 OK (7.2) | 605 | | |<------------+------------| 607 Pull content acquisition by CDN A directly from content provider's 608 origin servers in case of cache miss (continuation of Figure 5) 610 Figure 7 612 Message details 614 (7.1) CDN A surrogate sends a content acquisition request to an 615 origin server of the CSP. In the tests, (7.1) was triggered by a 616 cache miss on a delivery request. Stated differently, the tests 617 implemented dynamic acquisition, as opposed to content pre- 618 positioning. 620 (7.2) The CSP's origin server authorizes the request and delivers the 621 requested content to CDN A, through an HTTP 200 OK. 623 3. Lessons Learned 625 For basic interconnection tests, we have relied on extremely limited 626 information exchanges between the two interconnected CDNs and we have 627 configured most CDNI related features manually. This is because, 628 while present CDN technologies support APIs allowing configuration of 629 some of this information, those are difficult to use in multi-vendor 630 environments since: 632 o they are proprietary APIs; 633 o they are designed as "internal" APIs and therefore lack the 634 necessary inter-domain security and policy control. 636 Therefore, those APIs have not been used in these tests. 638 In the present section, we highlight some of the limitations induced 639 by the lack of standard CDNI interfaces that we have faced in our 640 tests. 642 One of the insights from this work is that by encoding information 643 inside the redirection URI, it is possible to communicate some 644 essential CDNI-related information across CDNs "in-band" (i.e., as 645 part of HTTP), rather than communicating it through an out-of-band 646 interface. In these tests, the information communicated in-band was 647 restricted to the most fundamental information, that is, a handle 648 allowing the Downstream CDN to determine where to acquire the 649 content. This was key to achieving multi-CDN operations without any 650 common CDNI "out-of-band" interface supported by existing CDN 651 technologies. This raises an interesting general question: what 652 subset of inter-CDN information is to be communicated between 653 interconnected CDNs in-band (possibly using existing methods) as 654 opposed to communicated via out-of-band interfaces? 656 3.1. Request Routing 658 3.1.1. Request-Routing Information and Policies 660 Because of the lack of CDNI interfaces allowing CDNs to exchange 661 information such as their coverage, capabilities, and performance, we 662 had to configure request-routing policies manually in the CDNs that 663 acted as uCDNs. While this may be tolerable for initial limited 664 deployments of CDNI scenarios with a small number of participants, 665 this is expected to create operational constraints in larger scale 666 deployments. 668 3.1.2. Iterative and Recursive Redirection 670 Because of the lack of CDNI interfaces allowing an upstream CDN to 671 query dCDN for how to redirect a request, the tests only covered 672 iterative redirection (i.e. uCDN redirects the user-agent to the dCDN 673 request-routing system, which redirects the user-agent to ...), not 674 recursive redirection. 676 While iterative redirection allows supporting redirection across 677 CDNs, it has some limitations: 679 o multiple redirections are exposed to the end-user; 680 o redirection latency cannot easily be reduced for future requests, 681 through the caching of request-routing decisions; 683 o some client implementations support a limited number of successive 684 redirections; 686 o the dCDN cannot reject a redirection, while allowing the uCDN to 687 handle the rejected request. 689 A standard request-routing API would allow supporting recursive 690 redirection, which removes these shortcomings. 692 3.1.3. Request Looping Avoidance 694 In case of cache-miss, the downstream CDN must fetch the requested 695 content, either through the authoritative CDN, or directly from the 696 CSP's origin server. 698 Consider the situation where the downstream CDN fetches the content 699 from the authoritative CDN, as illustrated in Section 2.6.1. In this 700 case, the authoritative CDN must not redirect the acquisition request 701 to the downstream CDN, because this would create the following 702 request-routing loop: dCDN -> uCDN -> dCDN. Consequently, the 703 upstream CDN must be able to determine that the source of the request 704 is a partner CDN and not a regular end-user. In addition, the 705 upstream CDN must be able to, to acquire content from the CSP's 706 origin server on behalf of the downstream CDN, if necessary: dCDN -> 707 uCDN -> CSP. 709 In the tests, we have successfully solved the request-looping issue, 710 through the use of separated URL spaces for regular users and CDN 711 users, as well as the manual configuration of appropriate request- 712 routing policies for every URL space. In other words, the URL used 713 by regular users to fetch content was different from the one used by 714 the downstream CDN to fetch the content. This way, we eliminated the 715 loops. More automated operation would be required in larger-scale 716 deployments. 718 3.2. Content Delivery Metadata 720 CDN technology typically supports APIs allowing creation, update, and 721 deletion of content delivery metadata in the CDN. However, while 722 often similar, those are proprietary and would require custom 723 support. In the tests, passing of the most essential information, 724 i.e., the upstream source for content acquisition, was achieved 725 indirectly via conveying a handle inside the URI and configuring 726 manually in the downstream CDN rules for extracting the upstream 727 source. 729 The upstream source for content acquisition can be specified through 730 the use of a specific URI scheme. For example, CDN A could use the 731 following scheme: http://cdni.cdna.com/origin-URI to point to a 732 cached copy of the content reachable at "origin-URI". The domain 733 name inside the URI scheme designates the request-routing system of a 734 CDN, and the remainder of the URI defines upstream source for content 735 acquisition: here, the content URI on the CSP's origin servers. If 736 the authoritative CDN and the downstream CDN use this URI scheme, the 737 authoritative CDN can easily map the URI that it receives in the end- 738 user's content request with a valid URI on the downstream CDN. 739 Similarly, the downstream CDN can easily extract a content 740 acquisition URI from the redirection URI. 742 In our tests, we have configured manually the rules that enabled the 743 authoritative CDN to redirect end-users to a valid URI on the 744 downstream CDN, and the downstream CDN to ingest content from the 745 appropriate upstream source. While this allowed validation of the 746 content distribution model, this solution may not be viable in a 747 production environment, as it imposes constraints on URI structure. 748 In addition, this approach does not support exchange of other 749 distribution metadata (e.g., geo-blocking, content validation,...) 750 which would require to be manually configured in the downstream CDN. 751 In a real-world deployment, the configuration of these policies could 752 rely on information that interconnected CDNs would exchange through a 753 CDNI interface. 755 3.3. Content Acquisition and Deletion 757 3.3.1. Content Pre-Positioning in Downstream CDN 759 CDN technology typically supports APIs that allow triggering of 760 content and metadata pre-positioning in a CDN. However, while often 761 similar, these APIs are proprietary and would require custom support. 762 For this reason content pre-positioning in dCDN was not covered in 763 the tests. While the highest requirements is for support of dynamic 764 acquisition, CDNI use-cases (defined in 765 [I-D.bertrand-cdni-use-cases]) call for support of pre-positioning, 766 which requires a triggering mechanism in a CDNI API. 768 3.3.2. Content Purge 770 CDN technology typically supports APIs allowing content purge in a 771 CDN. However, while often similar, these APIs are proprietary and 772 would require custom support. For this reason, content purge was not 773 covered in the tests. There is a strong requirement for content 774 purge in CDNI scenarios, which introduces the need for a purge 775 triggering mechanism in a CDNI API. 777 4. Acknowledgments 779 The authors would like to acknowledge the work of Elodie Hemon and 780 Sharon Schwartzman on the tests. They would like to thank Slim Gara, 781 Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for 782 valuable input and discussions. Finally, the authors acknowledge 783 interesting discussions with contributors of the EU FP7 OCEAN 784 project. 786 5. IANA Considerations 788 This memo includes no request to IANA. 790 6. Security Considerations 792 CDN interconnect, as described in this document, has a wide variety 793 of security issues that should be considered. This document focuses 794 on specific experiments for CDN interconnect, and therefore, does not 795 analyze the threats in detail. 797 7. References 799 7.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 7.2. Informative References 806 [I-D.bertrand-cdni-use-cases] 807 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and 808 P. Eardley, "Use Cases for Content Distribution Network 809 Interconnection", draft-bertrand-cdni-use-cases-01 (work 810 in progress), January 2011. 812 [I-D.jenkins-cdni-problem-statement] 813 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 814 Distribution Network Interconnection (CDNI) Problem 815 Statement", draft-jenkins-cdni-problem-statement-01 (work 816 in progress), January 2011. 818 [I-D.lefaucheur-cdni-requirements] 819 Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee, 820 "Content Distribution Network Interconnection (CDNI) 821 Requirements", draft-lefaucheur-cdni-requirements-00 (work 822 in progress), January 2011. 824 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 825 for Content Internetworking (CDI)", RFC 3466, 826 February 2003. 828 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 829 Content Network (CN) Request-Routing Mechanisms", 830 RFC 3568, July 2003. 832 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 833 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 835 Authors' Addresses 837 Gilles Bertrand (editor) 838 France Telecom R&D 839 38-40 rue du General Leclerc 840 Issy les Moulineaux 92130 841 FR 843 Phone: +33 1 45 29 89 46 844 Email: gilles.bertrand@orange-ftgroup.com 846 Francois Le Faucheur 847 Cisco Systems 848 Greenside, 400 Avenue de Roumanille 849 Sophia Antipolis 06410 850 FR 852 Phone: +33 4 97 23 26 19 853 Email: flefauch@cisco.com 855 Larry Peterson 856 Verivue, Inc. 857 2 Research Way 858 Princeton, NJ 08540 859 US 861 Phone: +1 978 303 8032 862 Email: lpeterson@verivue.com