idnits 2.17.00 (12 Aug 2021) /tmp/idnits3854/draft-jenkins-cdni-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 17, 2011) is 4141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IETF RFC3466' is mentioned on line 1046, but not defined ** Obsolete undefined reference: RFC 3466 (Obsoleted by RFC 7336) == Missing Reference: 'REF' is mentioned on line 1108, but not defined == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-use-cases-00 == Outdated reference: A later version (-03) exists of draft-penno-alto-cdn-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) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft Velocix (Alcatel-Lucent) 4 Intended status: Informational F. Le Faucheur 5 Expires: July 21, 2011 Cisco 6 N. Bitar 7 Verizon 8 January 17, 2011 10 Content Distribution Network Interconnection (CDNI) Problem Statement 11 draft-jenkins-cdni-problem-statement-01 13 Abstract 15 Content Delivery Networks (CDNs) provide numerous benefits: reduced 16 delivery cost for cacheable content, improved quality of experience 17 for End Users and increased robustness of delivery. For these 18 reasons they are frequently used for large-scale content delivery. 19 As a result, existing CDN providers are scaling up their 20 infrastructure and many Network Service Providers (NSPs) are 21 deploying their own CDNs. It is generally desirable that a given 22 content item can be delivered to an end user regardless of that end 23 user's location or attachment network. This creates a requirement 24 for interconnecting standalone CDNs so they can interoperate as an 25 open content delivery infrastructure for the end-to-end delivery of 26 content from Content Service Providers (CSPs) to end users. However, 27 no standards or open specifications currently exist to facilitate 28 such CDN interconnection. 30 The goal of this document is to outline the problem area for the IETF 31 with a view towards creating a working group. This working group 32 would work on interoperable and scalable solutions for CDN 33 interconnection. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on July 21, 2011. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8 78 2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 9 79 3. CDN Interconnect Model & Problem Area for IETF . . . . . . . . 10 80 3.1. Candidate CDNI Problem Area for IETF . . . . . . . . . . . 12 81 3.2. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 13 82 4. Design Approach for Realizing the CDNI APIs . . . . . . . . . 14 83 4.1. Relationship to the OSI network model . . . . . . . . . . 15 84 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . . . . 15 85 4.3. CDNI Request Routing API . . . . . . . . . . . . . . . . . 15 86 4.4. CDNI Metadata API . . . . . . . . . . . . . . . . . . . . 17 87 4.5. CDNI Logging API . . . . . . . . . . . . . . . . . . . . . 18 88 4.6. CDNI Control API . . . . . . . . . . . . . . . . . . . . . 19 89 5. Prioritizing the CDNI Work . . . . . . . . . . . . . . . . . . 19 90 6. Gap Analysis of relevant Standardization and Research 91 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 6.1. Related standardization activities . . . . . . . . . . . . 20 93 6.1.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 20 94 6.1.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 6.1.3. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 21 96 6.1.4. Cable Labs . . . . . . . . . . . . . . . . . . . . . . 22 97 6.1.5. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 22 98 6.1.6. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 22 99 6.1.7. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 23 100 6.1.8. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 23 101 6.1.9. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 23 102 6.1.10. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 6.2. Related Research Projects . . . . . . . . . . . . . . . . 24 104 6.2.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 24 105 6.2.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 24 106 6.2.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 24 107 6.3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . 25 108 6.3.1. Content Acquisition across CDNs and Delivery to 109 End User (Data plane) . . . . . . . . . . . . . . . . 25 110 6.3.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . 26 111 7. Relationship to relevant IETF Working Groups . . . . . . . . . 27 112 7.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 113 7.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 7.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 120 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 124 1. Introduction 126 The volume of video and multimedia content delivered over the 127 Internet is rapidly increasing and expected to continue doing so in 128 the future. In the face of this growth, Content Delivery Networks 129 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 130 content, improved quality of experience for end users and increased 131 robustness of delivery. For these reasons CDNs are frequently used 132 for large-scale content delivery. As a result, existing CDN 133 providers are scaling up their infrastructure and many Network 134 Service Providers (NSPs) are deploying their own CDNs. It is 135 generally desirable that a given content item can be delivered to an 136 End User regardless of that End User's location or attachment 137 network. However, the footprint of a given CDN in charge of 138 delivering a given content may not expand close enough to the End 139 User's current location or attachment network to realize the cost 140 benefit and user experience that a more distributed CDN would 141 provide. This creates a requirement for interconnecting standalone 142 CDNs so that their collective CDN footprint can be leveraged for the 143 end-to-end delivery of content from Content Service Providers (CSPs) 144 to End Users. However, no standards or open specifications currently 145 exist to facilitate such CDN interconnection. 147 The goal of this document is to outline the problem area for the IETF 148 with a view towards creating a working group. This working group 149 would work on interoperable and scalable solutions for CDN 150 interconnection. 152 Section 2 discusses the use cases for CDN interconnection. Section 3 153 presents the CDNI model and problem area to be considered by the 154 IETF. Section 4 discusses how existing protocols can be reused to 155 define the CDNI APIs while Section 5 proposes to focus the scope for 156 the initial charter of a CDNI Working Group to the minimum functional 157 elements necessary for basic CDN interconnection. Section 5 provides 158 a gap analysis of the work of other standards organization and 159 finally Section 5 discusses the relationship with relevant IETF 160 Working Groups. 162 1.1. Terminology 164 This document uses the following terms: 166 Content: Any form of digital data. One important form of Content 167 with additional constraints on Distribution and Delivery is 168 continuous media (i.e. where there is a timing relationship between 169 source and sink). 171 Metadata: Metadata in general is data about data. 173 Content Metadata: This is metadata about Content. Content Metadata 174 comprises: 176 1. Metadata that is relevant to the distribution of the content (and 177 therefore relevant to a CDN involved in the delivery of that 178 content). We refer to this type of metadata as "Content 179 Distribution Metadata". See also the definition of Content 180 Distribution Metadata. 181 2. Metadata that is associated with the actual Content (and not 182 directly relevant to the distribution of that Content) or content 183 representation. For example, such metadata may include 184 information pertaining to the Content's genre, cast, rating, etc 185 as well as information pertaining to the Content representation's 186 resolution, aspect ratio, etc. 188 Content Distribution Metadata: The subset of Content Metadata that is 189 relevant to the distribution of the content. This is the metadata 190 required by a CDN in order to enable and control content distribution 191 and delivery by the CDN. In a CDN Interconnection environment, some 192 of the Content Distribution Metadata may have an intra-CDN scope (and 193 therefore need not be communicated between CDNs), while some of the 194 Content Distribution Metadata have an inter-CDN scope (and therefore 195 needs to be communicated between CDNs). 197 CDNI Metadata: Content Distribution Metadata with inter-CDN scope. 198 For example, CDNI Metadata may include geo-blocking information (i.e. 199 information defining geographical areas where the content is to be 200 made available or blocked), availability windows (i.e. information 201 defining time windows during which the content is to be made 202 available or blocked) and access control mechanisms to be enforced 203 (e.g. URI signature validation). CDNI Metadata may also include 204 information about desired distribution policy (e.g. prepositioning vs 205 dynamic acquisition) and about where/how a CDN can acquire the 206 content. CDNI Metadata may also include content management 207 information (e.g. request for deletion of Content from Surrogates) 208 across interconnected CDNs. 210 End User (EU): The 'real' user of the system, typically a human but 211 maybe some combination of hardware and/or software emulating a human 212 (e.g. for automated quality monitoring etc.) 214 User Agent (UA): Software (or a combination of hardware and software) 215 through which the End User interacts with the Content Service. The 216 User Agent will communicate with the CSP's Service for the selection 217 of content and one or more CDNs for the delivery of the Content. 218 Such communication is not restricted to HTTP and may be via a variety 219 of protocols. Examples of User Agents (non-exhaustive) are: 220 Browsers, Set Top Boxes (STB), Dedicated content applications (e.g. 222 media players), etc. 224 Network Service Provider (NSP): Provides network-based connectivity/ 225 services to Users. 227 Content Service Provider (CSP): Provides a Content Service to End 228 Users (which they access via a User Agent). A CSP may own the 229 Content made available as part of the Content Service, or may license 230 content rights from another party. 232 Content Service: The service offered by a Content Service Provider. 233 The Content Service encompasses the complete service which may be 234 wider than just the delivery of items of Content, e.g. the Content 235 Service also includes any middleware, key distribution, program 236 guide, etc. which may not require any direct interaction with the 237 CDN. 239 Content Distribution Network (CDN) / Content Delivery Network (CDN): 240 Network infrastructure in which the network elements cooperate at 241 layers 4 through layer 7 for more effective delivery of Content to 242 User Agents. Typically a CDN consists of a Request Routing system, a 243 Distribution System (that includes a set of Surrogates), a Logging 244 System and a CDN control system . 246 CDN Provider: The service provider who operates a CDN. Note that a 247 given entity may operate in more than one role. For example, a 248 company may simultaneously operate as a Content Service Provider, a 249 Network Service Provider and a CDN Provider. 251 CDN Interconnect (CDNI): The set of interfaces over which two or more 252 CDNs communicate with each other in order to achieve the delivery of 253 content to User Agents by Surrogates in one CDN (the downstream CDN) 254 on behalf of another CDN (the upstream CDN). 256 Upstream CDN: For a given user request, the CDN (within a pair of 257 directly interconnected CDNs) that redirects the request to the other 258 CDN. 260 Downstream CDN: For a given user request, the CDN (within a pair of 261 directly interconnected CDNs) to which the request is redirected by 262 the other CDN (the Upstream CDN). Note that in the case of 263 successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g. 264 CDN2) may act as the Downstream CDN for a redirection (e.g. 265 CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection 266 of the same request (e.g. CDN2-->CDN3). 268 Over-the-top (OTT): A service, e.g. a CDN, operated by a different 269 operator than the NSP to which the users of that service are 270 attached. 272 Surrogate: A device/function that interacts with other elements of 273 the CDN for the control and distribution of Content within the CDN 274 and interacts with User Agents for the delivery of the Content. 276 Request Routing System: The function within a CDN responsible for 277 receiving a content request from a user agent, obtaining and 278 maintaining necessary information about a set of candidate surrogates 279 or candidate CDNs, and for selecting and redirecting the user to the 280 appropriate surrogate or CDN. To enable CDN Interconnect, the 281 Request Routing System must also be capable of handling user agent 282 content requests passed to it by another CDN. 284 Distribution System: the function within a CDN responsible for 285 distributing Content Distribution Metadata as well as content inside 286 the CDN (e.g. down to the surrogates) 288 Delivery: the function within CDN surrogates responsible for 289 delivering a piece of content to the User Agent. For example, 290 delivery may be based on HTTP progressive download or HTTP adaptive 291 streaming. 293 Logging System: the function within a CDN responsible for collecting 294 measurement and recording of distribution and delivery activities. 295 The information recorded by the logging system may be used for 296 various purposes including charging (e.g. of the CSP), analytics and 297 monitoring. 299 1.2. CDN Background 301 Readers are assumed to be familiar with the architecture, features 302 and operation of CDNs. For readers less familiar with the operation 303 of CDNs, the following resources may be useful: 305 o RFC 3040 [RFC3040] describes many of the component technologies 306 that are used in the construction of a CDN 307 o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs 308 o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 309 IETF Content Delivery Internetworking (CDI) working group which 310 was closed in 2003. 312 Note: Some of the terms used in this document are similar to terms 313 used the above referenced documents. When reading this document 314 terms should be interpreted as having the definitions provided in 315 Section 1.1. 317 2. CDN Interconnect Use Cases 319 An increasing number of NSPs are deploying CDNs in order to deal 320 cost-effectively with the growing usage of on-demand video services 321 and other content delivery applications. 323 CDNs allow caching of content closer to the edge so that a given item 324 of content can be delivered by a CDN Surrogate (i.e. a cache) to 325 multiple User Agents (and their End Users) without transiting 326 multiple times through the network core (i.e from the content origin 327 to the surrogate). This contributes to bandwidth cost reductions for 328 the NSP and to improved quality of experience for the end users. 329 CDNs also enable replication of popular content across many 330 surrogates, which enables content to be served to large numbers of 331 User Agents concurrently. This also helps dealing with situations 332 such as flash crowds and denial of service attacks. 334 The CDNs deployed by NSPs are not just restricted to the delivery of 335 content to support the Network Service Provider's own 'walled garden' 336 services, such as IP delivery of television services to Set Top 337 Boxes, but are also used for delivery of content to other devices 338 including PCs, tablets, mobile phones etc. 340 Some service providers operate over multiple geographies and federate 341 multiple affiliate NSPs. These NSPs typically operate independent 342 CDNs. As they evolve their services (e.g. for seamless support of 343 content services to nomadic users across affiliate NSPs) there is a 344 need for interconnection of these CDNs. However there are no open 345 specifications, nor common best practices, defining how to achieve 346 such CDN interconnection. 348 CSPs have a desire to be able to get (some of) their content to very 349 large number of End Users and/or over many/all geographies and/or 350 with a high quality of experience, all without having to maintain 351 direct business relationships with many different CDN providers (or 352 having to extend their own CDN to a large number of locations). Some 353 NSPs are considering interconnecting their respective CDNs (as well 354 as possibly over-the-top CDNs) so that this collective infrastructure 355 can address the requirements of CSPs in a cost effective manner. In 356 particular, this would enable the CSPs to benefit from on-net 357 delivery (i.e. within the Network Service Provider's own network/CDN 358 footprint) whenever possible and off-net delivery otherwise, without 359 requiring the CSPs to maintain direct business relationships with all 360 the CDNs involved in the delivery. Again, for this requirement, CDN 361 operators (NSPs or over-the-top CDN operators) are faced with a lack 362 of open specifications and best practices. 364 NSPs have often deployed CDNs as specialized cost-reduction projects 365 within the context of a particular service or environment, some NSPs 366 operate separate CDNs for separate services. For example, there may 367 be a CDN for managed IPTV service delivery, a CDN for web-TV delivery 368 and a CDN for video delivery to Mobile terminals. As NSPs integrate 369 their service portfolio, there is a need for interconnecting these 370 CDNs. Again, NSPs face the problem of lack of open interfaces for 371 CDN interconnection. 373 For operational reasons (e.g. disaster, flash crowd) or commercial 374 reasons, an over-the-top CDN may elect to make use of another CDN 375 (e.g. an NSP CDN with on-net Surrogates for a given footprint) for 376 serving a subset of the user requests (e.g. requests from users 377 attached to that NSP). Again, for this requirement, CDN operators 378 (over-the-top CDN operators or NSPs) are faced with a lack of open 379 specifications and best practices. 381 Use cases for CDN Interconnection are further discussed in 382 [I-D.watson-cdni-use-cases] and [I-D.bertrand-cdni-use-cases]. 384 3. CDN Interconnect Model & Problem Area for IETF 386 Interconnecting CDNs involves interactions among multiple different 387 functions and components that form each CDN. Only some of those 388 require standardization. The CDNI model and problem area proposed 389 for IETF work is illustrated in Figure 1. The candidate problem area 390 (and respectively the non-goals) for IETF work on CDN Interconnection 391 are discussed in Section 3.1 (and respectively Section 3.2 ). 393 -------- 394 / \ 395 | CSP | 396 \ / 397 -------- 398 * 399 * 400 * /\ 401 * / \ 402 --------------------- |CDNI| --------------------- 403 / Upstream CDN \ | | / Downstream CDN \ 404 | +-------------+ | Control API | +-------------+ | 405 | |CDN Control |<======|====|=======>| CDN Control | | 406 | +------*-*-*--+ | | | | +-*-*-*-------+ | 407 | * * * | | | | * * * | 408 | +------*------+ | Logging API | +-----*-------+ | 409 | ****| Logging |<======|====|=======>| Logging |**** | 410 | * --------------+ | | | | +-------------+ * | 411 | * * * | | | | * * * | 412 | * +--------*----+ | Req-Routing API | +---*---------+ * | 413 | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | 414 | * * +-------------+ | | | | +-------------+ * * | 415 | * * * | | | | * * * | 416 | * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * | 417 | * * |Distribution |<======|====|=======>| Distribution| * * | 418 | * * | | | \ / | | | * * | 419 | * * | | | \/ | | | * * | 420 | * ****+---------+ | | | | +---------+**** * | 421 | ******|Surrogate|*************************|Surrogate|****** | 422 | | +---------+ | | Acquisition | | +-----*---+ | | 423 | +-------------+ | | +-------*-----+ | 424 \ / \ * / 425 --------------------- ---------*----------- 426 * 427 * Delivery 428 * 429 +------+ 430 | User | 431 | Agent| 432 +------+ 434 <==> interfaces inside the scope of CDNI 436 **** interfaces outside the scope of CDNI 438 Figure 1: CDNI Problem Area 440 3.1. Candidate CDNI Problem Area for IETF 442 Listed below are the four APIs required to interconnect a pair of 443 CDNs and that constitute the problem space that is proposed to be 444 addressed by a potential CDNI working group in the IETF. The use of 445 the term "API" is meant to encompass the protocol over which CDNI 446 data representations (e.g. CDNI Metadata records) are exchanged as 447 well as the specification of the data representations themselves 448 (i.e. what properties/fields each record contains, its structure, 449 etc.). While "interface" would be a more accurate term, the term 450 "API" is retained in this document because of its common use. 452 o CDNI Control API: This API allows the "CDNI Control" system in 453 interconnected CDNs to communicate. This API may support the 454 following: 455 * Allow bootstrapping of the other CDNI APIs (e.g. API address 456 discovery and establishment of security associations). 457 * Allow configuration of the other CDNI APIs (e.g. Upstream CDN 458 specifies information to be reported through the CDNI Logging 459 API). 460 * Allow the downstream CDN to communicate information about its 461 delivery capabilities, resources and policies. 462 * Allow bootstrapping of the interface between CDNs for content 463 acquisition (even if that interface itself is outside the scope 464 of the CDNI work). 465 o CDNI Request Routing API: This API allows the Request Routing 466 system in interconnected CDNs to communicate to ensure that an end 467 user request can be (re)directed from an upstream CDN to a 468 surrogate in the downstream CDN, in particular where selection 469 responsibilities may be split across CDNs (for example the 470 upstream CDN may be responsible for selecting the downstream CDN 471 while the downstream CDN may be responsible for selecting the 472 actual surrogate within that CDN). 473 o CDNI Metadata Signaling API: This API allows: 474 * The Distribution system in interconnected CDNs to communicate 475 to ensure CDNI Metadata can be exchanged across CDNs. See 476 Section 1.1 for definition and examples of CDNI Metadata. 477 * Limited control management of a downstream CDN by an upstream 478 CDN, for example to allow an upstream CDN to request that 479 content files and/or CDNI Metadata that it shared to be purged 480 from a downstream CDN. Support for content deletion from a CDN 481 is a key requirement for some Content Service Providers in 482 order, amongst other use cases for content deletion, to support 483 the content rights agreements they have negotiated. Today's 484 CDNs use proprietary control interfaces to enable CSPs to 485 remove content cached in the CDN and therefore there is a need 486 to have a similar but standardised content deletion capability 487 between interconnected CDNs. 489 o CDNI Logging API: This API allows the Logging system in 490 interconnected CDNs to communicate the relevant activity logs in 491 order to allow log consuming applications to operate in a multi- 492 CDN environments. For example, an upstream CDN may collect 493 delivery logs from a downstream CDN in order to perform 494 consolidated charging of the CSP or for settlement purposes across 495 CDNs. Similarly, an upstream CDN may collect delivery logs from a 496 downstream CDN in order to provide consolidated reporting and 497 monitoring to the CSP. 499 Note that the actual grouping of functionalities under these four 500 APIs is considered tentative at this stage and may be changed after 501 further study (e.g. some subset of functionality be moved from one 502 API into another). 504 The above list covers a significant potential problem space, in part 505 because in order to interconnect two CDNs there are several 'touch 506 points' that require standardization. However, it is expected that 507 the CDNI APIs need not be defined from scratch and instead can very 508 significantly reuse or leverage existing protocols: this is discussed 509 further in Section 4. Also, it is expected that the items above will 510 be prioritized so that the CDNI Working Group can focus (at least 511 initially) on the most esssential and urgent work: this is discussed 512 further in Section 5. 514 3.2. Non-Goals for IETF 516 Listed below are aspects of content delivery that the authors propose 517 be kept outside of the scope of a potential CDNI working group: 518 o The interface between Content Service Provider and the 519 Authoritative CDN (i.e. the upstream CDN contracted by the CSP for 520 delivery by this CDN or by its downstream CDNs). 521 o The delivery interface between the delivering CDN surrogate and 522 the User Agent, such as streaming protocols. 523 o The content acquisition interface between CDNs (i.e. the data 524 plane interface for actual delivery of a piece of content from one 525 CDN to the other). This is expected to use existing protocols 526 such as HTTP or protocols defined in other forums for content 527 acquisition between an origin server and a CDN (e.g. HTTP-based 528 C2 reference point of ATIS IIF CoD). The CDN Interconnection 529 solution may only concern itself with the agreement/negotiation 530 aspects of which content acquisition protocol is to be used 531 between two interconnected CDNs in view of facilitating 532 interoperability. 533 o End User/User Agent Authentication. End User/User Agent 534 authentication and authorization are the responsibility of the 535 Content Service Provider. 537 o Content preparation, including encoding and transcoding. The CDNI 538 architecture aims at allowing distribution across interconnected 539 CDNs of content treated as opaque objects. Interpretation and 540 processing of the objects, as well as optimized delivery of these 541 objects by the surrogate to the end user are outside the scope of 542 CDNI. 543 o Digital Rights Management (DRM). DRM is an end-to-end issue 544 between a content protection system and the User Agent. 545 o Applications consuming CDNI logs (e.g. charging, analytics, 546 reporting,...). 547 o Internal CDN Protocols. i.e. protocols within one CDN. 548 o Scalability of individual CDNs. While scalability of the CDNI 549 protocols/approach is in scope, how an individual CDN scales is 550 out of scope. 551 o Actual algorithms for selection of CDNs or Surrogates by Request 552 Routing systems (however, some specific parameters required as 553 input to these algorithms may be in scope when they need to be 554 communicated across CDNs). 555 o Surrogate algorithms. For example caching algorithms and content 556 acquistion methods are outside the scope of the CDNI work. 557 Content management (e.g. Content Deletion) as it relates to CDNI 558 content management policies, is in scope but the internal 559 algorithms used by a cache to determine when to no longer cache an 560 item of Content (in the absence of any specific metadata to the 561 contrary) is out of scope. 562 o Element management interfaces. 563 o Commercial, business and legal aspects related to the 564 interconnections of CDNs. 566 The third bullet in the list above places the acquisition of content 567 between interconnected CDNs as out of scope for CDNI and deserves 568 some additional explanation. The consequence of such a decision is 569 that a CDNI WG would be focussed on only defining the control plane 570 for CDNI; and the CDNI data plane (i.e. the acquisition & 571 distribution of the actual content objects) would not be addressed by 572 a CDNI WG. The rationale for such a decision is that CDNs today 573 typically already use standardized protocols such as HTTP, FTP, 574 rsync, etc. to acquire content from their CSP customers and it is 575 expected that the same protocols could be used for acquisition 576 between interconnected CDNs. Therefore the problem of content 577 acquisition is considered already solved and all that is required 578 from a CDNI WG is describing within the CDNI Metadata where to go and 579 which protocol to use to retrieve the content. 581 4. Design Approach for Realizing the CDNI APIs 583 This section expands on how CDNI APIs can reuse and leverage existing 584 protocols. First the "reuse instead of reinvent" design principle is 585 restated, then each API is discussed individually with example 586 candidate protocols that can be considered for reuse or leverage. 587 This discussion is not intended to pre-empt any WG decision as to the 588 most appropriate protocols, technologies and solutions to select to 589 solve CDNI but is intended as an illustration of the fact that these 590 APIs need not be created in a vacuum and that reuse or leverage of 591 existing protocols is likely possible. 593 4.1. Relationship to the OSI network model 595 The four CDNI APIs (CDNI Control API, CDNI Request Routing API, CDNI 596 Metadata API, CDNI Logging API) described in Section 3.1 within the 597 CDNI problem area are all control plane interfaces operating at the 598 application layer (Layer 7 in the OSI network model). Since it is 599 not expected that these APIs would exhibit unique session, transport 600 or network requirements as compared to the many other existing 601 applications in the Internet, it is expected that the CDNI APIs will 602 be defined on top of existing session, transport and network 603 protocols. 605 4.2. "Reuse Instead of Reinvent" Principle 607 Although a new application protocol could be designed specifically 608 for CDNI we assume that this is unnecessary and it is recommended 609 that existing application protocols be reused or leveraged (HTTP 610 [RFC2616], Atom Publishing Protocol [RFC5023], XMPP [RFC3920], for 611 example) to realize the CDNI APIs. 613 4.3. CDNI Request Routing API 615 The CDNI Request Routing API enables a Request Routing function in an 616 upstream CDN to query a Request Routing function in a downstream CDN 617 to determine if the downstream CDN is able (and willing) to accept 618 the delegated content request and to allow the downstream CDN to 619 control what the upstream Request Routing function should return to 620 the User Agent in the redirection message. 622 The CDNI Request Routing API needs to offer a mechanism for an 623 upstream CDN to issue a "Redirection Request" to a downstream CDN. 624 The Request Routing API needs to be able to support scenarios where 625 the initial User Agent request to the upstream CDN is received over 626 DNS as well as over a content specific application protocol (e.g. 627 HTTP, RTSP, RTMP, etc.). 629 Therefore a Redirection Request needs to contain information such as: 631 o The protocol (e.g. DNS, HTTP) over which the upstream CDN 632 received the initial User Agent request 633 o Additional details of the User Agent request that are required to 634 perform effective Request Routing by the Downstream CDN. For DNS 635 this would typically be the IP address of the DNS resolver making 636 the request on behalf of the User Agent. For requests received 637 over content specific application protocols the Redirection 638 Request could contain significantly more information related to 639 the original User Agent request but at a minimum would need to 640 contain the User Agent's IP address, the equivalent of the HTTP 641 Host header and the equivalent of the HTTP abs_path defined in 642 [RFC2616]. 644 It should be noted that, the CDNI architecture needs to consider that 645 a downstream CDN may receive requests from User Agents without first 646 receiving a Redirection Request from an upstream CDN, for example 647 because: 649 o User Agents (or DNS resolvers) may cache DNS or application 650 responses from Request Routers. 651 o Responses to Redirection Requests over the Request Routing API may 652 be cacheable. 653 o Some CDNs may want broader policies, e.g. CDN B agrees to always 654 take CDN A's delegated redirection requests, in which case the 655 necessary redirection details are exchanged out of band (of the 656 CDNI protocols), e.g. configured. 658 On receiving a Redirection Request, the downstream CDN will use the 659 information provided in the request to determine if it is able (and 660 willing) to accept the delegated content request and needs to return 661 the result of its decision to the upstream CDN. 663 Thus, a Redirection Response from the downstream CDN needs to contain 664 information such as: 666 o Status code indicating acceptance or rejection (possibly with 667 accompanying reasons). 668 o Information to allow redirection by the Upstream CDN. In the case 669 of DNS-based request routing, this is expected to include the 670 equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN 671 should return to the requesting DNS resolver. In the case of 672 application based request routing, this is expected to include the 673 application specific redirection response(s) to return to the 674 requesting User Agent. For HTTP requests from User Agents this 675 could be in the form of a URI that the upstream CDN could return 676 in a HTTP 302 response. 678 The CDNI Request Routing API is therefore a fairly straightforward 679 request/response protocol and could be implemented over any number of 680 request/response protocols. For example, it may be implemented as a 681 WebService using one of the common WebServices methodologies (XML- 682 RPC, HTTP query to a known URI, etc.). This removes the need for a 683 CDNI WG to define a new protocol for the request/response element of 684 the Request Routing API. Thus, a CDNI WG would be left only with the 685 task of specifying: 687 o The recommended request/response protocol to use along with any 688 additional semantics and procedures that are specific to the CDNI 689 Request Routing API (e.g. handling of malformed requests/ 690 responses). 691 o The syntax (i.e representation/encoding) of the redirection 692 requests and responses. 693 o The semantics (i.e. meaning and expected contents) of the 694 redirection requests and responses. 696 4.4. CDNI Metadata API 698 The CDNI Metadata API enables the Metadata function in a downstream 699 CDN to obtain CDNI Metadata from an upstream CDN so that the 700 downstream CDN can properly process and respond to: 702 o Redirection Requests received over the CDNI Request Routing API. 703 o Content Requests received directly from User Agents. 705 The CDNI Metadata API needs to offer a mechanism for an Upstream CDN 706 to: 707 o distribute/update/remove CDNI Metadata to a Downstream CDN 709 and/or to allow a downstream CDN to: 711 o Make direct requests for CDNI Metadata records where the 712 downstream CDN knows the identity of the Metadata record(s) it 713 requires. 714 o Search for CDNI Metadata records where the downstream CDN does not 715 know the specific Metadata record(s) it requires but does know 716 some property of the record it is searching for. For example, it 717 may know the value of the HTTP Host header received in a HTTP 718 request and it wants to obtain the CDNI Metadata for that host so 719 that it can determine how to further process the received HTTP 720 request. 722 The CDNI Metadata API is therefore similar to the CDNI Request 723 Routing API because it is a request/response protocol with the 724 potential addition that CDNI Metadata search may have more complex 725 semantics than a straightforward Request Routing redirection request. 726 Therefore, like the CDNI Request Routing API, the CDNI Metadata API 727 may be implemented as a WebService using one of the common 728 WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) 729 or possibly using other existing protocols such as XMPP [RFC3920]. 730 This removes the need for a CDNI WG to define a new protocol for the 731 request/response element of the Metadata API. 733 Thus, a CDNI WG would be left only with the task of specifying: 735 o The recommended request/response protocol to use along with any 736 additional semantics that are specific to the CDNI Metadata API 737 (e.g. handling of malformed requests/responses). 738 o The syntax (i.e representation/encoding) of the CDNI Metadata 739 records that will be exchanged over the API. 740 o The semantics (i.e. meaning and expected contents) of the 741 individual properties of a Metadata record. 742 o How the relationships between different CDNI Metadata records are 743 represented. 745 4.5. CDNI Logging API 747 The CDNI Logging API enables details of logs or events to be 748 exchanged between interconnected CDNs, where events could be: 750 o Log lines related to the delivery of content (similar to the log 751 lines recorded in a web server's access log). 752 o Real-time or near-real time events before, during or after content 753 delivery, e.g. content Start/Pause/Stop events, etc. 754 o Operations and diagnostic messages. 756 Within CDNs today, logs and events are used for a variety of purposes 757 in addition to real-time and non real-time diagnostics and auditing 758 by the CDN Operator and its customers. Specifically CDNs use logs to 759 generate Call Data Records (CDRs) for passing to billing and payment 760 systems and to real-time (and near real-time) analytics systems. 761 Such use cases place requirements on the CDNI Logging API to support 762 guaranteed and timely delivery of log messages between interconnected 763 CDNs. It may also be necessary to be able to prove the integrity of 764 received log messages. 766 Several protocols already exist that could potentially be used to 767 exchange CDNI logs between interconnected CDNs including SNMP Traps, 768 syslog, ftp, HTTP POST, etc. although it is likely that some of the 769 candidate protocols may not be well suited to meet all the 770 requirements of CDNI. For example SNMP traps pose scalability 771 concerns and SNMP does not support guaranteed delivery of Traps and 772 therefore could result in log records being lost and the consequent 773 CDRs and billing records for that content delivery not being produced 774 as well as that content delivery being invisible to any analytics 775 platforms. 777 Although it is not necessary to define a new protocol for exchanging 778 logs across the CDNI Logging API, a CDNI WG would still need to 779 specify: 781 o The recommended protocol to use. 782 o A default set of log fields and their syntax & semantics. Today 783 there is no standard set of common log fields across different 784 content delivery protocols and in some cases there is not even a 785 standard set of log field names and values for different 786 implementations of the same delivery protocol. 787 o A default set of events that trigger logs to be generated. 789 4.6. CDNI Control API 791 The CDNI Control API allows the "CDNI Control" system in 792 interconnected CDNs to communicate. The exact inter-CDN control 793 functionality required to be supported by the CDNI Control API is 794 less well defined than the other three CDNI interfaces at this time. 796 However, as discussed in Section 3.1, the CDNI Control API may be 797 required to support functionality similar to the following: 798 o Allow an upstream CDN and downstream CDN to establish, update or 799 terminate their CDNI interconnection. 800 o Allow bootstrapping of the other CDNI APIs (e.g. API address 801 discovery and establishment of security associations). 802 o Allow configuration of the other CDNI APIs (e.g. Upstream CDN 803 specifies information to be reported through the CDNI Logging 804 API). 805 o Allow the downstream CDN to communicate information about its 806 delivery capabilities, resources and policies. 807 o Allow bootstrapping of the interface between CDNs for content 808 acquisition (even if that interface itself is outside the scope of 809 the CDNI work). 810 It is expected that for the Control API also, existing protocols can 811 be reused or leveraged. Those will be considered once the 812 requirements for the Control API have been refined. 814 5. Prioritizing the CDNI Work 816 In order to manage the potential workload of a CDNI WG, it is 817 recommended that the work be prioritized in a "walk before you run" 818 approach. 820 The CDNI problem area can be categorized into different solution 821 scopes as follows: 823 o "Base CDNI" Scope: This solution scope comprises the solution 824 elements that can be considered as the 'minimum' needed to 825 actually deliver any content using interconnected CDNs. For 826 example, a base CDNI Request Routing API and a base CDNI Metadata 827 API belong to this scope because without them the upstream CDN is 828 unable to redirect User Agents to the downstream CDN and the 829 downstream CDN is unable to obtain the delivery policies and other 830 CDNI Metadata required to ingest and deliver the content. 831 o "Operationalized CDNI" Scope: This solution scope comprises the 832 solution elements that can be considered as the 'minimum' needed 833 to 'operationalize' CDN Interconnects. For example, the CDNI 834 Logging API and the base capabilities of the CDNI Control API 835 (e.g. content file/metadata deletion) belong to this scope because 836 without them CDN operators are required to substitute for them 837 either with manual processes or proprietary interfaces. 838 o "Enhanced CDNI" Scope: This solution scope comprises the solution 839 elements that can be classed as 'enhanced features'. For example, 840 the aspects of the CDNI Control API related to automatic 841 bootstrapping and configuration belong to this scope. 843 It is proposed that these solution scopes be addressed primarily 844 sequentially by a CDNI WG and that the initial charter be centered 845 around the "Base CDNI" scope. However there is obvious benefit from 846 having a solution for the "Base CDNI" scope that is amenable to 847 extension for support of the "Operational" scope and "Enhanced" 848 scope. Therefore it is proposed that the initial CDNI WG charter 849 also includes definition of (at least) the main requirements for the 850 "Operationalized CDNI" scope and "Enhanced CDNI" Scope, so those can 851 be kept in mind when defining the solution for the "Base CDNI" scope. 853 6. Gap Analysis of relevant Standardization and Research Activities 855 There are a number of other standards bodies and industry forums that 856 are working in areas related to CDN, and in some cases related to 857 CDNI. This section will first outline the key standardization 858 organizations undertaking related work, some related research 859 projects, and will then outline any potential overlap with the 860 proposed CDNI WG and any component that could potentially be reused 861 by CDNI . 863 6.1. Related standardization activities 865 6.1.1. IETF CDI Working Group (Concluded) 867 The Content Distribution Internetworking (CDI) Working Group was 868 formed in the IETF following a BoF in December 2000 and closed in mid 869 2003. 871 For convenience, here is an extract from the CDI WG charter 872 [CDI-Charter]: 874 " 876 o The goal of this working group is to define protocols to allow the 877 interoperation of separately-administered content networks. 878 o A content network is an architecture of network elements, arranged 879 for efficient delivery of digital content. Such content includes, 880 but is not limited to, web pages and images delivered via HTTP, 881 and streaming or continuous media which are controlled by RTSP. 882 o The working group will first define requirements for three modes 883 of content internetworking: interoperation of request-routing 884 systems, interoperation of distribution systems, and 885 interoperation of accounting systems. These requirements are 886 intended to lead to a follow-on effort to define protocols for 887 interoperation of these systems. 888 o In its initial form, the working group is not chartered to deliver 889 those protocols [...] 891 " 893 Thus, the CDI WG touched on the same problem space as the present 894 document. 896 The CDI WG published 3 Informational RFCs: 898 o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". 899 o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing 900 Mechanisms". 901 o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". 903 6.1.2. 3GPP 905 3GPP has specified a Progressive Download and Dynamic Adaptive 906 Streaming over HTTP [3GPP-DASH] based on a Media Presentation 907 Description (MPD) and Media Segmentation Format. The 3GPP DASH work 908 is focussed on the information required by a User Agent to obtain and 909 present (e.g. play) content to an end user. Such content could be 910 obtained from a CDN but that is independent of the DASH 911 specifications. 3GPP DASH could be a candidate for content 912 acquisition between CDNs in a CDN Interconnect environment. 914 6.1.3. ATIS IIF 916 ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS) 917 that develops requirements, standards, and specifications for IPTV. 919 ATIS IIF is developing the "IPTV Content on Demand (CoD) Service" 920 specification. This includes use of a CDN (referred to in ATIS IIF 921 CoD as the "Content Distribution and Delivery Functions") for support 922 of a Content on Demand (CoD) Service as part of a broader IPTV 923 service. However, this only covers the case of a managed IPTV 924 service (in particular where the CDN is administered by the service 925 provider) and does not cover the use, or interconnection, of multiple 926 CDNs. 928 6.1.4. Cable Labs 930 "Founded in 1988 by cable operating companies, Cable Television 931 Laboratories, Inc. (CableLabs) is a non-profit research and 932 development consortium that is dedicated to pursuing new cable 933 telecommunications technologies and to helping its cable operator 934 members integrate those technical advancements into their business 935 objectives." [CableLabs] 937 Cable Labs has defined specifications for CoD Content Metadata as 938 part of its VOD Metadata project. 940 6.1.5. ETSI MCD 942 ETSI MCD (Media Content Distribution) is the ETSI technical committee 943 "in charge of guiding and coordinating standardization work aiming at 944 the successful overall development of multimedia systems (television 945 and communication) responding to the present and future market 946 requests on media content distribution". 948 MCD created a specific work item on interconnection of heterogeneous 949 CDNs ("CDN Interconnection, use cases and requirements") in March 950 2010. MCD very recently created a working group to progress this 951 work item. However, no protocol level work has yet started in MCD 952 for CDN Interconnect. 954 6.1.6. ETSI TISPAN 956 ETSI TISPAN has published two sets of IPTV specifications, one of 957 which is based on IMS. In addition, TISPAN is about to complete the 958 specifications of a CDN architecture supporting delivery of various 959 content services such as time-shifted TV and VoD to TISPAN devices 960 (UEs) or regular PCs. The use cases allow for hierarchically and 961 geographically distributed CDN scenarios, along with multi-CDN 962 cooperation. As a result, the architecture contains reference points 963 to support interconnection of other TISPAN CDNs. The protocol 964 definition phase for the corresponding CDN architecture was kicked- 965 off at the end of 2010. 967 6.1.7. ITU-T 969 SG13 is developing standards related to the support of IPTV services 970 (i.e.. multimedia services such as television/VoD/audio/text/ 971 graphics/data delivered over IP-based managed networks). 973 ITU-T Recommendation Y.1910 [Y.1910] provides the description of the 974 IPTV functional architecture. This architecture includes functions 975 and interfaces for the distribution and delivery of content. This 976 architecture is aligned with the ATIS IIF architecture. 978 Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in 979 more detail the content delivery functional architecture. This 980 architecture allows CDN Interconnection: some interfaces (such as D3, 981 D4) at the control level allow relationships between different CDNs, 982 in the same domain or in different domains. Generic procedures are 983 described, but the choice of the protocols is open. 985 6.1.8. Open IPTV Forum (OIPF) 987 The Open IPTV Forum has developed an end-to-end solution to allow any 988 OIPF terminal to access enriched and personalized IPTV services 989 either in a managed or a non-managed network[OIPF-Overview]. Some 990 OIPF services (such as Network PVR) may be hosted in a CDN. 992 To that end, the Open IPTV Forum specification is made of 5 parts: 994 o Media Formats including HTTP Adaptive Streaming 995 o Content Metadata 996 o Protocols 997 o Terminal (Declarative or Procedural Application Environment) 998 o Authentication, Content Protection and Service Protection 1000 6.1.9. TV-Anytime Forum 1002 Version 1 of the TV-Anytime Forum specifications were published as 1003 ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line 1004 Services: Search, select, and rightful use of content on personal 1005 storage systems ("TV-Anytime")". It includes the specification of 1006 content metadata in XML schemas (ETSI TS 102 822-3) which define 1007 technical parameters for the description of CoD and Live contents. 1008 The specification is referenced by DVB and OIPF. 1010 The TV-anytime Forum was closed in 2005. 1012 6.1.10. SNIA 1014 The Storage Networking Industry Association (SNIA) is an association 1015 of producers and consumers of storage networking products whose goal 1016 is to further storage networking technology and applications. 1018 SNIA has published the Cloud Data Management Interface (CDMI) 1019 standard ([SNIA-CDMI]). 1021 "The Cloud Data Management Interface defines the functional interface 1022 that applications will use to create, retrieve, update and delete 1023 data elements from the Cloud. As part of this interface the client 1024 will be able to discover the capabilities of the cloud storage 1025 offering and use this interface to manage containers and the data 1026 that is placed in them. In addition, metadata can be set on 1027 containers and their contained data elements through this interface." 1029 6.2. Related Research Projects 1031 6.2.1. IRTF P2P Research Group 1033 Some information on CDN interconnection motivations and technical 1034 issues were presented in the P2P RG at IETF 77. The presentation can 1035 be found in [P2PRG-CDNI]. 1037 6.2.2. OCEAN 1039 OCEAN (http://www.ict-ocean.eu/) is an EU funded research project 1040 that started in February 2010 for 3 years. Some of its objectives 1041 are relevant to CDNI. It aims, among other things, at designing a 1042 new architectural framework for audiovisual content delivery over the 1043 Internet, defining public interfaces between its major building 1044 blocks in order to foster multi-vendor solutions and interconnection 1045 between Content Networks (the term "Content Networks" corresponds 1046 here to the definition introduced in [IETF RFC3466], which 1047 encompasses CDNs). 1049 OCEAN has not yet published any open specifications, nor common best 1050 practices, defining how to achieve such CDN interconnection. 1052 6.2.3. Eurescom P1955 1054 Eurescom P1955 was a 2010 research project involving a four European 1055 Network operators, which studied the interests and feasibility of 1056 interconnecting CDNs by firstly elaborating the main service models 1057 around CDN interconnection, as well as analyzing an adequate CDN 1058 interconnection technical architecture and framework, and finally by 1059 providing recommendations for telcos to implement CDN 1060 interconnection. The Eurescom P1955 project ended in July 2010. 1062 The authors are not aware of material discussing CDN interconnection 1063 protocols made publically available as a deliverable of this project. 1065 6.3. Gap Analysis 1067 A number of standards bodies have produced specifications related to 1068 CDNs, namely: 1070 o TISPAN has a dedicated specification for CDN. 1071 o OIPF and ATIS specify the architecture and the protocols of an 1072 IPTV solution. Although OIPF and ATIS specifications include the 1073 interaction with a CDN, the CDN specifications are coupled with 1074 their IPTV specifications. 1075 o 1076 o IETF CDN WG (now concluded) touched on the same problem space as 1077 the present document. However, in accordance with its initial 1078 charter, the CDI WG did not define any protocols or interfaces to 1079 actually enable CDN Interconnection and at that time (2003) there 1080 was not enough industry interest and real life requirements to 1081 justify rechartering the WG to conduct the corresponding protocol 1082 work. 1084 Although some of the specifications describe multi-CDN cooperation or 1085 include reference points for interconnecting CDNs, none of them 1086 specify in sufficient detail all the CDNI protocols/APIs and CDNI 1087 Metadata representations required to enable even a base level of CDN 1088 Interconnect functionality to be implemented. 1090 The following sections will summarize the existing work described in 1091 Section 6.1 against the CDNI problem space. 1093 6.3.1. Content Acquisition across CDNs and Delivery to End User (Data 1094 plane) 1096 A number of standards bodies have completed work in the areas of 1097 content acquisition interface between a CSP and a CDN, as well as as 1098 on the delivery interface between the surrogate and the User Agent. 1099 Some of this work is summarized below. 1101 TISPAN, OIPF and ATIS have specified IPTV and/or CoD services, 1102 including the data plane aspects (typically different flavors of RTP/ 1103 RTCP and HTTP) to obtain content and deliver it to User Agents. For 1104 example, : 1105 o The OIPF data plane includes both RTP and HTTP flavors (HTTP 1106 progressive download, HTTP Adaptive streaming [3GPP-DASH],...). 1108 o ATIS specification "IPTV Content on Demand (CoD) Service" [REF] 1109 defines a reference point (C2) and the corresponding HTTP-based 1110 data plane protocol for content acquisition between an 1111 authoritative origin server and the CDN. 1112 While these protocols have not been explicitly specified for content 1113 acquisition across CDNs, they are suitable (in addition to others 1114 such as standard HTTP) for content acquisition between CDNs in a CDN 1115 Interconnect environment. Therefore for the purpose of a CDNI WG 1116 there are already multiple existing data plane protocols that can be 1117 used for content acquisition across CDNs. 1119 Similarly, there are multiple existing standards (e.g. OIPTF data 1120 plane mentioned above, HTTP adaptive streaming [3GPP-DASH]) or public 1121 specifications (e.g. vendor specific HTTP Adaptive streaming 1122 specification) so that content delivery is considered already solved 1123 (or at least sufficiently addressed in other forums). 1125 Thus, specificatio of the content acquisition interface between CDNs 1126 and the delivery interface between the surrogate and the User Agent 1127 are out of scope for CDNI. CDNI may only concern itself with the 1128 negotiation/selection aspects of the acquisition protocol to be used 1129 in a CDN interonnect scenario. 1131 6.3.2. CDNI Metadata 1133 Cable Labs, ITU, OIPF and TV-Anytime have work items dedicated to the 1134 specification of content metadata: 1136 o Cable Labs has defined specifications for CoD Content Metadata as 1137 part of its VOD Metadata project. "The VOD Metadata project is a 1138 cable television industry and cross-industry-wide effort to 1139 specify the metadata and interfaces for distribution of video-on- 1140 demand (VOD) material from multiple content providers to cable 1141 operators." [CableLabs-Metadata]. However, while the CableLabs 1142 work specifies an interface between a content provider and a 1143 service provider running a CDN, it does not include an interface 1144 that could be used between CDNs. 1145 o ITU Study Group 16 has started work on a number of draft 1146 Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA, 1147 HSTP.IPTV-UMCI) specifying metadata for content distribution in 1148 IPTV services. 1149 o An Open IPTV Terminal receives the technical description of the 1150 content distribution from the OIPF IPTV platform before receiving 1151 any content. The Content distribution metadata is sent in the 1152 format of a TV-Anytime XSD including tags to describes the 1153 location and program type (on demand or Live) as well as 1154 describing the time availability of the on demand and live 1155 content. 1157 However the specifications outlined above do not include metadata 1158 specific to the distribution of content within a CDN or between 1159 interconnected CDNs, for example geo-blocking information, 1160 availability windows, access control mechanisms to be enforced by the 1161 surrogate, how to map an incoming content request to a file on the 1162 origin server or acquire it from the upstream CDN etc. 1164 The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can 1165 be associated with data that is stored by a cloud storage provider. 1166 While the metadata currently defined do not match the need of a CDN 1167 Interconnect solution, it is worth considering CDMI as one of the 1168 existing pieces of work that may potentially be leveraged for the 1169 CDNI Metadata API (e.g by extending the CDMI metadata to address more 1170 specific CDNI needs). 1172 7. Relationship to relevant IETF Working Groups 1174 7.1. ALTO 1176 As stated in the ALTO Working Group charter [ALTO-Charter]: 1178 "The Working Group will design and specify an Application-Layer 1179 Traffic Optimization (ALTO) service that will provide applications 1180 with information to perform better-than-random initial peer 1181 selection. ALTO services may take different approaches at balancing 1182 factors such as maximum bandwidth, minimum cross-domain traffic, 1183 lowest cost to the user, etc. The WG will consider the needs of 1184 BitTorrent, tracker-less P2P, and other applications, such as content 1185 delivery networks (CDN) and mirror selection." 1187 In particular, the ALTO service can be used by a CDN Request Routing 1188 system to improve its selection of a CDN surrogate to serve a 1189 particular User Agent request (or to serve a request from another 1190 surrogate). See [I-D.penno-alto-cdn] for a detailed discussion on 1191 how CDN Request Routing can be used as an integration point of ALTO 1192 into CDNs. It is possible that the ALTO service could be used in the 1193 same manner in a multi-CDN environment based on CDN Interconnect. 1194 For example, an upstream CDN may take advantage of the ALTO service 1195 in its decision for selecting a downstream CDN to which a user 1196 request should be delegated. 1198 However, the work of ALTO is complementary to and does not overlap 1199 with the work proposed in this document because the integration 1200 between ALTO and a CDN would fall under "algorithms for selection of 1201 CDN or Surrogate by Request-Routing systems" in Section 3.2 and is 1202 therefore out of scope for a CDNI WG. One area for further study is 1203 whether additional information should be provided by an ALTO service 1204 to facilitate CDNI CDN selection. 1206 7.2. DECADE 1208 The DECADE Working Group [DECADE-Charter] is addressing the problem 1209 of reducing traffic on the last-mile uplink, as well as backbone and 1210 transit links caused by P2P streaming and file sharing applications. 1211 It addresses the problem by enabling an application endpoint to make 1212 content available from an in-network storage service and by enabling 1213 other application endpoints to retrieve the content from there. 1215 Exchanging data through the in-network storage service in this 1216 manner, instead of through direct communication, provides significant 1217 gain where: 1219 o The network capacity/bandwidth from in-network storage service to 1220 application endpoint significantly exceeds the capacity/bandwidth 1221 from application endpoint to application endpoint (e.g. because of 1222 an end-user uplink bottleneck); and 1223 o Where the content is to be accessed by multiple instances of 1224 application endpoints (e.g. as is typically the case for P2P 1225 applications). 1227 While, as is the case for any other data distribution application, 1228 the DECADE architecture and mechanisms could potentially be used for 1229 exchange of CDNI control plane information via an in-network-storage 1230 service (as opposed to directly between the entities terminating the 1231 CDNI APIs in the neighbor CDNs), we observe that: 1233 o CDNI would operate as a "Content Distribution Application" from 1234 the DECADE viewpoint (i.e. would operate on top of DECADE). 1235 o There does not seem to be obvious benefits in integrating the 1236 DECADE control plane responsible for signaling information 1237 relating to control of the in-network storage service itself, and 1238 the CDNI control plane responsible for application-specific CDNI 1239 interactions (such as exchange of CDNI metadata, CDNI request 1240 redirection, transfer of CDNI logging information). 1241 o There would typically be limited benefits in making use of a 1242 DECADE in-network storage service because the CDNI APIs are 1243 expected to be terminated by a very small number of CDNI clients 1244 (if not one) in each CDN, and the CDNI clients are expected to 1245 benefit from high bandwidth/capacity when communicating directly 1246 to each other (at least as high as if they were communicating via 1247 an in-network storage server). 1249 The DECADE in-network storage architecture and mechanisms may 1250 theoretically be used for the acquisition of the content objects 1251 themselves between interconnected CDNs. It is not expected that this 1252 would have obvious benefits in typical situations where a content 1253 object is acquired only once from an Upstream CDN to a Downstream CDN 1254 (and then distributed as needed inside the Downstream CDN). But it 1255 might have benefits in some particular situations. Since the 1256 acquisition API between CDNs is outside the scope of the CDNI work, 1257 this question is left for further study. 1259 The DECADE in-network storage architecture and mechanisms may 1260 potentially also be used within a given CDN for the distribution of 1261 the content objects themselves among surrogates of that CDN. Since 1262 the CDNI work does not concern itself with operation within a CDN, 1263 this question is left for further study. 1265 Therefore, the work of DECADE may be complementary to but does not 1266 overlap with the CDNI work proposed in this document. 1268 7.3. PPSP 1270 As stated in the PPSP Working Group charter [PPSP-Charter]: 1272 "The Peer-to-Peer Streaming Protocol (PPSP) working group develops 1273 two signaling and control protocols for a peer-to-peer (P2P) 1274 streaming system for transmitting live and time-shifted media content 1275 with near real-time delivery requirements." and "The PPSP WG designs 1276 a protocol for signaling and control between trackers and peers (the 1277 PPSP "tracker protocol") and a signaling and control protocol for 1278 communication among the peers (the PPSP "peer protocol"). The two 1279 protocols enable peers to receive streaming data within the time 1280 constraints required by specific content items." 1282 Therefore PPSP is concerned with the distribution of the streamed 1283 content itself along with the necessary signaling and control 1284 required to distribute the content. As such, it could potentially be 1285 used for the acquisition of streamed content across interconnected 1286 CDNs. But since the acquisition API is outside the scope of the work 1287 proposed for CDNI, we leave this for further study. Also, because of 1288 its streaming nature, PPSP is not seen as applicable to the 1289 distribution and control of the CDNI control plane and CDNI data 1290 representations. 1292 Therefore, the work of PPSP may be complementary to but does not 1293 overlap with the work proposed in this document for CDNI. 1295 8. IANA Considerations 1297 This document makes no request of IANA. 1299 Note to RFC Editor: this section may be removed on publication as an 1300 RFC. 1302 9. Security Considerations 1304 Distribution of content by a CDN comes with a range of security 1305 considerations such as how to enforce control of access to the 1306 content by users in line with the CSP policy. These security aspects 1307 are already dealt with by CDN Providers and CSPs today in the context 1308 of standalone CDNs. However, interconnection of CDNs introduces a 1309 new set of security considerations by extending the trust model (i.e. 1310 the CSP "trusts" a CDN that "trusts" another CDN). 1312 Maintaining the security of the content itself, its associated 1313 metadata (including distribution and delivery policies) and the CDNs 1314 distributing and delivering it, are critical requirements for both 1315 CDN Providers and CSPs and any work on CDN Interconnection must 1316 provide sufficient mechanisms to maintain the security of the overall 1317 system of interconnected CDNs as well as the information (content, 1318 metadata, logs, etc) distributed and delivered through any CDN 1319 Interconnects. 1321 10. Acknowledgements 1323 The authors would like to thank Andre Beck, Mark Carlson, Bruce 1324 Davie, David Ferguson, Yiu Lee, Julien Maisonneuve, Emile Stephan and 1325 Mahesh Viveganandhan for their review comments and contributions to 1326 the text. 1328 11. References 1330 11.1. Normative References 1332 [I-D.bertrand-cdni-use-cases] 1333 Bertrand, G. and E. Stephan, "Use Cases for Content 1334 Distribution Network Interconnection", 1335 draft-bertrand-cdni-use-cases-00 (work in progress), 1336 January 2011. 1338 [I-D.watson-cdni-use-cases] 1339 Watson, G., "CDN Interconnect Use Cases", 1340 draft-watson-cdni-use-cases-00 (work in progress), 1341 January 2011. 1343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1344 Requirement Levels", BCP 14, RFC 2119, March 1997. 1346 11.2. Informative References 1348 [3GPP-DASH] 1349 ""Progressive Download and Dynamic Adaptive Streaming over 1350 HTTP" http://www.3gpp.org/ftp/Specs/html-info/26.234.htm". 1352 [ALTO-Charter] 1353 "IETF ALTO WG Charter 1354 (http://datatracker.ietf.org/wg/alto/charter/)". 1356 [ATIS] "ATIS (http://www.atis.org/)". 1358 [CDI-Charter] 1359 "IETF CDI WG Charter 1360 (http://www.ietf.org/wg/concluded/cdi)". 1362 [CableLabs] 1363 "CableLabs (http://www.cablelabs.com/about/)". 1365 [CableLabs-Metadata] 1366 "CableLabs VoD Metadata Project Primer 1367 (http://www.cablelabs.com/projects/metadata/primer/)". 1369 [DECADE-Charter] 1370 "IETF DECADE WG Charter 1371 (http://datatracker.ietf.org/wg/decade/charter/)". 1373 [I-D.penno-alto-cdn] 1374 Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R., 1375 and S. Previdi, "ALTO and Content Delivery Networks", 1376 draft-penno-alto-cdn-02 (work in progress), October 2010. 1378 [OIPF-Overview] 1379 "OIPF Release 2 Specification Volume 1 - Overview", 1380 September 2010. 1382 [P2PRG-CDNI] 1383 Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 1384 "Peering Peer-to-Peer" 1385 (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", 1386 March 2010. 1388 [PPSP-Charter] 1389 "IETF PPSP WG Charter 1390 (http://datatracker.ietf.org/wg/ppsp/charter/)". 1392 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1393 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1394 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1396 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1397 Replication and Caching Taxonomy", RFC 3040, January 2001. 1399 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 1400 for Content Internetworking (CDI)", RFC 3466, 1401 February 2003. 1403 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 1404 Content Network (CN) Request-Routing Mechanisms", 1405 RFC 3568, July 2003. 1407 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 1408 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 1410 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1411 Protocol (XMPP): Core", RFC 3920, October 2004. 1413 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 1414 Protocol", RFC 5023, October 2007. 1416 [SNIA-CDMI] 1417 "SNIA CDMI (http://www.snia.org/tech_activities/standards/ 1418 curr_standards/cdmi)". 1420 [TAXONOMY] 1421 Pathan, A., "A Taxonomy and Survey of Content Delivery 1422 Networks 1423 (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. 1425 [Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional 1426 architecture"", September 2008. 1428 [Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional 1429 architecture in NGN"", September 2010. 1431 Authors' Addresses 1433 Ben Niven-Jenkins 1434 Velocix (Alcatel-Lucent) 1435 326 Cambridge Science Park 1436 Milton Road, Cambridge CB4 0WG 1437 UK 1439 Email: ben@velocix.com 1441 Francois Le Faucheur 1442 Cisco Systems 1443 Greenside, 400 Avenue de Roumanille 1444 Sophia Antipolis 06410 1445 France 1447 Phone: +33 4 97 23 26 19 1448 Email: flefauch@cisco.com 1450 Nabil Bitar 1451 Verizon 1452 40 Sylvan Road 1453 Waltham, MA 02145 1454 USA 1456 Email: nabil.bitar@verizon.com