idnits 2.17.1 draft-ietf-cdni-problem-statement-07.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 (June 23, 2012) is 4326 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-08 -- 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 (~~), 2 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: December 25, 2012 Cisco 6 N. Bitar 7 Verizon 8 June 23, 2012 10 Content Distribution Network Interconnection (CDNI) Problem Statement 11 draft-ietf-cdni-problem-statement-07 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 is the motivation for 24 interconnecting standalone CDNs so they can interoperate as an open 25 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 December 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 10 70 2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 11 71 3. CDN Interconnection Model & Problem Area for IETF . . . . . . 12 72 4. Scoping the CDNI Problem . . . . . . . . . . . . . . . . . . . 16 73 4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 17 74 4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 75 4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 18 76 4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 18 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 6.1. Security of the CDNI Control interface . . . . . . . . . . 19 80 6.2. Security of the CDNI Request Routing Interface . . . . . . 19 81 6.3. Security of the CDNI Metadata interface . . . . . . . . . 20 82 6.4. Security of the CDNI Logging interface . . . . . . . . . . 20 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 87 Appendix A. Design considerations for realizing the CDNI 88 Interfaces . . . . . . . . . . . . . . . . . . . . . 23 89 A.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 23 90 A.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 25 91 A.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 26 92 A.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 27 93 Appendix B. Additional Material . . . . . . . . . . . . . . . . . 28 94 B.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28 95 B.2. Relationship to relevant IETF Working Groups & IRTF 96 Reserach Groups . . . . . . . . . . . . . . . . . . . . . 29 97 B.2.1. ALTO WG . . . . . . . . . . . . . . . . . . . . . . . 29 98 B.2.2. DECADE WG . . . . . . . . . . . . . . . . . . . . . . 30 99 B.2.3. PPSP WG . . . . . . . . . . . . . . . . . . . . . . . 31 100 B.2.4. IRTF P2P Research Group . . . . . . . . . . . . . . . 32 101 Appendix C. Additional Material . . . . . . . . . . . . . . . . . 32 102 C.1. Related standardization activites . . . . . . . . . . . . 32 103 C.1.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 33 104 C.1.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 C.1.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 34 106 C.1.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 35 107 C.1.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 35 108 C.1.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 35 109 C.1.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 36 110 C.1.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 36 111 C.1.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 36 112 C.1.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 37 113 C.1.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 C.1.12. Summary of existing standardization work . . . . . . . 37 115 C.2. Related Research Projects . . . . . . . . . . . . . . . . 39 116 C.2.1. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 39 117 C.2.2. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 39 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 120 1. Introduction 122 The volume of video and multimedia content delivered over the 123 Internet is rapidly increasing and expected to continue doing so in 124 the future. In the face of this growth, Content Delivery Networks 125 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 126 content, improved quality of experience for End Users (EUs) and 127 increased robustness of delivery. For these reasons CDNs are 128 frequently used for large-scale content delivery. As a result, 129 existing CDN Providers are scaling up their infrastructure and many 130 Network Service Providers (NSPs) are deploying their own CDNs. 132 It is generally desirable that a given content item can be delivered 133 to an EU regardless of that EU's location or the network they are 134 attached to. However, a given CDN in charge of delivering a given 135 content may not have a footprint that expands close enough to the 136 EU's current location or attachment network, or may not have the 137 necessary resources, to realize the user experience and cost benefit 138 that a more distributed CDN infrastructure would allow. This is the 139 motivation for interconnecting standalone CDNs so that their 140 collective CDN footprint and resources can be leveraged for the end- 141 to-end delivery of content from Content Service Providers (CSPs) to 142 EUs. As an example, a CSP could contract with an "authoritative" CDN 143 Provider for the delivery of content and that authoritative CDN 144 Provider could contract with one or more downstream CDN Provider(s) 145 to distribute and deliver some or all of the content on behalf of the 146 authoritative CDN Provider. 148 A typical end to end content delivery scenario would then involve the 149 following business arrangements: 151 o A business arrangement between the EU and his CSP, authorizing 152 access by the EU to content items controlled by the CSP. 153 o A business arrangement between the CSP and an "authoritative" CDN 154 Provider where the CSP authorizes the CDN Provider to perform the 155 content delivery on behalf of the CSP. 156 o A business arrangement between the authoritative CDN Provider and 157 another (or other) CDN(s) where the authoritative CDN may delegate 158 the actual serving of some of the content delivery requests to the 159 other CDN(s). A particular case, is where this other CDN Provider 160 happens to also be the Network Service Provider providing network 161 access to the EU, in which case there is also a separate and 162 independent business relationship between the EU and the NSP for 163 the corresponding network access. 165 The formation and details of any business relationships between a CSP 166 and a CDN Provider as well as between one CDN Provider and another 167 CDN Provider are out of scope of this document. However, this 168 document concerns itself with the fact that no standards or open 169 specifications currently exist to facilitate such CDN interconnection 170 from a technical perspective. 172 One possible flow for performing an end to end content delivery 173 across a CDN Interconnect is described below: 175 o The initial request from an EU's User Agent is first received by 176 the authoritative (upstream) CDN, which is the CDN with a business 177 arrangement with the CSP. 178 o The authoritative (upstream) CDN may serve the request itself, or 179 it may elect to use CDN Interconnect to redirect the request to a 180 downstream CDN that is in a better position to do so (e.g. a 181 downstream CDN that is "closer" to the EU). 182 o The EU's User Agent will "follow" the redirect returned by the 183 authoritative CDN and request the content from the downstream CDN. 184 If required the downstream CDN will acquire the requested content 185 from the authoritative (upstream) CDN, and if necessary the 186 authoritative CDN will acquire the requested content from the 187 Content Service Provider. 189 The goal of this document is to outline the problem area of CDN 190 interconnection. Section 2 discusses the use cases for CDN 191 interconnection. Section 3 presents the CDNI model and problem area 192 being considered by the IETF. Section 4 describes each CDNI 193 interface individually and highlights example candidate protocols 194 that could be considered for reuse or leveraging to implement the 195 CDNI interfaces. Appendix B.2 describes the relationships between 196 the CDNI problem space and other relevant IETF Working Groups and 197 IRTF Reserach Groups. 199 1.1. Terminology 201 This document uses the following terms: 203 Content: Any form of digital data. One important form of Content 204 with additional constraints on distribution and delivery is 205 continuous media (i.e. where there is a timing relationship between 206 source and sink). 208 Metadata: Metadata in general is data about data. 210 Content Metadata: This is metadata about Content. Content Metadata 211 comprises: 213 1. Metadata that is relevant to the distribution of the content (and 214 therefore relevant to a CDN involved in the delivery of that 215 content). We refer to this type of metadata as "Content 216 Distribution Metadata". See also the definition of Content 217 Distribution Metadata. 218 2. Metadata that is associated with the actual Content or content 219 representation, and not directly relevant to the distribution of 220 that Content. For example, such metadata may include information 221 pertaining to the Content's genre, cast, rating, etc as well as 222 information pertaining to the Content representation's 223 resolution, aspect ratio, etc. 225 Content Distribution Metadata: The subset of Content Metadata that is 226 relevant to the distribution of the content. This is the metadata 227 required by a CDN in order to enable and control content distribution 228 and delivery by the CDN. In a CDN Interconnection environment, some 229 of the Content Distribution Metadata may have an intra-CDN scope (and 230 therefore need not be communicated between CDNs), while some of the 231 Content Distribution Metadata may have an inter-CDN scope (and 232 therefore needs to be communicated between CDNs). 234 CDNI Metadata: Content Distribution Metadata with inter-CDN scope. 235 For example, CDNI Metadata may include geo-blocking information (i.e. 236 information defining geographical areas where the content is to be 237 made available or blocked), availability windows (i.e. information 238 defining time windows during which the content is to be made 239 available or blocked) and access control mechanisms to be enforced 240 (e.g. URI signature validation). CDNI Metadata may also include 241 information about desired distribution policy (e.g. prepositioned vs 242 dynamic acquisition) and about where/how a CDN can acquire the 243 content. CDNI Metadata may also include content management 244 information (e.g. request for deletion of Content from Surrogates) 245 across interconnected CDNs. 247 Dynamic content acquisition: Dynamic content acquisition is where a 248 CDN acquires content from the content source in response to an End 249 User requesting that content from the CDN. In the context of CDN 250 Interconnection, dynamic acquisition means that a downstream CDN 251 acquires the content from content sources (including upstream CDNs) 252 at some point in time after a request for that content is delegated 253 to the downstream CDN by an Upstream CDN (and that specific content 254 is not yet available in the downstream CDN). 256 Dynamic CDNI metadata acquisition: In the context of CDN 257 Interconnection, dynamic CDNI metadata acquisition means that a 258 downstream CDN acquires CDNI metadata for content from the upstream 259 CDN at some point in time after a request for that content is 260 delegated to the downstream CDN by an Upstream CDN (and that specific 261 CDNI metadata is not yet available in the downstream CDN). See also 262 the definitions for downstream CDN and upstream CDN. 264 Pre-positioned content acquisition: Content Pre-positioning is where 265 a CDN acquires content from the content source prior to, or 266 independently of, any End User requesting that content from the CDN. 267 In the context of CDN interconnection the Upstream CDN instructs the 268 Downstream CDN to acquire the content from content sources (including 269 upstream CDNs) in advance of or independent of any End User 270 requesting it. 272 Pre-positioned CDNI Metadata acquisition: In the context of CDN 273 Interconnection, CDNI Metadata pre-positioning is where the 274 Downstream CDN acquires CDNI metadata for content prior to or 275 independent of any End User requesting that content from the 276 Downstream CDN. 278 End User (EU): The 'real' user of the system, typically a human but 279 maybe some combination of hardware and/or software emulating a human 280 (e.g. for automated quality monitoring etc.) 282 User Agent (UA): Software (or a combination of hardware and software) 283 through which the End User interacts with a Content Service. The 284 User Agent will communicate with a Content Service for the selection 285 of content and one or more CDNs for the delivery of the Content. 286 Such communication is not restricted to HTTP and may be via a variety 287 of protocols. Examples of User Agents (non-exhaustive) are: 288 Browsers, Set Top Boxes (STBs), dedicated content applications (e.g. 289 media players), etc. 291 Network Service Provider (NSP): Provides network-based connectivity/ 292 services to End Users. 294 Content Service Provider (CSP): Provides a Content Service to End 295 Users (which they access via a User Agent). A CSP may own the 296 Content made available as part of the Content Service, or may license 297 content rights from another party. 299 Content Service: The service offered by a Content Service Provider. 300 The Content Service encompasses the complete service which may be 301 wider than just providing access to items of Content, e.g. the 302 Content Service also includes any middleware, key distribution, 303 program guide, etc. which may not require any direct interaction with 304 the CDN, or CDNs, involved in the distribution and delivery of the 305 content. 307 Content Distribution Network (CDN) / Content Delivery Network (CDN): 308 Network infrastructure in which the network elements cooperate at 309 layers 4 through layer 7 for more effective delivery of Content to 310 User Agents. Typically a CDN consists of a Request Routing system, a 311 Distribution System (that includes a set of Surrogates), a Logging 312 System and a CDN control system. 314 CDN Provider: The service provider who operates a CDN and offers a 315 service of content delivery, typically used by a Content Service 316 Provider or another CDN Provider. Note that a given entity may 317 operate in more than one role. For example, a company may 318 simultaneously operate as a Content Service Provider, a Network 319 Service Provider and a CDN Provider. 321 CDN Interconnection (CDNI): A relationship between a pair of CDNs 322 that enables one CDN to provide content delivery services on behalf 323 of another CDN. A CDN Interconnection may be wholly or partially 324 realized through a set of interfaces over which a pair of CDNs 325 communicate with each other in order to achieve the delivery of 326 content to User Agents by Surrogates in one CDN (the downstream CDN) 327 on behalf of another CDN (the upstream CDN). 329 Authoritative CDN: A CDN which has a direct relationship with a CSP 330 for the distribution & delivery of that CSP's content by the 331 authoritative CDN or by downstream CDNs of the authoritative CDN. 333 Upstream CDN: For a given End User request, the CDN (within a pair of 334 directly interconnected CDNs) that redirects the request to the other 335 CDN. 337 Downstream CDN: For a given End User request, the CDN (within a pair 338 of directly interconnected CDNs) to which the request is redirected 339 by the other CDN (the Upstream CDN). Note that in the case of 340 successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g. 341 CDN2) may act as the Downstream CDN for a redirection (e.g. 342 CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection 343 of the same request (e.g. CDN2-->CDN3). 345 Over-the-top (OTT): A service, e.g. content delivery using a CDN, 346 operated by a different operator than the NSP to which the users of 347 that service are attached. 349 Surrogate: A device/function (often called a cache) that interacts 350 with other elements of the CDN for the control and distribution of 351 Content within the CDN and interacts with User Agents for the 352 delivery of the Content. Typically, surrogates will cache requested 353 content so that it can deliver the same content to a number of User 354 Agents (and their End Users) avoiding the need for those requests to 355 transit multiple times through the network core (i.e from the content 356 origin to the surrogate). 358 Request Routing System: The function within a CDN responsible for 359 receiving a content request from a User Agent, obtaining and 360 maintaining necessary information about a set of candidate surrogates 361 or candidate CDNs, and for selecting and redirecting the user to the 362 appropriate surrogate or CDN. To enable CDN Interconnection, the 363 Request Routing System must also be capable of handling User Agent 364 content requests passed to it by another CDN. 366 Distribution System: The function within a CDN responsible for 367 distributing Content Distribution Metadata as well as the Content 368 itself inside the CDN (e.g. down to the surrogates). 370 Delivery: The function within CDN surrogates responsible for 371 delivering a piece of content to the User Agent. For example, 372 delivery may be based on HTTP progressive download or HTTP adaptive 373 streaming. 375 Logging System: The function within a CDN responsible for collecting 376 the measurement and recording of distribution and delivery 377 activities. The information recorded by the logging system may be 378 used for various purposes including charging (e.g. of the CSP), 379 analytics and monitoring. 381 Control System: The function within a CDN responsible for 382 bootstrapping and controlling the other components of the CDN as well 383 as for handling interactions with external systems (e.g. handling 384 delivery service creation/update/removal requests, or specific 385 service provisioning requests). 387 Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390] 389 1.2. CDN Background 391 Readers are assumed to be familiar with the architecture, features 392 and operation of CDNs. For readers less familiar with the operation 393 of CDNs, the following resources may be useful: 395 o RFC 3040 [RFC3040] describes many of the component technologies 396 that are used in the construction of a CDN. 397 o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. 398 o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 399 IETF Content Delivery Internetworking (CDI) working group which 400 was closed in 2003. 402 Note: Some of the terms used in this document are similar to terms 403 used the above referenced documents. When reading this document 404 terms should be interpreted as having the definitions provided in 405 Section 1.1. 407 2. CDN Interconnection Use Cases 409 An increasing number of NSPs are deploying CDNs in order to deal 410 cost-effectively with the growing usage of on-demand video services 411 and other content delivery applications. 413 CDNs allow caching of content closer to the edge of a network so that 414 a given item of content can be delivered by a CDN Surrogate (i.e. a 415 cache) to multiple User Agents (and their End Users) without 416 transiting multiple times through the network core (i.e from the 417 content origin to the surrogate). This contributes to bandwidth cost 418 reductions for the NSP and to improved quality of experience for the 419 End Users. CDNs also enable replication of popular content across 420 many surrogates, which enables content to be served to large numbers 421 of User Agents concurrently. This also helps dealing with situations 422 such as flash crowds and denial of service attacks. 424 The CDNs deployed by NSPs are not just restricted to the delivery of 425 content to support the Network Service Provider's own 'walled garden' 426 services, such as IP delivery of television services to Set Top 427 Boxes, but are also used for delivery of content to other devices 428 including PCs, tablets, mobile phones etc. 430 Some service providers operate over multiple geographies and federate 431 multiple affiliate NSPs. These NSPs typically operate independent 432 CDNs. As they evolve their services (e.g. for seamless support of 433 content services to nomadic users across affiliate NSPs) there is a 434 need for interconnection of these CDNs, that represents a first use 435 case for CDNI. However there are no open specifications, nor common 436 best practices, defining how to achieve such CDN interconnection. 438 CSPs have a desire to be able to get (some of) their content to very 439 large numbers of End Users, who are often distributed across a number 440 of geographies, while maintaining a high quality of experience, all 441 without having to maintain direct business relationships with many 442 different CDN Providers (or having to extend their own CDN to a large 443 number of locations). Some NSPs are considering interconnecting 444 their respective CDNs (as well as possibly over-the-top CDNs) so that 445 this collective infrastructure can address the requirements of CSPs 446 in a cost effective manner. This represents a second use case for 447 CDNI. In particular, this would enable the CSPs to benefit from on- 448 net delivery (i.e. within the Network Service Provider's own network/ 449 CDN footprint) whenever possible and off-net delivery otherwise, 450 without requiring the CSPs to maintain direct business relationships 451 with all the CDNs involved in the delivery. Again, CDN Providers 452 (NSPs or over-the-top CDN operators) are faced with a lack of open 453 specifications and best practices. 455 NSPs have often deployed CDNs as specialized cost-reduction projects 456 within the context of a particular service or environment. Some NSPs 457 operate separate CDNs for separate services. For example, there may 458 be a CDN for managed IPTV service delivery, a CDN for web-TV delivery 459 and a CDN for video delivery to Mobile terminals. As NSPs integrate 460 their service portfolio, there is a need for interconnecting these 461 CDNs, representing a third use case for CDNI. Again, NSPs face the 462 problem of lack of open interfaces for CDN interconnection. 464 For operational reasons (e.g. disaster, flash crowd) or commercial 465 reasons, an over-the-top CDN may elect to make use of another CDN 466 (e.g. an NSP CDN with on-net Surrogates for a given footprint) for 467 serving a subset of the user requests (e.g. requests from users 468 attached to that NSP), which results in a fourth use case for CDNI 469 because CDN Providers (over-the-top CDN Providers or NSPs) are faced 470 with a lack of open specifications and best practices. 472 Use cases for CDN Interconnection are further discussed in 473 [I-D.ietf-cdni-use-cases]. 475 3. CDN Interconnection Model & Problem Area for IETF 477 This section discusses the problem area for the IETF work on CDN 478 Interconnection. 480 Interconnecting CDNs involves interactions among multiple different 481 functions and components that form each CDN. Only some of those 482 require standardization. 484 Some NSPs have started to perform experiments to explore whether 485 their CDN use cases can already be addressed with existing CDN 486 implementations. One set of such experiments is documented in 487 [I-D.bertrand-cdni-experiments]. The conclusions of those 488 experiments are that while some basic limited CDN Interconnection 489 functionality can be achieved with existing CDN technology, the 490 current lack of any standardized CDNI interfaces with the necessary 491 level of functionality such as those discussed in this document is 492 preventing the deployment of CDN Interconnection. 494 Listed below are the four interfaces required to interconnect a pair 495 of CDNs and that constitute the problem space of CDN Interconnection 496 along with the required functionality of each interface for which 497 standards do not currently exist. As part of the development of the 498 CDNI interfaces it will also be necessary to agree on common 499 mechanisms for how to identify and name the data objects that are to 500 be interchanged between interconnected CDNs. 502 The use of the term "interface" is meant to encompass the protocol 503 over which CDNI data representations (e.g. CDNI Metadata objects) 504 are exchanged as well as the specification of the data 505 representations themselves (i.e. what properties/fields each object 506 contains, its structure, etc.). 508 o CDNI Control interface: This interface allows the "CDNI Control" 509 system in interconnected CDNs to communicate. This interface may 510 support the following: 511 * Allow bootstrapping of the other CDNI interfaces (e.g. 512 interface address/URL discovery and establishment of security 513 associations). 514 * Allow configuration of the other CDNI interfaces (e.g. 515 Upstream CDN specifies information to be reported through the 516 CDNI Logging interface). 517 * Allow the downstream CDN to communicate static (or fairly 518 static) information about its delivery capabilities and 519 policies. 520 * Allow bootstrapping of the interface between CDNs for content 521 acquisition (even if that interface itself is outside the scope 522 of the CDNI work). 523 * Allow an upstream CDN to initiate or request specific actions 524 to be undertaken in the downstream CDN. For example, to allow 525 an upstream CDN to initiate content or CDNI Metadata 526 acquisition (pre-positioning) or to request the invalidation or 527 purging of content files and/or CDNI Metadata in a downstream 528 CDN. 529 o CDNI Request Routing interface: This interface allows the Request 530 Routing systems in interconnected CDNs to communicate to ensure 531 that an End User request can be (re)directed from an upstream CDN 532 to a surrogate in the downstream CDN, in particular where 533 selection responsibilities may be split across CDNs (for example 534 the upstream CDN may be responsible for selecting the downstream 535 CDN while the downstream CDN may be responsible for selecting the 536 actual surrogate within that downstream CDN). In particular, the 537 functions of the CDN Request Routing interface may be divided as 538 follows: 539 * A CDNI Request Routing Redirection interface which allows the 540 upstream CDN to query the downstream CDN at request routing 541 time before redirecting the request to the downstream CDN. 542 * A CDNI Footprint & Capabilities advertisement interface which 543 allows the downstream CDN to provide to the upstream CDN 544 (static or dynamic) information (e.g. resources, footprint, 545 load) to facilitate selection of the downstream CDN by the 546 upstream CDN request routing system when processing subsequent 547 content requests from User Agents. 549 o CDNI Metadata distribution interface: This interface allows the 550 Distribution system in interconnected CDNs to communicate to 551 ensure CDNI Metadata can be exchanged across CDNs. See 552 Section 1.1 for definition and examples of CDNI Metadata. 553 o CDNI Logging interface: This interface allows the Logging system 554 in interconnected CDNs to communicate the relevant activity logs 555 in order to allow log consuming applications to operate in a 556 multi-CDN environments. For example, an upstream CDN may collect 557 delivery logs from a downstream CDN in order to perform 558 consolidated charging of the CSP or for settlement purposes across 559 CDNs. Similarly, an upstream CDN may collect delivery logs from a 560 downstream CDN in order to provide consolidated reporting and 561 monitoring to the CSP. 563 Note that the actual grouping of functionalities under these four 564 interfaces is considered tentative at this stage and may be changed 565 after further study (e.g. some subset of functionality be moved from 566 one interface into another). 568 The above list covers a significant potential problem space, in part 569 because in order to interconnect two CDNs there are several 'touch 570 points' that require standardization. However, it is expected that 571 the CDNI interfaces need not be defined from scratch and instead can 572 very significantly reuse or leverage existing protocols; this is 573 discussed further in Section 4. 575 The interfaces that form the CDNI problem area are illustrated in 576 Figure 1. 578 -------- 579 / \ 580 | CSP | 581 \ / 582 -------- 583 * 584 * 585 * /\ 586 * / \ 587 ---------------------- |CDNI| ---------------------- 588 / Upstream CDN \ | | / Downstream CDN \ 589 | +-------------+ | Control Interface| +-------------+ | 590 |******* Control |<======|====|========>| Control *******| 591 |* +------*----*-+ | | | | +-*----*------+ *| 592 |* * * | | | | * * *| 593 |* +------*------+ | Logging Interface| +------*------+ *| 594 |* ***** Logging |<======|====|========>| Logging ***** *| 595 |* * +-*-----------+ | | | | +-----------*-+ * *| 596 |* * * * | Request Routing | * * * *| 597 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 598 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 599 . |* * * +-------------+.| | | | +-------------+ * * *| . 600 . |* * * . CDNI Metadata | * * *| . 601 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 602 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 603 . |* * * | | | . \ / | | | * * *| . 604 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 605 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 606 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 607 . |******* +---------+| | Acquisition | |+----------+ *******| . 608 . | +-------------+ | | +-------*-----+ | . 609 . \ / \ * / . 610 . ---------------------- ---------*------------ . 611 . * . 612 . * Delivery . 613 . * . 614 . +--*---+ . 615 ...............Request.............................| User |..Request.. 616 | Agent| 617 +------+ 619 <==> interfaces inside the scope of CDNI 620 **** interfaces outside the scope of CDNI 621 .... interfaces outside the scope of CDNI 623 Figure 1: A Model for the CDNI Problem Area 625 As illustrated in Figure 1, the acquisition of content between 626 interconnected CDNs is out of scope for CDNI, which deserves some 627 additional explanation. The consequence of such a decision is that 628 the CDNI problem space described in this document is focussed on only 629 defining the control plane for CDNI; and the CDNI data plane (i.e. 630 the acquisition & distribution of the actual content objects) is out 631 of scope. The rationale for such a decision is that CDNs today 632 typically already use standardized protocols such as HTTP, FTP, 633 rsync, etc. to acquire content from their CSP customers and it is 634 expected that the same protocols could be used for acquisition 635 between interconnected CDNs. Therefore the problem of content 636 acquisition is considered already solved and all that is required 637 from specifications developed by the CDNI working group is to 638 describe within the CDNI Metadata the parameters to use to retrieve 639 the content for example the IP address/hostname to connect to, what 640 protocol to use to retrieve the content, etc. 642 4. Scoping the CDNI Problem 644 This section outlines how the scope of work addressing the CDNI 645 problem space can be constrained through reuse or leveraging of 646 existing protocols to implement the CDNI interfaces. This discussion 647 is not intended to pre-empt any working group decision as to the most 648 appropriate protocols, technologies and solutions to select to 649 realize the CDNI interfaces but is intended as an illustration of the 650 fact that the CDNI interfaces need not be created in a vacuum and 651 that reuse or leverage of existing protocols is likely possible. 653 The four CDNI interfaces (CDNI Control interface, CDNI Request 654 Routing interface, CDNI Metadata interface, CDNI Logging interface) 655 described in Section 3 within the CDNI problem area are all control 656 plane interfaces operating at the application layer (Layer 7 in the 657 OSI network model). Firstly, since it is not expected that these 658 interfaces would exhibit unique session, transport or network 659 requirements as compared to the many other existing applications in 660 the Internet, it is expected that the CDNI interfaces will be defined 661 on top of existing session, transport and network protocols. 663 Secondly, although a new application protocol could be designed 664 specifically for CDNI our analysis below shows that this is 665 unnecessary and it is recommended that existing application protocols 666 be reused or leveraged (HTTP [RFC2616], Atom Publishing Protocol 667 [RFC5023], XMPP [RFC6120], for example) to realize the CDNI 668 interfaces. 670 4.1. CDNI Request Routing Interface 672 The CDNI Request Routing interface enables a Request Routing function 673 in an upstream CDN to query a Request Routing function in a 674 downstream CDN to determine if the downstream CDN is able (and 675 willing) to accept the delegated content request. It also allows the 676 downstream CDN to control what should be returned to the User Agent 677 in the redirection message by the upstream Request Routing function . 679 The CDNI Request Routing interface is therefore a fairly 680 straightforward request/response interface and could be implemented 681 over any number of request/response protocols. For example, it may 682 be implemented as a WebService using one of the common WebServices 683 methodologies (XML-RPC, HTTP query to a known URI, etc.). This 684 removes the need for the CDNI working group to define a new protocol 685 for the request/response element of the CDNI Request Routing 686 interface. 688 Additionally, as discussed in Section 3, the CDNI Request Routing 689 interface is also expected to enable a downstream CDN to provide to 690 the upstream CDN (static or dynamic) information (e.g. resources, 691 footprint, load) to facilitate selection of the downstream CDN by the 692 upstream CDN request routing system when processing subsequent 693 content requests from User Agents. It is expected that such 694 functionality of the CDNI request Routing could be specified by the 695 CDNI working group with significant leveraging of existing IETF 696 protocols supporting the dynamic distribution of reachability 697 information (for example by leveraging existing routing protocols) or 698 supporting application level queries for topological information (for 699 example by leveraging ALTO [RFC5693]). 701 4.2. CDNI Metadata Interface 703 The CDNI Metadata interface enables the Distribution System in a 704 downstream CDN to request CDNI Metadata from an upstream CDN so that 705 the downstream CDN can properly process and respond to redirection 706 requests received over the CDNI Request Routing interface and Content 707 Requests received directly from User Agents. 709 The CDNI Metadata interface is therefore similar to the CDNI Request 710 Routing interface because it is a request/response interface with the 711 potential addition that CDNI Metadata search may have more complex 712 semantics than a straightforward Request Routing redirection request. 713 Therefore, like the CDNI Request Routing interface, the CDNI Metadata 714 interface may be implemented as a WebService using one of the common 715 WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 716 or possibly using other existing protocols such as XMPP [RFC6120]. 717 This removes the need for the CDNI working group to define a new 718 protocol for the request/response element of the CDNI Metadata 719 interface. 721 4.3. CDNI Logging Interface 723 The CDNI Logging interface enables details of content distribution 724 and delivery activities to be exchanged between interconnected CDNs. 725 For example the exchange of log records related to the delivery of 726 content, similar to the log records recorded in a web server's access 727 log. 729 Several protocols already exist that could potentially be used to 730 exchange CDNI logs between interconnected CDNs including SNMP, 731 syslog, ftp (and secure variants), HTTP POST, etc. 733 4.4. CDNI Control Interface 735 The CDNI Control interface allows the Control System in 736 interconnected CDNs to communicate. The exact inter-CDN control 737 functionality required to be supported by the CDNI Control interface 738 is less well defined than the other three CDNI interfaces at this 739 time. 741 It is expected that for the Control interface, as for the other CDNI 742 Interfaces, existing protocols can be reused or leveraged. 744 5. IANA Considerations 746 This document makes no request of IANA. 748 Note to RFC Editor: this section may be removed on publication as an 749 RFC. 751 6. Security Considerations 753 Distribution of content by a CDN comes with a range of security 754 considerations such as how to enforce control of access to the 755 content by end users in line with the CSP policy, or how to trust the 756 logging information generated by the CDN for the purposes of charging 757 the CSP. These security aspects are already dealt with by CDN 758 Providers and CSPs today in the context of standalone CDNs. However, 759 interconnection of CDNs introduces a new set of security 760 considerations by extending the trust model to a chain of trust (i.e. 761 the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms 762 used to mitigate these risks in multi-CDN environments may be similar 763 to those used in the single CDN case, but their suitability in this 764 more complex environment must be validated. 766 The interconnection of CDNs may also introduce additional privacy 767 considerations on top of those that apply to the single CDN case. In 768 a multi-CDN environment, the different CDNs may reside in different 769 legal regimes that require differing privacy requirements to be 770 enforced. Such privacy requirements may impact the granularity of 771 information that can be exchanged across the CDNI interfaces. For 772 example the Logging System in a downstream CDN may need to apply some 773 degree of anonymization, obfuscation or even the complete removal of 774 some fields before exchanging log records containing details of End 775 User deliveries with an upstream CDN. 777 Maintaining the security of the content itself, its associated 778 metadata (including delivery policies) and the CDNs distributing and 779 delivering it, are critical requirements for both CDN Providers and 780 CSPs and the CDN Interconnection interfaces must provide sufficient 781 mechanisms to maintain the security of the overall system of 782 interconnected CDNs as well as the information (content, metadata, 783 logs, etc) distributed and delivered through any set of 784 interconnected CDNs. 786 6.1. Security of the CDNI Control interface 788 Information exchanged between interconnected CDNs over this interface 789 is of a sensitive nature. A pair of CDNs use this interface to allow 790 bootstrapping of all the other CDNI interfaces possibly including 791 establishment of the mechanisms for securing these interfaces. 792 Therefore, corruption of that interface may result in corruption of 793 all other interfaces. Using this interface, an upstream CDN may pre- 794 position or delete content or metadata in a downstream CDN and a 795 downstream CDN may provide administrative information to an upstream 796 CDN, etc. All of these operations require that the peer CDNs are 797 appropriately authenticated and that the confidentiality and 798 integrity of information flowing between them can be ensured. 800 6.2. Security of the CDNI Request Routing Interface 802 Appropriate levels of authentication and confidentiality must be used 803 in this interface because it allows an upstream CDN to query the 804 downstream CDN in order to redirect requests, and conversely, allows 805 the downstream CDN to influence the upstream CDN's Request Routing 806 function. 808 In the absence of appropriate security on this interface, a rogue 809 upstream CDN could inundate downstream CDNs with bogus requests, or 810 have the downstream CDN send the rogue upstream CDN private 811 information. Also, a rogue downstream CDN could influence the 812 upstream CDN so the upstream CDN redirects requests to the rogue dCDN 813 or another dCDN in order to, for example, attract additional delivery 814 revenue. 816 6.3. Security of the CDNI Metadata interface 818 This interface allows a downstream CDN to request CDNI metadata from 819 an upstream CDN, and therefore the upstream CDN must ensure that the 820 former is appropriately authenticated before sending the data. 821 Conversely, a downstream CDN must authenticate an upstream CDN before 822 requesting metadata to insulate itself from poisoning by rogue 823 upstream CDNs. The confidentiality and integrity of the information 824 exchanged between the peers must be protected. 826 6.4. Security of the CDNI Logging interface 828 Logging data consists of potentially sensitive information (which end 829 user accessed which media resource, IP addresses of end users, 830 potential names and subscriber account information, etc.). 831 Confidentiality of this information must be protected as log records 832 are moved between CDNs. This information may also be sensitive from 833 the viewpoint that it can be the basis for charging across CDNs. 834 Therefore, appropriate levels of protection are needed against 835 corruption, duplication and loss of this information. 837 7. Acknowledgements 839 The authors would like to thank Andre Beck, Gilles Bertrand, Mark 840 Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, 841 Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile 842 Stephan, Oskar van Deventer, Mahesh Viveganandhan and Richard Woundy 843 for their review comments and contributions to the text. 845 8. References 847 8.1. Normative References 849 8.2. Informative References 851 [3GP-DASH] 852 "Transparent end-to-end Packet-switched Streaming Service 853 (PSS); Progressive Download and Dynamic Adaptive Streaming 854 over HTTP (3GP-DASH) 855 http://www.3gpp.org/ftp/Specs/html-info/26247.htm". 857 [ALTO-Charter] 858 "IETF ALTO WG Charter 859 (http://datatracker.ietf.org/wg/alto/charter/)". 861 [ATIS] "ATIS (http://www.atis.org/)". 863 [ATIS-COD] 864 "ATIS IIF: IPTV Content on Demand Service, January 2011 (h 865 ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/ 866 ATIS-0800042.pdf)". 868 [CDI-Charter] 869 "IETF CDI WG Charter 870 (http://www.ietf.org/wg/concluded/cdi)". 872 [CableLabs] 873 "CableLabs (http://www.cablelabs.com/about/)". 875 [CableLabs-Metadata] 876 "CableLabs VoD Metadata Project Primer 877 (http://www.cablelabs.com/projects/metadata/primer/)". 879 [DECADE-Charter] 880 "IETF DECADE WG Charter 881 (http://datatracker.ietf.org/wg/decade/charter/)". 883 [I-D.bertrand-cdni-experiments] 884 Faucheur, F. and L. Peterson, "Content Distribution 885 Network Interconnection (CDNI) Experiments", 886 draft-bertrand-cdni-experiments-02 (work in progress), 887 February 2012. 889 [I-D.ietf-cdni-use-cases] 890 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 891 K., and G. Watson, "Use Cases for Content Delivery Network 892 Interconnection", draft-ietf-cdni-use-cases-08 (work in 893 progress), June 2012. 895 [I-D.jenkins-alto-cdn-use-cases] 896 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 897 S. Previdi, "Use Cases for ALTO within CDNs", 898 draft-jenkins-alto-cdn-use-cases-03 (work in progress), 899 June 2012. 901 [MPEG-DASH] 902 "Information technology - MPEG systems technologies - Part 903 6: Dynamic adaptive streaming over HTTP (DASH), (DIS 904 version), February 2011 905 http://mpeg.chiariglione.org/ 906 working_documents.htm#MPEG-B". 908 [OIPF-Overview] 909 "OIPF Release 2 Specification Volume 1 - Overview", 910 September 2010. 912 [P2PRG-CDNI] 913 Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 914 "Peering Peer-to-Peer" 915 (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", 916 March 2010. 918 [PPSP-Charter] 919 "IETF PPSP WG Charter 920 (http://datatracker.ietf.org/wg/ppsp/charter/)". 922 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 923 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 924 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 926 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 927 Replication and Caching Taxonomy", RFC 3040, January 2001. 929 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 930 for Content Internetworking (CDI)", RFC 3466, 931 February 2003. 933 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 934 Content Network (CN) Request-Routing Mechanisms", 935 RFC 3568, July 2003. 937 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 938 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 940 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 941 Protocol", RFC 5023, October 2007. 943 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 944 Optimization (ALTO) Problem Statement", RFC 5693, 945 October 2009. 947 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 948 Protocol (XMPP): Core", RFC 6120, March 2011. 950 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 951 Performance Metric Development", BCP 170, RFC 6390, 952 October 2011. 954 [SNIA-CDMI] 955 "SNIA CDMI (http://www.snia.org/tech_activities/standards/ 956 curr_standards/cdmi)". 958 [TAXONOMY] 959 Pathan, A., "A Taxonomy and Survey of Content Delivery 960 Networks 961 (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. 963 [Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional 964 architecture"", September 2008. 966 [Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional 967 architecture in NGN"", September 2010. 969 Appendix A. Design considerations for realizing the CDNI Interfaces 971 This section expands on how CDNI interfaces can reuse and leverage 972 existing protocols before describing each CDNI interface individually 973 and highlighting example candidate protocols that could be considered 974 for reuse or leveraging to implement the CDNI interfaces. 976 A.1. CDNI Request Routing Interface 978 The CDNI Request Routing interface enables a Request Routing function 979 in an upstream CDN to query a Request Routing function in a 980 downstream CDN to determine if the downstream CDN is able (and 981 willing) to accept the delegated content request and to allow the 982 downstream CDN to control what the upstream Request Routing function 983 should return to the User Agent in the redirection message. 985 Therefore, the CDNI Request Routing interface needs to offer a 986 mechanism for an upstream CDN to issue a "Redirection Request" to a 987 downstream CDN. The Request Routing interface needs to be able to 988 support scenarios where the initial User Agent request to the 989 upstream CDN is received over DNS as well as over a content specific 990 application protocol (e.g. HTTP, RTSP, RTMP, etc.). 992 Therefore a Redirection Request is expected to contain information 993 such as: 995 o The protocol (e.g. DNS, HTTP) over which the upstream CDN 996 received the initial User Agent request. 997 o Additional details of the User Agent request that are required to 998 perform effective Request Routing by the Downstream CDN. For DNS 999 this would typically be the IP address of the DNS resolver making 1000 the request on behalf of the User Agent. For requests received 1001 over content specific application protocols the Redirection 1002 Request could contain significantly more information related to 1003 the original User Agent request but at a minimum is expected to 1004 include the User Agent's IP address, the equivalent of the HTTP 1005 Host header and the equivalent of the HTTP abs_path defined in 1006 [RFC2616]. 1008 It should be noted that, the CDNI architecture needs to consider that 1009 a downstream CDN may receive requests from User Agents without first 1010 receiving a Redirection Request from an upstream CDN for the 1011 corresponding User Agent request, for example because: 1013 o User Agents (or DNS resolvers) may cache DNS or application 1014 responses from Request Routers. 1015 o Responses to Redirection Requests over the Request Routing 1016 interface may be cacheable. 1017 o Some CDNs may rely on simple coarse policies, e.g. CDN B agrees 1018 to always serve CDN A's delegated redirection requests, in which 1019 case the necessary redirection details are exchanged out of band 1020 (of the CDNI interfaces), e.g. configured. 1022 On receiving a Redirection Request, the downstream CDN will use the 1023 information provided in the request to determine if it is able (and 1024 willing) to accept the delegated content request and needs to return 1025 the result of its decision to the upstream CDN. 1027 Thus, a Redirection Response from the downstream CDN is expected to 1028 contain information such as: 1030 o Status code indicating acceptance or rejection (possibly with 1031 accompanying reasons). 1032 o Information to allow redirection by the Upstream CDN. In the case 1033 of DNS-based request routing, this is expected to include the 1034 equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN 1035 should return to the requesting DNS resolver. In the case of 1036 application based request routing, this is expected to include the 1037 information necessary to construct the application specific 1038 redirection response(s) to return to the requesting User Agent. 1039 For HTTP requests from User Agents this could include a URI that 1040 the upstream CDN could return in a HTTP 3xx response. 1042 The CDNI Request Routing interface is therefore a fairly 1043 straightforward request/response interface and could be implemented 1044 over any number of request/response protocols. For example, it may 1045 be implemented as a WebService using one of the common WebServices 1046 methodologies (XML-RPC, HTTP query to a known URI, etc.). This 1047 removes the need for the CDNI working group to define a new protocol 1048 for the request/response element of the CDNI Request Routing 1049 interface. Thus, the CDNI working group would be left only with the 1050 task of specifying: 1052 o The recommended request/response protocol to use along with any 1053 additional semantics and procedures that are specific to the CDNI 1054 Request Routing interface (e.g. handling of malformed requests/ 1055 responses). 1056 o The syntax (i.e representation/encoding) of the redirection 1057 requests and responses. 1058 o The semantics (i.e. meaning and expected contents) of the 1059 redirection requests and responses. 1061 Additionally, as discussed in Section 3, the CDNI Request Routing 1062 interface is also expected to enable a downstream CDN to provide to 1063 the upstream CDN (static or dynamic) information (e.g. resources, 1064 footprint, load) to facilitate selection of the downstream CDN by the 1065 upstream CDN request routing system when processing subsequent 1066 content requests from User Agents. It is expected that such 1067 functionality of the CDNI request Routing could be specified by the 1068 CDNI working group with significant leveraging of existing IETF 1069 protocols supporting the dynamic distribution of reachability 1070 information (for example by leveraging existing routing protocols) or 1071 supporting application level queries for topological information (for 1072 example by leveraging ALTO). 1074 A.2. CDNI Metadata Interface 1076 The CDNI Metadata interface enables the Distribution System in a 1077 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 1078 the downstream CDN can properly process and respond to: 1080 o Redirection Requests received over the CDNI Request Routing 1081 interface. 1082 o Content Requests received directly from User Agents. 1084 The CDNI Metadata interface needs to offer a mechanism for an 1085 Upstream CDN to: 1087 o Distribute/update/remove CDNI Metadata to a Downstream CDN. 1089 and/or to allow a downstream CDN to: 1091 o Make direct requests for CDNI Metadata objects 1092 o Make recursive requests for CDNI metadata, for example to enable a 1093 downstream CDN to walk down a tree of objects with inter-object 1094 relationships. 1096 The CDNI Metadata interface is therefore similar to the CDNI Request 1097 Routing interface because it is a request/response interface with the 1098 potential addition that CDNI Metadata search may have more complex 1099 semantics than a straightforward Request Routing redirection request. 1100 Therefore, like the CDNI Request Routing interface, the CDNI Metadata 1101 interface may be implemented as a WebService using one of the common 1102 WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 1103 or possibly using other existing protocols such as XMPP [RFC6120]. 1104 This removes the need for the CDNI working group to define a new 1105 protocol for the request/response element of the CDNI Metadata 1106 interface. 1108 Thus, the CDNI working group would be left only with the task of 1109 specifying: 1111 o The recommended request/response protocol to use along with any 1112 additional semantics that are specific to the CDNI Metadata 1113 interface (e.g. handling of malformed requests/responses). 1114 o The syntax (i.e representation/encoding) of the CDNI Metadata 1115 objects that will be exchanged over the interface. 1116 o The semantics (i.e. meaning and expected contents) of the 1117 individual properties of a Metadata object. 1118 o How the relationships between different CDNI Metadata objects are 1119 represented. 1121 A.3. CDNI Logging Interface 1123 The CDNI Logging interface enables details of logs or events to be 1124 exchanged between interconnected CDNs, where events could be: 1126 o Log records related to the delivery of content (similar to the log 1127 records recorded in a web server's access log). 1128 o Real-time or near-real time events before, during or after content 1129 delivery, e.g. content delivery interruption 1130 o Operations and diagnostic messages. 1132 Within CDNs today, logs and events are used for a variety of purposes 1133 in addition to real-time and non real-time diagnostics and auditing 1134 by the CDN Provider and its customers. Specifically CDNs use logs to 1135 generate Call Data Records (CDRs) for passing to billing and payment 1136 systems and to real-time (and near real-time) analytics systems. 1137 Such applications place requirements on the CDNI Logging interface to 1138 support guaranteed and timely delivery of log messages between 1139 interconnected CDNs. It may also be necessary to be able to prove 1140 the integrity of received log messages. 1142 Several protocols already exist that could potentially be used to 1143 exchange CDNI logs between interconnected CDNs including SNMP Traps, 1144 syslog, ftp, HTTP POST, etc. although it is likely that some of the 1145 candidate protocols may not be well suited to meet all the 1146 requirements of CDNI. For example SNMP traps pose scalability 1147 concerns and SNMP does not support guaranteed delivery of Traps and 1148 therefore could result in log records being lost and the consequent 1149 CDRs and billing records for that content delivery not being produced 1150 as well as that content delivery being invisible to any analytics 1151 platforms. 1153 Although it is not necessary to define a new protocol for exchanging 1154 logs across the CDNI Logging interface, the CDNI working group would 1155 still need to specify: 1157 o The recommended protocol to use. 1158 o A default set of log fields and their syntax & semantics. Today 1159 there is no standard set of common log fields across different 1160 content delivery protocols and in some cases there is not even a 1161 standard set of log field names and values for different 1162 implementations of the same delivery protocol. 1163 o A default set of events that trigger logs to be generated. 1165 A.4. CDNI Control Interface 1167 The CDNI Control interface allows the Control System in 1168 interconnected CDNs to communicate. The exact inter-CDN control 1169 functionality required to be supported by the CDNI Control interface 1170 is less well defined than the other three CDNI interfaces at this 1171 time. 1173 However, as discussed in Section 3, the CDNI Control interface may be 1174 required to support functionality similar to the following: 1175 o Allow an upstream CDN and downstream CDN to establish, update or 1176 terminate their CDNI interconnection. 1177 o Allow bootstrapping of the other CDNI interfaces (e.g. protocol 1178 address discovery and establishment of security associations). 1179 o Allow configuration of the other CDNI interfaces (e.g. Upstream 1180 CDN specifies information to be reported through the CDNI Logging 1181 interface). 1182 o Allow the downstream CDN to communicate static information about 1183 its delivery capabilities, resources and policies. 1184 o Allow bootstrapping of the interface between CDNs for content 1185 acquisition (even if that interface itself is outside the scope of 1186 the CDNI work). 1187 It is expected that for the Control interface also, existing 1188 protocols can be reused or leveraged. Those will be considered once 1189 the requirements for the Control interface have been refined. 1191 Appendix B. Additional Material 1193 This section records related information that was produced as part of 1194 defining the CDNI problem statement. 1196 B.1. Non-Goals for IETF 1198 Listed below are aspects of content delivery that the authors propose 1199 be kept outside of the scope of the CDNI working group: 1200 o The interface between Content Service Provider and the 1201 Authoritative CDN (i.e. the upstream CDN contracted by the CSP for 1202 delivery by this CDN or by its downstream CDNs). 1203 o The delivery interface between the delivering CDN surrogate and 1204 the User Agent, such as streaming protocols. 1205 o The request interface between the User Agent and the request- 1206 routing system of a given CDN. Existing IETF protocols (e.g. 1207 HTTP, RTSP, DNS) are commonly used by User Agents to request 1208 content from a CDN and by CDN request routing systems to redirect 1209 the User Agent requests. The CDNI working group need not define 1210 new protocols for this purpose. Note however, that the CDNI 1211 control plane interface may indirectly affect some of the 1212 information exchanged through the request interface (e.g. URI). 1213 o The content acquisition interface between CDNs (i.e. the data 1214 plane interface for actual delivery of a piece of content from one 1215 CDN to the other). This is expected to use existing protocols 1216 such as HTTP or protocols defined in other forums for content 1217 acquisition between an origin server and a CDN (e.g. HTTP-based 1218 C2 reference point of ATIS IIF CoD). The CDN Interconnection 1219 problem space described in this document may therefore only 1220 concern itself with the agreement/negotiation aspects of which 1221 content acquisition protocol is to be used between two 1222 interconnected CDNs in view of facilitating interoperability. 1223 o End User/User Agent Authentication. End User/User Agent 1224 authentication and authorization are the responsibility of the 1225 Content Service Provider. 1226 o Content preparation, including encoding and transcoding. The CDNI 1227 architecture aims at allowing distribution across interconnected 1228 CDNs of content treated as opaque objects. Interpretation and 1229 processing of the objects, as well as optimized delivery of these 1230 objects by the surrogate to the End User are outside the scope of 1231 CDNI. 1232 o Digital Rights Management (DRM). DRM is an end-to-end issue 1233 between a content protection system and the User Agent. 1234 o Applications consuming CDNI logs (e.g. charging, analytics, 1235 reporting,...). 1236 o Internal CDN interfaces & protocols (i.e. interfaces & protocols 1237 within one CDN). 1239 o Scalability of individual CDNs. While scalability of the CDNI 1240 interfaces/approach is in scope, how an individual CDN scales is 1241 out of scope. 1242 o Actual algorithms for selection of CDNs or Surrogates by Request 1243 Routing systems (however, some specific parameters required as 1244 input to these algorithms may be in scope when they need to be 1245 communicated across CDNs). 1246 o Surrogate algorithms. For example caching algorithms and content 1247 acquisition methods are outside the scope of the CDNI work. 1248 Content management (e.g. Content Deletion) as it relates to CDNI 1249 content management policies, is in scope but the internal 1250 algorithms used by a cache to determine when to no longer cache an 1251 item of Content (in the absence of any specific metadata to the 1252 contrary) is out of scope. 1253 o Element management interfaces. 1254 o Commercial, business and legal aspects related to the 1255 interconnections of CDNs. 1257 B.2. Relationship to relevant IETF Working Groups & IRTF Reserach 1258 Groups 1260 B.2.1. ALTO WG 1262 As stated in the ALTO Working Group charter [ALTO-Charter]: 1264 "The Working Group will design and specify an Application-Layer 1265 Traffic Optimization (ALTO) service that will provide applications 1266 with information to perform better-than-random initial peer 1267 selection. ALTO services may take different approaches at balancing 1268 factors such as maximum bandwidth, minimum cross-domain traffic, 1269 lowest cost to the user, etc. The working group will consider the 1270 needs of BitTorrent, tracker-less P2P, and other applications, such 1271 as content delivery networks (CDN) and mirror selection." 1273 In particular, the ALTO service can be used by a CDN Request Routing 1274 system to improve its selection of a CDN surrogate to serve a 1275 particular User Agent request (or to serve a request from another 1276 surrogate). [I-D.jenkins-alto-cdn-use-cases] describes a number of 1277 use cases for a CDN to be able to obtain network topology and cost 1278 information from an ALTO server(s) and discusses how CDN Request 1279 Routing could be used as an integration point of ALTO into CDNs. It 1280 is possible that the ALTO service could be used in the same manner in 1281 a multi-CDN environment based on CDN Interconnection. For example, 1282 an upstream CDN may take advantage of the ALTO service in its 1283 decision for selecting a downstream CDN to which a user request 1284 should be delegated. 1286 However, the current work of ALTO is complementary to and does not 1287 overlap with the work described in this document because the 1288 integration between ALTO and a CDN is an internal decision for a 1289 specific CDN and is therefore out of scope for the CDNI working 1290 group. One area for further study is whether additional information 1291 should be provided by an ALTO service to facilitate CDNI CDN 1292 selection. 1294 B.2.2. DECADE WG 1296 The DECADE Working Group [DECADE-Charter] is addressing the problem 1297 of reducing traffic on the last-mile uplink, as well as backbone and 1298 transit links caused by P2P streaming and file sharing applications. 1299 It addresses the problem by enabling an application endpoint to make 1300 content available from an in-network storage service and by enabling 1301 other application endpoints to retrieve the content from there. 1303 Exchanging data through the in-network storage service in this 1304 manner, instead of through direct communication, provides significant 1305 gain where: 1307 o The network capacity/bandwidth from in-network storage service to 1308 application endpoint significantly exceeds the capacity/bandwidth 1309 from application endpoint to application endpoint (e.g. because of 1310 an end-user uplink bottleneck); and 1311 o Where the content is to be accessed by multiple instances of 1312 application endpoints (e.g. as is typically the case for P2P 1313 applications). 1315 While, as is the case for any other data distribution application, 1316 the DECADE architecture and mechanisms could potentially be used for 1317 exchange of CDNI control plane information via an in-network-storage 1318 service (as opposed to directly between the entities terminating the 1319 CDNI interfaces in the neighbor CDNs), we observe that: 1321 o CDNI would operate as a "Content Distribution Application" from 1322 the DECADE viewpoint (i.e. would operate on top of DECADE). 1323 o There does not seem to be obvious benefits in integrating the 1324 DECADE control plane responsible for signaling information 1325 relating to control of the in-network storage service itself, and 1326 the CDNI control plane responsible for application-specific CDNI 1327 interactions (such as exchange of CDNI metadata, CDNI request 1328 redirection, transfer of CDNI logging information). 1329 o There would typically be limited benefits in making use of a 1330 DECADE in-network storage service because the CDNI interfaces are 1331 expected to be terminated by a very small number of CDNI clients 1332 (if not one) in each CDN, and the CDNI clients are expected to 1333 benefit from high bandwidth/capacity when communicating directly 1334 to each other (at least as high as if they were communicating via 1335 an in-network storage server). 1337 The DECADE in-network storage architecture and mechanisms may 1338 theoretically be used for the acquisition of the content objects 1339 themselves between interconnected CDNs. It is not expected that this 1340 would have obvious benefits in typical situations where a content 1341 object is acquired only once from an Upstream CDN to a Downstream CDN 1342 (and then distributed as needed inside the Downstream CDN). But it 1343 might have benefits in some particular situations. Since the 1344 acquisition protocol between CDNs is outside the scope of the CDNI 1345 work, this question is left for further study. 1347 The DECADE in-network storage architecture and mechanisms may 1348 potentially also be used within a given CDN for the distribution of 1349 the content objects themselves among surrogates of that CDN. Since 1350 the CDNI work does not concern itself with operation within a CDN, 1351 this question is left for further study. 1353 Therefore, the work of DECADE may be complementary to but does not 1354 overlap with the CDNI work described in this document. 1356 B.2.3. PPSP WG 1358 As stated in the PPSP Working Group charter [PPSP-Charter]: 1360 "The Peer-to-Peer Streaming Protocol (PPSP) working group develops 1361 two signaling and control protocols for a peer-to-peer (P2P) 1362 streaming system for transmitting live and time-shifted media content 1363 with near real-time delivery requirements." and "The PPSP working 1364 group designs a protocol for signaling and control between trackers 1365 and peers (the PPSP "tracker protocol") and a signaling and control 1366 protocol for communication among the peers (the PPSP "peer 1367 protocol"). The two protocols enable peers to receive streaming data 1368 within the time constraints required by specific content items." 1370 Therefore PPSP is concerned with the distribution of the streamed 1371 content itself along with the necessary signaling and control 1372 required to distribute the content. As such, it could potentially be 1373 used for the acquisition of streamed content across interconnected 1374 CDNs. But since the acquisition protocol is outside the scope of the 1375 work proposed for CDNI, we leave this for further study. Also, 1376 because of its streaming nature, PPSP is not seen as applicable to 1377 the distribution and control of the CDNI control plane and CDNI data 1378 representations. 1380 Therefore, the work of PPSP may be complementary to but does not 1381 overlap with the work described in this document for CDNI. 1383 B.2.4. IRTF P2P Research Group 1385 Some information on CDN interconnection motivations and technical 1386 issues were presented in the P2P RG at IETF 77. The presentation can 1387 be found in [P2PRG-CDNI]. 1389 Appendix C. Additional Material 1391 Note to RFC Editor: This appendix is to be removed on publication as 1392 an RFC. 1394 C.1. Related standardization activites 1396 There are a number of other standards bodies and industry forums that 1397 are working in areas related to CDNs, and in some cases related to 1398 CDNI. This section outlines any potential overlap with the work of 1399 the CDNI working group and any component that could potentially be 1400 reused to realize the CDNI interfaces. 1402 A number of standards bodies have produced specifications related to 1403 CDNs, for example: 1405 o ETSI TISPAN (Telecommunications and Internet converged Services 1406 and Protocols for Advanced Networking) has a series of 1407 specifications focusing on CDNs. 1408 o The Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum 1409 (IIF) specify the architecture and the protocols of an IPTV 1410 solution. Although OIPF and ATIS specifications include the 1411 interaction with a CDN, the CDN specifications are coupled with 1412 their IPTV specifications and do not cover interconnection of 1413 CDNs. 1414 o ATIS Cloud Services Forum (CSF) has started investigating 1415 interconnection of CDNs. The ATIS CSF focuses on defining use 1416 cases and requirements for such CDN interconnection, which are 1417 expected to be considered as input into the work of the CDNI 1418 working group. At the time of writing this document, ATIS CSF is 1419 not specifying the corresponding protocols or interfaces and is 1420 expected to leverage the work of the IETF CDNI working group for 1421 those. 1422 o CableLabs, SNIA and ITU have developed (or are working on) 1423 definitions for content related metadata and specifications for 1424 its distribution. However, they do not include metadata specific 1425 to the distribution of content within a CDN or between 1426 interconnected CDNs. 1427 o IETF CDI working group (now concluded) touched on the same problem 1428 space as the present document. However, in accordance with its 1429 initial charter, the CDI working group did not define any 1430 protocols or interfaces to actually enable CDN Interconnection and 1431 at that time (2003) there was not enough industry interest and 1432 real life requirements to justify rechartering the working group 1433 to conduct the corresponding protocol work. 1435 Although some of the specifications describe multi-CDN cooperation or 1436 include reference points for interconnecting CDNs, none of them 1437 specify in sufficient detail all the CDNI interfaces and CDNI 1438 Metadata representations required to enable even a base level of CDN 1439 Interconnection functionality to be implemented. 1441 C.1.1. IETF CDI Working Group (Concluded) 1443 The Content Distribution Internetworking (CDI) Working Group was 1444 formed in the IETF following a BoF in December 2000 and closed in mid 1445 2003. 1447 For convenience, here is an extract from the CDI working group 1448 charter [CDI-Charter]: 1450 " 1452 o The goal of this working group is to define protocols to allow the 1453 interoperation of separately-administered content networks. 1454 o A content network is an architecture of network elements, arranged 1455 for efficient delivery of digital content. Such content includes, 1456 but is not limited to, web pages and images delivered via HTTP, 1457 and streaming or continuous media which are controlled by RTSP. 1458 o The working group will first define requirements for three modes 1459 of content internetworking: interoperation of request-routing 1460 systems, interoperation of distribution systems, and 1461 interoperation of accounting systems. These requirements are 1462 intended to lead to a follow-on effort to define protocols for 1463 interoperation of these systems. 1464 o In its initial form, the working group is not chartered to deliver 1465 those protocols [...] 1467 " 1469 Thus, the CDI working group touched on the same problem space as the 1470 present document. 1472 The CDI working group published 3 Informational RFCs: 1474 o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". 1475 o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing 1476 Mechanisms". 1478 o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". 1480 C.1.2. 3GPP 1482 3GPP was the first organization that released a specification related 1483 to adaptive streaming over HTTP. 3GPP Release 9 specification on 1484 adaptive HTTP streaming was published in March 2010, and there have 1485 been some bug fixes on this specification since the publication. In 1486 addition, 3GPP has produced an extended version for Release 10, which 1487 was published in 2011. This release will include a number of 1488 clarifications, improvements and new features. 1490 [3GP-DASH] is defined as a general framework independent of the data 1491 encapsulation format. It has support for fast initial startup and 1492 seeking, adaptive bitrate switching, re-use of HTTP origin and cache 1493 servers, re-use of existing media playout engines, on-demand, live 1494 and time-shifted delivery. It specifies syntax and semantics of 1495 Media Presentation Description (MPD), format of segments and delivery 1496 protocol for segments. It does not specify content provisioning, 1497 client behavior or transport of MPD. 1499 The content retrieved by a client using [3GP-DASH] adaptive streaming 1500 could be obtained from a CDN but this is not discussed or specified 1501 in the 3GPP specifications as it is transparent to [3GP-DASH] 1502 operations. Similarly, it is expected that [3GP-DASH] can be used 1503 transparently from the CDNs as a delivery protocol (between the 1504 delivering CDN surrogate and the User Agent) in a CDN Interconnection 1505 environment. [3GP-DASH] could also be a candidate for content 1506 acquisition between CDNs in a CDN Interconnection environment. 1508 C.1.3. ISO MPEG 1510 Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad- 1511 hoc group adopted the 3GPP Release 9 [3GP-DASH] specification as a 1512 starting point and has made some improvements and extensions. 1513 Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on 1514 standardizing the manifest file and the delivery format. 1515 Additionally, the MPEG DASH ad-hoc group has also been working on the 1516 use of MPEG-2 Transport Streams as a media format, conversion from/to 1517 existing file formats, common encryption, and so on. The MPEG DASH 1518 specification could also be a candidate for delivery to the User 1519 Agent and for content acquisition between CDNs in a CDN 1520 Interconnection environment. The Draft International Standard (DIS) 1521 version [MPEG-DASH] is currently publicly available since early 1522 February 2011. 1524 In the 95th MPEG meeting in January 2011, the DASH ad-hoc group 1525 decided to start a new evaluation experiment called "CDN-EE". The 1526 goals are to understand the requirements for MPEG DASH to better 1527 support CDN-based delivery, and to provide a guidelines document for 1528 CDN operators to better support MPEG DASH streaming services. The 1529 ongoing work is still very preliminary and does not currently target 1530 looking into CDN Interconnection use cases. 1532 C.1.4. ATIS IIF 1534 ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS) 1535 that develops requirements, standards, and specifications for IPTV. 1537 ATIS IIF is developing the "IPTV Content on Demand (CoD) Service" 1538 specification. This includes use of a CDN (referred to in ATIS IIF 1539 CoD as the "Content Distribution and Delivery Functions") for support 1540 of a Content on Demand (CoD) Service as part of a broader IPTV 1541 service. However, this only covers the case of a managed IPTV 1542 service (in particular where the CDN is administered by the service 1543 provider) and does not cover the use, or interconnection, of multiple 1544 CDNs. 1546 C.1.5. CableLabs 1548 "Founded in 1988 by cable operating companies, Cable Television 1549 Laboratories, Inc. (CableLabs) is a non-profit research and 1550 development consortium that is dedicated to pursuing new cable 1551 telecommunications technologies and to helping its cable operator 1552 members integrate those technical advancements into their business 1553 objectives." [CableLabs] 1555 CableLabs has defined specifications for CoD Content Metadata as part 1556 of its VOD Metadata project. 1558 C.1.6. ETSI MCD 1560 ETSI MCD (Media Content Distribution) is the ETSI technical committee 1561 "in charge of guiding and coordinating standardization work aiming at 1562 the successful overall development of multimedia systems (television 1563 and communication) responding to the present and future market 1564 requests on media content distribution". 1566 MCD created a specific work item on interconnection of heterogeneous 1567 CDNs ("CDN Interconnection, use cases and requirements") in March 1568 2010. MCD very recently created a working group to progress this 1569 work item. However, no protocol level work has yet started in MCD 1570 for CDN Interconnection. 1572 C.1.7. ETSI TISPAN 1574 ETSI TISPAN has published two sets of IPTV specifications, one of 1575 which is based on IMS. In addition, TISPAN has published a CDN 1576 architecture supporting delivery of various content services such as 1577 time-shifted TV and VoD to TISPAN devices (UEs) or regular PCs. The 1578 use cases allow for hierarchically and geographically distributed CDN 1579 scenarios, along with multi-CDN cooperation. As a result, the 1580 architecture contains reference points to support interconnection of 1581 other TISPAN CDNs. The protocol definition phase for the 1582 corresponding CDN architecture was kicked-off at the end of 2010 as 1583 is still in progress. In line with its long history of leveraging 1584 IETF protocols, ETSI could potentially leverage CDNI interfaces 1585 developed in the IETF for their related protocol level work on 1586 interconnections of CDNs. 1588 C.1.8. ITU-T 1590 SG13 is developing standards related to the support of IPTV services 1591 (i.e.. multimedia services such as television/VoD/audio/text/ 1592 graphics/data delivered over IP-based managed networks). 1594 ITU-T Recommendation Y.1910 [Y.1910] provides the description of the 1595 IPTV functional architecture. This architecture includes functions 1596 and interfaces for the distribution and delivery of content. This 1597 architecture is aligned with the ATIS IIF architecture. 1599 Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in 1600 more detail the content delivery functional architecture. This 1601 architecture allows CDN Interconnection: some interfaces (such as D3, 1602 D4) at the control level allow relationships between different CDNs, 1603 in the same domain or in different domains. Generic procedures are 1604 described, but the choice of the protocols is open. 1606 C.1.9. Open IPTV Forum (OIPF) 1608 The Open IPTV Forum has developed an end-to-end solution to allow any 1609 OIPF terminal to access enriched and personalized IPTV services 1610 either in a managed or a non-managed network[OIPF-Overview]. Some 1611 OIPF services (such as Network PVR) may be hosted in a CDN. 1613 To that end, the Open IPTV Forum specification is made of 5 parts: 1615 o Media Formats including HTTP Adaptive Streaming 1616 o Content Metadata 1617 o Protocols 1618 o Terminal (Declarative or Procedural Application Environment) 1619 o Authentication, Content Protection and Service Protection 1621 C.1.10. TV-Anytime Forum 1623 Version 1 of the TV-Anytime Forum specifications were published as 1624 ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line 1625 Services: Search, select, and rightful use of content on personal 1626 storage systems ("TV-Anytime")". It includes the specification of 1627 content metadata in XML schemas (ETSI TS 102 822-3) which define 1628 technical parameters for the description of CoD and Live contents. 1629 The specification is referenced by DVB and OIPF. 1631 The TV-anytime Forum was closed in 2005. 1633 C.1.11. SNIA 1635 The Storage Networking Industry Association (SNIA) is an association 1636 of producers and consumers of storage networking products whose goal 1637 is to further storage networking technology and applications. 1639 SNIA has published the Cloud Data Management Interface (CDMI) 1640 standard ([SNIA-CDMI]). 1642 "The Cloud Data Management Interface defines the functional interface 1643 that applications will use to create, retrieve, update and delete 1644 data elements from the Cloud. As part of this interface the client 1645 will be able to discover the capabilities of the cloud storage 1646 offering and use this interface to manage containers and the data 1647 that is placed in them. In addition, metadata can be set on 1648 containers and their contained data elements through this interface." 1650 C.1.12. Summary of existing standardization work 1652 The following sections will summarize the existing work of the 1653 standard bodies listed earlier against the CDNI problem space. 1654 Appendix C.1.12.1 summarizes existing interfaces that could be 1655 leveraged for content acquisition between CDNs and Appendix C.1.12.2 1656 summarizes existing metadata specifications that may be applicable to 1657 CDNI. To date we are not aware of any standardization activities in 1658 the areas of the remaining CDNI interfaces (CDNI Request Routing, 1659 CDNI Control and CDNI Logging). 1661 C.1.12.1. Content Acquisition across CDNs and Delivery to End User 1662 (Data plane) 1664 A number of standards bodies have completed work in the areas of 1665 content acquisition interface between a CSP and a CDN, as well as as 1666 on the delivery interface between the surrogate and the User Agent. 1667 Some of this work is summarized below. 1669 TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand 1670 (CoD) services, including the data plane aspects (typically different 1671 flavors of RTP/RTCP and HTTP) to obtain content and deliver it to 1672 User Agents. For example, : 1673 o The OIPF data plane includes both RTP and HTTP flavors (HTTP 1674 progressive download, HTTP Adaptive streaming [3GP-DASH]). 1675 o The ATIS IIF specification "IPTV Content on Demand (CoD) Service" 1676 [ATIS-COD] defines a reference point (C2) and the corresponding 1677 HTTP-based data plane protocol for content acquisition between an 1678 authoritative origin server and the CDN. 1679 While these protocols have not been explicitly specified for content 1680 acquisition across CDNs, they are suitable (in addition to others 1681 such as standard HTTP) for content acquisition between CDNs in a CDN 1682 Interconnection environment. Therefore for the purpose of the CDNI 1683 working group there are already multiple existing data plane 1684 protocols that can be used for content acquisition across CDNs. 1686 Similarly, there are multiple existing standards (e.g. the OIPF data 1687 plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public 1688 specifications (e.g. vendor specific HTTP Adaptive streaming 1689 specifications) so that content delivery can be considered already 1690 solved (or at least sufficiently addressed in other forums). 1692 Thus, specification of the content acquisition interface between CDNs 1693 and the delivery interface between the surrogate and the User Agent 1694 are out of scope for the CDNI working group. The CDNI working group 1695 may only concern itself with the negotiation/selection aspects of the 1696 acquisition protocol to be used in a CDN interonnect scenario. 1698 C.1.12.2. CDNI Metadata 1700 CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the 1701 specification of content metadata: 1703 o CableLabs has defined specifications for CoD Content Metadata as 1704 part of its VOD Metadata project. "The VOD Metadata project is a 1705 cable television industry and cross-industry-wide effort to 1706 specify the metadata and interfaces for distribution of video-on- 1707 demand (VOD) material from multiple content providers to cable 1708 operators." [CableLabs-Metadata]. However, while the CableLabs 1709 work specifies an interface between a content provider and a 1710 service provider running a CDN, it does not include an interface 1711 that could be used between CDNs. 1713 o ITU Study Group 16 has started work on a number of draft 1714 Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA, 1715 HSTP.IPTV-UMCI) specifying metadata for content distribution in 1716 IPTV services. 1717 o An Open IPTV Terminal receives the technical description of the 1718 content distribution from the OIPF IPTV platform before receiving 1719 any content. The Content distribution metadata is sent in the 1720 format of a TV-Anytime XSD including tags to describes the 1721 location and program type (on demand or Live) as well as 1722 describing the time availability of the on demand and live 1723 content. 1725 However the specifications outlined above do not include metadata 1726 specific to the distribution of content within a CDN or between 1727 interconnected CDNs, for example geo-blocking information, 1728 availability windows, access control mechanisms to be enforced by the 1729 surrogate, how to map an incoming content request to a file on the 1730 origin server or acquire it from the upstream CDN etc. 1732 The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can 1733 be associated with data that is stored by a cloud storage provider. 1734 While the metadata currently defined do not match the needs of CDN 1735 Interconnection, it is worth considering CDMI as one of the existing 1736 pieces of work that may potentially be leveraged for the CDNI 1737 Metadata interface (e.g by extending the CDMI metadata to address 1738 more specific CDNI needs). 1740 C.2. Related Research Projects 1742 C.2.1. OCEAN 1744 OCEAN (http://www.ict-ocean.eu/) is an EU funded research project 1745 that started in February 2010 for 3 years. Some of its objectives 1746 are relevant to CDNI. It aims, among other things, at designing a 1747 new architectural framework for audiovisual content delivery over the 1748 Internet, defining public interfaces between its major building 1749 blocks in order to foster multi-vendor solutions and interconnection 1750 between Content Networks (the term "Content Networks" corresponds 1751 here to the definition introduced in [RFC3466], which encompasses 1752 CDNs). 1754 OCEAN has not yet published any open specifications, nor common best 1755 practices, defining how to achieve such CDN interconnection. 1757 C.2.2. Eurescom P1955 1759 Eurescom P1955 was a 2010 research project involving a four European 1760 Network operators, which studied the interests and feasibility of 1761 interconnecting CDNs by firstly elaborating the main service models 1762 around CDN interconnection, as well as analyzing an adequate CDN 1763 interconnection technical architecture and framework, and finally by 1764 providing recommendations for telcos to implement CDN 1765 interconnection. The Eurescom P1955 project ended in July 2010. 1767 The authors are not aware of material discussing CDN interconnection 1768 protocols or interfaces made publicly available as a deliverable of 1769 this project. 1771 Authors' Addresses 1773 Ben Niven-Jenkins 1774 Velocix (Alcatel-Lucent) 1775 326 Cambridge Science Park 1776 Milton Road, Cambridge CB4 0WG 1777 UK 1779 Email: ben@velocix.com 1781 Francois Le Faucheur 1782 Cisco Systems 1783 Greenside, 400 Avenue de Roumanille 1784 Sophia Antipolis 06410 1785 France 1787 Phone: +33 4 97 23 26 19 1788 Email: flefauch@cisco.com 1790 Nabil Bitar 1791 Verizon 1792 40 Sylvan Road 1793 Waltham, MA 02145 1794 USA 1796 Email: nabil.bitar@verizon.com