idnits 2.17.00 (12 Aug 2021) /tmp/idnits1358/draft-bertrand-cdni-experiments-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 (August 19, 2011) is 3927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'I-D.lefaucheur-cdni-requirements' is defined on line 806, but no explicit reference was found in the text -- 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, Ed. 3 Internet-Draft France Telecom - Orange 4 Intended status: Informational F. Le Faucheur 5 Expires: February 20, 2012 Cisco Systems 6 L. Peterson 7 Verivue, Inc. 8 August 19, 2011 10 Content Distribution Network Interconnection (CDNI) Experiments 11 draft-bertrand-cdni-experiments-01 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 February 20, 2012. 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 . . . . . . . . . . . . . . . 5 74 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 12 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 CP B . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 18 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], [RFC3570], the problem statement 125 draft [I-D.jenkins-cdni-problem-statement] and the use cases draft 126 [I-D.bertrand-cdni-use-cases]. 128 Content Distribution Network (CDN) / Content Delivery Network (CDN): 130 A type of network in which the components are arranged for more 131 effective delivery of content to User Agents. 133 Content Delivery Service 135 Set of services offered to content providers (CPs) for delivering 136 their content through a single Content Delivery Network or 137 interconnections of Content Delivery Networks. 139 CDN Service Provider (CDSP): 141 An administrative entity who operates a CDN over a Network Service 142 Provider (NSP) or over the Internet. 144 Authoritative CDN (aCDN): 146 The CDSP contracted by the CP for delivery of content by this CDN or 147 by its downstream CDNs. 149 Downstream CDN (dCDN): 151 A CDSP which is contracted by an upstream CDN to achieve the delivery 152 of content to users. 154 CDN Interconnection (CDNI): 156 Relationship between two CDNs that enables a CDN to provide content 157 delivery services on behalf of another CDN. It relies on a set of 158 interfaces over which two CDNs communicate in order to achieve the 159 delivery of content to end-users by one CDN (the downstream CDN) on 160 behalf of another CDN (the upstream CDN). 162 Recursive Request Routing: 164 Recursive: Where a process is repeated, but embedded within the 165 original process. In the case of Request Routing, this means that 166 the initial request received by the Authoritative CDN is processed 167 downstream from one CDN to another and that the responses are send 168 back upstream to the Authoritative CDN which then replies to the 169 initial request. 171 Iterative Request Routing: 173 Iterative: Where a process is repeated multiple times to make 174 progress towards a goal. In the case of Request Routing, this means 175 that the initial request is received by the Authoritative CDN, which 176 replies it with a redirection directive to a dowstream CDN. When the 177 end-user sends its request to the downstream CDN, the same process is 178 repeated, until the request arrives to the delivering CDN. 180 User-Agent (UA): 182 A client application acting as the end point of a communication 183 session. 185 2. CDN Interconnection Experiments 187 2.1. Experiment Configuration 189 The interconnection of two CDN solutions from different vendors has 190 been tested. These tests have been run with CDN solutions from Cisco 191 (hereafter referred to as Vendor A) and from Verivue/CoBlitz 192 (hereafter referred to as Vendor B). 194 As depicted in Figure 1, we have interconnected two experimental CDNs 195 (CDN A and CDN B) operated by different subsidiaries of a large CDSP. 196 The CDNs lab equipment were located in two different countries, 197 henceforth referred to as Country A and Country B and they relied on 198 CDN solutions from two different equipment vendors, namely, Vendor A 199 and Vendor B. The CDNI experiment supported the services of two 200 emulated CPs (CP A and CP B). 202 +-------+ : +-------+ 203 | CP A | : | CP B | 204 +-------+ : +-------+ 205 | : | 206 ,--,--,--. : ,--,--,--. 207 ,-' CDN A `-. : ,-' CDN B `-. 208 ( (Vendor A) )=====( (Vendor B) ) 209 `-. ,-' : `-. ,-' 210 `--'--'--' : `--'--'--' 211 : 212 COUNTRY A : COUNTRY B 214 === CDN Interconnect 216 Figure 1 218 More precisely, we have run the experiments represented in Figure 2 219 and Figure 4. We base our description on Figure 2. In this 220 experiment, CP A has an agreement with CDSP A for content delivery to 221 end-users located in Country A and Country B. However, CDSP A 222 operates a CDN (CDN A), whose footprint does not include country B. 223 Therefore, CDSP A has an agreement with CDSP B, so that CDN A can 224 delegate to CDN B the delivery of some content. More specifically, 225 CDN A is allowed to delegate to CDN B the handling of requests sent 226 by end-users located in Country B for CP A's content. 228 When CDN A receives a content request related to CP A and from an 229 end-user in Country B, it redirects the end-user to CDN B. If CDN B 230 does not have a local copy of the requested content yet (cache miss), 231 CDN B ingests the content from CDN A (or from the CP's origin 232 servers, depending on the test scenario); if CDN A also does not have 233 a local copy of the requested content, it requests this asset from 234 the CP's origin servers before sending the asset to CDN B. 236 There are several differences between the tests in Figure 2 and 237 Figure 4, in addition to the different role played by the two CDN 238 solutions. We list the main ones below. 240 o We have tested different content acquisition methods (see 241 Section 2.6). 243 o Specific URL schemes were involved in providing content 244 acquisition source information to the downstream CDN. As we have 245 tested different content acquisition methods, depending on which 246 solution played the role of dCDN, the two solutions have used 247 different URL schemes to address content. Therefore, the tests 248 required the configuration of different content delivery metadata 249 on the uCDN (see Section 2.4). 251 o The two solutions use different methods to identify the end-user's 252 geographic locations (see Section 2.4). 254 2.2. Control 256 The tested CDN solutions support control APIs but those are 257 proprietary, so that the tested CDN solutions do not support a common 258 inter-operable CDNI control interface. Therefore, we have not tested 259 CDNI control operations and we had to perform manually most 260 operations related to the configuration of the CDNI. 262 2.3. Logging 264 Proprietary mechanisms to export transaction logs were available in 265 the tested CDN solutions, but have not been covered by our tests. 267 2.4. Request Routing and Content Delivery 269 As defined in [I-D.bertrand-cdni-use-cases], two main types of 270 request-routing call flows can be used for CDNI: 272 1. iterative request-routing, 274 2. recursive request-routing. 276 Moreover, two main methods can be used for redirecting an end-user 277 from the authoritative CDN to the downstream CDN: 279 1. DNS-based redirection, 281 2. Service-level redirection, for example HTTP-based or RTSP-based. 283 We have focused our tests on iterative request-routing. Our tests 284 involved HTTP-based request redirection by the authoritative CDN, as 285 they focused on the delivery of large objects, such as movies. 287 The tested CDN solutions did not feature a CDNI request-routing 288 interface allowing exchange of "CDN routing" information among CDNs. 289 Therefore, we have manually configured appropriate policies on the 290 authoritative CDN to permit iterative request-routing (e.g., CDN A 291 redirects the end-user to CDN B request-routing system, cf. 292 Figure 3). 294 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B 296 This section describes the tested request routing and content 297 delivery features in the scenario depicted in Figure 2, with HTTP 298 redirection by CDN A and delivery by CDN B. 300 We have tested the selection of the downstream CDN based on the 301 content type in the client request and/or the geographic location of 302 the client. 304 o File-type based selection relied on static XML files where content 305 file extensions can be associated to a specific delivery CDN. 307 o The geographic location of the end-user was determined by an 308 external geolocation server. 310 +-------+ : 311 | CP A | : 312 +-------+ : 313 | : 314 ,--,--,--. : ,--,--,--. 315 ,-' CDN A `-. : ,-' CDN B `-. 316 ( (Vendor A) )=====( (Vendor B) ) 317 `-. CDSP A ,-' : `-. CDSP B ,-' 318 `--'--'--' : `--'--'--' 319 : | 320 : +------+ 321 : | EU B | 322 : +------+ 323 : 324 COUNTRY A : COUNTRY B 326 === CDN Interconnect 328 Figure 2 330 Figure 3 details the messages exchanged by the components involved in 331 the experiment. 333 End-User CP A 334 served by contract with 335 CDN B DNS CDN A Geoloc CDN B SurgtB CDN A 336 | DNS REQ (1)| | | | | | 337 |----------->| | | | | | 338 | DNS REP (2)| | | | | | 339 |<-----------| | | | | | 340 | HTTP GET (3) | | | | | 341 |------------+------->| (3.1) | | | | 342 | | |------->| | | | 343 | | | (3.2) | | | | 344 | HTTP 302 (4) |<-------| | | | 345 |<-----------+--------| | | | | 346 | HTTP GET (5) | | | | | 347 |------------+--------+--------+------>| | | 348 | HTTP 302 (6) | | | | | 349 |<-----------+--------+--------+-------| | | 350 | HTTP GET (7) | | | | | 351 |------------+--------+--------+-------+----->| | 352 | HTTP 200 OK (8) | | | | | 353 |<-----------+--------+--------+-------+------| | 355 HTTP redirection by CDN A and delivery by CDN B 357 Figure 3 359 Message details 361 (1) The user-agent sends a DNS request to resolve the FQDN of the 362 content URI. 364 (2) The DNS answers with the IP address of a request-router in CDN A. 366 (3) The user-agent sends to CDN A request-router an HTTP GET request 367 for the content URI. 369 (3.1) CDN A request-router analyzes the request and queries a 370 geolocation database to identify the geographic location of the end- 371 user. 373 (3.2) The geolocation database answers with geolocation information 374 related to the end-user's IP address. The end-user is in country B; 375 thus, CDN A determines that the end-user's request must be served by 376 CDN B. 378 (4) CDN A request-router replies to the user-agent with an HTTP 302 379 redirection message, which provides the URI of the content on CDN B. 381 (5) If necessary, the user-agent resolves the FQDN on the redirection 382 URI (steps not represented in the figure), and thus, determines the 383 IP address of a request-router in CDN B. Then, it sends an HTTP GET 384 request to this request-router. 386 (6) CDN B request-router analyzes the request and replies to the 387 user-agent with an HTTP 302 redirection message that provides the URI 388 of the content on a surrogate in CDN B. 390 (7) If necessary, the user-agent resolves the FQDN of the redirection 391 URI (steps not represented in the figure), and thus, determines the 392 IP address of a surrogate in CDN B. Then, it sends an HTTP GET 393 request to the surrogate. 395 (8) The surrogate analyzes the request and delivers the requested 396 content to the end-user, through an HTTP 200 OK message. 398 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A 400 This section describes the tested request routing and content 401 delivery features in the scenario depicted in Figure 4, with HTTP 402 redirection by CDN B and delivery by CDN A. 404 We have tested the selection of the downstream CDN based on end- 405 user's geolocation. For these tests, the geolocation database had 406 been populated manually with the mapping of IP prefixes to countries. 407 Alternative solutions, such as geolocation based on BGP communities 408 or on the extraction of per country IP prefixes thanks to commercial 409 geoIP databases, exist but they have not been tested in this 410 experiment. 412 : +-------+ 413 : | CP B | 414 : +-------+ 415 : | 416 ,--,--,--. : ,--,--,--. 417 ,-' CDN A `-. : ,-' CDN B `-. 418 ( (Vendor A) )=====( (Vendor B) ) 419 `-. CDSP A ,-' : `-. CDSP B ,-' 420 `--'--'--' : `--'--'--' 421 | : 422 +------+ : 423 | EU A | : 424 +------+ : 425 : 426 COUNTRY A : COUNTRY B 428 === CDN Interconnect 430 Figure 4 432 Figure 5 details the messages exchanged by the components involved in 433 the experiment. 435 End-User CP B 436 served by contract with 437 CDN A DNS CDN A Srgt A CDN B CDN B 438 | DNS REQ (1)| | | | | 439 |----------->| | | | | 440 | DNS REP (2)| | | | | 441 |<-----------| | | | | 442 | HTTP GET (3) | | | | 443 |------------+--------+-------+------->| | 444 | HTTP 302 (4) | | | | 445 |<-----------+--------+-------+--------| | 446 | HTTP GET (5) | | | | 447 |------------+------->| | | | 448 | HTTP 302 (6) | | | | 449 |<-----------+--------| | | | 450 | HTTP GET (7) | | | | 451 |------------+--------+------>| | | 452 | HTTP 200 OK (8) | | | | 453 |<-----------+--------+-------| | | 455 HTTP redirection by CDN B and delivery by CDN A 457 Figure 5 459 Message details 461 (1) The user-agent sends a DNS request to resolve the FQDN of the 462 content URI. 464 (2) The DNS answers with the IP address of a request-router in CDN B. 466 (3) The user-agent sends to CDN B request-router an HTTP GET request 467 for the content URI. 469 (4) CDN B request-router analyzes the request. The end-user is in 470 country A; thus, CDN B determines that the end-user's request must be 471 served by CDN A. Consequently, CDN B replies to the user-agent with 472 an HTTP 302 redirection message that provides the URI of the content 473 on CDN A. 475 (5) If necessary, the user-agent resolves the FQDN on the redirection 476 URI (steps not represented in the figure), and thus, determines the 477 IP address of a request-router in CDN A. Then, it sends an HTTP GET 478 request to this request-router. 480 (6) CDN A request-router analyzes the request and replies to the 481 user-agent with an HTTP 302 redirection message, which provides the 482 URI of the content on a surrogate in CDN A. 484 (7) If necessary, the user-agent resolves the FQDN of the redirection 485 URI (steps not represented in the figure), and thus, determines the 486 IP address of a surrogate in CDN A. Then, it sends an HTTP GET 487 request to the surrogate. 489 (8) The surrogate analyzes the request and delivers the requested 490 content to the end-user, through an HTTP 200 OK message. 492 2.4.3. Test Result 494 HTTP redirection by the authoritative CDN was successful in the 495 tests: end-users were redirected to the CDN that served their 496 country. This guaranteed that: 498 o content from CP A be delivered by CDN B to end-users in country B, 499 even if CP A had no direct relationship with CDSP B; 501 o content from CP B be delivered by CDN A to end-users in country A, 502 even if CP B had no direct relationship with CDSP A. 504 2.5. Content Delivery Metadata 506 The tested CDN solutions feature proprietary metadata APIs, but these 507 APIs have not been covered by the tests. We had to configure 508 distribution metadata consistently in the dCDN and the uCDN (e.g., 509 rules to determine upstream source for content acquisition). 511 Content pre-positioning in the dCDN has not been tested: only dynamic 512 content acquisition has been covered by the experiments. 514 Proprietary APIs were available for content purge, but those have not 515 been covered by tests. 517 2.6. Content Acquisition 519 We have used regular HTTP for content acquisition. We have relied on 520 HTTP custom headers to transfer trivial metadata such as content 521 integrity check (MD5 hash). 523 The correct acquisition and delivery of the requested file has been 524 tested for Adobe Flash and MS HTTP smooth-streaming files. 526 2.6.1. Content Acquisition by CDN B through CDN A 528 We describe here the content acquisition operations triggered in case 529 of cache miss, for the test scenario depicted in Figure 2 and 530 Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In 531 this scenario, the dCDN (CDN B) does not have the requested content 532 in cache and must request it to the uCDN (CDN A). 534 The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides 535 a summary (the involved internal entities of the uCDN are not 536 detailed) of the related content acquisition operations. 537 Section 3.1.3 provides more details on specific issues related to 538 this content acquisition mode. 540 End-User CP A 541 served by contract with 542 CDN B DNS CDN A Geoloc CDN B CDN A 543 | | | | | | 544 | | | HTTP GET (7.1) | | 545 | | |<--------+-----------| | 546 | | | HTTP GET (7.2) | | 547 | | |---------+-----------+----------->| 548 | | | HTTP 200 OK (7.3) | | 549 | | |<--------+-----------+------------| 550 | | | HTTP 200 OK (7.4) | | 551 | | |---------+---------->| | 552 | | | | | | 554 Pull content acquisition by CDN B through CDN A in case of cache miss 555 (continuation of Figure 3) 557 Figure 6 559 Message details 561 (7.1) CDN B surrogate or parent cache sends a content acquisition 562 request to the uCDN (CDN A). In the tests, (7.1) was triggered by a 563 cache miss on delivery request. Stated differently, the tests 564 implemented dynamic acquisition, as opposed to content pre- 565 positioning. 567 (7.2) CDN A analyzes the request. In case of cache miss, it sends an 568 acquisition request to the CP's origin servers. 570 (7.3) The CP's origin server authorizes the request and delivers the 571 requested content to CDN A, through an HTTP 200 OK. 573 (7.4) CDN A delivers the requested content to CDN B surrogate or 574 parent cache, through an HTTP 200 OK. 576 2.6.2. Content Acquisition by CDN A Directly from CP B 578 We describe here (Figure 7) the content acquisition operations 579 triggered in case of cache miss, for the test scenario with HTTP 580 redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5). 581 In this scenario, the dCDN (CDN A) does not have the requested 582 content in cache and must request it to CP B. 584 End-User CP B 585 served by contract with 586 CDN A DNS CDN A CDN B CDN B 587 | | | | | 588 | | |HTTP GET (7.1) | 589 | | |-------------+----------->| 590 | | |HTTP 200 OK (7.2) | 591 | | |<------------+------------| 593 Pull content acquisition by CDN A directly from content provider's 594 origin servers in case of cache miss (continuation of Figure 5) 596 Figure 7 598 Message details 600 (7.1) CDN A surrogate sends a content acquisition request to an 601 origin server of the CP. In the tests, (7.1) was triggered by a 602 cache miss on a delivery request. Stated differently, the tests 603 implemented dynamic acquisition, as opposed to content pre- 604 positioning. 606 (7.2) The CP's origin server authorizes the request and delivers the 607 requested content to CDN A, through an HTTP 200 OK. 609 3. Lessons Learned 611 For basic interconnection tests, we have relied on extremely limited 612 information exchanges between the two interconnected CDNs and we have 613 configured most CDNI related features manually. This is because, 614 while present CDN technologies support APIs allowing configuration of 615 some of this information, those are difficult to use in multi-vendor 616 environments since: 618 o they are proprietary APIs; 620 o they are designed as "internal" APIs and therefore lack the 621 necessary inter-domain security and policy control. 623 Therefore, those APIs have not been used in these tests. 625 In the present section, we highlight some of the limitations induced 626 by the lack of standard CDNI interfaces that we have faced in our 627 tests. 629 One of the insights from this work is that by encoding information 630 inside the redirection URI, it is possible to communicate some 631 essential CDNI-related information across CDNs "in-band" (i.e., as 632 part of HTTP), rather than communicating it through an out-of-band 633 interface. In these tests, the information communicated in-band was 634 restricted to the most fundamental information, that is, a handle 635 allowing the Downstream CDN to determine where to acquire the 636 content. This was key to achieving multi-CDN operations without any 637 common CDNI "out-of-band" interface supported by existing CDN 638 technologies. This raises an interesting general question: what 639 subset of inter-CDN information is to be communicated between 640 interconnected CDNs in-band (possibly using existing methods) as 641 opposed to communicated via out-of-band interfaces? 643 3.1. Request Routing 645 3.1.1. Request-Routing Information and Policies 647 Because of the lack of CDNI interfaces allowing CDNs to exchange 648 information such as their coverage, capabilities, and performance, we 649 had to configure request-routing policies manually in the CDNs that 650 acted as uCDNs. While this may be tolerable for initial limited 651 deployments of CDNI scenarios with a small number of participants, 652 this is expected to create operational constraints in larger scale 653 deployments. 655 3.1.2. Iterative and Recursive Redirection 657 Because of the lack of CDNI interfaces allowing an upstream CDN to 658 query dCDN for how to redirect a request, the tests only covered 659 iterative redirection (i.e. uCDN redirects the user-agent to the dCDN 660 request-routing system, which redirects the user-agent to ...), not 661 recursive redirection. 663 While iterative redirection allows supporting redirection across 664 CDNs, it has some limitations: 666 o multiple redirections are exposed to the end-user; 668 o redirection latency cannot easily be reduced for future requests, 669 through the caching of request-routing decisions; 671 o some client implementations support a limited number of successive 672 redirections; 674 o the dCDN cannot reject a redirection, while allowing the uCDN to 675 handle the rejected request. 677 A standard request-routing API would allow supporting recursive 678 redirection, which removes these shortcomings. 680 3.1.3. Request Looping Avoidance 682 In case of cache-miss, the downstream CDN must fetch the requested 683 content, either through the authoritative CDN, or directly from the 684 CP's origin server. 686 Consider the situation where the downstream CDN fetches the content 687 from the authoritative CDN, as illustrated in Section 2.6.1. In this 688 case, the authoritative CDN must not redirect the acquisition request 689 to the downstream CDN, because this would create the following 690 request-routing loop: dCDN -> uCDN -> dCDN. Consequently, the 691 upstream CDN must be able to determine that the source of the request 692 is a partner CDN and not a regular end-user. In addition, the 693 upstream CDN must be able to acquire content from the CP's origin 694 server on behalf of the downstream CDN, if necessary: dCDN -> uCDN -> 695 CP. 697 In the tests, we have successfully solved the request-looping issue, 698 through the use of separated URL spaces for regular users and CDN 699 users, as well as the manual configuration of appropriate request- 700 routing policies for every URL space. In other words, the URL used 701 by regular users to fetch content was different from the one used by 702 the downstream CDN to fetch the content. This way, we eliminated the 703 loops. More automated operation would be required in larger-scale 704 deployments. 706 3.2. Content Delivery Metadata 708 CDN technology typically supports APIs allowing creation, update, and 709 deletion of content delivery metadata in the CDN. However, while 710 often similar, those are proprietary and would require custom 711 support. In the tests, passing of the most essential information, 712 i.e., the upstream source for content acquisition, was achieved 713 indirectly via conveying a handle inside the URI and configuring 714 manually in the downstream CDN rules for extracting the upstream 715 source. 717 The upstream source for content acquisition can be specified through 718 the use of a specific URI scheme. For example, CDN A could use the 719 following scheme: http://cdni.cdna.com/origin-URI to point to a 720 cached copy of the content reachable at "origin-URI". The domain 721 name inside the URI scheme designates the request-routing system of a 722 CDN, and the remainder of the URI defines upstream source for content 723 acquisition: here, the content URI on the CP's origin servers. If 724 the authoritative CDN and the downstream CDN use this URI scheme, the 725 authoritative CDN can easily map the URI that it receives in the end- 726 user's content request with a valid URI on the downstream CDN. 727 Similarly, the downstream CDN can easily extract a content 728 acquisition URI from the redirection URI. 730 In our tests, we have configured manually the rules that enabled the 731 authoritative CDN to redirect end-users to a valid URI on the 732 downstream CDN, and the downstream CDN to ingest content from the 733 appropriate upstream source. While this allowed validation of the 734 content distribution model, this solution may not be viable in a 735 production environment, as it imposes constraints on URI structure. 736 In addition, this approach does not support exchange of other 737 distribution metadata (e.g., geo-blocking, content validation,...) 738 which would require to be manually configured in the downstream CDN. 739 In a real-world deployment, the configuration of these policies could 740 rely on information that interconnected CDNs would exchange through a 741 CDNI interface. 743 3.3. Content Acquisition and Deletion 745 3.3.1. Content Pre-Positioning in Downstream CDN 747 CDN technology typically supports APIs that allow triggering of 748 content and metadata pre-positioning in a CDN. However, while often 749 similar, these APIs are proprietary and would require custom support. 750 For this reason content pre-positioning in dCDN was not covered in 751 the tests. While the highest requirements is for support of dynamic 752 acquisition, CDNI use-cases call for support of pre-positioning, 753 which requires a triggering mechanism in a CDNI API. 755 3.3.2. Content Purge 757 CDN technology typically supports APIs allowing content purge in a 758 CDN. However, while often similar, these APIs are proprietary and 759 would require custom support. For this reason, content purge was not 760 covered in the tests. There is a strong requirement for content 761 purge in CDNI scenarios, which introduces the need for a purge 762 triggering mechanism in a CDNI API. 764 4. Acknowledgments 766 The authors would like to acknowledge the work of Elodie Hemon and 767 Marcin Pilarski on the tests, with the technical support of Sharon 768 Schwartzman and Marc Fiuczynski. They would like to thank Slim Gara, 769 Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for 770 valuable input and discussions. Finally, the authors acknowledge 771 interesting discussions with contributors of the EU FP7 OCEAN 772 project. 774 5. IANA Considerations 776 This memo includes no request to IANA. 778 6. Security Considerations 780 CDN interconnect, as described in this document, has a wide variety 781 of security issues that should be considered. This document focuses 782 on specific experiments for CDN interconnect, and therefore, does not 783 analyze the threats in detail. 785 7. References 787 7.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 7.2. Informative References 794 [I-D.bertrand-cdni-use-cases] 795 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 796 Eardley, P., and K. Ma, "Use Cases for Content Delivery 797 Network Interconnection", draft-bertrand-cdni-use-cases-02 798 (work in progress), July 2011. 800 [I-D.jenkins-cdni-problem-statement] 801 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 802 Distribution Network Interconnection (CDNI) Problem 803 Statement", draft-jenkins-cdni-problem-statement-02 (work 804 in progress), March 2011. 806 [I-D.lefaucheur-cdni-requirements] 807 Leung, K., Lee, Y., Faucheur, F., Viveganandhan, M., and 808 G. Watson, "Content Distribution Network Interconnection 809 (CDNI) Requirements", 810 draft-lefaucheur-cdni-requirements-02 (work in progress), 811 July 2011. 813 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 814 for Content Internetworking (CDI)", RFC 3466, 815 February 2003. 817 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 818 Content Network (CN) Request-Routing Mechanisms", 819 RFC 3568, July 2003. 821 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 822 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 824 Authors' Addresses 826 Gilles Bertrand (editor) 827 France Telecom - Orange 828 38-40 rue du General Leclerc 829 Issy les Moulineaux 92130 830 FR 832 Phone: +33 1 45 29 89 46 833 Email: gilles.bertrand@orange-ftgroup.com 835 Francois Le Faucheur 836 Cisco Systems 837 Greenside, 400 Avenue de Roumanille 838 Sophia Antipolis 06410 839 FR 841 Phone: +33 4 97 23 26 19 842 Email: flefauch@cisco.com 844 Larry Peterson 845 Verivue, Inc. 846 2 Research Way 847 Princeton, NJ 08540 848 US 850 Phone: +1 978 303 8032 851 Email: lpeterson@verivue.com