idnits 2.17.00 (12 Aug 2021) /tmp/idnits5064/draft-jenkins-cdni-problem-statement-00.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 (December 2, 2010) is 4187 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-penno-alto-cdn-02 -- 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 (==), 3 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: June 5, 2011 Cisco 6 N. Bitar 7 Verizon 8 December 2, 2010 10 Content Distribution Network Interconnection (CDNI) Problem Statement 11 draft-jenkins-cdni-problem-statement-00 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 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 June 5, 2011. 58 Copyright Notice 60 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 6 78 2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 6 79 3. Gap Analysis of relevant Standardization Activities . . . . . 7 80 3.1. IETF Concluded CDI Working Group . . . . . . . . . . . . . 7 81 3.2. IRTF P2P Research Group . . . . . . . . . . . . . . . . . 8 82 3.3. ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.3.1. TISPAN . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.3.2. MCD . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 3.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.5. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . . . 10 87 3.6. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 3.7. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 3.8. CableLabs VoD Metadata . . . . . . . . . . . . . . . . . . 11 90 4. CDN Interconnect Problem Area for IETF . . . . . . . . . . . . 11 91 4.1. Candidate CDNI Goals for IETF . . . . . . . . . . . . . . 13 92 4.2. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 14 93 5. Relationship to relevant IETF Working Group . . . . . . . . . 15 94 5.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 The volume of video and multimedia content delivered over the 106 Internet is rapidly increasing and expected to continue doing so in 107 the future. In the face of this growth, Content Delivery Networks 108 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 109 content, improved quality of experience for end users and increased 110 robustness of delivery. For these reasons CDNs are frequently used 111 for large-scale content delivery. As a result, existing CDN 112 providers are scaling up their infrastructure and many Network 113 Service Providers (NSPs) are deploying their own CDNs. It is 114 generally desirable that a given content item can be delivered to an 115 end user regardless of that user's location or attachment network. 116 This creates a requirement for interconnecting standalone CDNs so 117 they can interoperate as an open content delivery infrastructure for 118 the end-to-end delivery of content from Content Service Providers 119 (CSPs) to end users. However, no standards or open specifications 120 currently exist to facilitate such CDN interconnection. 122 The goal of this document is to outline the problem area for the IETF 123 with a view towards creating a working group. This working group 124 would work on interoperable and scalable solutions for CDN 125 interconnection. 127 1.1. Terminology 129 This document uses the following terms: 131 Content: Any form of digital data. One important form of Content 132 with additional constraints on Distribution and Delivery is 133 continuous media (i.e. where there is a timing relationship between 134 source and sink). 136 Metadata: Metadata in general is data about data. 138 Content Metata: this is metadata about content. It may vary in depth 139 from merely identifying the content (e.g. title or other information 140 to populate a program guide), to providing a complete index of 141 different scenes in a movie or providing business rules detailing how 142 the content may be displayed, copied, or sold and it can include 143 policies to control the distribution and delivery of the content. 145 Content Distribution Metadata: Content Distribution Metadata is the 146 subset of the Metadata pertaining to rules that control how the 147 content is to be distributed and delivered by CDNs. 149 User: The 'real' user of the system, typically a human but maybe some 150 combination of hardware and/or software emulating a human (e.g. for 151 automated quality monitoring etc.) 153 Network Service Provider (NSP): Provides network-based connectivity/ 154 services to Users. 156 Content Service Provider (CSP): Provides a Content Service to Users. 157 A CSP may own the content made available as part of the Content 158 Service, or may license content rights from another party. 160 Content Service: The service offered by a Content Service Provider. 161 The Content Service encompasses the complete service which may be 162 wider than just the delivery of items of Content, e.g. the Content 163 Service also includes any middleware, key distribution, program 164 guide, etc. which may not require any direct interaction with the 165 CDN. 167 Content Distribution Network (CDN) / Content Delivery Network (CDN): 168 A type of network in which the content network elements are arranged 169 for more effective delivery of content to User Agents. Typically a 170 CDN consists of a Request Routing system, a Distribution System and a 171 set of Surrogates. 173 CDN Provider: The service provider who operates a CDN. 175 CDN Interconnect (CDNI): The set of interfaces over which two or more 176 CDNs communicate with each other in order to achieve the delivery of 177 content to users by surrogates in one CDN (the downstream CDN) on 178 behalf of another CDN (the upstream CDN). 180 Over-the-top (OTT): A service, e.g. a CDN, operated over the Internet 181 rather than by a particular NSP. 183 Surrogate: A device/function that interacts with other elements of 184 the CDN for the control and distribution of Content within the CDN 185 and interacts with User Agents for the delivery of the Content. 187 Request Routing System: The function within a CDN responsible for 188 steering or directing a content request received directly from an end 189 user to a suitable Surrogate. 191 Distribution System: the function within a CDN responsible for 192 distributing Content Distribution Metadata as well as content inside 193 the CDN (e.g. down to the surrogates) 195 Delivery: the function within CDN surrogates responsible for 196 delivering a piece of content to the end user. For example, delivery 197 may be based on HTTP progressive download or HTTP adaptive streaming. 199 Logging System: the function within a CDN responsible for collecting 200 measurement and recording of distribution and delivery activities. 201 The information recorded by the logging system may be used for 202 various purposes including charging (e.g. of the CSP), analytics and 203 monitoring. 205 1.2. CDN Background 207 Readers are assumed to be familiar with the architecture, features 208 and operation of CDNs. For readers less familiar with the operation 209 of CDNs, the following resources may be useful: 211 o RFC 3040 [RFC3040] describes many of the component technologies 212 that are used in the construction of a CDN 213 o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs 214 o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the 215 IETF Content Delivery Internetworking (CDI) working group which 216 was closed in 2003. 218 Note: Some of the terms used in this document are similar to terms 219 used the above referenced documents. When reading this document 220 terms should be interpreted as having the definitions provided in 221 Section 1.1. 223 2. CDN Interconnect Use Cases 225 An increasing number of NSPs are deploying CDNs in order to deal 226 cost-effectively with the growing usage of on-demand video services 227 and other content delivery applications. 229 CDNs allow caching of content closer to the edge so that a given item 230 of content can be delivered by a CDN surrogate (i.e. a cache) to 231 multiple end users without transiting multiple times through the 232 network core (i.e from the content origin to the cache). This 233 contributes to bandwidth cost reductions for the NSP. CDNs also 234 enable replication of popular content across many surrogates, which 235 enables content to be served to large numbers of users concurrently. 236 This also helps dealing with situations such as flash crowds and 237 denial of service attacks. 239 The CDNs deployed by NSPs are not just restricted to the delivery of 240 content to support the Network Service Provider's own 'walled garden' 241 services, such as delivery of IPTV services to Set Top Boxes, but are 242 also used for delivery of content to other devices including PCs, 243 tablets, mobile phones etc. 245 Traditional CDNs have operated as over-the-top providers of digital 246 content distribution services, operating as an overlay on the 247 Internet. More recently, Network Service Providers have begun to 248 operate their own CDNs by deploying CDN devices within their network 249 infrastructure. 251 Some service providers operate over multiple geographies and federate 252 multiple affiliate NSPs. These NSPs typically operate independent 253 CDNs. As they evolve their services (e.g. for seamless support of 254 content services to nomadic users across affiliate NSPs) there is a 255 need for interconnection of these CDNs. However there are no open 256 specifications, nor common best practices, defining how to achieve 257 such CDN interconnection. 259 CSPs have a desire to be able to get (some of their) content to very 260 large number of users and/or over many/all geographies and/or with a 261 high quality of experience, all without having to maintain direct 262 business relationships with many different CDN providers. Some NSPs 263 are considering interconnecting their respective CDNs (as well as 264 possibly over-the-top CDNs) so that this collective infrastructure 265 can address the requirements of CSPs in a cost effective manner. In 266 particular, this would enable the CSPs to benefit from on-net 267 delivery (i.e. within the Network Service Provider's own network/CDN 268 footprint) whenever possible and off-net delivery otherwise without 269 requiring the CSPs having to maintain direct business relationships 270 with all the CDNs involved in the delivery. Again, for this 271 requirement, CDN operators (NSPs or over-the-top) are faced with a 272 lack of open specifications and best practices. 274 Finally, NSPs have often deployed CDNs as specialized cost-reduction 275 projects within the context of a particular service or environment, 276 some NSPs operate separate CDNs for separate services. For example, 277 there may be a CDN for managed IPTV service delivery, a CDN for 278 web-TV delivery and a CDN for video delivery to Mobile terminals. As 279 NSPs integrate their service portfolio, there is a need for 280 interconnecting these CDNs. Again, NSPs face the problem of lack of 281 open interfaces for CDN interconnection. 283 3. Gap Analysis of relevant Standardization Activities 285 3.1. IETF Concluded CDI Working Group 287 The Content Distribution Internetworking (CDI) Working Group was 288 formed in the IETF following a BoF in December 2000 and closed in mid 289 2003. 291 For convenience, here is an extract from the CDI WG charter 292 [CDI-Charter]: 294 " 296 o The goal of this working group is to define protocols to allow the 297 interoperation of separately-administered content networks. 298 o A content network is an architecture of network elements, arranged 299 for efficient delivery of digital content. Such content includes, 300 but is not limited to, web pages and images delivered via HTTP, 301 and streaming or continuous media which are controlled by RTSP. 302 o The working group will first define requirements for three modes 303 of content internetworking: interoperation of request-routing 304 systems, interoperation of distribution systems, and 305 interoperation of accounting systems. These requirements are 306 intended to lead to a follow-on effort to define protocols for 307 interoperation of these systems. 308 o In its initial form, the working group is not chartered to deliver 309 those protocols [...] 311 " 313 Thus, the CDI WG touched on the same problem space as the present 314 document. 316 The CDI WG published 3 Informational RFCs: 318 o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". 319 o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing 320 Mechanisms". 321 o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". 323 Although the market, design and requirements placed on CDNs has 324 changed since 2003, the RFCs above provide a reasonable starting 325 point and framework for discussing CDN Interconnect. 327 However, in accordance with its initial charter, the CDI WG did not 328 define any protocols or interfaces to actually enable CDN 329 Interconnection and at that time (2003) there was not enough industry 330 interest and real life requirements to justify rechartering the WG to 331 conduct the corresponding protocol work. 333 3.2. IRTF P2P Research Group 335 Some information on CDN interconnection motivations and technical 336 issues were presented in the P2P RG at IETF 77. The presentation can 337 be found in [P2PRG-CDNI]. 339 3.3. ETSI 341 ETSI is the European Telecommunications Standards Institute. ETSI 342 produces standards for Information and Communications Technologies 343 (ICT), including fixed, mobile, radio, converged, broadcast and 344 internet technologies. 346 3.3.1. TISPAN 348 TISPAN (Telecommunications and Internet converged Services and 349 Protocols for Advanced Networking) is an ETSI technical committee 350 creating Next Generation Networks (NGN) specifications. 352 TISPAN has published two IPTV specifications, one of which is based 353 on IMS. An extension of these specifications is being designed with 354 a CDN architecture supporting VoD for delivery to TISPAN devices 355 (UEs) or regular PCs. The use cases allow for hierarchically and 356 geographically distributed CDN scenarios, along with multi-CDN 357 cooperation. As a result, the architecture contains reference points 358 to support interconnection of other TISPAN CDNs. There is no intent 359 to support heterogeneous interconnection at this point. Also, this 360 effort is focusing on managed IPTV services. 362 The protocols phase has not yet started, and thus no protocols have 363 yet been defined. 365 3.3.2. MCD 367 MCD (Media Content Distribution) is the ETSI technical committee "in 368 charge of guiding and coordinating standardization work aiming at the 369 successful overall development of multimedia systems (television and 370 communication) responding to the present and future market requests 371 on media content distribution". 373 MCD created a specific work item on interconnection of heterogeneous 374 CDNs ("CDN Interconnection, use cases and requirements") in March 375 2010. However, no protocol level work has yet started in MCD for CDN 376 Interconnect. 378 3.4. ATIS IIF 380 ATIS ([ATIS]) is the Alliance for Telecommunications Industry 381 Solutions. 383 IIF is the IPTV Interoperability Forum (within ATIS) that develops 384 requirements, standards, and specifications for IPTV. 386 The IIF is developing the "IPTV Content on Demand (CoD) Service" 387 specification. This includes use of a CDN (referred to in ATIS IIF 388 CoD as the "Content Distribution and Delivery Functions") for support 389 of a Content on Demand (CoD) Service as part of a broader IPTV 390 service. However, this only covers the case of a managed IPTV 391 service (in particular where the CDN is administered by the IPTV 392 service provider) and does not cover the use, or interconnection, of 393 multiple CDNs. 395 The "IPTV Content on Demand (CoD) Service" specification defines a 396 reference point (C2) and the corresponding HTTP-based data plane 397 protocol for content acquisition between an authoritative origin 398 server and the CDN. While this protocol has not been explicitly 399 specified for content acquisition across CDNs, it could be a 400 candidate (in addition to others such as standard HTTP) for content 401 acquisition between CDNs in a CDN Interconnect environment. 403 3.5. Open IPTV Forum (OIPF) 405 "The Open IPTV Forum has developed an end-to-end solution to allow 406 any consumer end-device, compliant to the Open IPTV Forum 407 specifications, to access enriched and personalised IPTV services 408 either in a managed or a non-managed network. To that end, the Open 409 IPTV Forum focuses on standardising the user-to-network interface 410 (UNI) both for a managed and a non-managed network" [OIPF-Overview]. 412 OIPF has defined specifications for Content Metadata, however they 413 specify a definition for IPTV service related metadata and do not 414 include a metadata definition or interface that could be used between 415 CDNs. 417 3.6. ITU-T 419 Text to be added in a future version of this document. 421 3.7. OCEAN 423 OCEAN (http://www.ict-ocean.eu/) is an EU funded research project 424 that started in February 2010. Some of its objectives are relevant 425 to CDNI, for example "design a new content delivery framework" and 426 "foster multi-vendor solutions", however others are much more 427 implementation orientated, e.g. "self-learning caching algorithms" 428 and "media-aware congestion control mechanisms". 430 OCEAN has not yet defined any protocols for CDN Interconnection. 432 3.8. CableLabs VoD Metadata 434 "Founded in 1988 by cable operating companies, Cable Television 435 Laboratories, Inc. (CableLabs) is a non-profit research and 436 development consortium that is dedicated to pursuing new cable 437 telecommunications technologies and to helping its cable operator 438 members integrate those technical advancements into their business 439 objectives." [CableLabs] 441 Cable Labs has defined specifications for CoD Content Metadata as 442 part of its VOD Metadata project. "The VOD Metadata project is a 443 cable television industry and cross-industry-wide effort to specify 444 the metadata and interfaces for distribution of video-on-demand (VOD) 445 material from multiple content providers to cable operators." 446 [CableLabs-Metadata] 448 However, while the CableLabs work specifies an interface between a 449 content provider and a service provider running a CDN, it does not 450 include an interface that could be used between CDNs. 452 4. CDN Interconnect Problem Area for IETF 454 Interconnecting CDNs involves many different functions and components 455 being integrated to some degree. Only some of those require 456 standardization. Out of those, only some fit within the expertise 457 and charter of the IETF. The problem area proposed for IETF work is 458 illustrated in Figure 1. The candidate goals (and respectively the 459 non-goals) for IETF work on CDN Interconnection are discussed in 460 Section 4.1 (and respectively Section 4.2 ). 462 -------- 463 / \ 464 | CSP | 465 \ / 466 -------- 467 * 468 * 469 * /\ 470 * / \ 471 --------------------- |CDNI| --------------------- 472 / Upstream CDN \ | | / Downstream CDN \ 473 | +-------------+ | Control API | +-------------+ | 474 | |CDNI Control |<======|====|=======>| CDNI Control| | 475 | +------*-*-*--+ | | | | +-*-*-*-------+ | 476 | * * * | | | | * * * | 477 | +------*------+ | Logging API | +-----*-------+ | 478 | ****| Logging |<======|====|=======>| Logging |**** | 479 | * --------------+ | | | | +-------------+ * | 480 | * * * | | | | * * * | 481 | * +--------*----+ | Req-Routing API | +---*---------+ * | 482 | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | 483 | * * +-------------+ | | | | +-------------+ * * | 484 | * * * | | | | * * * | 485 | * * +----------*--+ | CD Metadata API | +-*-----------+ * * | 486 | * * |Distribution |<======|====|=======>| Distribution| * * | 487 | * * | | | \ / | | | * * | 488 | * * | | | \/ | | | * * | 489 | * ****+---------+ | | | | +---------+**** * | 490 | ******|Surrogate|*************************|Surrogate|****** | 491 | | +---------+ | | Acquisition | | +-----*---+ | | 492 | +-------------+ | | +-------*-----+ | 493 \ / \ * / 494 --------------------- ---------*----------- 495 * 496 * 497 +------+ 498 | user | 499 +------+ 501 <==> interfaces inside the scope of CDNI 503 **** interfaces outside the scope of CDNI 505 Figure 1: CDNI Problem Area 507 4.1. Candidate CDNI Goals for IETF 509 Listed below are parts of the problem space that are proposed to be 510 addressed by a potential CDNI working group in the IETF: 511 o Specification of a control plane architecture for CDN 512 Interconnect. 513 o Specification of the APIs and protocols required to Interconnect a 514 pair of CDNs (where a given CDN may support multiple interconnects 515 with different CDNs). This is expected to comprise (but possibly 516 grouped in a different manner): 517 * CDNI Control API: This API allows the "CDNI Control" system in 518 interconnected CDNs to communicate. This API may support the 519 following: 520 + allows an upstream CDN and downstream CDN to establish, 521 update or terminate their CDNI relationship 522 + allows bootstrapping of the other CDNI APIs (e.g. API 523 address discovery and establishment of security 524 associations) 525 + allows configuration of the other CDNI APIs (e.g. Upstream 526 CDN specifies information to be reported through the Logging 527 API) 528 + allows the downstream CDN to communicate information about 529 its delivery capabilities, resources and policies 530 + allows bootstrapping of the interface between CDNs for 531 content acquisition (even if that interface itself is 532 outside the scope of the CDNI work) 533 * Request-Routing API: This API allows the Request-Routing system 534 in interconnected CDNs to communicate to ensure that an end- 535 user request can be (re)directed from an upstream CDN to a 536 surrogate in the downstream CDN, in particular where selection 537 responsibilities may be split across CDNs (for example the 538 upstream CDN may be responsible for selecting the downstream 539 CDN while the downstream CDN may be responsible for selecting 540 the actual surrogate within that CDN). 541 * Content Distribution Metadata Signaling API: This API allows 542 the Distribution system in interconnected CDNs to communicate 543 to ensure content distribution metadata can be exchanged across 544 CDNs. For example, the distribution metadata information may 545 include information about desired distribution policy (e.g. 546 prepositioning vs dynamic acquisition) and about content access 547 policy (e.g. allowed/blocked time/geography, authorization 548 checks to be performed at delivery time). It may also contain 549 information about where/how to acquire the content. This may 550 also include content management (e.g. deletion of Content from 551 caches) across interconnected CDNs. It is expected that the 552 specification of this API will comprise (i) specification of a 553 schema for Content Distribution Metadata as well as (ii) 554 specification/selection of a signaling protocol (quite possibly 555 an existing IETF protocol) to signal the actual Content 556 Distribution Metadata encoded as per the schema. 557 * Logging API: This API allows the Logging system in 558 interconnected CDNs to communicate the relevant activity logs 559 in order to allow log consuming applications to operate in a 560 multi-CDN environments. For example, an upstream CDN may 561 collect delivery logs from a downstream CDN in order to perform 562 consolidated charging of the CSP. Similarly, an upstream CDN 563 may collect delivery logs from a downstream CDN in order to 564 provide consolidated reporting and monitoring to the CSP. 565 o Scalability of the CDNI protocols & approach. 567 4.2. Non-Goals for IETF 569 Listed below are aspects of content delivery that the authors propose 570 be kept outside of the scope of a potential CDNI working group: 571 o The interface between Content Service Provider and the 572 Authoritative CDN (i.e. the upstream CDN contracted by the CSP for 573 delivery by this CDN or by its downstream CDNs). 574 o The delivery interface between the delivering CDN surrogate and 575 the enduser, such as streaming protocols. 576 o The content acquisition interface between CDNs (i.e. the dataplane 577 interface for actual delivery of a piece of content from one CDN 578 to the other). This is expected to use existing protocols such as 579 HTTP or protocols defined in other forums for content acquisition 580 between an origin server and a CDN (e.g. HTTP-based C2 reference 581 point of ATIS IIF CoD). 582 o User Authentication. User authentication and authorization are 583 the responsibility of the Content Service Provider. 584 o Content preparation, including encoding and transcoding. The CDNI 585 architecture aims at allowing distribution across interconnected 586 CDNs of content treated as opaque objects. Interpretation and 587 processing of the objects, as well as optimised delivery of these 588 objects by the surrogate to the enduser are outside the scope of 589 CDNI. 590 o Digital Right Management (DRM). DRM is an end-to-end issue 591 between Origin and User-Agent. 592 o applications consuming CDNI logs (e.g. charging, analytics, 593 reporting,...) 594 o Internal CDN Protocols. i.e. protocols within one CDN. 595 o Scalability of individual CDNs. While scalability of the CDNI 596 protocols/approach is in scope, how an individual CDN scales is 597 out of scope. 598 o actual criteria and algorithms for selection of CDN or Surrogate 599 by Request-Routing systems. 600 o Surrogate algorithms - e.g. how to acquire content or cache 601 replacement algorithms. Content management (e.g. Content 602 Deletion) is in scope but the internal algorithms used by a cache 603 to determine when to no longer cache an item of Content (in the 604 absence of any specific metadata to the contrary) is out of scope. 605 o Element management interfaces 606 o commercial, business and legal aspects related to the 607 interconnections of CDNs. 609 5. Relationship to relevant IETF Working Group 611 5.1. ALTO 613 As stated in the ALTO Working Group charter [ALTO-Charter]: 615 "The Working Group will design and specify an Application-Layer 616 Traffic Optimization (ALTO) service that will provide applications 617 with information to perform better-than-random initial peer 618 selection. ALTO services may take different approaches at balancing 619 factors such as maximum bandwidth, minimum cross-domain traffic, 620 lowest cost to the user, etc. The WG will consider the needs of 621 BitTorrent, tracker-less P2P, and other applications, such as content 622 delivery networks (CDN) and mirror selection." 624 In particular, the ALTO service could be used by a CDN Request 625 Routing system to improve its selection of a CDN surrogate to serve a 626 particular user request. See [I-D.penno-alto-cdn] for a detailed 627 discussion on how CDN Request Routing can be used as an integration 628 point of ALTO into CDNs. It is possible that the ALTO service could 629 be used in the same manner in a multi-CDN environment based on CDN 630 Interconnect. For example, an upstream CDN may take advantage of the 631 ALTO service in its decision for selecting a downstream CDN to which 632 a user request should be delegated. 634 However, the work of ALTO is complementary to and does not overlap 635 with the work proposed in this document because the integration 636 between ALTO and a CDN would fall under "algorithms for selection of 637 CDN or Surrogate by Request-Routing systems" in Section 4.2 639 6. IANA Considerations 641 This document makes no request of IANA. 643 Note to RFC Editor: this section may be removed on publication as an 644 RFC. 646 7. Security Considerations 648 This document describes a problem faced by CDN Providers and does not 649 itself introduce any new security considerations. 651 However, maintaining the security of the content itself, its 652 associated metadata (including distribution and delivery policies) 653 and the CDNs distributing and delivering it are critical requirements 654 for both CDN Providers and their customers and any work on CDN 655 Interconnection must provide sufficient mechanisms to maintain the 656 security of the overall system of interconnected CDNs as well as the 657 information (content, metadata, logs, etc) distributed and delivered 658 through any CDN Interconnects. 660 8. Acknowledgements 662 The authors would like to thank David Ferguson, Julien Maisonneuve, 663 Mahesh Viveganandhan and Bruce Davie for their early review comments 664 and contributions to the text. 666 9. References 668 9.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 9.2. Informative References 675 [ALTO-Charter] 676 "IETF ALTO WG Charter 677 (http://datatracker.ietf.org/wg/alto/charter/)". 679 [ATIS] "ATIS (http://www.atis.org/)". 681 [CDI-Charter] 682 "IETF CDI WG Charter 683 (http://www.ietf.org/wg/concluded/cdi)". 685 [CableLabs] 686 "CableLabs (http://www.cablelabs.com/about/)". 688 [CableLabs-Metadata] 689 "CableLabs VoD Metadata Project Primer 690 (http://www.cablelabs.com/projects/metadata/primer/)". 692 [I-D.penno-alto-cdn] 693 Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R., 694 and S. Previdi, "ALTO and Content Delivery Networks", 695 draft-penno-alto-cdn-02 (work in progress), October 2010. 697 [OIPF-Overview] 698 "OIPF Release 2 Specification Volume 1 - Overview", 699 September 2010. 701 [P2PRG-CDNI] 702 Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 703 "Peering Peer-to-Peer" 704 (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", 705 March 2010. 707 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 708 Replication and Caching Taxonomy", RFC 3040, January 2001. 710 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 711 for Content Internetworking (CDI)", RFC 3466, 712 February 2003. 714 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 715 Content Network (CN) Request-Routing Mechanisms", 716 RFC 3568, July 2003. 718 [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content 719 Internetworking (CDI) Scenarios", RFC 3570, July 2003. 721 [TAXONOMY] 722 Pathan, A., "A Taxonomy and Survey of Content Delivery 723 Networks 724 (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. 726 Authors' Addresses 728 Ben Niven-Jenkins 729 Velocix (Alcatel-Lucent) 730 326 Cambridge Science Park 731 Milton Road, Cambridge CB4 0WG 732 UK 734 Email: ben@velocix.com 735 Francois Le Faucheur 736 Cisco Systems 737 Greenside, 400 Avenue de Roumanille 738 Sophia Antipolis 06410 739 France 741 Phone: +33 4 97 23 26 19 742 Email: flefauch@cisco.com 744 Nabil Bitar 745 Verizon 746 40 Sylvan Road 747 Waltham, MA 02145 748 USA 750 Email: nabil.bitar@verizon.com