idnits 2.17.1 draft-bertrand-cdni-use-cases-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 (July 7, 2011) is 4648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 619, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-experiments-00 == Outdated reference: A later version (-02) exists of draft-lefaucheur-cdni-requirements-01 -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Bertrand 3 Internet-Draft E. Stephan 4 Intended status: Informational France Telecom - Orange 5 Expires: January 8, 2012 G. Watson 6 T. Burbridge 7 P. Eardley 8 BT 9 K. Ma 10 Azuki Systems 11 July 7, 2011 13 Use Cases for Content Delivery Network Interconnection 14 draft-bertrand-cdni-use-cases-02 16 Abstract 18 Content Delivery Networks (CDNs) are commonly used for improving the 19 footprint and the end-user experience of a content delivery service, 20 at a reasonable cost. This document outlines real world use-cases 21 (not technical solutions) for interconnecting CDNs. It provides the 22 business motivations for CDNI Working Group, which can be used to 23 validate different interconnection arrangements, and requirements of 24 the various CDNI interfaces. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 8, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 75 1.3. High Level Use Cases for Multi-CDN Systems . . . . . . . . 6 76 1.4. The Need for CDNI Standards . . . . . . . . . . . . . . . 8 77 2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 8 78 2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 8 79 2.2. Region to Region Interconnection . . . . . . . . . . . . . 9 80 2.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 9 81 2.4. Delivery Restrictions . . . . . . . . . . . . . . . . . . 9 82 3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 83 3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10 84 3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.2.1. Failure of Content Delivery Resources . . . . . . . . 11 86 3.2.2. Failure of Content Acquisition . . . . . . . . . . . . 11 87 3.3. Branding Consideration . . . . . . . . . . . . . . . . . . 11 88 4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 12 89 4.1. Device and Network Technology Extension . . . . . . . . . 12 90 4.2. Technology and Vendor Interoperability . . . . . . . . . . 13 91 4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 13 92 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 This document now merges input from [I-D.watson-cdni-use-cases] and 103 [I-D.ma-cdni-publisher-use-cases]. 105 Content Delivery Networks (CDNs) are commonly used for improving the 106 footprint and the end-user experience of a content delivery service, 107 at a reasonable cost. This document outlines real world use-cases 108 (not technical solutions) for interconnecting CDNs. It provides the 109 business motivations for CDNI Working Group, which can be used to 110 validate different interconnection arrangements, and requirements of 111 the various CDNI interfaces. 113 There are many possible combinations for the relationships between 114 the different parties (Network Service Provider (NSP), CDN Provider, 115 Content Service Provider (CSP) and End User) involved in end-to-end 116 content delivery. However, in the context of interconnecting CDNs 117 the key relationships are listed below. 119 o How the CSP interacts with the CDN provider, so that the CDN 120 delivers content in a manner compliant with CSP's distribution 121 policies. 123 o How the End User interacts with the CSP and one or more CDNs to 124 request and receive content. 126 o How the different CDN providers, operating their CDNs, interact 127 with one another to deliver the CSP's content to the End User 128 while continuing to enforce the CSP's distribution policies. 130 This document describes a number of use cases that motivate CDN 131 Interconnection. 133 1.1. Terminology 135 We adopt the terminology described in 136 [I-D.jenkins-cdni-problem-statement], [RFC3466], and [RFC3568], 137 except for the terms defined below. 139 CDN Provider: 141 An administrative entity who operates a CDN over a NSP or over the 142 Internet. 144 Authoritative CDN (aCDN): 146 A CDN provider contracted by the CSP for delivery of content by its 147 CDN or by its downstream CDNs. 149 Downstream CDN (dCDN): 151 A CDN provider which is contracted by an uCDN to achieve the delivery 152 of content to users. 154 Access CDN: 156 A CDN that is connected to the end-user's access and has information 157 about the end-user's profile and access capabilities. 159 Delivering CDN: 161 The CDN that delivers the requested content asset to the end-user. 162 In particular, the delivering CDN can be an access CDN. 164 CDN Interconnection (CDNI): 166 Relationship between two CDNs that enables a CDN to provide content 167 delivery services on behalf of another CDN. It relies on a set of 168 interfaces over which two CDNs communicate in order to achieve the 169 delivery of content to end-users by one CDN (the downstream CDN) on 170 behalf of another CDN (the upstream CDN). 172 CDN peering: A business relation between two CDN providers based on 173 one or more CDN interconnections. 175 Recursive request routing: 177 Recursive: Where a process is repeated, but embedded within the 178 original process. In the case of Request Routing, this means that 179 the initial request received by the Authoritative CDN is processed 180 downstream from one CDN to another and that the responses are send 181 back upstream to the Authoritative CDN which then replies to the 182 initial request. 184 Iterative request routing 186 Iterative: Where a process is repeated multiple times to make 187 progress towards a goal. In the case of Request Routing, this means 188 that the initial request is received by the Authoritative CDN, which 189 replies it with a redirection directive to a downstream CDN. When 190 the end-user sends its request to the downstream CDN, the same 191 process is repeated, until the request arrives to the delivering CDN. 193 Asymmetric Distribution: 195 A distribution scenario where different NSPs have distribution rights 196 to the same content, but at different levels of quality (e.g., high 197 definition vs. low definition video), which places restrictions on 198 delivery delegation. 200 1.2. Abbreviations 202 [Ed. Note: List of abbreviations to be updated later] 204 o CSP: Content Service Provider 206 o dCDN: downstream CDN 208 o ISP: Internet Service Provider 210 o NSP: Network Service Provider 212 o PC: Personal Computer 214 o QoE: Quality of Experience 216 o QoS: Quality of Service 218 o SLA: Service Level Agreement 220 o STB: Set-Top-Box 222 o uCDN: upstream CDN 224 o UA: User Agent 226 o UE: User Equipment 228 o VoD: Video on Demand 230 o WiFi: Wireless Fidelity 232 1.3. High Level Use Cases for Multi-CDN Systems 234 Content Delivery Networks (CDNs) are used to deliver content because 235 they can: 237 o improve the experience for the End User; for instance delivery has 238 lower latency and better robustness, 240 o reduce the operator's costs; for instance lower delivery cost 241 (reduced bandwidth usage) for cacheable content, 243 o reduce the Content Service Provider costs, such as datacenter 244 capacity, space, and electricity consumption. 246 Indeed, many network service providers and enterprise service 247 providers are deploying or have deployed their own CDNs. Despite the 248 potential benefits of interconnecting CDNs, today each CDN is a 249 standalone network. The objective of CDN interconnection is to 250 overcome this restriction: the interconnected CDNs should be able to 251 collectively behave as a single delivery infrastructure. 253 Let's take an example, as depicted in Figure 1. Two CDN Providers 254 establish a CDN Interconnect. The Content Service Provider CSP-1 255 reaches an agreement with CDN Provider A for the delivery of its 256 content. CDN Provider A and CDN Provider B agree to interconnect 257 their CDNs. When a User Agent that is connected to CDN Provider B's 258 network requests Content from CSP-1, the Content is actually 259 delivered from CDN-B, because handling of requests for CSP-1's 260 Content has been delegated as part of the CDN Interconnect agreement. 261 The End User benefits through a better quality of experience, because 262 the Content is delivered from a nearby Surrogate. CDN Provider A 263 benefits because it doesn't need to deploy such an extensive CDN, 264 whilst CDN Provider B receives some compensation for the delivery. 265 CSP-1 benefits because it only needs to make one business agreement 266 and one physical connection, with CDN Provider A, but its End Users 267 get a service quality as though it had also gone to the trouble of 268 making a business agreement with CDN Provider B. 270 +-------+ +-------+ 271 | CSP-1 | | CSP-2 | 272 +-------+ +-------+ 273 | | 274 ,--,--,--. ,--,--,--. 275 ,-' `-. ,-' `-. 276 ( CDN Provider A )=====( CDN Provider B ) 277 `-. (CDN-A) ,-' `-. (CDN-B) ,-' 278 `--'--'--' `--'--'--' 279 | 280 +------------+ 281 | User Agent | 282 +------------+ 283 === CDN Interconnect 285 Figure 1 287 To extend the example, another Content Service Provider, CSP-3, may 288 also reach an agreement with CDN Provider A. But it does not want its 289 Content to be distributed by CDN Provider B, for example, CSP-3 may 290 not have distribution rights in the country where CDN Provider B 291 operates. This example illustrates that policy considerations are an 292 important part of CDNI. 294 This document identifies three main motivations for a CDN Provider to 295 interconnect its CDN: 297 o CDN Footprint Extension Use Cases (Section 2) 299 o CDN Offload Use Cases (Section 3) 301 o CDN Capability Use Cases (Section 4) 303 1.4. The Need for CDNI Standards 305 Existing CDN interfaces are proprietary and an external CDN typically 306 cannot use them, especially if the two CDNs rely on different 307 solutions. Nevertheless, [I-D.bertrand-cdni-experiments] shows that 308 some level of CDN interconnection can be achieved experimentally 309 without standardized interfaces between the CDNs. The methods used 310 in these experiments are hardly usable in an operational context, 311 because they suffer from several limitations in terms of 312 functionalities, scalability, and security level. 314 The aim of the CDNI standards work is therefore to overcome such 315 shortcomings; a full list of requirements is being developed in 316 [I-D.lefaucheur-cdni-requirements]. 318 2. Footprint Extension Use Cases 320 Footprint extension is expected to be a major use case for CDN 321 interconnection. 323 2.1. Geographic Extension 325 In this use case, the CDN Provider wants to extend the geographic 326 distribution that it can offer CSPs, without 328 o compromising the quality of delivery 330 o attracting transit and other network costs by serving from 331 geographically or topologically remote surrogates. 333 If there are several CDN Providers that have a geographically limited 334 footprint (e.g., restricted to one country), or do not serve all end- 335 users in a geographic area, then interconnecting their CDNs enables 336 CDN Providers to provide their services beyond their own footprint. 338 As an example, suppose a French CSP wants to distribute its TV 339 programs to End Users located in various countries in Europe and 340 North Africa. It asks a French CDN Provider to deliver the content. 341 The French CDN Provider's network only covers France, so it makes an 342 agreement with another CDN Provider that covers North Africa. 343 Overall, from the CSP's perspective the French CDN Provider provides 344 a CDN service for both France and North Africa. 346 In addition to video, this use case applies to other types of content 347 such as automatic software updates (browser updates, operating system 348 patches, virus database update, etc). 350 2.2. Region to Region Interconnection 352 In the previous section, we have described the case of geographic 353 extension between CDNs operated by different entities. A large CDN 354 Provider may also operate CDNs from several subsidiaries (which may 355 rely on different CDN solutions, see Section 4.2). In certain 356 circumstances, the CDN Provider needs to make its CDNs interoperate 357 to provide a consistent service to its customers on its whole 358 footprint. 360 2.3. Nomadic Users 362 In this scenario a CSP wishes to allow users who move to other 363 geographic regions to continue to access their content. The 364 motivation in this case is to allow nomadic users to maintain access, 365 rather than to allow all residents within a region access to the 366 content. 368 This use case covers situations like users moving between different 369 CDN Providers within the same geographic region, or users switching 370 between different devices, as discussed in Section 4. 372 2.4. Delivery Restrictions 374 The content distribution policies that a CSP attaches to a content 375 asset depend on many criteria. Distribution rights for audiovisual 376 content are often negotiated using a combination of temporal 377 licensing (e.g., available for 24 hours, available 28 days after DVD 378 release, etc.), resolution-based licensing (e.g., high definition vs. 379 standard definition), and geo- location-based licensing (e.g., per 380 country). 382 "Geo-blocking" rules may specify: 384 o the geographic regions where content can be delivered from (i.e. 385 the location of the Surrogates), or 387 o geographic locations where content can be delivered to (i.e., the 388 location of the End Users). 390 Hence, the exchange through the CDN interconnection of information 391 for controlling the footprint of the delivery is an important use 392 case. 394 The delivery of content may be further influenced by policies which 395 may include time-based rules that specify: 397 o an activation time (i.e., the time when the content should become 398 available for delivery), 400 o a deactivation time (i.e., time after which the content should no 401 longer be delivered), or 403 o an expiration time (i.e., the time at which the content files 404 should be expunged from all CDN storage). 406 The delivery of content may be further influenced by policies which 407 may include quality of service rules that specify: 409 o the maximum resolution deliverable to specific devices, 411 o the maximum resolution deliverable though a specific NSP, or 413 o the maximum resolution deliverable to users based on their 414 subscription levels. 416 The enforcement of CSP licensing rules when making CDN delegation 417 decisions is another important use case for CDN interconnection. 419 3. Offload Use Cases 421 3.1. Overload Handling and Dimensioning 423 A CDN is likely to be dimensioned to support the prime-time traffic. 424 However, unexpected spikes in content popularity may drive load 425 beyond the expected peak. The prime recurrent time peaks of content 426 distribution may differ between two CDNs. Taking advantage of the 427 different traffic peak times, a CDN may interconnect with another CDN 428 to increase its effective capacity during the peak of traffic. This 429 brings dimensioning savings to the CDNs as they can use the resources 430 of each other during their peaks of activity. 432 Offload also applies to planned situations where a CDN Provider needs 433 CDN capacities in a particular region during a short period of time. 435 For example, a CDN can offload traffic to another CDN during a 436 specific maintenance operation or for covering the distribution of a 437 special event. For instance, consider a TV-channel which has 438 exclusive distribution rights on a major event, such as a 439 celebrities' wedding, or a major sport competitions. The CDNs that 440 the TV-channel uses for delivering the content related to this event 441 are likely to experience a flash crowd during the event and to need 442 offloading traffic, while other CDNs will support a more usual 443 traffic load and be able to handle the offloaded traffic load. 445 3.2. Resiliency 447 3.2.1. Failure of Content Delivery Resources 449 It is important for CDNs to be able to guarantee service continuity 450 during partial failures (e.g., failure of some Surrogates). In 451 partial failure scenarios, a CDN Provider could redirect some 452 requests towards another CDN, which must be able to serve the 453 redirected requests or, depending on traffic management policies, to 454 forward these requests to the CSP's origin server. 456 3.2.2. Failure of Content Acquisition 458 Source content acquisition is typically handled in one of two ways: 460 o CDN origin, where a downstream CDN acquires content from an 461 upstream CDN, and the authoritative CDN acquires content from an 462 origin server of the CSP, or 464 o CSP origin, where the CDNs acquire content directly from an origin 465 server of the CSP. 467 Resiliency may be required against failure to ingest content from the 468 CSP. If a CDN is unable to retrieve the content, it may be that the 469 CSP's origin server is inaccessible to only this CDN, in which case 470 redirection of the end-users to an alternative CDN may circumvent the 471 problem. A CSP may also choose to specify one or more backup origin 472 servers. 474 3.3. Branding Consideration 476 There are situations where one CDN Provider cannot or does not want 477 to operate all the functions of a CDN. For instance, it always acts 478 as an uCDN and offloads the content delivery to dCDNs, i.e., it uses 479 the surrogates of other CDSPs. In this model, the uCDN acquires 480 content and receives the initial routing requests from the user 481 agent; whereas, the dCDNs operate the content delivery functions. 482 The uCDN also retrieves and presents the logging for the CSP. 484 Preserving branding elements could interest the CSP or CDSPs. The 485 CSP might desire to offer content services under its name, even if 486 the associated CDN service involves other organizations. Therefore, 487 the CSP could request that the name of the CDSPs does not appear in 488 the URLs. Similarly, in offload situations, the uCDN might want to 489 offer CDN services under its own branding. This highlight a 490 requirement for exchanging branding related constraints over a CDNI. 492 4. CDN Capability Use Cases 494 4.1. Device and Network Technology Extension 496 In this use case, the CDN Provider may have the right geographic 497 footprint, but wishes to support the delivery of content to 498 alternative devices, such as smartphones connected to a mobile 499 network. In this case, the CDN Provider may federate with another 500 CDN Provider that offers service to these devices. 502 Consider the scenario shown in Figure 2. In this example, a nomadic 503 user switches from a TV going through a cable provider to a 504 smartphone going through a mobile operator. The CDN Provider on the 505 cable network may wish to delegate delivery of Content to the CDN 506 Provider on the mobile network. There are several possible 507 differences that may arise in this use case compared with the ones 508 discussed earlier, for example: 510 o the phone may require the Content at lower resolution than the TV; 512 o the CSP may want to license only lower resolution Content to CDN 513 Provider 2; 515 o the CSP may not want CDN Provider 2 to deliver Content if the 516 connection quality is below some threshold; 518 o the CSP may want to tailor the Content in some special way 519 depending on whether the End User is on cable or mobile, for 520 example, different adverts / DRMs / codecs / container formats / 521 delivery protocols... 523 These examples suggest the requirement for Asymmetric Distribution of 524 Content across the CDN interconnect. In the nomadic scenario, the 525 switch of CDN should be as seamless as possible from the End User's 526 perspective. 528 +-----+ 529 | CSP | 530 +-----+ 531 | 532 ,--,--,--. ,--,--,--. 533 ,-' `-. ,-' `-. 534 ( CDN Provider A )=====( CDN Provider B ) 535 `-. Fixed ,-' `-. Mobile ,-' 536 `--'--'--' `--'--'--' 537 | | 538 +----+ +-------+ 539 | TV |(1) | Phone |(2) 540 +----+ +-------+ 542 === CDN Interconnect 544 Fixed-Mobile Session Shifting 546 Figure 2 548 4.2. Technology and Vendor Interoperability 550 A CDN Provider may deploy a new CDN to run alongside its existing 551 CDN, as a simple way of migrating its CDN service to a new 552 technology. A CDN Provider may have a multi-vendor strategy for its 553 CDN deployment. A CDN Provider may want to deploy a separate CDN for 554 a particular CSP or a specific network. In all these circumstances, 555 CDNI benefits the CDN Provider, as it simplifies or automates some 556 inter-CDN operations (e.g., migrating the request routing function 557 progressively). 559 4.3. QoE and QoS Improvement 561 Some CSPs are willing to pay a premium for enhanced delivery of 562 Content to their End Users. In some cases, even if the CDN Provider 563 could deliver the content to the end users, it cannot meet the CSP's 564 service level agreement. So, it makes a CDN Interconnect agreement 565 with another CDN Provider that can meet the SLA, for instance an 566 Access CDN, which is able to deliver content from Surrogates located 567 closer to the end-user. 569 5. Acknowledgments 571 The authors would like to thank Francois Le Faucheur and Ben Niven- 572 Jenkins for lively discussions. 574 They also thank the contributors of the EU FP7 OCEAN and ETICS 575 projects for valuable inputs. 577 6. IANA Considerations 579 This memo includes no request to IANA. 581 7. Security Considerations 583 CDN interconnect, as described in this document, has a wide variety 584 of security issues that should be considered. The security issues 585 fall into three general categories: 587 o CSP Trust: where the CSP may have negotiated service level 588 agreements for delivery quality of service with the uCDN, and/or 589 configured distribution policies (e.g., geo-restrictions, 590 availability windows, or other licensing restrictions), which it 591 assumes will be upheld by dCDNs to which the uCDN delegates 592 requests. Furthermore, billing and accounting information must be 593 aggregated from dCDNs with which the CSP may have no direct 594 business relationship. These situtations where trust is delegated 595 must be handled in a secure fashion to ensure CSP confidence in 596 the CDN interconnection. 598 o Client Transparency: where the client device or application which 599 connects to the CDN must be able to interact with any dCDN using 600 its existing security and DRM protocols (e.g., cookies, 601 certificate-based authentication, custom DRM protocols, URL 602 signing algorithms, etc.) in a transparent fashion. 604 o CDN Infrastructure Protection: where the dCDNs must be able to 605 identify and validate delegated requests, in order to prevent 606 unauthorized use of the network and to be able to properly bill 607 for delivered content. A dCDN may not wish to advertise that it 608 has access to or is carrying content for the uCDN or CSP, 609 especially if that information may be used to enhance denial of 610 service attacks. In general, CDNI interfaces and protocols should 611 minimize overhead for dCDNs. 613 This document focuses on the motivational use cases for CDN 614 interconnect, and does not analyze these threats in detail. 616 8. References 617 8.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 8.2. Informative References 624 [I-D.bertrand-cdni-experiments] 625 Bertrand, G., Faucheur, F., and L. Peterson, "Content 626 Distribution Network Interconnection (CDNI) Experiments", 627 draft-bertrand-cdni-experiments-00 (work in progress), 628 February 2011. 630 [I-D.jenkins-cdni-problem-statement] 631 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 632 Distribution Network Interconnection (CDNI) Problem 633 Statement", draft-jenkins-cdni-problem-statement-02 (work 634 in progress), March 2011. 636 [I-D.lefaucheur-cdni-requirements] 637 Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee, 638 "Content Distribution Network Interconnection (CDNI) 639 Requirements", draft-lefaucheur-cdni-requirements-01 (work 640 in progress), March 2011. 642 [I-D.ma-cdni-publisher-use-cases] 643 Nair, R. and K. Ma, "Content Distribution Network 644 Interconnection (CDNI) Publisher Use", 645 draft-ma-cdni-publisher-use-cases-00 (work in progress), 646 March 2011. 648 [I-D.watson-cdni-use-cases] 649 Watson, G., "CDN Interconnect Use Cases", 650 draft-watson-cdni-use-cases-00 (work in progress), 651 January 2011. 653 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 654 for Content Internetworking (CDI)", RFC 3466, 655 February 2003. 657 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 658 Content Network (CN) Request-Routing Mechanisms", 659 RFC 3568, July 2003. 661 Authors' Addresses 663 Gilles Bertrand 664 France Telecom - Orange 665 38-40 rue du General Leclerc 666 Issy les Moulineaux, 92130 667 FR 669 Phone: +33 1 45 29 89 46 670 Email: gilles.bertrand@orange-ftgroup.com 672 Stephan Emile 673 France Telecom - Orange 674 2 avenue Pierre Marzin 675 Lannion F-22307 676 France 678 Email: emile.stephan@orange-ftgroup.com 680 Grant Watson 681 BT 682 pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham 683 Ipswich, IP5 3RE 684 UK 686 Email: grant.watson@bt.com 688 Trevor Burbridge 689 BT 690 B54 Room 70, Adastral Park, Martlesham 691 Ipswich, IP5 3RE 692 UK 694 Email: trevor.burbridge@bt.com 696 Philip Eardley 697 BT 698 B54 Room 77, Adastral Park, Martlesham 699 Ipswich, IP5 3RE 700 UK 702 Email: philip.eardley@bt.com 703 Kevin Ma 704 Azuki Systems 705 43 Nagog Park 706 Acton, MA 01720 707 USA 709 Phone: +1 978 844 5100 710 Email: kevin.ma@azukisystems.com