idnits 2.17.1 draft-bertrand-cdni-experiments-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2012) is 4446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 762, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-logging-00 == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-03 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-02 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-03 -- 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 (~~), 8 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: August 18, 2012 Cisco Systems 6 L. Peterson 7 Verivue, Inc. 8 February 15, 2012 10 Content Distribution Network Interconnection (CDNI) Experiments 11 draft-bertrand-cdni-experiments-02 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 18, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 4 74 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 4 75 2.2. Control . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.4. Request Routing and Content Delivery . . . . . . . . . . . 6 78 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B . . . 7 79 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A . . . 9 80 2.4.3. Test Result . . . . . . . . . . . . . . . . . . . . . 11 81 2.5. Content Delivery Metadata . . . . . . . . . . . . . . . . 12 82 2.6. Content Acquisition . . . . . . . . . . . . . . . . . . . 12 83 2.6.1. Content Acquisition by CDN B through CDN A . . . . . . 12 84 2.6.2. Content Acquisition by CDN A Directly from CP B . . . 13 85 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 15 87 3.1.1. Request-Routing Information and Policies . . . . . . . 15 88 3.1.2. Iterative and Recursive Redirection . . . . . . . . . 15 89 3.1.3. Request Looping Avoidance . . . . . . . . . . . . . . 16 90 3.2. Content Delivery Metadata . . . . . . . . . . . . . . . . 16 91 3.3. Content Acquisition and Deletion . . . . . . . . . . . . . 17 92 3.3.1. Content Pre-Positioning in Downstream CDN . . . . . . 17 93 3.3.2. Content Purge . . . . . . . . . . . . . . . . . . . . 17 94 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 We adopt the terminology described in [RFC3466], [RFC3568], 124 [RFC3570], CDNI problem statement draft 125 [I-D.ietf-cdni-problem-statement], CDNI framework draft 126 [I-D.davie-cdni-framework] and CDNI use cases draft 127 [I-D.ietf-cdni-use-cases]. 129 Content Delivery Service 131 Set of services offered to content service providers (CSPs) for 132 delivering their content through a single Content Delivery Network or 133 interconnections of Content Delivery Networks. 135 2. CDN Interconnection Experiments 137 2.1. Experiment Configuration 139 The interconnection of two CDN solutions from different vendors has 140 been tested. These tests have been run with CDN solutions from Cisco 141 (hereafter referred to as Vendor A) and from Verivue/CoBlitz 142 (hereafter referred to as Vendor B). 144 As depicted in Figure 1, we have interconnected two experimental CDNs 145 (CDN A and CDN B) operated by different subsidiaries of a large CDSP. 146 The CDNs lab equipment were located in two different countries, 147 henceforth referred to as Country A and Country B and they relied on 148 CDN solutions from two different equipment vendors, namely, Vendor A 149 and Vendor B. The CDNI experiment supported the services of two 150 emulated CPs (CP A and CP B). 152 +-------+ : +-------+ 153 | CP A | : | CP B | 154 +-------+ : +-------+ 155 | : | 156 ,--,--,--. : ,--,--,--. 157 ,-' CDN A `-. : ,-' CDN B `-. 158 ( (Vendor A) )=====( (Vendor B) ) 159 `-. ,-' : `-. ,-' 160 `--'--'--' : `--'--'--' 161 : 162 COUNTRY A : COUNTRY B 164 === CDN Interconnect 166 Figure 1 168 More precisely, we have run the experiments represented in Figure 2 169 and Figure 4. We base our description on Figure 2. In this 170 experiment, CP A has an agreement with CDSP A for content delivery to 171 end-users located in Country A and Country B. However, CDSP A 172 operates a CDN (CDN A), whose footprint does not include country B. 173 Therefore, CDSP A has an agreement with CDSP B, so that CDN A can 174 delegate to CDN B the delivery of some content. More specifically, 175 CDN A is allowed to delegate to CDN B the handling of requests sent 176 by end-users located in Country B for CP A's content. 178 When CDN A receives a content request related to CP A and from an 179 end-user in Country B, it redirects the end-user to CDN B. If CDN B 180 does not have a local copy of the requested content yet (cache miss), 181 CDN B ingests the content from CDN A (or from the CP's origin 182 servers, depending on the test scenario); if CDN A also does not have 183 a local copy of the requested content, it requests this asset from 184 the CP's origin servers before sending the asset to CDN B. 186 There are several differences between the tests in Figure 2 and 187 Figure 4, in addition to the different role played by the two CDN 188 solutions. We list the main ones below. 190 o We have tested different content acquisition methods (see 191 Section 2.6). 193 o Specific URL schemes were involved in providing content 194 acquisition source information to the downstream CDN. As we have 195 tested different content acquisition methods, depending on which 196 solution played the role of dCDN, the two solutions have used 197 different URL schemes to address content. Therefore, the tests 198 required the configuration of different content delivery metadata 199 on the uCDN (see Section 2.4). 201 o The two solutions use different methods to identify the end-user's 202 geographic locations (see Section 2.4). 204 2.2. Control 206 The tested CDN solutions support control APIs but those are 207 proprietary, so that the tested CDN solutions do not support a common 208 inter-operable CDNI control interface. Therefore, we have not tested 209 CDNI control operations and we had to perform manually most 210 operations related to the configuration of the CDNI. 212 2.3. Logging 214 Proprietary mechanisms to export transaction logs 215 [I-D.bertrand-cdni-logging] were available in the tested CDN 216 solutions, but have not been covered by our tests. 218 2.4. Request Routing and Content Delivery 220 As defined in [I-D.davie-cdni-framework], two main types of request- 221 routing call flows can be used for CDNI: 223 1. iterative request-routing, 225 2. recursive request-routing. 227 Moreover, two main methods can be used for redirecting an end-user 228 from the authoritative CDN to the downstream CDN: 230 1. DNS-based redirection, 232 2. Service-level redirection, for example HTTP-based or RTSP-based. 234 We have focused our tests on iterative request-routing. Our tests 235 involved HTTP-based request redirection by the authoritative CDN, as 236 they focused on the delivery of large objects, such as movies. 238 The tested CDN solutions did not feature a CDNI request-routing 239 interface allowing exchange of "CDN routing" information among CDNs. 240 Therefore, we have manually configured appropriate policies on the 241 authoritative CDN to permit iterative request-routing (e.g., CDN A 242 redirects the end-user to CDN B request-routing system, cf. 244 Figure 3). 246 2.4.1. HTTP Redirection by CDN A and Delivery by CDN B 248 This section describes the tested request routing and content 249 delivery features in the scenario depicted in Figure 2, with HTTP 250 redirection by CDN A and delivery by CDN B. 252 We have tested the selection of the downstream CDN based on the 253 content type in the client request and/or the geographic location of 254 the client. 256 o File-type based selection relied on static XML files where content 257 file extensions can be associated to a specific delivery CDN. 259 o The geographic location of the end-user was determined by an 260 external geolocation server. 262 +-------+ : 263 | CP A | : 264 +-------+ : 265 | : 266 ,--,--,--. : ,--,--,--. 267 ,-' CDN A `-. : ,-' CDN B `-. 268 ( (Vendor A) )=====( (Vendor B) ) 269 `-. CDSP A ,-' : `-. CDSP B ,-' 270 `--'--'--' : `--'--'--' 271 : | 272 : +------+ 273 : | EU B | 274 : +------+ 275 : 276 COUNTRY A : COUNTRY B 278 === CDN Interconnect 280 Figure 2 282 Figure 3 details the messages exchanged by the components involved in 283 the experiment. 285 End-User CP A 286 served by contract with 287 CDN B DNS CDN A Geoloc CDN B SurgtB CDN A 288 | DNS REQ (1)| | | | | | 289 |----------->| | | | | | 290 | DNS REP (2)| | | | | | 291 |<-----------| | | | | | 292 | HTTP GET (3) | | | | | 293 |------------+------->| (3.1) | | | | 294 | | |------->| | | | 295 | | | (3.2) | | | | 296 | HTTP 302 (4) |<-------| | | | 297 |<-----------+--------| | | | | 298 | HTTP GET (5) | | | | | 299 |------------+--------+--------+------>| | | 300 | HTTP 302 (6) | | | | | 301 |<-----------+--------+--------+-------| | | 302 | HTTP GET (7) | | | | | 303 |------------+--------+--------+-------+----->| | 304 | HTTP 200 OK (8) | | | | | 305 |<-----------+--------+--------+-------+------| | 307 HTTP redirection by CDN A and delivery by CDN B 309 Figure 3 311 Message details 313 (1) The user-agent sends a DNS request to resolve the FQDN of the 314 content URI. 316 (2) The DNS answers with the IP address of a request-router in CDN A. 318 (3) The user-agent sends to CDN A request-router an HTTP GET request 319 for the content URI. 321 (3.1) CDN A request-router analyzes the request and queries a 322 geolocation database to identify the geographic location of the end- 323 user. 325 (3.2) The geolocation database answers with geolocation information 326 related to the end-user's IP address. The end-user is in country B; 327 thus, CDN A determines that the end-user's request must be served by 328 CDN B. 330 (4) CDN A request-router replies to the user-agent with an HTTP 302 331 redirection message, which provides the URI of the content on CDN B. 333 (5) If necessary, the user-agent resolves the FQDN on the redirection 334 URI (steps not represented in the figure), and thus, determines the 335 IP address of a request-router in CDN B. Then, it sends an HTTP GET 336 request to this request-router. 338 (6) CDN B request-router analyzes the request and replies to the 339 user-agent with an HTTP 302 redirection message that provides the URI 340 of the content on a surrogate in CDN B. 342 (7) If necessary, the user-agent resolves the FQDN of the redirection 343 URI (steps not represented in the figure), and thus, determines the 344 IP address of a surrogate in CDN B. Then, it sends an HTTP GET 345 request to the surrogate. 347 (8) The surrogate analyzes the request and delivers the requested 348 content to the end-user, through an HTTP 200 OK message. 350 2.4.2. HTTP Redirection by CDN B and Delivery by CDN A 352 This section describes the tested request routing and content 353 delivery features in the scenario depicted in Figure 4, with HTTP 354 redirection by CDN B and delivery by CDN A. 356 We have tested the selection of the downstream CDN based on end- 357 user's geolocation. For these tests, the geolocation database had 358 been populated manually with the mapping of IP prefixes to countries. 359 Alternative solutions, such as geolocation based on BGP communities 360 or on the extraction of per country IP prefixes thanks to commercial 361 geoIP databases, exist but they have not been tested in this 362 experiment. 364 : +-------+ 365 : | CP B | 366 : +-------+ 367 : | 368 ,--,--,--. : ,--,--,--. 369 ,-' CDN A `-. : ,-' CDN B `-. 370 ( (Vendor A) )=====( (Vendor B) ) 371 `-. CDSP A ,-' : `-. CDSP B ,-' 372 `--'--'--' : `--'--'--' 373 | : 374 +------+ : 375 | EU A | : 376 +------+ : 377 : 378 COUNTRY A : COUNTRY B 380 === CDN Interconnect 382 Figure 4 384 Figure 5 details the messages exchanged by the components involved in 385 the experiment. 387 End-User CP B 388 served by contract with 389 CDN A DNS CDN A Srgt A CDN B CDN B 390 | DNS REQ (1)| | | | | 391 |----------->| | | | | 392 | DNS REP (2)| | | | | 393 |<-----------| | | | | 394 | HTTP GET (3) | | | | 395 |------------+--------+-------+------->| | 396 | HTTP 302 (4) | | | | 397 |<-----------+--------+-------+--------| | 398 | HTTP GET (5) | | | | 399 |------------+------->| | | | 400 | HTTP 302 (6) | | | | 401 |<-----------+--------| | | | 402 | HTTP GET (7) | | | | 403 |------------+--------+------>| | | 404 | HTTP 200 OK (8) | | | | 405 |<-----------+--------+-------| | | 407 HTTP redirection by CDN B and delivery by CDN A 409 Figure 5 411 Message details 413 (1) The user-agent sends a DNS request to resolve the FQDN of the 414 content URI. 416 (2) The DNS answers with the IP address of a request-router in CDN B. 418 (3) The user-agent sends to CDN B request-router an HTTP GET request 419 for the content URI. 421 (4) CDN B request-router analyzes the request. The end-user is in 422 country A; thus, CDN B determines that the end-user's request must be 423 served by CDN A. Consequently, CDN B replies to the user-agent with 424 an HTTP 302 redirection message that provides the URI of the content 425 on CDN A. 427 (5) If necessary, the user-agent resolves the FQDN on the redirection 428 URI (steps not represented in the figure), and thus, determines the 429 IP address of a request-router in CDN A. Then, it sends an HTTP GET 430 request to this request-router. 432 (6) CDN A request-router analyzes the request and replies to the 433 user-agent with an HTTP 302 redirection message, which provides the 434 URI of the content on a surrogate in CDN A. 436 (7) If necessary, the user-agent resolves the FQDN of the redirection 437 URI (steps not represented in the figure), and thus, determines the 438 IP address of a surrogate in CDN A. Then, it sends an HTTP GET 439 request to the surrogate. 441 (8) The surrogate analyzes the request and delivers the requested 442 content to the end-user, through an HTTP 200 OK message. 444 2.4.3. Test Result 446 HTTP redirection by the authoritative CDN was successful in the 447 tests: end-users were redirected to the CDN that served their 448 country. This guaranteed that: 450 o content from CP A be delivered by CDN B to end-users in country B, 451 even if CP A had no direct relationship with CDSP B; 453 o content from CP B be delivered by CDN A to end-users in country A, 454 even if CP B had no direct relationship with CDSP A. 456 2.5. Content Delivery Metadata 458 The tested CDN solutions feature proprietary metadata APIs, but these 459 APIs have not been covered by the tests. We had to configure 460 distribution metadata consistently in the dCDN and the uCDN (e.g., 461 rules to determine upstream source for content acquisition). 463 Content pre-positioning in the dCDN has not been tested: only dynamic 464 content acquisition has been covered by the experiments. 466 Proprietary APIs were available for content purge, but those have not 467 been covered by tests. 469 2.6. Content Acquisition 471 We have used regular HTTP for content acquisition. We have relied on 472 HTTP custom headers to transfer trivial metadata such as content 473 integrity check (MD5 hash). 475 The correct acquisition and delivery of the requested file has been 476 tested for Adobe Flash and MS HTTP smooth-streaming files. 478 2.6.1. Content Acquisition by CDN B through CDN A 480 We describe here the content acquisition operations triggered in case 481 of cache miss, for the test scenario depicted in Figure 2 and 482 Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In 483 this scenario, the dCDN (CDN B) does not have the requested content 484 in cache and must request it to the uCDN (CDN A). 486 The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides 487 a summary (the involved internal entities of the uCDN are not 488 detailed) of the related content acquisition operations. 489 Section 3.1.3 provides more details on specific issues related to 490 this content acquisition mode. 492 End-User CP A 493 served by contract with 494 CDN B DNS CDN A Geoloc CDN B CDN A 495 | | | | | | 496 | | | HTTP GET (7.1) | | 497 | | |<--------+-----------| | 498 | | | HTTP GET (7.2) | | 499 | | |---------+-----------+----------->| 500 | | | HTTP 200 OK (7.3) | | 501 | | |<--------+-----------+------------| 502 | | | HTTP 200 OK (7.4) | | 503 | | |---------+---------->| | 504 | | | | | | 506 Pull content acquisition by CDN B through CDN A in case of cache miss 507 (continuation of Figure 3) 509 Figure 6 511 Message details 513 (7.1) CDN B surrogate or parent cache sends a content acquisition 514 request to the uCDN (CDN A). In the tests, (7.1) was triggered by a 515 cache miss on delivery request. Stated differently, the tests 516 implemented dynamic acquisition, as opposed to content pre- 517 positioning. 519 (7.2) CDN A analyzes the request. In case of cache miss, it sends an 520 acquisition request to the CP's origin servers. 522 (7.3) The CP's origin server authorizes the request and delivers the 523 requested content to CDN A, through an HTTP 200 OK. 525 (7.4) CDN A delivers the requested content to CDN B surrogate or 526 parent cache, through an HTTP 200 OK. 528 2.6.2. Content Acquisition by CDN A Directly from CP B 530 We describe here (Figure 7) the content acquisition operations 531 triggered in case of cache miss, for the test scenario with HTTP 532 redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5). 533 In this scenario, the dCDN (CDN A) does not have the requested 534 content in cache and must request it to CP B. 536 End-User CP B 537 served by contract with 538 CDN A DNS CDN A CDN B CDN B 539 | | | | | 540 | | |HTTP GET (7.1) | 541 | | |-------------+----------->| 542 | | |HTTP 200 OK (7.2) | 543 | | |<------------+------------| 545 Pull content acquisition by CDN A directly from content provider's 546 origin servers in case of cache miss (continuation of Figure 5) 548 Figure 7 550 Message details 552 (7.1) CDN A surrogate sends a content acquisition request to an 553 origin server of the CP. In the tests, (7.1) was triggered by a 554 cache miss on a delivery request. Stated differently, the tests 555 implemented dynamic acquisition, as opposed to content pre- 556 positioning. 558 (7.2) The CP's origin server authorizes the request and delivers the 559 requested content to CDN A, through an HTTP 200 OK. 561 3. Lessons Learned 563 For basic interconnection tests, we have relied on extremely limited 564 information exchanges between the two interconnected CDNs and we have 565 configured most CDNI related features manually. This is because, 566 while present CDN technologies support APIs allowing configuration of 567 some of this information, those are difficult to use in multi-vendor 568 environments since: 570 o they are proprietary APIs; 572 o they are designed as "internal" APIs and therefore lack the 573 necessary inter-domain security and policy control. 575 Therefore, those APIs have not been used in these tests. 577 In the present section, we highlight some of the limitations induced 578 by the lack of standard CDNI interfaces that we have faced in our 579 tests. 581 One of the insights from this work is that by encoding information 582 inside the redirection URI, it is possible to communicate some 583 essential CDNI-related information across CDNs "in-band" (i.e., as 584 part of HTTP), rather than communicating it through an out-of-band 585 interface. In these tests, the information communicated in-band was 586 restricted to the most fundamental information; that is, a handle 587 allowing the Downstream CDN to determine where to acquire the 588 content. This was key to achieving multi-CDN operations without any 589 common CDNI "out-of-band" interface supported by existing CDN 590 technologies. This raises an interesting general question: what 591 subset of inter-CDN information is to be communicated between 592 interconnected CDNs in-band (possibly using existing methods) as 593 opposed to communicated via out-of-band interfaces? 595 3.1. Request Routing 597 3.1.1. Request-Routing Information and Policies 599 Because of the lack of CDNI interfaces allowing CDNs to exchange 600 information such as their coverage, capabilities, and performance, we 601 had to configure request-routing policies manually in the CDNs that 602 acted as uCDNs. While this may be tolerable for initial limited 603 deployments of CDNI scenarios with a small number of participants, 604 this is expected to create operational constraints in larger scale 605 deployments. 607 3.1.2. Iterative and Recursive Redirection 609 Because of the lack of CDNI interfaces allowing an upstream CDN to 610 query dCDN for how to redirect a request, the tests only covered 611 iterative redirection (i.e. uCDN redirects the user-agent to the dCDN 612 request-routing system, which redirects the user-agent to ...), not 613 recursive redirection. 615 While iterative redirection allows supporting redirection across 616 CDNs, it has some limitations: 618 o multiple redirections are exposed to the end-user; 620 o redirection latency cannot easily be reduced for future requests, 621 through the caching of request-routing decisions; 623 o some client implementations support a limited number of successive 624 redirections; 626 o the dCDN cannot reject a redirection, while allowing the uCDN to 627 handle the rejected request. 629 A standard request-routing API would allow supporting recursive 630 redirection, which removes these shortcomings. 632 3.1.3. Request Looping Avoidance 634 In case of cache-miss, the downstream CDN must fetch the requested 635 content, either through the authoritative CDN, or directly from the 636 CP's origin server. 638 Consider the situation where the downstream CDN fetches the content 639 from the authoritative CDN, as illustrated in Section 2.6.1. In this 640 case, the authoritative CDN must not redirect the acquisition request 641 to the downstream CDN, because this would create the following 642 request-routing loop: dCDN -> uCDN -> dCDN. Consequently, the 643 upstream CDN must be able to determine that the source of the request 644 is a partner CDN and not a regular end-user. In addition, the 645 upstream CDN must be able to acquire content from the CP's origin 646 server on behalf of the downstream CDN, if necessary: dCDN -> uCDN -> 647 CP. 649 In the tests, we have successfully solved the request-looping issue, 650 through the use of separated URL spaces for regular users and CDN 651 users, as well as the manual configuration of appropriate request- 652 routing policies for every URL space. In other words, the URL used 653 by regular users to fetch content was different from the one used by 654 the downstream CDN to fetch the content. This way, we eliminated the 655 loops. More automated operation would be required in larger-scale 656 deployments. 658 3.2. Content Delivery Metadata 660 CDN technology typically supports APIs allowing creation, update, and 661 deletion of content delivery metadata in the CDN. However, while 662 often similar, those are proprietary and would require custom 663 support. In the tests, passing of the most essential information, 664 i.e., the upstream source for content acquisition, was achieved 665 indirectly via conveying a handle inside the URI and configuring 666 manually in the downstream CDN rules for extracting the upstream 667 source. 669 The upstream source for content acquisition can be specified through 670 the use of a specific URI scheme. For example, CDN A could use the 671 following scheme: http://cdni.cdna.com/origin-URI to point to a 672 cached copy of the content reachable at "origin-URI". The domain 673 name inside the URI scheme designates the request-routing system of a 674 CDN, and the remainder of the URI defines upstream source for content 675 acquisition: here, the content URI on the CP's origin servers. If 676 the authoritative CDN and the downstream CDN use this URI scheme, the 677 authoritative CDN can easily map the URI that it receives in the end- 678 user's content request with a valid URI on the downstream CDN. 679 Similarly, the downstream CDN can easily extract a content 680 acquisition URI from the redirection URI. 682 In our tests, we have configured manually the rules that enabled the 683 authoritative CDN to redirect end-users to a valid URI on the 684 downstream CDN, and the downstream CDN to ingest content from the 685 appropriate upstream source. While this allowed validation of the 686 content distribution model, this solution may not be viable in a 687 production environment, as it imposes constraints on URI structure. 688 In addition, this approach does not support exchange of other 689 distribution metadata (e.g., geo-blocking, content validation,...) 690 which would require to be manually configured in the downstream CDN. 691 In a real-world deployment, the configuration of these policies could 692 rely on information that interconnected CDNs would exchange through a 693 CDNI interface. 695 3.3. Content Acquisition and Deletion 697 3.3.1. Content Pre-Positioning in Downstream CDN 699 CDN technology typically supports APIs that allow triggering of 700 content and metadata pre-positioning in a CDN. However, while often 701 similar, these APIs are proprietary and would require custom support. 702 For this reason content pre-positioning in dCDN was not covered in 703 the tests. While the highest requirements is for support of dynamic 704 acquisition, CDNI use-cases call for support of pre-positioning, 705 which requires a triggering mechanism in a CDNI API. 707 3.3.2. Content Purge 709 CDN technology typically supports APIs allowing content purge in a 710 CDN. However, while often similar, these APIs are proprietary and 711 would require custom support. For this reason, content purge was not 712 covered in the tests. There is a strong requirement for content 713 purge in CDNI scenarios, which introduces the need for a purge 714 triggering mechanism in a CDNI API. 716 4. Acknowledgments 718 The authors would like to acknowledge the work of Elodie Hemon and 719 Marcin Pilarski on the tests, with the technical support of Sharon 720 Schwartzman and Marc Fiuczynski. They would like to thank Slim Gara, 721 Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for 722 valuable input and discussions. Finally, the authors acknowledge 723 interesting discussions with contributors of the EU FP7 OCEAN 724 project. 726 5. IANA Considerations 728 This memo includes no request to IANA. 730 6. Security Considerations 732 CDN interconnect, as described in this document, has a wide variety 733 of security issues that should be considered. This document focuses 734 on specific experiments for CDN interconnect, and therefore, does not 735 analyze the threats in detail. 737 7. References 739 7.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 7.2. Informative References 746 [I-D.bertrand-cdni-logging] 747 Gilles, B. and S. Emile, "CDNI Logging Interface", 748 draft-bertrand-cdni-logging-00 (work in progress), 749 February 2012. 751 [I-D.davie-cdni-framework] 752 Davie, B. and L. Peterson, "Framework for CDN 753 Interconnection", draft-davie-cdni-framework-01 (work in 754 progress), October 2011. 756 [I-D.ietf-cdni-problem-statement] 757 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 758 Distribution Network Interconnection (CDNI) Problem 759 Statement", draft-ietf-cdni-problem-statement-03 (work in 760 progress), January 2012. 762 [I-D.ietf-cdni-requirements] 763 Leung, K. and Y. Lee, "Content Distribution Network 764 Interconnection (CDNI) Requirements", 765 draft-ietf-cdni-requirements-02 (work in progress), 766 December 2011. 768 [I-D.ietf-cdni-use-cases] 769 Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley, 770 P., and K. Ma, "Use Cases for Content Delivery Network 771 Interconnection", draft-ietf-cdni-use-cases-03 (work in 772 progress), January 2012. 774 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 775 for Content Internetworking (CDI)", RFC 3466, 776 February 2003. 778 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 779 Content Network (CN) Request-Routing Mechanisms", 780 RFC 3568, July 2003. 782 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 783 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 785 Authors' Addresses 787 Gilles Bertrand (editor) 788 France Telecom - Orange 789 38-40 rue du General Leclerc 790 Issy les Moulineaux 92130 791 FR 793 Phone: +33 1 45 29 89 46 794 Email: gilles.bertrand@orange.com 796 Francois Le Faucheur 797 Cisco Systems 798 Greenside, 400 Avenue de Roumanille 799 Sophia Antipolis 06410 800 FR 802 Phone: +33 4 97 23 26 19 803 Email: flefauch@cisco.com 805 Larry Peterson 806 Verivue, Inc. 807 2 Research Way 808 Princeton, NJ 08540 809 US 811 Phone: +1 978 303 8032 812 Email: lpeterson@verivue.com