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