idnits 2.17.1 draft-ietf-cdni-problem-statement-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 date (January 16, 2012) is 4477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-experiments-01 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-01 == Outdated reference: A later version (-03) exists of draft-jenkins-alto-cdn-use-cases-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) -- Obsolete informational reference (is this intentional?): RFC 3570 (Obsoleted by RFC 6770) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft Velocix (Alcatel-Lucent) 4 Intended status: Informational F. Le Faucheur 5 Expires: July 19, 2012 Cisco 6 N. Bitar 7 Verizon 8 January 16, 2012 10 Content Distribution Network Interconnection (CDNI) Problem Statement 11 draft-ietf-cdni-problem-statement-02 13 Abstract 15 Content Delivery Networks (CDNs) provide numerous benefits: reduced 16 delivery cost for cacheable content, improved quality of experience 17 for End Users and increased robustness of delivery. For these 18 reasons they are frequently used for large-scale content delivery. 19 As a result, existing CDN providers are scaling up their 20 infrastructure and many Network Service Providers (NSPs) are 21 deploying their own CDNs. It is generally desirable that a given 22 content item can be delivered to an End User regardless of that End 23 User's location or attachment network. This creates a requirement 24 for interconnecting standalone CDNs so they can interoperate as an 25 open content delivery infrastructure for the end-to-end delivery of 26 content from Content Service Providers (CSPs) to End Users. However, 27 no standards or open specifications currently exist to facilitate 28 such CDN interconnection. 30 The goal of this document is to outline the problem area of CDN 31 interconnection for the IETF CDNI (CDN Interconnection) working 32 group. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 19, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8 70 2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 9 71 3. CDN Interconnection Model & Problem Area for IETF . . . . . . 10 72 4. Design Approach for Realizing the CDNI Interfaces . . . . . . 14 73 4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 15 74 4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 75 4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 18 76 4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 19 77 5. Relevant work from other standardization activities . . . . . 19 78 5.1. Content Acquisition across CDNs and Delivery to End 79 User (Data plane) . . . . . . . . . . . . . . . . . . . . 20 80 5.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 21 81 6. Relationship to relevant IETF Working Groups . . . . . . . . . 22 82 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 6.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 6.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 91 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 28 92 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28 93 A.2. Related standardization activities . . . . . . . . . . . . 29 94 A.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 29 95 A.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 A.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31 97 A.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 31 98 A.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 31 99 A.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32 100 A.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 32 101 A.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 32 102 A.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33 103 A.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33 104 A.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 33 105 A.3. Related Research Projects . . . . . . . . . . . . . . . . 34 106 A.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 34 107 A.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 34 108 A.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 34 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 111 1. Introduction 113 The volume of video and multimedia content delivered over the 114 Internet is rapidly increasing and expected to continue doing so in 115 the future. In the face of this growth, Content Delivery Networks 116 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 117 content, improved quality of experience for End Users and increased 118 robustness of delivery. For these reasons CDNs are frequently used 119 for large-scale content delivery. As a result, existing CDN 120 Providers are scaling up their infrastructure and many Network 121 Service Providers (NSPs) are deploying their own CDNs. 123 It is generally desirable that a given content item can be delivered 124 to an End User regardless of that End User's location or attachment 125 network. However, a given CDN in charge of delivering a given 126 content may not have a footprint that expands close enough to the End 127 User's current location or attachment network, or may not have the 128 necessary resources, to realize the user experience and cost benefit 129 that a more distributed CDN infrastructure would allow. This creates 130 a requirement for interconnecting standalone CDNs so that their 131 collective CDN footprint and resources can be leveraged for the end- 132 to-end delivery of content from Content Service Providers (CSPs) to 133 End Users. As an example, a CSP could contract with an 134 "authoritative" CDN Provider for the delivery of content and that 135 authoritative CDN Provider could contract with one or more downstream 136 CDN Provider(s) to distribute and deliver some or all of the content 137 on behalf of the authoritative CDN Provider. The formation and 138 details of any business relationships between a CSP and a CDN 139 Provider and between one CDN Provider and another CDN Provider are 140 out of scope of this document. However, no standards or open 141 specifications currently exist to facilitate such CDN 142 interconnection. 144 The goal of this document is to outline the problem area of CDN 145 interconnection for the IETF CDNI (CDN Interconnection) working 146 group. Section 2 discusses the use cases for CDN interconnection. 147 Section 3 presents the CDNI model and problem area being considered 148 by the IETF. Section 4 describes each CDNI interface individually 149 and highlights example candidate protocols that could be considered 150 for reuse or leveraging to implement the CDNI interfaces. Section 5 151 discusses the relevant work of other standards organizations. 152 Section 6 describes the relationships between the CDNI problem space 153 and other relevant IETF Working Groups. 155 1.1. Terminology 157 This document uses the following terms: 159 Content: Any form of digital data. One important form of Content 160 with additional constraints on distribution and delivery is 161 continuous media (i.e. where there is a timing relationship between 162 source and sink). 164 Metadata: Metadata in general is data about data. 166 Content Metadata: This is metadata about Content. Content Metadata 167 comprises: 169 1. Metadata that is relevant to the distribution of the content (and 170 therefore relevant to a CDN involved in the delivery of that 171 content). We refer to this type of metadata as "Content 172 Distribution Metadata". See also the definition of Content 173 Distribution Metadata. 174 2. Metadata that is associated with the actual Content or content 175 representation, and not directly relevant to the distribution of 176 that Content. For example, such metadata may include information 177 pertaining to the Content's genre, cast, rating, etc as well as 178 information pertaining to the Content representation's 179 resolution, aspect ratio, etc. 181 Content Distribution Metadata: The subset of Content Metadata that is 182 relevant to the distribution of the content. This is the metadata 183 required by a CDN in order to enable and control content distribution 184 and delivery by the CDN. In a CDN Interconnection environment, some 185 of the Content Distribution Metadata may have an intra-CDN scope (and 186 therefore need not be communicated between CDNs), while some of the 187 Content Distribution Metadata may have an inter-CDN scope (and 188 therefore needs to be communicated between CDNs). 190 CDNI Metadata: Content Distribution Metadata with inter-CDN scope. 191 For example, CDNI Metadata may include geo-blocking information (i.e. 192 information defining geographical areas where the content is to be 193 made available or blocked), availability windows (i.e. information 194 defining time windows during which the content is to be made 195 available or blocked) and access control mechanisms to be enforced 196 (e.g. URI signature validation). CDNI Metadata may also include 197 information about desired distribution policy (e.g. prepositioned vs 198 dynamic acquisition) and about where/how a CDN can acquire the 199 content. CDNI Metadata may also include content management 200 information (e.g. request for deletion of Content from Surrogates) 201 across interconnected CDNs. 203 Dynamic content acquisition: Dynamic content acquisition is where a 204 CDN acquires content from the content source in response to an End 205 User requesting that content from the CDN. In the context of CDN 206 Interconnection, dynamic acquisition means that a downstream CDN 207 acquires the content from content sources (including upstream CDNs) 208 at some point in time after a request for that content is delegated 209 to the downstream CDN by an Upstream CDN (and that specific content 210 is not yet available in the downstream CDN). 212 Dynamic CDNI metadata acquisition: In the context of CDN 213 Interconnection, dynamic CDNI metadata acquisition means that a 214 downstream CDN acquires CDNI metadata for content from the upstream 215 CDN at some point in time after a request for that content is 216 delegated to the downstream CDN by an Upstream CDN (and that specific 217 CDNI metadata is not yet available in the downstream CDN). 219 Pre-positioned content acquisition: Content Pre-positioning is where 220 a CDN acquires content from the content source prior to, or 221 independently of, any End User requesting that content from the CDN. 222 In the context of CDN interconnection the Upstream CDN instructs the 223 Downstream CDN to acquire the content from content sources (including 224 upstream CDNs) in advance of or independent of any End User 225 requesting it. 227 Pre-positioned CDNI Metadata acquisition: In the context of CDN 228 Interconnection, CDNI Metadata pre-positioning is where the 229 Downstream CDN acquires CDNI metadata for content prior to or 230 independent of any End User requesting that content from the 231 Downstream CDN. 233 End User (EU): The 'real' user of the system, typically a human but 234 maybe some combination of hardware and/or software emulating a human 235 (e.g. for automated quality monitoring etc.) 237 User Agent (UA): Software (or a combination of hardware and software) 238 through which the End User interacts with a Content Service. The 239 User Agent will communicate with a Content Service for the selection 240 of content and one or more CDNs for the delivery of the Content. 241 Such communication is not restricted to HTTP and may be via a variety 242 of protocols. Examples of User Agents (non-exhaustive) are: 243 Browsers, Set Top Boxes (STBs), dedicated content applications (e.g. 244 media players), etc. 246 Network Service Provider (NSP): Provides network-based connectivity/ 247 services to End Users. 249 Content Service Provider (CSP): Provides a Content Service to End 250 Users (which they access via a User Agent). A CSP may own the 251 Content made available as part of the Content Service, or may license 252 content rights from another party. 254 Content Service: The service offered by a Content Service Provider. 256 The Content Service encompasses the complete service which may be 257 wider than just providing access to items of Content, e.g. the 258 Content Service also includes any middleware, key distribution, 259 program guide, etc. which may not require any direct interaction with 260 the CDN, or CDNs, involved in the distribution and delivery of the 261 content. 263 Content Distribution Network (CDN) / Content Delivery Network (CDN): 264 Network infrastructure in which the network elements cooperate at 265 layers 4 through layer 7 for more effective delivery of Content to 266 User Agents. Typically a CDN consists of a Request Routing system, a 267 Distribution System (that includes a set of Surrogates), a Logging 268 System and a CDN control system. 270 CDN Provider: The service provider who operates a CDN and offers a 271 service of content delivery, typically used by a Content Service 272 Provider or another CDN Provider. Note that a given entity may 273 operate in more than one role. For example, a company may 274 simultaneously operate as a Content Service Provider, a Network 275 Service Provider and a CDN Provider. 277 CDN Interconnection (CDNI): A relationship between a pair of CDNs 278 that enables one CDN to provide content delivery services on behalf 279 of another CDN. A CDN Interconnection may be wholly or partially 280 realised through a set of interfaces over which a pair of CDNs 281 communicate with each other in order to achieve the delivery of 282 content to User Agents by Surrogates in one CDN (the downstream CDN) 283 on behalf of another CDN (the upstream CDN). 285 Authoritative CDN: A CDN which has a direct relationship with a CSP 286 for the distribution & delivery of that CSP's content by the 287 authoritative CDN or by downstream CDNs of the authoritative CDN. 289 Upstream CDN: For a given End User request, the CDN (within a pair of 290 directly interconnected CDNs) that redirects the request to the other 291 CDN. 293 Downstream CDN: For a given End User request, the CDN (within a pair 294 of directly interconnected CDNs) to which the request is redirected 295 by the other CDN (the Upstream CDN). Note that in the case of 296 successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g. 297 CDN2) may act as the Downstream CDN for a redirection (e.g. 298 CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection 299 of the same request (e.g. CDN2-->CDN3). 301 Over-the-top (OTT): A service, e.g. content delivery using a CDN, 302 operated by a different operator than the NSP to which the users of 303 that service are attached. 305 Surrogate: A device/function that interacts with other elements of 306 the CDN for the control and distribution of Content within the CDN 307 and interacts with User Agents for the delivery of the Content. 309 Request Routing System: The function within a CDN responsible for 310 receiving a content request from a User Agent, obtaining and 311 maintaining necessary information about a set of candidate surrogates 312 or candidate CDNs, and for selecting and redirecting the user to the 313 appropriate surrogate or CDN. To enable CDN Interconnection, the 314 Request Routing System must also be capable of handling User Agent 315 content requests passed to it by another CDN. 317 Distribution System: The function within a CDN responsible for 318 distributing Content Distribution Metadata as well as the Content 319 itself inside the CDN (e.g. down to the surrogates). 321 Delivery: The function within CDN surrogates responsible for 322 delivering a piece of content to the User Agent. For example, 323 delivery may be based on HTTP progressive download or HTTP adaptive 324 streaming. 326 Logging System: The function within a CDN responsible for collecting 327 the measurement and recording of distribution and delivery 328 activities. The information recorded by the logging system may be 329 used for various purposes including charging (e.g. of the CSP), 330 analytics and monitoring. 332 Control System: The function within a CDN responsible for 333 bootstrapping and controlling the other components of the CDN as well 334 as for handling interactions with external systems (e.g. handling 335 delivery service creation/update/removal requests, or specific 336 service provisioning requests). 338 1.2. CDN Background 340 Readers are assumed to be familiar with the architecture, features 341 and operation of CDNs. For readers less familiar with the operation 342 of CDNs, the following resources may be useful: 344 o RFC 3040 [RFC3040] describes many of the component technologies 345 that are used in the construction of a CDN. 346 o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. 347 o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 348 IETF Content Delivery Internetworking (CDI) working group which 349 was closed in 2003. 351 Note: Some of the terms used in this document are similar to terms 352 used the above referenced documents. When reading this document 353 terms should be interpreted as having the definitions provided in 354 Section 1.1. 356 2. CDN Interconnection Use Cases 358 An increasing number of NSPs are deploying CDNs in order to deal 359 cost-effectively with the growing usage of on-demand video services 360 and other content delivery applications. 362 CDNs allow caching of content closer to the edge of a network so that 363 a given item of content can be delivered by a CDN Surrogate (i.e. a 364 cache) to multiple User Agents (and their End Users) without 365 transiting multiple times through the network core (i.e from the 366 content origin to the surrogate). This contributes to bandwidth cost 367 reductions for the NSP and to improved quality of experience for the 368 End Users. CDNs also enable replication of popular content across 369 many surrogates, which enables content to be served to large numbers 370 of User Agents concurrently. This also helps dealing with situations 371 such as flash crowds and denial of service attacks. 373 The CDNs deployed by NSPs are not just restricted to the delivery of 374 content to support the Network Service Provider's own 'walled garden' 375 services, such as IP delivery of television services to Set Top 376 Boxes, but are also used for delivery of content to other devices 377 including PCs, tablets, mobile phones etc. 379 Some service providers operate over multiple geographies and federate 380 multiple affiliate NSPs. These NSPs typically operate independent 381 CDNs. As they evolve their services (e.g. for seamless support of 382 content services to nomadic users across affiliate NSPs) there is a 383 need for interconnection of these CDNs, that represents a first use 384 case for CDNI. However there are no open specifications, nor common 385 best practices, defining how to achieve such CDN interconnection. 387 CSPs have a desire to be able to get (some of) their content to very 388 large number of End Users and/or over many/all geographies and/or 389 with a high quality of experience, all without having to maintain 390 direct business relationships with many different CDN providers (or 391 having to extend their own CDN to a large number of locations). Some 392 NSPs are considering interconnecting their respective CDNs (as well 393 as possibly over-the-top CDNs) so that this collective infrastructure 394 can address the requirements of CSPs in a cost effective manner. 395 This represents a second use case for CDNI. In particular, this 396 would enable the CSPs to benefit from on-net delivery (i.e. within 397 the Network Service Provider's own network/CDN footprint) whenever 398 possible and off-net delivery otherwise, without requiring the CSPs 399 to maintain direct business relationships with all the CDNs involved 400 in the delivery. Again, for this requirement, CDN providers (NSPs or 401 over-the-top CDN operators) are faced with a lack of open 402 specifications and best practices. 404 NSPs have often deployed CDNs as specialized cost-reduction projects 405 within the context of a particular service or environment, some NSPs 406 operate separate CDNs for separate services. For example, there may 407 be a CDN for managed IPTV service delivery, a CDN for web-TV delivery 408 and a CDN for video delivery to Mobile terminals. As NSPs integrate 409 their service portfolio, there is a need for interconnecting these 410 CDNs, representing a third use case for CDNI. Again, NSPs face the 411 problem of lack of open interfaces for CDN interconnection. 413 For operational reasons (e.g. disaster, flash crowd) or commercial 414 reasons, an over-the-top CDN may elect to make use of another CDN 415 (e.g. an NSP CDN with on-net Surrogates for a given footprint) for 416 serving a subset of the user requests (e.g. requests from users 417 attached to that NSP), which results in a fourth use case for CDNI. 418 Again, for this requirement, CDN providers (over-the-top CDN 419 providers or NSPs) are faced with a lack of open specifications and 420 best practices. 422 Use cases for CDN Interconnection are further discussed in 423 [I-D.ietf-cdni-use-cases]. 425 3. CDN Interconnection Model & Problem Area for IETF 427 Interconnecting CDNs involves interactions among multiple different 428 functions and components that form each CDN. Only some of those 429 require standardization. This section discusses the problem area for 430 the IETF work on CDN Interconnection. The CDNI model and problem 431 area defined for IETF work is illustrated in Figure 1. 433 -------- 434 / \ 435 | CSP | 436 \ / 437 -------- 438 * 439 * 440 * /\ 441 * / \ 442 ---------------------- |CDNI| ---------------------- 443 / Upstream CDN \ | | / Downstream CDN \ 444 | +-------------+ | Control Interface| +-------------+ | 445 |******* Control |<======|====|========>| Control *******| 446 |* +------*----*-+ | | | | +-*----*------+ *| 447 |* * * | | | | * * *| 448 |* +------*------+ | Logging Interface| +------*------+ *| 449 |* ***** Logging |<======|====|========>| Logging ***** *| 450 |* * +-*-----------+ | | | | +-----------*-+ * *| 451 |* * * * | Request Routing | * * * *| 452 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 453 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 454 . |* * * +-------------+.| | | | +-------------+ * * *| . 455 . |* * * . CDNI Metadata | * * *| . 456 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 457 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 458 . |* * * | | | . \ / | | | * * *| . 459 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 460 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 461 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 462 . |******* +---------+| | Acquisition | |+----------+ *******| . 463 . | +-------------+ | | +-------*-----+ | . 464 . \ / \ * / . 465 . ---------------------- ---------*------------ . 466 . * . 467 . * Delivery . 468 . * . 469 . +--*---+ . 470 ...............Request.............................| User |..Request.. 471 | Agent| 472 +------+ 474 <==> interfaces inside the scope of CDNI 475 **** interfaces outside the scope of CDNI 476 .... interfaces outside the scope of CDNI 478 Figure 1: CDNI Model 480 Listed below are the four interfaces required to interconnect a pair 481 of CDNs and that constitute the problem space that is proposed to be 482 addressed by the CDNI working group in the IETF. The use of the term 483 "interface" is meant to encompass the protocol over which CDNI data 484 representations (e.g. CDNI Metadata objects) are exchanged as well 485 as the specification of the data representations themselves (i.e. 486 what properties/fields each object contains, its structure, etc.). 488 o CDNI Control interface: This interface allows the "CDNI Control" 489 system in interconnected CDNs to communicate. This interface may 490 support the following: 491 * Allow bootstrapping of the other CDNI interfaces (e.g. 492 interface address/URL discovery and establishment of security 493 associations). 494 * Allow configuration of the other CDNI interfaces (e.g. 495 Upstream CDN specifies information to be reported through the 496 CDNI Logging interface). 497 * Allow the downstream CDN to communicate static (or fairly 498 static) information about its delivery capabilities and 499 policies. 500 * Allow bootstrapping of the interface between CDNs for content 501 acquisition (even if that interface itself is outside the scope 502 of the CDNI work). 503 * Allow upstream CDN to initiate or request specific actions to 504 be undertaken in the downstream CDN. For example, this may 505 include the following capabilities: 506 + Allow an upstream CDN to request that content files and/or 507 CDNI Metadata that it previously shared, be purged from, or 508 invalidated in, a downstream CDN. Support for content 509 deletion or invalidation from a CDN is a key requirement for 510 some Content Service Providers in order, amongst other use 511 cases for content deletion, to support the content rights 512 agreements they have negotiated. Today's CDNs use 513 proprietary control interfaces to enable CSPs to remove 514 content cached in the CDN and therefore there is a need to 515 have a similar but standardized content deletion capability 516 between interconnected CDNs. 517 + Allow an upstream CDN to initiate Pre-positioned content 518 acquisition and/or Pre-positioned CDNI Metadata acquisition 519 in a downstream CDN. 520 o CDNI Request Routing interface: This interface allows the Request 521 Routing systems in interconnected CDNs to communicate to ensure 522 that an End User request can be (re)directed from an upstream CDN 523 to a surrogate in the downstream CDN, in particular where 524 selection responsibilities may be split across CDNs (for example 525 the upstream CDN may be responsible for selecting the downstream 526 CDN while the downstream CDN may be responsible for selecting the 527 actual surrogate within that downstream CDN). In particular, the 528 CDN Request Routing interface, may support the following: 530 * Allow the upstream CDN to query the downstream CDN at request 531 routing time before redirecting the request to the downstream 532 CDN. 533 * Allow the downstream CDN to provide to the upstream CDN (static 534 or dynamic) information (e.g. resources, footprint, load) to 535 facilitate selection of the downstream CDN by the upstream CDN 536 request routing system when processing subsequent content 537 requests from User Agents. 538 o CDNI Metadata distribution interface: This interface allows the 539 Distribution system in interconnected CDNs to communicate to 540 ensure CDNI Metadata can be exchanged across CDNs. See 541 Section 1.1 for definition and examples of CDNI Metadata. 542 o CDNI Logging interface: This interface allows the Logging system 543 in interconnected CDNs to communicate the relevant activity logs 544 in order to allow log consuming applications to operate in a 545 multi-CDN environments. For example, an upstream CDN may collect 546 delivery logs from a downstream CDN in order to perform 547 consolidated charging of the CSP or for settlement purposes across 548 CDNs. Similarly, an upstream CDN may collect delivery logs from a 549 downstream CDN in order to provide consolidated reporting and 550 monitoring to the CSP. 552 Note that the actual grouping of functionalities under these four 553 interfaces is considered tentative at this stage and may be changed 554 after further study (e.g. some subset of functionality be moved from 555 one interface into another). 557 The above list covers a significant potential problem space, in part 558 because in order to interconnect two CDNs there are several 'touch 559 points' that require standardization. However, it is expected that 560 the CDNI interfaces need not be defined from scratch and instead can 561 very significantly reuse or leverage existing protocols: this is 562 discussed further in Section 4. Also, it is expected that the items 563 above will be prioritized so that the CDNI Working Group can focus 564 (at least initially) on the most essential and urgent work. 566 As part of the development of the CDNI interfaces and solutions it 567 will also be necessary to agree on common mechanisms for how to 568 identify and name the data objects that are to be interchanged 569 between interconnected CDNs. 571 Some NSPs have started to perform experiments to explore whether 572 their CDN use cases can already be addressed with existing CDN 573 implementations. One set of such experiments is documented in 574 [I-D.bertrand-cdni-experiments]. The conclusions of those 575 experiments are that while some basic limited CDN Interconnection 576 functionality can be achieved with existing CDN technology, the 577 current lack of any standardized CDNI interfaces/protocols such as 578 those discussed in this document is preventing the deployment of 579 production CDN Interconnection solutions with the necessary level of 580 functionality. 582 As illustrated in Figure 1, the acquisition of content between 583 interconnected CDNs is out of scope for CDNI, which deserves some 584 additional explanation. The consequence of such a decision is that 585 the CDNI working group is focussed on only defining the control plane 586 for CDNI; and the CDNI data plane (i.e. the acquisition & 587 distribution of the actual content objects) will not be addressed by 588 the CDNI working group. The rationale for such a decision is that 589 CDNs today typically already use standardized protocols such as HTTP, 590 FTP, rsync, etc. to acquire content from their CSP customers and it 591 is expected that the same protocols could be used for acquisition 592 between interconnected CDNs. Therefore the problem of content 593 acquisition is considered already solved and all that is required 594 from specifications developed by the CDNI working group is to 595 describe within the CDNI Metadata where to go and which protocol to 596 use to retrieve the content. 598 4. Design Approach for Realizing the CDNI Interfaces 600 This section expands on how CDNI interfaces can reuse and leverage 601 existing protocols before describing each CDNI interface individually 602 and highlighting example candidate protocols that could be considered 603 for reuse or leveraging to implement the CDNI interfaces. This 604 discussion is not intended to pre-empt any working group decision as 605 to the most appropriate protocols, technologies and solutions to 606 select to realize the CDNI interfaces but is intended as an 607 illustration of the fact that the CDNI interfaces need not be created 608 in a vacuum and that reuse or leverage of existing protocols is 609 likely possible. 611 The four CDNI interfaces (CDNI Control interface, CDNI Request 612 Routing interface, CDNI Metadata interface, CDNI Logging interface) 613 described in Section 3 within the CDNI problem area are all control 614 plane interfaces operating at the application layer (Layer 7 in the 615 OSI network model). Firstly, since it is not expected that these 616 interfaces would exhibit unique session, transport or network 617 requirements as compared to the many other existing applications in 618 the Internet, it is expected that the CDNI interfaces will be defined 619 on top of existing session, transport and network protocols. 621 Secondly, although a new application protocol could be designed 622 specifically for CDNI we assume that this is unnecessary and it is 623 recommended that existing application protocols be reused or 624 leveraged (HTTP [RFC2616], Atom Publishing Protocol [RFC5023], XMPP 626 [RFC6120], for example) to realize the CDNI interfaces. 628 4.1. CDNI Request Routing Interface 630 The CDNI Request Routing interface enables a Request Routing function 631 in an upstream CDN to query a Request Routing function in a 632 downstream CDN to determine if the downstream CDN is able (and 633 willing) to accept the delegated content request and to allow the 634 downstream CDN to control what the upstream Request Routing function 635 should return to the User Agent in the redirection message. 637 Therefore, the CDNI Request Routing interface needs to offer a 638 mechanism for an upstream CDN to issue a "Redirection Request" to a 639 downstream CDN. The Request Routing interface needs to be able to 640 support scenarios where the initial User Agent request to the 641 upstream CDN is received over DNS as well as over a content specific 642 application protocol (e.g. HTTP, RTSP, RTMP, etc.). 644 Therefore a Redirection Request is expected to contain information 645 such as: 647 o The protocol (e.g. DNS, HTTP) over which the upstream CDN 648 received the initial User Agent request. 649 o Additional details of the User Agent request that are required to 650 perform effective Request Routing by the Downstream CDN. For DNS 651 this would typically be the IP address of the DNS resolver making 652 the request on behalf of the User Agent. For requests received 653 over content specific application protocols the Redirection 654 Request could contain significantly more information related to 655 the original User Agent request but at a minimum is expected to 656 include the User Agent's IP address, the equivalent of the HTTP 657 Host header and the equivalent of the HTTP abs_path defined in 658 [RFC2616]. 660 It should be noted that, the CDNI architecture needs to consider that 661 a downstream CDN may receive requests from User Agents without first 662 receiving a Redirection Request from an upstream CDN for the 663 corresponding User Agent request, for example because: 665 o User Agents (or DNS resolvers) may cache DNS or application 666 responses from Request Routers. 667 o Responses to Redirection Requests over the Request Routing 668 interface may be cacheable. 669 o Some CDNs may rely on simple coarse policies, e.g. CDN B agrees 670 to always serve CDN A's delegated redirection requests, in which 671 case the necessary redirection details are exchanged out of band 672 (of the CDNI interfaces), e.g. configured. 674 On receiving a Redirection Request, the downstream CDN will use the 675 information provided in the request to determine if it is able (and 676 willing) to accept the delegated content request and needs to return 677 the result of its decision to the upstream CDN. 679 Thus, a Redirection Response from the downstream CDN is expected to 680 contain information such as: 682 o Status code indicating acceptance or rejection (possibly with 683 accompanying reasons). 684 o Information to allow redirection by the Upstream CDN. In the case 685 of DNS-based request routing, this is expected to include the 686 equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN 687 should return to the requesting DNS resolver. In the case of 688 application based request routing, this is expected to include the 689 information necessary to construct the application specific 690 redirection response(s) to return to the requesting User Agent. 691 For HTTP requests from User Agents this could include a URI that 692 the upstream CDN could return in a HTTP 3xx response. 694 The CDNI Request Routing interface is therefore a fairly 695 straightforward request/response interface and could be implemented 696 over any number of request/response protocols. For example, it may 697 be implemented as a WebService using one of the common WebServices 698 methodologies (XML-RPC, HTTP query to a known URI, etc.). This 699 removes the need for the CDNI working group to define a new protocol 700 for the request/response element of the CDNI Request Routing 701 interface. Thus, the CDNI working group would be left only with the 702 task of specifying: 704 o The recommended request/response protocol to use along with any 705 additional semantics and procedures that are specific to the CDNI 706 Request Routing interface (e.g. handling of malformed requests/ 707 responses). 708 o The syntax (i.e representation/encoding) of the redirection 709 requests and responses. 710 o The semantics (i.e. meaning and expected contents) of the 711 redirection requests and responses. 713 Additionally, as discussed in Section 3, the CDNI Request Routing 714 interface is also expected to enable a downstream CDN to provide to 715 the upstream CDN (static or dynamic) information (e.g. resources, 716 footprint, load) to facilitate selection of the downstream CDN by the 717 upstream CDN request routing system when processing subsequent 718 content requests from User Agents. It is expected that such 719 functionality of the CDNI request Routing could be specified by the 720 CDNI working group with significant leveraging of existing IETF 721 protocols supporting the dynamic distribution of reachability 722 information (for example by leveraging existing routing protocols) or 723 supporting application level queries for topological information (for 724 example by leveraging ALTO). 726 4.2. CDNI Metadata Interface 728 The CDNI Metadata interface enables the Distribution System in a 729 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 730 the downstream CDN can properly process and respond to: 732 o Redirection Requests received over the CDNI Request Routing 733 interface. 734 o Content Requests received directly from User Agents. 736 The CDNI Metadata interface needs to offer a mechanism for an 737 Upstream CDN to: 739 o Distribute/update/remove CDNI Metadata to a Downstream CDN. 741 and/or to allow a downstream CDN to: 743 o Make direct requests for CDNI Metadata objects 744 o Make recursive requests for CDNI metadata, for example to enable a 745 downstream CDN to walk down a tree of objects with inter-object 746 relationships. 748 The CDNI Metadata interface is therefore similar to the CDNI Request 749 Routing interface because it is a request/response interface with the 750 potential addition that CDNI Metadata search may have more complex 751 semantics than a straightforward Request Routing redirection request. 752 Therefore, like the CDNI Request Routing interface, the CDNI Metadata 753 interface may be implemented as a WebService using one of the common 754 WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 755 or possibly using other existing protocols such as XMPP [RFC6120]. 756 This removes the need for the CDNI working group to define a new 757 protocol for the request/response element of the CDNI Metadata 758 interface. 760 Thus, the CDNI working group would be left only with the task of 761 specifying: 763 o The recommended request/response protocol to use along with any 764 additional semantics that are specific to the CDNI Metadata 765 interface (e.g. handling of malformed requests/responses). 766 o The syntax (i.e representation/encoding) of the CDNI Metadata 767 objects that will be exchanged over the interface. 769 o The semantics (i.e. meaning and expected contents) of the 770 individual properties of a Metadata object. 771 o How the relationships between different CDNI Metadata objects are 772 represented. 774 4.3. CDNI Logging Interface 776 The CDNI Logging interface enables details of logs or events to be 777 exchanged between interconnected CDNs, where events could be: 779 o Log lines related to the delivery of content (similar to the log 780 lines recorded in a web server's access log). 781 o Real-time or near-real time events before, during or after content 782 delivery, e.g. content delivery interruption 783 o Operations and diagnostic messages. 785 Within CDNs today, logs and events are used for a variety of purposes 786 in addition to real-time and non real-time diagnostics and auditing 787 by the CDN Provider and its customers. Specifically CDNs use logs to 788 generate Call Data Records (CDRs) for passing to billing and payment 789 systems and to real-time (and near real-time) analytics systems. 790 Such applications place requirements on the CDNI Logging interface to 791 support guaranteed and timely delivery of log messages between 792 interconnected CDNs. It may also be necessary to be able to prove 793 the integrity of received log messages. 795 Several protocols already exist that could potentially be used to 796 exchange CDNI logs between interconnected CDNs including SNMP Traps, 797 syslog, ftp, HTTP POST, etc. although it is likely that some of the 798 candidate protocols may not be well suited to meet all the 799 requirements of CDNI. For example SNMP traps pose scalability 800 concerns and SNMP does not support guaranteed delivery of Traps and 801 therefore could result in log records being lost and the consequent 802 CDRs and billing records for that content delivery not being produced 803 as well as that content delivery being invisible to any analytics 804 platforms. 806 Although it is not necessary to define a new protocol for exchanging 807 logs across the CDNI Logging interface, the CDNI working group would 808 still need to specify: 810 o The recommended protocol to use. 811 o A default set of log fields and their syntax & semantics. Today 812 there is no standard set of common log fields across different 813 content delivery protocols and in some cases there is not even a 814 standard set of log field names and values for different 815 implementations of the same delivery protocol. 817 o A default set of events that trigger logs to be generated. 819 4.4. CDNI Control Interface 821 The CDNI Control interface allows the Control System in 822 interconnected CDNs to communicate. The exact inter-CDN control 823 functionality required to be supported by the CDNI Control interface 824 is less well defined than the other three CDNI interfaces at this 825 time. 827 However, as discussed in Section 3, the CDNI Control interface may be 828 required to support functionality similar to the following: 829 o Allow an upstream CDN and downstream CDN to establish, update or 830 terminate their CDNI interconnection. 831 o Allow bootstrapping of the other CDNI interfaces (e.g. protocol 832 address discovery and establishment of security associations). 833 o Allow configuration of the other CDNI interfaces (e.g. Upstream 834 CDN specifies information to be reported through the CDNI Logging 835 interface). 836 o Allow the downstream CDN to communicate static information about 837 its delivery capabilities, resources and policies. 838 o Allow bootstrapping of the interface between CDNs for content 839 acquisition (even if that interface itself is outside the scope of 840 the CDNI work). 841 It is expected that for the Control interface also, existing 842 protocols can be reused or leveraged. Those will be considered once 843 the requirements for the Control interface have been refined. 845 5. Relevant work from other standardization activities 847 There are a number of other standards bodies and industry forums that 848 are working in areas related to CDNs, and in some cases related to 849 CDNI. This section outlines any potential overlap with the work of 850 the CDNI working group and any component that could potentially be 851 reused to realize the CDNI interfaces. 853 A number of standards bodies have produced specifications related to 854 CDNs, for example: 856 o ETSI TISPAN (Telecommunications and Internet converged Services 857 and Protocols for Advanced Networking) has a series of 858 specifications focusing on CDNs. 859 o The Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum 860 (IIF) specify the architecture and the protocols of an IPTV 861 solution. Although OIPF and ATIS specifications include the 862 interaction with a CDN, the CDN specifications are coupled with 863 their IPTV specifications and do not cover interconnection of 864 CDNs. 865 o ATIS Cloud Services Forum (CSF) has started investigating 866 interconnection of CDNs. The ATIS CSF focuses on defining use 867 cases and requirements for such CDN interconnection, which are 868 expected to be considered as input into the work of the CDNI 869 working group. At the time of writing this document, ATIS CSF is 870 not specifying the corresponding protocols or interfaces and is 871 expected to leverage the work of the IETF CDNI working group for 872 those. 873 o CableLabs, SNIA and ITU have developed (or are working on) 874 definitions for content related metadata and specifications for 875 its distribution. However, they do not include metadata specific 876 to the distribution of content within a CDN or between 877 interconnected CDNs. 878 o IETF CDI working group (now concluded) touched on the same problem 879 space as the present document. However, in accordance with its 880 initial charter, the CDI working group did not define any 881 protocols or interfaces to actually enable CDN Interconnection and 882 at that time (2003) there was not enough industry interest and 883 real life requirements to justify rechartering the working group 884 to conduct the corresponding protocol work. 886 Although some of the specifications describe multi-CDN cooperation or 887 include reference points for interconnecting CDNs, none of them 888 specify in sufficient detail all the CDNI interfaces and CDNI 889 Metadata representations required to enable even a base level of CDN 890 Interconnection functionality to be implemented. 892 The following sections will summarize the existing work of the 893 standard bodies listed earlier against the CDNI problem space. 894 Section 5.1 summarises existing interfaces that could be leveraged 895 for content acquisition between CDNs and Section 5.2 summarises 896 existing metadata specifications that may be applicable to CDNI. To 897 date we are not aware of any standardisation activities in the areas 898 of the remaining CDNI interfaces (CDNI Request Routing, CDNI Control 899 and CDNI Logging). 901 5.1. Content Acquisition across CDNs and Delivery to End User (Data 902 plane) 904 A number of standards bodies have completed work in the areas of 905 content acquisition interface between a CSP and a CDN, as well as as 906 on the delivery interface between the surrogate and the User Agent. 907 Some of this work is summarized below. 909 TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand 910 (CoD) services, including the data plane aspects (typically different 911 flavors of RTP/RTCP and HTTP) to obtain content and deliver it to 912 User Agents. For example, : 913 o The OIPF data plane includes both RTP and HTTP flavors (HTTP 914 progressive download, HTTP Adaptive streaming [3GP-DASH]). 915 o The ATIS IIF specification "IPTV Content on Demand (CoD) Service" 916 [ATIS-COD] defines a reference point (C2) and the corresponding 917 HTTP-based data plane protocol for content acquisition between an 918 authoritative origin server and the CDN. 919 While these protocols have not been explicitly specified for content 920 acquisition across CDNs, they are suitable (in addition to others 921 such as standard HTTP) for content acquisition between CDNs in a CDN 922 Interconnection environment. Therefore for the purpose of the CDNI 923 working group there are already multiple existing data plane 924 protocols that can be used for content acquisition across CDNs. 926 Similarly, there are multiple existing standards (e.g. the OIPF data 927 plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public 928 specifications (e.g. vendor specific HTTP Adaptive streaming 929 specifications) so that content delivery can be considered already 930 solved (or at least sufficiently addressed in other forums). 932 Thus, specification of the content acquisition interface between CDNs 933 and the delivery interface between the surrogate and the User Agent 934 are out of scope for the CDNI working group. The CDNI working group 935 may only concern itself with the negotiation/selection aspects of the 936 acquisition protocol to be used in a CDN interonnect scenario. 938 5.2. CDNI Metadata 940 CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the 941 specification of content metadata: 943 o CableLabs has defined specifications for CoD Content Metadata as 944 part of its VOD Metadata project. "The VOD Metadata project is a 945 cable television industry and cross-industry-wide effort to 946 specify the metadata and interfaces for distribution of video-on- 947 demand (VOD) material from multiple content providers to cable 948 operators." [CableLabs-Metadata]. However, while the CableLabs 949 work specifies an interface between a content provider and a 950 service provider running a CDN, it does not include an interface 951 that could be used between CDNs. 952 o ITU Study Group 16 has started work on a number of draft 953 Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA, 954 HSTP.IPTV-UMCI) specifying metadata for content distribution in 955 IPTV services. 956 o An Open IPTV Terminal receives the technical description of the 957 content distribution from the OIPF IPTV platform before receiving 958 any content. The Content distribution metadata is sent in the 959 format of a TV-Anytime XSD including tags to describes the 960 location and program type (on demand or Live) as well as 961 describing the time availability of the on demand and live 962 content. 964 However the specifications outlined above do not include metadata 965 specific to the distribution of content within a CDN or between 966 interconnected CDNs, for example geo-blocking information, 967 availability windows, access control mechanisms to be enforced by the 968 surrogate, how to map an incoming content request to a file on the 969 origin server or acquire it from the upstream CDN etc. 971 The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can 972 be associated with data that is stored by a cloud storage provider. 973 While the metadata currently defined do not match the need of a CDN 974 Interconnection solution, it is worth considering CDMI as one of the 975 existing pieces of work that may potentially be leveraged for the 976 CDNI Metadata interface (e.g by extending the CDMI metadata to 977 address more specific CDNI needs). 979 6. Relationship to relevant IETF Working Groups 981 6.1. ALTO 983 As stated in the ALTO Working Group charter [ALTO-Charter]: 985 "The Working Group will design and specify an Application-Layer 986 Traffic Optimization (ALTO) service that will provide applications 987 with information to perform better-than-random initial peer 988 selection. ALTO services may take different approaches at balancing 989 factors such as maximum bandwidth, minimum cross-domain traffic, 990 lowest cost to the user, etc. The working group will consider the 991 needs of BitTorrent, tracker-less P2P, and other applications, such 992 as content delivery networks (CDN) and mirror selection." 994 In particular, the ALTO service can be used by a CDN Request Routing 995 system to improve its selection of a CDN surrogate to serve a 996 particular User Agent request (or to serve a request from another 997 surrogate). [I-D.jenkins-alto-cdn-use-cases] describes a number of 998 use cases for a CDN to be able to obtain network topology and cost 999 information from an ALTO server(s) and discusses how CDN Request 1000 Routing could be used as an integration point of ALTO into CDNs. It 1001 is possible that the ALTO service could be used in the same manner in 1002 a multi-CDN environment based on CDN Interconnection. For example, 1003 an upstream CDN may take advantage of the ALTO service in its 1004 decision for selecting a downstream CDN to which a user request 1005 should be delegated. 1007 However, the current work of ALTO is complementary to and does not 1008 overlap with the work described in this document because the 1009 integration between ALTO and a CDN is an internal decision for a 1010 specific CDN and is therefore out of scope for the CDNI working 1011 group. One area for further study is whether additional information 1012 should be provided by an ALTO service to facilitate CDNI CDN 1013 selection. 1015 6.2. DECADE 1017 The DECADE Working Group [DECADE-Charter] is addressing the problem 1018 of reducing traffic on the last-mile uplink, as well as backbone and 1019 transit links caused by P2P streaming and file sharing applications. 1020 It addresses the problem by enabling an application endpoint to make 1021 content available from an in-network storage service and by enabling 1022 other application endpoints to retrieve the content from there. 1024 Exchanging data through the in-network storage service in this 1025 manner, instead of through direct communication, provides significant 1026 gain where: 1028 o The network capacity/bandwidth from in-network storage service to 1029 application endpoint significantly exceeds the capacity/bandwidth 1030 from application endpoint to application endpoint (e.g. because of 1031 an end-user uplink bottleneck); and 1032 o Where the content is to be accessed by multiple instances of 1033 application endpoints (e.g. as is typically the case for P2P 1034 applications). 1036 While, as is the case for any other data distribution application, 1037 the DECADE architecture and mechanisms could potentially be used for 1038 exchange of CDNI control plane information via an in-network-storage 1039 service (as opposed to directly between the entities terminating the 1040 CDNI interfaces in the neighbor CDNs), we observe that: 1042 o CDNI would operate as a "Content Distribution Application" from 1043 the DECADE viewpoint (i.e. would operate on top of DECADE). 1044 o There does not seem to be obvious benefits in integrating the 1045 DECADE control plane responsible for signaling information 1046 relating to control of the in-network storage service itself, and 1047 the CDNI control plane responsible for application-specific CDNI 1048 interactions (such as exchange of CDNI metadata, CDNI request 1049 redirection, transfer of CDNI logging information). 1050 o There would typically be limited benefits in making use of a 1051 DECADE in-network storage service because the CDNI interfaces are 1052 expected to be terminated by a very small number of CDNI clients 1053 (if not one) in each CDN, and the CDNI clients are expected to 1054 benefit from high bandwidth/capacity when communicating directly 1055 to each other (at least as high as if they were communicating via 1056 an in-network storage server). 1058 The DECADE in-network storage architecture and mechanisms may 1059 theoretically be used for the acquisition of the content objects 1060 themselves between interconnected CDNs. It is not expected that this 1061 would have obvious benefits in typical situations where a content 1062 object is acquired only once from an Upstream CDN to a Downstream CDN 1063 (and then distributed as needed inside the Downstream CDN). But it 1064 might have benefits in some particular situations. Since the 1065 acquisition protocol between CDNs is outside the scope of the CDNI 1066 work, this question is left for further study. 1068 The DECADE in-network storage architecture and mechanisms may 1069 potentially also be used within a given CDN for the distribution of 1070 the content objects themselves among surrogates of that CDN. Since 1071 the CDNI work does not concern itself with operation within a CDN, 1072 this question is left for further study. 1074 Therefore, the work of DECADE may be complementary to but does not 1075 overlap with the CDNI work described in this document. 1077 6.3. PPSP 1079 As stated in the PPSP Working Group charter [PPSP-Charter]: 1081 "The Peer-to-Peer Streaming Protocol (PPSP) working group develops 1082 two signaling and control protocols for a peer-to-peer (P2P) 1083 streaming system for transmitting live and time-shifted media content 1084 with near real-time delivery requirements." and "The PPSP working 1085 group designs a protocol for signaling and control between trackers 1086 and peers (the PPSP "tracker protocol") and a signaling and control 1087 protocol for communication among the peers (the PPSP "peer 1088 protocol"). The two protocols enable peers to receive streaming data 1089 within the time constraints required by specific content items." 1091 Therefore PPSP is concerned with the distribution of the streamed 1092 content itself along with the necessary signaling and control 1093 required to distribute the content. As such, it could potentially be 1094 used for the acquisition of streamed content across interconnected 1095 CDNs. But since the acquisition protocol is outside the scope of the 1096 work proposed for CDNI, we leave this for further study. Also, 1097 because of its streaming nature, PPSP is not seen as applicable to 1098 the distribution and control of the CDNI control plane and CDNI data 1099 representations. 1101 Therefore, the work of PPSP may be complementary to but does not 1102 overlap with the work described in this document for CDNI. 1104 7. IANA Considerations 1106 This document makes no request of IANA. 1108 Note to RFC Editor: this section may be removed on publication as an 1109 RFC. 1111 8. Security Considerations 1113 Distribution of content by a CDN comes with a range of security 1114 considerations such as how to enforce control of access to the 1115 content by users in line with the CSP policy. These security aspects 1116 are already dealt with by CDN Providers and CSPs today in the context 1117 of standalone CDNs. However, interconnection of CDNs introduces a 1118 new set of security considerations by extending the trust model (i.e. 1119 the CSP "trusts" a CDN that "trusts" another CDN). 1121 Maintaining the security of the content itself, its associated 1122 metadata (including distribution and delivery policies) and the CDNs 1123 distributing and delivering it, are critical requirements for both 1124 CDN Providers and CSPs and any work on CDN Interconnection must 1125 provide sufficient mechanisms to maintain the security of the overall 1126 system of interconnected CDNs as well as the information (content, 1127 metadata, logs, etc) distributed and delivered through any CDN 1128 interconnections. 1130 9. Acknowledgements 1132 The authors would like to thank Andre Beck, Gilles Bertrand, Mark 1133 Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, 1134 Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van 1135 Deventer and Mahesh Viveganandhan for their review comments and 1136 contributions to the text. 1138 10. References 1140 10.1. Normative References 1142 10.2. Informative References 1144 [3GP-DASH] 1145 "Transparent end-to-end Packet-switched Streaming Service 1146 (PSS); Progressive Download and Dynamic Adaptive Streaming 1147 over HTTP (3GP-DASH) 1148 http://www.3gpp.org/ftp/Specs/html-info/26247.htm". 1150 [ALTO-Charter] 1151 "IETF ALTO WG Charter 1152 (http://datatracker.ietf.org/wg/alto/charter/)". 1154 [ATIS] "ATIS (http://www.atis.org/)". 1156 [ATIS-COD] 1157 "ATIS IIF: IPTV Content on Demand Service, January 2011 (h 1158 ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/ 1159 ATIS-0800042.pdf)". 1161 [CDI-Charter] 1162 "IETF CDI WG Charter 1163 (http://www.ietf.org/wg/concluded/cdi)". 1165 [CableLabs] 1166 "CableLabs (http://www.cablelabs.com/about/)". 1168 [CableLabs-Metadata] 1169 "CableLabs VoD Metadata Project Primer 1170 (http://www.cablelabs.com/projects/metadata/primer/)". 1172 [DECADE-Charter] 1173 "IETF DECADE WG Charter 1174 (http://datatracker.ietf.org/wg/decade/charter/)". 1176 [I-D.bertrand-cdni-experiments] 1177 Bertrand, G., Faucheur, F., and L. Peterson, "Content 1178 Distribution Network Interconnection (CDNI) Experiments", 1179 draft-bertrand-cdni-experiments-01 (work in progress), 1180 August 2011. 1182 [I-D.ietf-cdni-use-cases] 1183 Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley, 1184 P., and K. Ma, "Use Cases for Content Delivery Network 1185 Interconnection", draft-ietf-cdni-use-cases-01 (work in 1186 progress), December 2011. 1188 [I-D.jenkins-alto-cdn-use-cases] 1189 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 1190 S. Previdi, "Use Cases for ALTO within CDNs", 1191 draft-jenkins-alto-cdn-use-cases-01 (work in progress), 1192 June 2011. 1194 [MPEG-DASH] 1195 "Information technology - MPEG systems technologies - Part 1196 6: Dynamic adaptive streaming over HTTP (DASH), (DIS 1197 version), February 2011 1198 http://mpeg.chiariglione.org/ 1199 working_documents.htm#MPEG-B". 1201 [OIPF-Overview] 1202 "OIPF Release 2 Specification Volume 1 - Overview", 1203 September 2010. 1205 [P2PRG-CDNI] 1206 Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 1207 "Peering Peer-to-Peer" 1208 (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", 1209 March 2010. 1211 [PPSP-Charter] 1212 "IETF PPSP WG Charter 1213 (http://datatracker.ietf.org/wg/ppsp/charter/)". 1215 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1216 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1217 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1219 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1220 Replication and Caching Taxonomy", RFC 3040, January 2001. 1222 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 1223 for Content Internetworking (CDI)", RFC 3466, 1224 February 2003. 1226 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 1227 Content Network (CN) Request-Routing Mechanisms", 1228 RFC 3568, July 2003. 1230 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 1231 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 1233 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 1234 Protocol", RFC 5023, October 2007. 1236 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1237 Protocol (XMPP): Core", RFC 6120, March 2011. 1239 [SNIA-CDMI] 1240 "SNIA CDMI (http://www.snia.org/tech_activities/standards/ 1241 curr_standards/cdmi)". 1243 [TAXONOMY] 1244 Pathan, A., "A Taxonomy and Survey of Content Delivery 1245 Networks 1246 (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. 1248 [Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional 1249 architecture"", September 2008. 1251 [Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional 1252 architecture in NGN"", September 2010. 1254 Appendix A. Additional Material 1256 Note to RFC Editor: This appendix is to be removed on publication as 1257 an RFC. 1259 A.1. Non-Goals for IETF 1261 Listed below are aspects of content delivery that the authors propose 1262 be kept outside of the scope of a potential CDNI working group: 1263 o The interface between Content Service Provider and the 1264 Authoritative CDN (i.e. the upstream CDN contracted by the CSP for 1265 delivery by this CDN or by its downstream CDNs). 1266 o The delivery interface between the delivering CDN surrogate and 1267 the User Agent, such as streaming protocols. 1268 o The request interface between the User Agent and the request- 1269 routing system of a given CDN. Existing IETF protocols (e.g. 1270 HTTP, RTSP, DNS) are commonly used by User Agents to request 1271 content from a CDN and by CDN request routing systems to redirect 1272 the User Agent requests. The CDNI working group need not define 1273 new protocols for this purpose. Note however, that the CDNI 1274 control plane interface may indirectly affect some of the 1275 information exchanged through the request interface (e.g. URI). 1276 o The content acquisition interface between CDNs (i.e. the data 1277 plane interface for actual delivery of a piece of content from one 1278 CDN to the other). This is expected to use existing protocols 1279 such as HTTP or protocols defined in other forums for content 1280 acquisition between an origin server and a CDN (e.g. HTTP-based 1281 C2 reference point of ATIS IIF CoD). The CDN Interconnection 1282 solution may only concern itself with the agreement/negotiation 1283 aspects of which content acquisition protocol is to be used 1284 between two interconnected CDNs in view of facilitating 1285 interoperability. 1286 o End User/User Agent Authentication. End User/User Agent 1287 authentication and authorization are the responsibility of the 1288 Content Service Provider. 1289 o Content preparation, including encoding and transcoding. The CDNI 1290 architecture aims at allowing distribution across interconnected 1291 CDNs of content treated as opaque objects. Interpretation and 1292 processing of the objects, as well as optimized delivery of these 1293 objects by the surrogate to the End User are outside the scope of 1294 CDNI. 1295 o Digital Rights Management (DRM). DRM is an end-to-end issue 1296 between a content protection system and the User Agent. 1297 o Applications consuming CDNI logs (e.g. charging, analytics, 1298 reporting,...). 1299 o Internal CDN interfaces & protocols (i.e. interfaces & protocols 1300 within one CDN). 1301 o Scalability of individual CDNs. While scalability of the CDNI 1302 interfaces/approach is in scope, how an individual CDN scales is 1303 out of scope. 1304 o Actual algorithms for selection of CDNs or Surrogates by Request 1305 Routing systems (however, some specific parameters required as 1306 input to these algorithms may be in scope when they need to be 1307 communicated across CDNs). 1308 o Surrogate algorithms. For example caching algorithms and content 1309 acquisition methods are outside the scope of the CDNI work. 1310 Content management (e.g. Content Deletion) as it relates to CDNI 1311 content management policies, is in scope but the internal 1312 algorithms used by a cache to determine when to no longer cache an 1313 item of Content (in the absence of any specific metadata to the 1314 contrary) is out of scope. 1315 o Element management interfaces. 1316 o Commercial, business and legal aspects related to the 1317 interconnections of CDNs. 1319 A.2. Related standardization activities 1321 A.2.1. IETF CDI Working Group (Concluded) 1323 The Content Distribution Internetworking (CDI) Working Group was 1324 formed in the IETF following a BoF in December 2000 and closed in mid 1325 2003. 1327 For convenience, here is an extract from the CDI working group 1328 charter [CDI-Charter]: 1330 " 1332 o The goal of this working group is to define protocols to allow the 1333 interoperation of separately-administered content networks. 1334 o A content network is an architecture of network elements, arranged 1335 for efficient delivery of digital content. Such content includes, 1336 but is not limited to, web pages and images delivered via HTTP, 1337 and streaming or continuous media which are controlled by RTSP. 1338 o The working group will first define requirements for three modes 1339 of content internetworking: interoperation of request-routing 1340 systems, interoperation of distribution systems, and 1341 interoperation of accounting systems. These requirements are 1342 intended to lead to a follow-on effort to define protocols for 1343 interoperation of these systems. 1344 o In its initial form, the working group is not chartered to deliver 1345 those protocols [...] 1347 " 1349 Thus, the CDI working group touched on the same problem space as the 1350 present document. 1352 The CDI working group published 3 Informational RFCs: 1354 o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". 1355 o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing 1356 Mechanisms". 1357 o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". 1359 A.2.2. 3GPP 1361 3GPP was the first organization that released a specification related 1362 to adaptive streaming over HTTP. 3GPP Release 9 specification on 1363 adaptive HTTP streaming was published in March 2010, and there have 1364 been some bug fixes on this specification since the publication. In 1365 addition, 3GPP is preparing an extended version for Release 10, which 1366 is scheduled to be published later in 2011. This release will 1367 include a number of clarifications, improvements and new features. 1369 [3GP-DASH] is defined as a general framework independent of the data 1370 encapsulation format. It has support for fast initial startup and 1371 seeking, adaptive bitrate switching, re-use of HTTP origin and cache 1372 servers, re-use of existing media playout engines, on-demand, live 1373 and time-shifted delivery. It specifies syntax and semantics of 1374 Media Presentation Description (MPD), format of segments and delivery 1375 protocol for segments. It does not specify content provisioning, 1376 client behavior or transport of MPD. 1378 The content retrieved by a client using [3GP-DASH] adaptive streaming 1379 could be obtained from a CDN but this is not discussed or specified 1380 in the 3GPP specifications as it is transparent to [3GP-DASH] 1381 operations. Similarly, it is expected that [3GP-DASH] can be used 1382 transparently from the CDNs as a delivery protocol (between the 1383 delivering CDN surrogate and the User Agent) in a CDN Interconnection 1384 environment. [3GP-DASH] could also be a candidate for content 1385 acquisition between CDNs in a CDN Interconnection environment. 1387 A.2.3. ISO MPEG 1389 Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad- 1390 hoc group adopted the 3GPP Release 9 [3GP-DASH] specification as a 1391 starting point and has made some improvements and extensions. 1392 Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on 1393 standardizing the manifest file and the delivery format. 1394 Additionally, the MPEG DASH ad-hoc group has also been working on the 1395 use of MPEG-2 Transport Streams as a media format, conversion from/to 1396 existing file formats, common encryption, and so on. The MPEG DASH 1397 specification could also be a candidate for delivery to the User 1398 Agent and for content acquisition between CDNs in a CDN 1399 Interconnection environment. The Draft International Standard (DIS) 1400 version [MPEG-DASH] is currently publicly available since early 1401 February 2011. 1403 In the 95th MPEG meeting in January 2011, the DASH ad-hoc group 1404 decided to start a new evaluation experiment called "CDN-EE". The 1405 goals are to understand the requirements for MPEG DASH to better 1406 support CDN-based delivery, and to provide a guidelines document for 1407 CDN operators to better support MPEG DASH streaming services. The 1408 ongoing work is still very preliminary and does not currently target 1409 looking into CDN Interconnection use cases. 1411 A.2.4. ATIS IIF 1413 ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS) 1414 that develops requirements, standards, and specifications for IPTV. 1416 ATIS IIF is developing the "IPTV Content on Demand (CoD) Service" 1417 specification. This includes use of a CDN (referred to in ATIS IIF 1418 CoD as the "Content Distribution and Delivery Functions") for support 1419 of a Content on Demand (CoD) Service as part of a broader IPTV 1420 service. However, this only covers the case of a managed IPTV 1421 service (in particular where the CDN is administered by the service 1422 provider) and does not cover the use, or interconnection, of multiple 1423 CDNs. 1425 A.2.5. CableLabs 1427 "Founded in 1988 by cable operating companies, Cable Television 1428 Laboratories, Inc. (CableLabs) is a non-profit research and 1429 development consortium that is dedicated to pursuing new cable 1430 telecommunications technologies and to helping its cable operator 1431 members integrate those technical advancements into their business 1432 objectives." [CableLabs] 1434 CableLabs has defined specifications for CoD Content Metadata as part 1435 of its VOD Metadata project. 1437 A.2.6. ETSI MCD 1439 ETSI MCD (Media Content Distribution) is the ETSI technical committee 1440 "in charge of guiding and coordinating standardization work aiming at 1441 the successful overall development of multimedia systems (television 1442 and communication) responding to the present and future market 1443 requests on media content distribution". 1445 MCD created a specific work item on interconnection of heterogeneous 1446 CDNs ("CDN Interconnection, use cases and requirements") in March 1447 2010. MCD very recently created a working group to progress this 1448 work item. However, no protocol level work has yet started in MCD 1449 for CDN Interconnection. 1451 A.2.7. ETSI TISPAN 1453 ETSI TISPAN has published two sets of IPTV specifications, one of 1454 which is based on IMS. In addition, TISPAN is about to complete the 1455 specifications of a CDN architecture supporting delivery of various 1456 content services such as time-shifted TV and VoD to TISPAN devices 1457 (UEs) or regular PCs. The use cases allow for hierarchically and 1458 geographically distributed CDN scenarios, along with multi-CDN 1459 cooperation. As a result, the architecture contains reference points 1460 to support interconnection of other TISPAN CDNs. The protocol 1461 definition phase for the corresponding CDN architecture was kicked- 1462 off at the end of 2010. In line with its long history of leveraging 1463 IETF protocols, ETSI could potentially leverage CDNI interfaces 1464 developed in the IETF for their related protocol level work on 1465 interconnections of CDNs. 1467 A.2.8. ITU-T 1469 SG13 is developing standards related to the support of IPTV services 1470 (i.e.. multimedia services such as television/VoD/audio/text/ 1471 graphics/data delivered over IP-based managed networks). 1473 ITU-T Recommendation Y.1910 [Y.1910] provides the description of the 1474 IPTV functional architecture. This architecture includes functions 1475 and interfaces for the distribution and delivery of content. This 1476 architecture is aligned with the ATIS IIF architecture. 1478 Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in 1479 more detail the content delivery functional architecture. This 1480 architecture allows CDN Interconnection: some interfaces (such as D3, 1481 D4) at the control level allow relationships between different CDNs, 1482 in the same domain or in different domains. Generic procedures are 1483 described, but the choice of the protocols is open. 1485 A.2.9. Open IPTV Forum (OIPF) 1487 The Open IPTV Forum has developed an end-to-end solution to allow any 1488 OIPF terminal to access enriched and personalized IPTV services 1489 either in a managed or a non-managed network[OIPF-Overview]. Some 1490 OIPF services (such as Network PVR) may be hosted in a CDN. 1492 To that end, the Open IPTV Forum specification is made of 5 parts: 1494 o Media Formats including HTTP Adaptive Streaming 1495 o Content Metadata 1496 o Protocols 1497 o Terminal (Declarative or Procedural Application Environment) 1498 o Authentication, Content Protection and Service Protection 1500 A.2.10. TV-Anytime Forum 1502 Version 1 of the TV-Anytime Forum specifications were published as 1503 ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line 1504 Services: Search, select, and rightful use of content on personal 1505 storage systems ("TV-Anytime")". It includes the specification of 1506 content metadata in XML schemas (ETSI TS 102 822-3) which define 1507 technical parameters for the description of CoD and Live contents. 1508 The specification is referenced by DVB and OIPF. 1510 The TV-anytime Forum was closed in 2005. 1512 A.2.11. SNIA 1514 The Storage Networking Industry Association (SNIA) is an association 1515 of producers and consumers of storage networking products whose goal 1516 is to further storage networking technology and applications. 1518 SNIA has published the Cloud Data Management Interface (CDMI) 1519 standard ([SNIA-CDMI]). 1521 "The Cloud Data Management Interface defines the functional interface 1522 that applications will use to create, retrieve, update and delete 1523 data elements from the Cloud. As part of this interface the client 1524 will be able to discover the capabilities of the cloud storage 1525 offering and use this interface to manage containers and the data 1526 that is placed in them. In addition, metadata can be set on 1527 containers and their contained data elements through this interface." 1529 A.3. Related Research Projects 1531 A.3.1. IRTF P2P Research Group 1533 Some information on CDN interconnection motivations and technical 1534 issues were presented in the P2P RG at IETF 77. The presentation can 1535 be found in [P2PRG-CDNI]. 1537 A.3.2. OCEAN 1539 OCEAN (http://www.ict-ocean.eu/) is an EU funded research project 1540 that started in February 2010 for 3 years. Some of its objectives 1541 are relevant to CDNI. It aims, among other things, at designing a 1542 new architectural framework for audiovisual content delivery over the 1543 Internet, defining public interfaces between its major building 1544 blocks in order to foster multi-vendor solutions and interconnection 1545 between Content Networks (the term "Content Networks" corresponds 1546 here to the definition introduced in [RFC3466], which encompasses 1547 CDNs). 1549 OCEAN has not yet published any open specifications, nor common best 1550 practices, defining how to achieve such CDN interconnection. 1552 A.3.3. Eurescom P1955 1554 Eurescom P1955 was a 2010 research project involving a four European 1555 Network operators, which studied the interests and feasibility of 1556 interconnecting CDNs by firstly elaborating the main service models 1557 around CDN interconnection, as well as analyzing an adequate CDN 1558 interconnection technical architecture and framework, and finally by 1559 providing recommendations for telcos to implement CDN 1560 interconnection. The Eurescom P1955 project ended in July 2010. 1562 The authors are not aware of material discussing CDN interconnection 1563 protocols or interfaces made publically available as a deliverable of 1564 this project. 1566 Authors' Addresses 1568 Ben Niven-Jenkins 1569 Velocix (Alcatel-Lucent) 1570 326 Cambridge Science Park 1571 Milton Road, Cambridge CB4 0WG 1572 UK 1574 Email: ben@velocix.com 1575 Francois Le Faucheur 1576 Cisco Systems 1577 Greenside, 400 Avenue de Roumanille 1578 Sophia Antipolis 06410 1579 France 1581 Phone: +33 4 97 23 26 19 1582 Email: flefauch@cisco.com 1584 Nabil Bitar 1585 Verizon 1586 40 Sylvan Road 1587 Waltham, MA 02145 1588 USA 1590 Email: nabil.bitar@verizon.com