idnits 2.17.1 draft-fmn-cdni-advanced-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 120, but not defined == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'I-D.stiemerling-cdni-routing-cons' is defined on line 535, but no explicit reference was found in the text == Unused Reference: '3GP-DASH' is defined on line 544, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-00 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-00 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-00 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Th. Zahariadis, Ed. 3 Internet Draft Synelixis 4 Intended Status: Informational Y. Le Louedec 5 Expires: April 26, 2012 Orange Labs 6 Ch. Timmerer 7 UNI-KLU 8 S. Spirou 9 Intracom 10 D. Griffin 11 UCL 12 October 24, 2011 14 Catalogue of Advanced Use Cases for 15 Content Delivery Network Interconnection 17 draft-fmn-cdni-advanced-use-cases-00 19 Abstract 21 The purpose of this draft is to complement the current CDNi WG use- 22 cases with a catalogue of advanced, longer-term CDN interconnection 23 use cases. The work has been the contribution of six European 24 Commission (EC) co-funded projects, which are part of the EC Future 25 Media networks (FMN) cluster. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 81 2 Advanced/Long-term CDNi Use Cases . . . . . . . . . . . . . . . 5 82 2.1 Use Case 1: Caching-CDN interconnection . . . . . . . . . . 5 83 2.2 Use Case 2: CDN-CDN interconnections at large scale . . . . 6 84 2.3 Use Case 3: Dynamic adaptive streaming over HTTP in 85 multi-CDNs . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 2.4 Use Case 4: Dynamic expansion of CDN capacity and 87 geographical reach . . . . . . . . . . . . . . . . . . . . . 8 88 3 Relationship between CDNI and Information-Centric Networking . 9 89 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.1 List of Contributors . . . . . . . . . . . . . . . . . . . 12 91 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 93 5.2 Informative reference . . . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 96 1 Introduction 98 The purpose of this draft is to complement the current CDNi Work 99 Group short-term use-cases with a catalogue of advanced, longer-term 100 CDN interconnection use cases. The proposed catalogue of use cases is 101 coming from or inspired by work in the European Commission (EC) 102 Future Media Network (FMN) cluster research projects. Though they are 103 beyond the current short-term objectives of the CDNi WG, the proposed 104 use cases could drive future work in the CDNi WG, especially in case 105 of WG re-chartering (once the present goals will be reached). The use 106 cases are derived from ongoing research work in six EC co-funded 107 projects where concrete design, implementation and evaluation work is 108 being undertaken to validate the approaches. 110 Moreover, this draft compares CDNs with Information-Centric 111 Networking (ICN) which have similar goals and use cases. We discuss 112 here this relation for the benefit of people and organizations 113 working in these areas. 115 1.1 Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC2119 [RFC2119]. 121 The present document reuses terminology defined by CDNi WG documents 122 [I-D.ietf-cdni-problem-statement], [I-D.ietf-cdni-use-cases] and [I- 123 D.ietf-cdni-requirements]". 125 1.2 Abbreviations 127 [Ed. Note: List of abbreviations to be updated later] 129 o CSP: Content Service Provider 131 o dCDN: downstream CDN 133 o FMN: Future Media Networks 135 o ICN: Information-Centric Networking 137 o NSP: Network Service Provider 139 o QoE: Quality of Experience 141 o SLA: Service Level Agreement 143 o uCDN: upstream CDN 144 o MPD: Media Presentation Description 146 o DASH: Dynamic Adaptive Streaming over HTTP 148 2 Advanced/Long-term CDNi Use Cases 150 This draft includes four advanced CDNi use cases. The first use case 151 introduces a Caching-CDN interconnection that put emphasis on the in- 152 the network caching mechanism. As CDNi WG mainly targets 153 interconnection between two CDNs, the second use case extends this 154 use case to large-scale CDNs. The third use case introduces support 155 of dynamic adaptive streaming over HTTP (DASH) in a multi-CDNs 156 context, which may be today's most promising video distribution 157 method as it overcomes limitations posed by firewalls and promises 158 efficient distribution utilizing CDNs and network caching resources. 159 Finally, the forth use case proposes the dynamic expansion of CDN 160 capacity and geographical reach. 162 2.1 Use Case 1: Caching-CDN interconnection 164 Some telecom operators and NSP deploy caching servers, a.k.a. 165 "transparent caching" servers, in their IP networks in order to cache 166 content by CDNs over Internet, with as goal to relax and balance the 167 load on their IP networks. 169 Today in most situations the two overlay networks - the upstream CDN 170 (uCDN) and the downstream CDN (dCDN) set of transparent caching 171 servers - run independently from each other. There is no specific 172 interconnection interface between the two overlay networks. 174 There could be some interest to set up interfaces between these 175 overlay networks (of course on condition that their owners get the 176 right business incentives for). 178 Here are two illustrations of the potential benefits (this is not an 179 exhaustive list): 181 - Setting up a "logging interface" between the two overlay networks 182 could be beneficial for providing the uCDN (and beyond the Content 183 Service Providers, CSP) with useful logging, monitoring, reporting 184 data. 186 - Setting up a "CDN metadata interface" between the two overlay 187 networks could be beneficial for allowing the uCDN to request that a 188 given content file be purged from, or invalidated in, any downstream 189 caching server. 191 The current charter of the CDNi WG states "the WG will not define 192 support for transparent caching across CDNs". The first priority is 193 indeed to meet the goals and milestones specified in the current 194 charter. 196 This use case proposal aims at recommending that this "caching-cdn 197 interconnection" use case be considered in case of WG re-chartering 198 (once the present goals will be reached). 200 The first difference with the present cdn-cdn interconnection model 201 addressed by the CDNi WG is that there is no request routing 202 interface in this "caching-cdn interconnection" use case. Then 203 different sub-cases can be envisioned, depending on which CDNi 204 interfaces are leveraged (with or without logging interface, with or 205 without CDNI metadata interface, etc.). In a first approach, this 206 "caching-cdn interconnection" use case could therefore be considered 207 as a sub-case of the current CDNi WG's cdn-cdn interconnection 208 model. 210 Note. Once such specific interfaces are set up between the uCDN and 211 the dCDN set of transparent caching servers, the latter ones cannot 212 be any more considered as fully transparent, at least from the 213 viewpoint of the uCDN. This should call for a slight evolution of the 214 terminology. 216 2.2 Use Case 2: CDN-CDN interconnections at large scale 218 The current focus of the CDNi WG is on the interconnection between 219 two CDNs. 221 The purpose here would be to investigate situations where (possibly 222 much) more than two CDNs are involved in a CDN federation. 224 As stated by the Amplification Principle defined in [RFC3439] "there 225 do exist non-linearities which do not occur at small to medium scale, 226 but occur at large scale". As a result, the number of involved CDNs 227 could impact on the requirements and constraints, especially in terms 228 of scalability, and therefore on the conceivable technical options to 229 ensure interconnection. 231 As an illustration of the amplification principle application in 232 CDNi, the initial considerations, and potential issues, about request 233 routing in CDN interconnect scenarios presented in [I-D.stiemerling- 234 cdni-routing-cons] could be even more critical in large scale CDN 235 federations. 237 This would possibly lead to the definition of specific sub cases 238 corresponding to cdn-cdn interconnections at large scale. Yet the 239 first priority (and prerequisite before investigating such large 240 scale use cases) is to meet the goals and milestones specified in the 241 current charter, i.e. to specify adequate interfaces for 242 interconnecting two CDNs. So this proposal aims at recommending that 243 this "cdn-cdn interconnections at large scale" use case be considered 244 in case of WG re-chartering (once the present goals will be reached). 246 2.3 Use Case 3: Dynamic adaptive streaming over HTTP in multi-CDNs 248 The ever-growing video traffic on the Internet requires more 249 efficient content distribution mechanisms. Compared to existing 250 RTP/RTSP-based streaming or HTTP progressive download, Dynamic 251 Adaptive Streaming over HTTP (DASH) enables stateless communication 252 between a client and the corresponding server, better content 253 adaptability and support for live media services [Stockhammer2011]. 254 Intrinsic characteristic of DASH is the content fragmentation into 255 various representations comprising segments (or sub-segments) of 256 different encodings of one or several media components. These 257 components/segments are transferred, along with content metadata 258 descriptors referred to as media presentation description (MPD), to 259 the origin servers. Using MPD, clients request the segments utilizing 260 HTTP GET or partial GET requests. 262 DASH is considered as a promising solution for efficient and high- 263 quality delivery of streaming services over the Internet and is 264 currently standardized as 3GP-DASH, MPEG-DASH, and OIPF HAS. It 265 supports among others, re-use of existing technologies (codecs, 266 containers, etc.), deployment on top of HTTP-CDNs, re-use of HTTP 267 origin and cache/proxy servers, re-use of existing media play-out 268 engines, as well as on-demand, live and time-shifted delivery. 270 For example, DASH may be exploited within specific CDNs enabling 271 clients to retrieve content hosted by given surrogates, taking into 272 account the scale, the coverage and the reliability of HTTP-based CDN 273 systems. Additionally, DASH can be also utilized as a delivery 274 solution in a CDN Interconnect environment, enabling content 275 acquisition among different providers. In such a case, a content 276 service provider (e.g., CSP-1 in the following figure) will first 277 ingest the prepared content into CDN-A, so that each surrogate can 278 act as a DASH server offering the streaming service to the requesting 279 End-User, acting as DASH client, connected with a different CDN 280 (e.g., CDN-B). Towards this, CDN Interconnection requires interfaces 281 among CDNs to be capable of facilitating their collaboration besides 282 ensuring content streaming efficiently. 284 +-------+ +-------+ 285 | CSP-1 | | CSP-2 | 286 +-------+ +-------+ 287 | | 288 ,--,--,--. ,--,--,--. 289 ,-' `-. ,-' `-. 290 ( CDN Provider A )=====( CDN Provider B ) 291 `-. (CDN-A) ,-'-------`-. (CDN-B) ,-' 292 `--'--'--' | `--'--'--' 293 | | 294 | | DASH 295 DASH +------------+ 296 | User Agent/| 297 | DASH Client| 298 +------------+ 299 === CDN Interconnection 301 In other words, in an interconnected CDN environment the definition 302 of a control interface is required, which will enable DASH clients to 303 acquire specific information from a hosting CDN over multiple-CDNs. 304 Towards these, the anticipated interface must be able of 305 providing/delivering: 307 - The Media Presentation Description that contains metadata to 308 construct appropriate HTTP-URLs to access segments and to provide the 309 streaming service to the user. 311 - The Number of source surrogates: one or multiple (content segments 312 can be acquired from multiple sources). 314 - The location of source surrogates: e.g., locality-aware 315 capabilities for choosing the nearest source(s), as a matter of 316 geographical (internal or external) or network-based metrics (e.g., 317 using latency or cost-based metrics). 319 - Delivery protocols: Definition of the delivery protocols used for 320 the delivery of segments. 322 - Additional metadata for content delivery (e.g., metadata for 323 content-aware networks). 325 2.4 Use Case 4: Dynamic expansion of CDN capacity and geographical reach 327 ISPs may offer a set of specialized network services which may be 328 invoked by their customers, including CDN providers, with appropriate 329 prior agreements and possible payments. The network service of most 330 relevance to this use case is the provision of caching resources 331 located within the ISP. A CDN provider making use of such a service 332 may invoke new caching resources within a local or remote ISP to 333 dynamically create new CDN surrogate nodes. The newly created 334 resources are provided by the network provider but under the control 335 of the CDN provider. 337 This is an alternative way of dealing with increased load on a CDN, 338 and a CDN provider who is able to invoke dynamic nodes is therefore 339 able to expand dynamically to accommodate increased traffic demand or 340 extend geographical reach. Such a CDN provider could a) advertise its 341 elasticity to upstream CDNs which could simplify/enhance its 342 resource-routing algorithm decisions, or b) advertise its new 343 capabilities dynamically as it expands/contracts. These announcements 344 could be made part of the CDNi control interface interactions and 345 contributions could be made on the protocol extensions to announce 346 capabilities dynamically and also to propose elasticity metrics. 348 3 Relationship between CDNI and Information-Centric Networking 350 CDN interconnection has similar goals and use cases to Information- 351 Centric Networking (ICN). We discuss here this relation for the 352 benefit of people and organizations working in these areas. We start 353 with a very brief description of CDNs and ICN in order to have a 354 common understanding. We then discuss similarities and differences in 355 terms of objectives, technical approach, deployment and business 356 models. Finally, we explore the possibility of interaction and 357 coexistence of ICN and CDN in a future Internet. CDNs are real 358 working systems, while ICN is still at the research stage. It is 359 important to note that our analysis is based on the state of ICN 360 research and the assumption that ICN will meet its design goals. 362 A CDN is a privately owned overlay network that aims to optimize 363 delivery of content from (Content Service Providers) CSPs to End 364 Users. CDNs are independent of each other. Optimization is in terms 365 of performance, availability and cost. CDNs operate by serving 366 content to User Agents from managed caches - called surrogates - at 367 the edge of the network. CDNs may also use reserved network 368 resources. The CDN provider collaborates with NSPs on surrogate 369 placement and network resource reservation. The deployment, extension 370 and (part of) the operation of CDNs are centrally managed. To 371 maintain transparency for End Users, normal content locators (e.g., 372 URLs) are used to access content. However, the CDN treats those 373 locators as simple content identifiers when selecting a surrogate, in 374 effect, decoupling the locator from the content location. 376 ICN shares many of the goals of CDNs. Optimization of delivery with 377 ICN usually entails caching, QoS-aware routing and traffic 378 differentiation, to various degrees. Unlike CDNs, ICN aims at 379 operating natively at the NSP level (although operation as an overlay 380 is also possible). An NSP deploys ICN-enabled elements (mainly 381 routers) with minimal planning in terms of content demand. The ICN 382 reach grows with each new ICN-enabled NSP, without any central 383 management. For content access, ICN uses explicit content identifiers 384 that are independent from the content location. 386 A main objective of both CDNs and ICN is the effective delivery of 387 content from CSPs to End Users. ICN also aims at accommodating End 388 Users as small CSPs, i.e., End Users who want to share content. The 389 decoupling of content identifiers from the content location is an 390 explicit goal in ICN, while in CDN this is a by-product. 392 The main elements of a CDN are a set of content servers and a request 393 redirection system. The content servers are carefully placed to be 394 close to the User Agents and can be populated prior to any requests 395 based on foreseen demand. An End User requests content with a normal 396 URL, which triggers a part of the redirection system that resides at 397 the seeming location of the content. The redirection system selects a 398 content server based on criteria aiming to optimize some aspect of 399 the delivery task. The selected content server then delivers the 400 requested content to the User Agent. 402 In ICN, any edge router with storage capabilities can act as a 403 content server, which is populated based on actual demand. 404 Alternatively, or in addition, QoS-aware routing and traffic 405 differentiation techniques are used to establish a path from the 406 content source to the User Agent. Content is requested with a 407 dedicated identifier. This identifier can be used to route the 408 request to the content source or to an intermediate content server, 409 while constructing the path. Alternatively, the identifier can be 410 used as an index in a directory system to retrieve content metadata. 411 The metadata are then used to setup a path from the content source to 412 the User Agent. 414 A CDN constitutes an administrative domain, whereas in ICN an 415 administrative domain can be as granular as an ICN router. When 416 viewed in terms of administrative domains, CDN interconnection 417 resembles the interconnection of ICN elements/domains. As such, 418 request routing in CDNI and in ICN presents similar technical 419 challenges. Following this thinking, the Content Distribution 420 Metadata and CDNI Metadata of CDNI become related to the content 421 metadata that are used in ICN to establish a path. 423 A CDN is deployed as an overlay with all its elements independent 424 from NSPs and belonging to the same CDN Provider. The CDN Provider 425 works closely with the CSP in order to ingest and place content. 426 There's also close collaboration between the CDN Provider and the 427 NSPs for server placement and reservation of resources. Once the CDN 428 is operational, any unforeseen change in CSP requirements, network 429 conditions or End User demand will force the CDN Provider to re- 430 design the deployment. To avoid this, CDNs are designed with over- 431 provisioning and redundancy. On the other hand, ICN is deployed as 432 NSP infrastructure. Each NSP owns and independently manages the ICN 433 elements in its domain. There's no "ICN Provider" to oversee the 434 deployment of ICN. The system grows as each NSP becomes ICN-enabled. 435 In order to use ICN, CSPs need to provide content source servers and 436 content metadata. ICN is designed with flexibility in mind, which 437 permits coping with many unforeseen events. 439 In a typical business case for CDNs, a CDN is deployed in and NSP 440 domain and the NSP acts both as a CDN Provider and a (sole) CSP. NSPs 441 use this model to offer content services, such as IPTV, to their End 442 Users and so to differentiate their business. In another model for 443 CDNs, a CDN Provider agrees with several NSPs to deploy content 444 servers and reserve resources in their domain. The CDN Provider then 445 sells content delivery services to interested CSPs. 447 The ICN business model is very similar to that for connectivity 448 services. An NSP deploys ICN in its domain and makes transit or 449 peering agreements with other ICN-enabled NSPs. The NSP then offers 450 content delivery services to CSPs. It is also possible for the NSP to 451 offer content consumption services to its End Users. 453 In a future Internet where ICN is deployed by some NSPs, it would be 454 difficult to meet end-to-end the ICN performance goals, because of 455 the "holes" between ICN domains. In such a case, CDNs can act as 456 overlay bridges, because they might already have content close to the 457 downstream ICN domain. In essence, from the ICN point of view, CDN 458 Providers would become CSPs. However, the incentive for the CDN 459 Provider is unclear, as such a move could undermine its own content 460 delivery service. Borrowing from the motivation for CDNI, a CDN 461 Provider who wants to extend its reach, instead of interfacing with a 462 neighboring CDN, could interface with an ICN-enabled NSP. This is of 463 course a scenario that only market forces and time can validate. 465 4 Acknowledgements 467 This draft has been produced by the Future Media Networks (FMN) 468 cluster of the Networked Media Systems FP7 projects. The work leading 469 to these results has received funding from the European Union's 470 Seventh Framework Programme (FP7/2007-2013) in(alphabetic order): 471 ALICANTE (FP7-ICT-248652; http://www.ict-alicante.eu/), 472 COAST (FP7-ICT-248036; http://www.coast-fp7.eu/), 473 COMET (FP7-ICT-248784; http://www.comet-project.org/), 474 ENVISION (FP7-ICT-248565; http://www.envision-project.org/), 475 NEXTMEDIA (FP7-ICT-249065; http://www.fi-nextmedia.eu/) and 476 OCEAN (FP7-ICT-248775; http://www.ict-ocean.eu/). 478 4.1 List of Contributors 480 Andrzej Beben, Warsaw University of Technology, Poland; 482 Christian Timmerer, UNI-KLU, Austria; 484 David Florez Rodriguez, Telefonica R&D, Spain; 486 David Griffin, Yiannis Psaras, Raul Landa, UCL, UK; 488 Daniel Negru, Labri, France; 490 Evangelos Pallis, Petros Anapliotis, TEIC, Greece; 492 George Xilouris, DEMOKRITOS, Greece; 494 Isidro Laso, European Commission, Belgium (on a personal basis); 496 Klaus Satzke, Alcatel-Lucent Bell Labs, Germany; 498 Michalis Georgiadis, PrimeTel, Cyprus; 500 Ning Wang, University of Surrey, UK; 502 Spiros Spirou, Intracom Telecom, Greece; 504 Theodore Zahariadis (editor), Synelixis, Greece; 506 Yannick Le Louedec, Orange Labs, France; 508 Yiping Chen, Daniel Negru, CNRS-LaBRI, France. 510 5 References 512 5.1 Normative References 514 [RFC3439] R. Bush, D. Meyer, "Internet Architectural Guidelines," 515 RFC 3439, http://www.ietf.org/rfc/rfc3439.txt (updates 516 RFC 1958), December 2002. 518 [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., 519 and N. Bitar, "Content Distribution Network 520 Interconnection (CDNI) Problem Statement", draft-ietf- 521 cdni-problem-statement-00 (work progress), September 2011. 523 [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content 524 Distribution Network Interconnection (CDNI) Requirements", 525 draft-ietf-cdni-requirements-00 (work in progress), 526 September 2011. 528 [I-D.ietf-cdni-use-cases] Bertrand, G., Stephan, E., Watson, G., 529 Burbridge, T., Ma, K., "Use Cases for Content Delivery 530 Network Interconnection", draft-ietf-cdni-use-cases-00 531 (work in progress), September 2011. 533 5.2 Informative reference 535 [I-D.stiemerling-cdni-routing-cons] Stiemerling, M., "Considerations 536 on Request Routing for CDNI", draft-stiemerling-cdni- 537 routing-cons-00, July 2011 539 [Stockhammer2011] T. Stockhammer, "Dynamic adaptive streaming over 540 HTTP: standards and design principles", ACM Proceedings of 541 the second annual ACM conference on Multimedia systems, 542 2011. 544 [3GP-DASH] ETSI TS 126 247 v10.0.0 (2011-06) Universal Mobile 545 Telecommunications System (UMTS); LTE; Transparent end-to- 546 end Packet-switched Streaming Service (PSS); Progressive 547 Download and Dynamic Adaptive Streaming over HTTP (3GP- 548 DASH) (3GPP TS 26.247 version 10.0.0 Release 10). 550 Authors' Addresses 552 Yannick Le Louedec 553 Orange Labs, France 554 Email: yannick.lelouedec@orange.com 556 Christian Timmerer 557 UNI-KLU, Austria 558 Email: christian.timmerer@itec.uni-klu.ac.at 560 Spiros Spirou 561 Intracom, Greece 562 Email: spis@intracom.com 564 David Griffin 565 UCL, UK 566 Email: dgriffin@ee.ucl.ac.uk 568 Theodore Zahariadis 569 Synelixis, Greece 570 Email: zahariad@synelixis.com