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