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