idnits 2.17.1 draft-ietf-cdni-requirements-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 30, 2014) is 3711 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4949' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RTMP' is defined on line 1052, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-07 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Leung, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational Y. Lee, Ed. 5 Expires: August 3, 2014 Comcast 6 Jan 30, 2014 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-17 11 Abstract 13 Content delivery is frequently provided by specifically architected 14 and provisioned Content Delivery Networks (CDNs). As a result of 15 significant growth in content delivered over IP networks, existing 16 CDN providers are scaling up their infrastructure. Many Network 17 Service Providers and Enterprise Service Providers are also deploying 18 their own CDNs. To deliver contents from the Content Service 19 Provider (CSP) to end users, the contents may traverse across 20 multiple CDNs. This creates a need for interconnecting (previously) 21 standalone CDNs so that they can collectively act as a single 22 delivery platform from the CSP to the end users. 24 The goal of the present document is to outline the requirements for 25 the solution and interfaces to be specified by the CDNI working 26 group. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 3, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 65 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 7 66 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 8 67 5. CDNI Request Routing Redirection Interface Requirements . . . 11 68 6. CDNI Footprint & Capabilities Advertisement Interface 69 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15 71 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 19 72 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 79 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 82 1. Introduction 84 The volume of video and multimedia content delivered over the 85 Internet is rapidly increasing and expected to continue doing so in 86 the future. In the face of this growth, Content Delivery Networks 87 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 88 content, improved quality of experience for end users, and increased 89 robustness of delivery. For these reasons CDNs are frequently used 90 for large-scale content delivery. As a result of the significant 91 growth in content delivered over IP networks, existing CDN providers 92 are scaling up their infrastructure and many Network Service 93 Providers and Enterprise Service Providers are deploying their own 94 CDNs. Subject to the policy of the Content Service Provider (CSP), 95 it is generally desirable that a given item of content can be 96 delivered to an end user regardless of that end user's location or 97 attachment network. This creates a need for interconnecting 98 (previously) standalone CDNs so they can interoperate and 99 collectively behave as a single delivery infrastructure. The Content 100 Distribution Network Interconnection (CDNI) working group has been 101 chartered to develop an interoperable and scalable solution for such 102 CDN interconnections. 104 CDNI Problem Statement [RFC6707] outlines the problem area that the 105 CDNI working group is chartered to address. Use Cases for CDNI 106 [RFC6770] discusses the use cases for CDN Interconnection. Framework 107 for CDN Interconnection [I-D.ietf-cdni-framework] discusses the 108 technology framework for the CDNI solution and interfaces. 110 The goal of the present document is to document the requirements for 111 the CDNI solution and interfaces. In order to meet the timelines 112 defined in the working group charter, the present document 113 categorizes the CDNI requirements as "High Priority", "Medium 114 Priority", and "Low Priority". 116 1.1. Terminology 118 This document uses the terminology defined in [RFC6707]. In 119 addition, the key words "High Priority", "Medium Priority" and "Low 120 Priority" in this document are to be interpreted in the following 121 way: 123 o "High Priority": When a requirement is tagged as "{HIGH}", it is 124 considered by the working group as an essential function for CDNI 125 and necessary to a deployable solution. This requirement has to 126 be met even if it causes a delay in the delivery by the working 127 group of a deployable solution. 129 o "Medium Priority": When a requirement is tagged as "{MED}", it is 130 considered by the working group as an important function for CDNI. 131 This requirement has to be met, unless it is established that 132 attempting to meet this requirement would cause a delay in the 133 delivery by the working group of a deployable solution. 135 o "Low Priority": When a requirement is tagged as "{LOW}", it is 136 considered by the working group as a useful function for CDNI. 137 The working group will attempt to meet this requirement as long as 138 it does not prevent meeting the "High Priority" and "Medium 139 Priority" requirements and does not cause a delay in the delivery 140 by the working group of a deployable solution. 142 2. CDNI Model and CDNI Interfaces 144 The "CDNI Expanded Model and CDNI Interfaces" figure and brief 145 descriptions of the CDNI interfaces in [I-D.ietf-cdni-framework] are 146 replicated below for convenience. That document contains the 147 definitive reference model and descriptions for the CDNI interfaces. 149 o CDNI Control interface (CI): Operations to bootstrap and 150 parameterize the other CDNI interfaces, as well as operations to 151 pre-position, revalidate, and purge both metadata and content. 152 The latter subset of operations is sometimes collectively called 153 the "Trigger interface." 155 o CDNI Request Routing interface: Operations to determine what CDN 156 (and optionally what surrogate within a CDN) is to serve end- 157 user's requests. This interface is actually a logical bundling of 158 two separate but related interfaces: 160 * CDNI Footprint & Capabilities Advertisement interface (FCI): 161 Asynchronous operations (as defined in 162 [I-D.ietf-cdni-framework]) to exchange routing information 163 (e.g., the network footprint and capabilities served by a given 164 CDN) that enables CDN selection for subsequent user requests; 165 and 167 * CDNI Request Routing Redirection interface (RI): Synchronous 168 operations (as defined in [I-D.ietf-cdni-framework]) to select 169 a delivery CDN (surrogate) for a given user request. 171 o CDNI Metadata interface (MI): Operations to communicate metadata 172 that governs how the content is delivered by interconnected CDNs. 173 Examples of CDNI metadata include geo-blocking directives, 174 availability windows, access control mechanisms, and purge 175 directives. It may include a combination of: 177 * Asynchronous operations to exchange metadata that govern 178 subsequent user requests for content; and 180 * Synchronous operations that govern behavior for a given user 181 request for content. 183 o CDNI Logging interface (LI): Operations that allow interconnected 184 CDNs to exchange relevant activity logs. It may include a 185 combination of: 187 * Real-time exchanges, suitable for runtime traffic monitoring; 188 and 190 * Offline exchanges, suitable for analytics and billing. 192 -------- 193 / \ 194 | CSP | 195 \ / 196 -------- 197 * 198 * 199 * /\ 200 * / \ 201 ---------------------- |CDNI| ---------------------- 202 / Upstream CDN \ | | / Downstream CDN \ 203 | +-------------+ | | CI | | +-------------+ | 204 |******* Control |<======|====|=======>| Control *******| 205 |* +------*----*-+ | | | | +-*----*------+ *| 206 |* * * | | | | * * *| 207 |* +------*------+ | | LI | | +------*------+ *| 208 |* ***** Logging |<======|====|=======>| Logging ***** *| 209 |* * +-*-----------+ | | | | +-----------*-+ * *| 210 |* * * * | | | | * * * *| 211 .....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*... 212 . |* * | |<======|====|=======>| | * *| . 213 . |* * | Req-Routing | | |FCI | | | Req-Routing | * *| . 214 . |* * *** |<======|====|=======>| |** * *| . 215 . |* * * +-------------+.| | | | +-------------+ * * *| . 216 . |* * * . | | | * * *| . 217 . |* * * +-------------+ |. | MI | | +-------------+ * * *| . 218 . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| . 219 . |* * * | | | . \ / | | | * * *| . 220 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 221 . |* * ***| +---------+| | ...Request......+---------+ |*** * *| . 222 . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| . 223 . |******* +---------+| | Acquisition | |+----------+ *******| . 224 . | +-------------+ | | +-------*-----+ | . 225 . \ / \ * / . 226 . ---------------------- ---------*------------ . 227 . * . 228 . * Delivery . 229 . * . 230 . +--*---+ . 231 ...............Request............................| User |..Request.. 232 | Agent| 233 +------+ 235 <==> interfaces inside the scope of CDNI 237 **** and .... interfaces outside the scope of CDNI 239 Figure 1: CDNI Expanded Model and CDNI Interfaces 241 3. Generic CDNI Requirements 243 This section identifies generic requirements independent of the 244 individual CDNI interfaces. Some of those are expected to affect 245 multiple or all interfaces. Management is an important aspect of CDN 246 operation. The fault and performance management is covered in CDNI 247 Logging interface requirements. The other types of management are 248 specific to the CDN provider and not needed for interoperability 249 between CDN providers. 251 GEN-1 {MED} Wherever possible, the CDNI interfaces should reuse or 252 leverage existing IETF protocols. 254 GEN-2 {HIGH} The CDNI solution shall not require a change, or an 255 upgrade, to the User Agent to benefit from content delivery 256 through interconnected CDNs. 258 GEN-3 {HIGH} The CDNI solution shall not require a change, or an 259 upgrade, to the Content Service Provider delivering content 260 through a single CDN, to benefit from content delivery 261 through interconnected CDNs. 263 GEN-4 {HIGH} The CDNI solution shall not depend on intra-CDN 264 information to be exposed to other CDNs for effective and 265 efficient delivery of the content. Examples of intra-CDN 266 information include surrogate topology, surrogate status, 267 cached content, etc. 269 GEN-5 {HIGH} The CDNI solution shall support CDN interconnection 270 when delivery to the User Agent is based on HTTP [RFC2616]. 271 (Note that while delivery and acquisition "data plane" 272 protocols are out of the CDNI solution scope, the CDNI 273 solution "control plane" protocols are expected to 274 participate in enabling, selecting or facilitating operations 275 of such acquisition and delivery protocols. Hence it is 276 useful to state requirements on the CDNI solution in terms of 277 specifying which acquisition and delivery protocols are to be 278 supported). 280 GEN-6 {HIGH} The CDNI solution shall support acquisition across 281 CDNs based on HTTP [RFC2616]. (The note above applies to 282 this requirement too) 284 GEN-7 {LOW} The CDNI solution may support delivery to the User 285 Agent based on protocols other than HTTP. 287 GEN-8 {LOW} The CDNI solution may support acquisition across CDNs 288 based on protocols other than HTTP. 290 GEN-9 {MED} The CDNI solution should support cascaded CDN 291 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 292 to an arbitrary number of levels beyond the first level. 294 GEN-10 {MED} The CDNI solution should support an arbitrary topology 295 of interconnected CDNs (i.e. the topology of interconnected 296 CDNs cannot be restricted to a tree, ring, star, etc.). 298 GEN-11 {HIGH} The CDNI solution shall prevent looping of any CDNI 299 information exchange. 301 GEN-12 {HIGH} When making use of third party reference, the CDNI 302 solution shall consider the potential issues associated with 303 the use of various format of third-party references (e.g. 304 NAT or IPv4/IPv6 translation potentially breaking third-party 305 references based on an IP addresses such as URI containing 306 IPv4 or IPv6 address literals, split DNS situations 307 potentially breaking third-party references based on DNS 308 fully qualified domain names) and wherever possible avoid, 309 minimize or mitigate the associated risks based on the 310 specifics of the environments where the reference is used 311 (e.g. likely or unlikely presence of NAT in the path). In 312 particular, this applies to situations where the CDNI 313 solution needs to construct and convey uniform resource 314 identifiers for directing/redirecting a content request, as 315 well as to situations where the CDNI solution needs to pass 316 on a third party reference (e.g. identify the IP address of a 317 User Agent) in order to allow another entity to make a more 318 informed decision (e.g. make a more informed request routing 319 decision by attempting to derive location information from 320 the third party reference). 322 GEN-13 {HIGH} The CDNI solution shall support HTTP Adaptive 323 Streaming content. 325 4. CDNI Control Interface Requirements 327 The primary purpose of the CDNI Control interface (CI) is to initiate 328 the interconnection across CDNs, bootstrap the other CDNI interfaces 329 and trigger actions into the Downstream CDN by the Upstream CDN (such 330 as delete object from caches or trigger pre-positioned content 331 acquisition). The working group attempts to align requirements with 332 the appropriate interface; however, solutions to these requirements 333 may apply to a different interface or another interface in addition 334 to the interface it is associated with. 336 CI-1 {HIGH} The CDNI Control interface shall allow the Upstream CDN 337 to request that the Downstream CDN, including downstream 338 cascaded CDNs, delete an object or set of objects and/or its 339 CDNI metadata from the CDN surrogates and any storage. Only 340 the object(s) and CDNI metadata that pertain to the requesting 341 Upstream CDN are allowed to be purged. 343 CI-2 {MED} The CDNI Control interface should allow for multiple 344 content items identified by a Content Collection ID to be 345 purged using a single Content Purge action. 347 CI-3 {MED} The CDNI Control interface should allow the Upstream CDN 348 to request that the Downstream CDN, including downstream 349 cascaded CDNs, mark an object or set of objects and/or its 350 CDNI metadata as "stale" and revalidate them before they are 351 delivered again. 353 CI-4 {HIGH} The CDNI Control interface shall allow the Downstream 354 CDN to report on the completion of these actions (by itself, 355 and including downstream cascaded CDNs), in a manner 356 appropriate for the action (e.g. synchronously or 357 asynchronously). The confirmation receipt should include a 358 success or failure indication. The failure indication and the 359 reason are included if the Downstream CDN cannot delete the 360 content in its storage. 362 CI-5 {MED} The CDNI Control interface should support initiation and 363 control by the Upstream CDN of pre-positioned CDNI metadata 364 acquisition by the Downstream CDN. 366 CI-6 {MED} The CDNI Control interface should support initiation and 367 control by the Upstream CDN of pre-positioned content 368 acquisition by the Downstream CDN. 370 CI-7 {LOW} The CDNI Control interface may allow a CDN to establish, 371 update and terminate a CDN interconnection with another CDN 372 whereby one CDN can act as a Downstream CDN for the other CDN 373 (that acts as an Upstream CDN). 375 CI-8 {LOW} The CDNI Control interface may allow control of the CDNI 376 interfaces between any two CDNs independently for each 377 direction (e.g. For the direction where CDN1 is the Upstream 378 CDN and CDN2 is the Downstream CDN, and for the direction 379 where CDN2 is the Upstream CDN and CDN1 is the Downstream 380 CDN). 382 CI-9 {LOW} The CDNI Control interface may allow bootstrapping of 383 the CDNI Request Routing interface. For example, this can 384 potentially include: 386 * negotiation of the request routing method (e.g. DNS vs 387 HTTP, if more than one method is specified) 389 * discovery of the CDNI Request Routing interface endpoints 391 * information necessary to establish secure communication 392 between the CDNI Request Routing interface endpoints. 394 CI-10 {LOW} The CDNI Control interface may allow bootstrapping of 395 the CDNI Metadata interface. This information could, for 396 example, include: 398 * discovery of the CDNI Metadata interface endpoints 400 * information necessary to establish secure communication 401 between the CDNI Metadata interface endpoints. 403 CI-11 {LOW} The CDNI Control interface may allow bootstrapping of 404 the Content Acquisition interface. This could, for example, 405 include exchange and negotiation of the Content Acquisition 406 methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, 407 ATIS C2[ATIS-0800042]). 409 CI-12 {LOW} The CDNI Control interface may allow bootstrapping of 410 the CDNI Logging interface. This information could, for 411 example, include: 413 * discovery of the CDNI Logging interface endpoints 415 * information necessary to establish secure communication 416 between the CDNI Logging interface endpoints 418 * negotiation/definition of the log file format and set of 419 fields to be exported through the logging protocol, with 420 some granularity (e.g. On a per content type basis). 422 * negotiation/definition of parameters related to 423 transaction logs export (e.g., export protocol, file 424 compression, export frequency, directory). 426 5. CDNI Request Routing Redirection Interface Requirements 428 The main function of the CDNI Request Routing Redirection interface 429 (RI) is to allow the Request-Routing systems in interconnected CDNs 430 to communicate to facilitate redirection of the request across CDNs. 432 RI-1 {HIGH} The CDNI Request Routing Redirection interface shall 433 support efficient request routing for small objects. This 434 may, for example, call for a mode of operation (e.g. DNS- 435 based request routing) where freshness and accuracy of CDN/ 436 Surrogate selection can be traded-off against reduced request 437 routing load (e.g. Via lighter-weight queries and caching of 438 request routing decisions). 440 RI-2 {HIGH} The CDNI Request Routing Redirection interface shall 441 support efficient request routing for large objects. This 442 may, for example, call for a mode of operation (e.g. HTTP- 443 based request routing) where freshness and accuracy of CDN/ 444 Surrogate selection justifies a per-request decision and a 445 per-request CDNI Request-Routing protocol call. 447 RI-3 {HIGH} The CDNI Request Routing Redirection interface shall 448 support recursive CDNI request routing. 450 RI-4 {HIGH} The CDNI Request Routing Redirection interface shall 451 support iterative CDNI request routing. 453 RI-5 {MED} In case of detection of a request redirection loop, the 454 CDNI Request Routing Redirection Interface's loop prevention 455 mechanism should allow redirection of the request on an 456 alternate CDN path (as opposed to the request not being 457 redirected at all). 459 RI-6 {MED} The CDNI Request Routing Redirection interface should 460 support a mechanism allowing enforcement of a limit on the 461 number of successive CDN redirections for a given request. 463 RI-7 {LOW} The CDNI Request Routing Redirection interface may 464 support a mechanism allowing an Upstream CDN to avoid 465 redirecting a request to a Downstream CDN if that is likely to 466 result in the total redirection time exceeding some limit. 468 RI-8 {HIGH} The CDNI Request Routing Redirection interface shall 469 allow the Upstream CDN to include, in the query to the 470 Downstream CDN, the necessary information to allow the 471 Downstream CDN to process the redirection query. This could, 472 for example, include: 474 * information from which the geographic region pertaining to 475 the IP address of the User Agent that originated the 476 request can be inferred (e.g. User Agent fully qualified 477 domain name in case of HTTP-based Request Routing, DNS 478 Proxy fully qualified domain name in case of DNS-based 479 Request Routing) 481 * requested resource information (e.g. Resource URI in case 482 of HTTP-based Request Routing, Resource hostname in case 483 of DNS-based Request Routing) 485 * additional available request information (e.g. request 486 headers in case of HTTP-based Request Routing). 488 RI-9 {LOW} The CDNI Request Routing Redirection interface may also 489 allow the Upstream CDN to convey information pointing to CDNI 490 metadata applicable (individually or through inheritance) to 491 the requested content. For illustration, the CDNI metadata 492 pointed to could potentially include metadata that is 493 applicable to any content, metadata that is applicable to a 494 content collection (to which the requested content belongs) 495 and/or metadata that is applicable individually to the 496 requested content. 498 RI-10 {HIGH} The CDNI Request Routing Redirection interface shall 499 allow the Downstream CDN to include the following information 500 in the response to the Upstream CDN: 502 * status code, in particular indicating acceptance or 503 rejection of request (e.g. Because the Downstream CDN is 504 unwilling or unable to serve the request). In case of 505 rejection, an error code is also to be provided, which 506 allows the Upstream CDN to react appropriately (e.g. 507 Select another Downstream CDN, or serve the request 508 itself) 510 * redirection information (e.g. Resource URI in case of 511 HTTP-based Request Routing, equivalent of a DNS record in 512 case of DNS-based Request Routing). 514 RI-11 {HIGH} The CDNI Request Routing Redirection interface shall 515 allow for per-chunk request routing of HTTP Adaptive Streaming 516 content. 518 RI-12 {LOW} The CDNI Request Routing Redirection interface may allow 519 the Upstream CDN to use the information conveyed by the 520 Downstream CDN during the Recursive Request Routing process to 521 rewrite an HTTP Adaptive Streaming manifest file. 523 RI-13 {LOW} The CDNI Request-Routing interface may allow the 524 Upstream CDN to re-compute the message digest or digital 525 signature over the invariant portion of the chunk URIs 526 embedded in the HTTP Adaptive Streaming manifest file. 528 RI-14 {MED} The CDNI Request Routing Redirection interface should 529 correlate the HTTP Adaptive Stream manifest file to the 530 related chunks referenced in the manifest file. 532 RI-15 {MED} The CDNI Request Routing Redirection interface should 533 allow for an efficient method of transferring request routing 534 information for multiple chunks from the Downstream CDN to the 535 Upstream CDN as part of the recursive request routing process. 537 6. CDNI Footprint & Capabilities Advertisement Interface Requirements 539 The main function of the CDNI Footprint & Capabilities Advertisement 540 interface (FCI) is to allow the Downstream CDN to advertise the 541 information regarding its footprint and capabilities to the Upstream 542 CDN. 544 FCI-1 {HIGH} The CDNI Footprint & Capabilities Advertisement 545 interface shall allow the Downstream CDN to communicate to the 546 Upstream CDN coarse information about the Downstream CDN 547 ability and/or willingness to handle requests from the 548 Upstream CDN. For example, this could potentially include a 549 binary signal ("Downstream CDN ready/not-ready to take 550 additional requests from Upstream CDN") to be used in case of 551 excessive load or failure condition in the Downstream CDN. 553 FCI-2 {MED} The CDNI Footprint & Capabilities Advertisement 554 interface should allow the Downstream CDN to communicate to 555 the Upstream CDN aggregate information to facilitate CDN 556 selection during request routing, such as Downstream CDN 557 capabilities, resources and affinities (i.e. Preferences or 558 cost). This information could, for example, include: 560 * supported content types and delivery protocols 562 * footprint (e.g. layer-3 coverage) 564 * a set of metrics/attributes (e.g. Streaming bandwidth, 565 storage resources, distribution and delivery priority) 567 * a set of affinities (e.g. Preferences, indication of 568 distribution/delivery fees) 570 * information to facilitate request redirection (e.g. 571 Reachability information of Downstream CDN Request Routing 572 system). 574 [Note: Some of this information - such as supported content 575 types and delivery protocols- may also potentially be taken 576 into account by the distribution system in the Upstream CDN 577 for pre-positioning of content and/or metadata in the 578 Downstream CDN in case of pre-positioned content acquisition 579 and/or pre-positioned CDNI metadata acquisition.] 581 FCI-3 {MED} In the case of cascaded redirection, the CDNI Footprint 582 & Capabilities Advertisement interface should allow the 583 Downstream CDN to also include in the information communicated 584 to the Upstream CDN, information on the capabilities, 585 resources and affinities of CDNs to which the Downstream CDN 586 may (in turn) redirect requests received by the Upstream CDN. 587 In that case, the CDNI Request-Routing interface shall prevent 588 looping of such information exchange. 590 FCI-4 {LOW} The CDNI Footprint & Capabilities Advertisement 591 interface may allow the Downstream CDN to communicate to the 592 Upstream CDN aggregate information on CDNI administrative 593 limits and policy. This information can be taken into account 594 by the Upstream CDN Request Routing system in its CDN 595 Selection decisions. This information could, for example, 596 include: 598 * maximum number of requests redirected by the Upstream CDN 599 to be served simultaneously by the Downstream CDN 601 * maximum aggregate volume of content (e.g. in Terabytes) to 602 be delivered by the Downstream CDN over a time period. 604 FCI-5 {MED} The CDNI Footprint & Capabilities Advertisement 605 interface should support advertisement of the following types 606 of capabilities: 608 * delivery protocol (e.g., HTTP vs. RTMP) 610 * acquisition protocol (for acquiring content from an 611 Upstream CDN) 613 * redirection mode (e.g., DNS Redirection vs. HTTP 614 Redirection) 616 * capabilities related to CDNI Logging (e.g., supported 617 logging mechanisms) 619 * capabilities related to CDNI Metadata (e.g., authorization 620 algorithms or support for proprietary vendor metadata) 622 FCI-6 {LOW} The CDNI Control interface may allow exchange and 623 negotiation of delivery authorization mechanisms to be 624 supported across the CDNs (e.g. URI signature based 625 validation). 627 FCI-7 {HIGH} The CDNI Footprint & Capabilities Advertisement 628 interface shall support extensible fields used to convey the 629 CDN capabilities and methods to indicate the footprint in the 630 advertisement from the Downstream CDN to the Upstream CDN. 632 7. CDNI Metadata Interface Requirements 634 The primary function of the CDNI Metadata interface (MI) is to allow 635 the Distribution system in interconnected CDNs to communicate to 636 ensure Content Distribution Metadata with inter-CDN scope can be 637 exchanged across CDNs. We observe that while the CDNI Metadata 638 Distribution protocol is currently discussed as a single "protocol", 639 further analysis will determine whether the corresponding 640 requirements are to be realized over a single interface and protocol, 641 or over multiple interfaces and protocols. For example, a subset of 642 the CDNI metadata might be conveyed in-band along with the actual 643 content acquisition across CDNs (e.g. content MD5 in HTTP header) 644 while another subset might require an out-of-band interface & 645 protocol (e.g. geo-blocking information). 647 MI-1 {HIGH} The CDNI Metadata interface shall allow the Upstream 648 CDN to provide the Downstream CDN with content distribution 649 metadata of inter-CDN scope. 651 MI-2 {HIGH} The CDNI Metadata interface shall support exchange of 652 CDNI metadata for both the dynamic content acquisition model 653 and the pre-positioning content acquisition model. 655 MI-3 {HIGH} The CDNI Metadata interface shall support a mode where 656 no, or a subset of, the Metadata is initially communicated to 657 the Downstream CDN along with information about how/where to 658 acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI 659 metadata acquisition). 661 MI-4 {MED} The CDNI Metadata interface should support a mode where 662 all the relevant Metadata is initially communicated to the 663 Downstream CDN (i.e. Pre-positioned CDNI metadata 664 acquisition). 666 MI-5 {HIGH} Whether in the pre-positioned content acquisition model 667 or in the dynamic content acquisition model, the CDNI Metadata 668 interface shall provide the necessary information to allow the 669 Downstream CDN to acquire the content from an upstream source 670 (e.g. Acquisition protocol and Uniform Resource Identifier in 671 Upstream CDN- or rules to construct this URI). 673 MI-6 {HIGH} The CDNI metadata shall allow signaling of one or more 674 upstream sources, where each upstream source can be in the 675 Upstream CDN, in another CDN, the CSP origin server or any 676 arbitrary source designated by the Upstream CDN. Note that 677 some upstream sources (e.g. the content origin server) may or 678 may not be willing to serve the content to the Downstream CDN, 679 if this policy is known to the Upstream CDN then it may omit 680 those sources when exchanging CDNI metadata. 682 MI-7 {HIGH} The CDNI Metadata interface (possibly in conjunction 683 with the CDNI Control interface) shall allow the Upstream CDN 684 to request addition and modification of CDNI Metadata into the 685 Downstream CDN. 687 MI-8 {HIGH} The CDNI Metadata interface (possibly in conjunction 688 with the CDNI Control interface) shall allow removal of 689 obsolete CDNI Metadata from the Downstream CDN (this could, 690 for example, be achieved via an explicit removal request from 691 the Upstream CDN or via expiration of a Time-To-Live 692 associated to the Metadata). 694 MI-9 {HIGH} The CDNI Metadata interface shall allow association of 695 CDNI Metadata at the granularity of individual object. This 696 is necessary to achieve fine-grain Metadata distribution at 697 the level of an individual object when necessary. 699 MI-10 {HIGH} The CDNI Metadata interface shall allow association of 700 CDNI Metadata at the granularity of an object set. This is 701 necessary to achieve scalable distribution of metadata when a 702 large number of objects share the same distribution policy. 704 MI-11 {HIGH} The CDNI Metadata interface shall support multiple 705 levels of inheritance with precedence to more specific 706 metadata. For example, the CDNI Metadata Distribution 707 protocol may support metadata that is applicable to any 708 content, metadata that is applicable to a content collection 709 and metadata that is applicable to an individual content where 710 content level metadata overrides content collection metadata 711 that overrides metadata for any content. 713 MI-12 {HIGH} The CDNI Metadata interface shall ensure that 714 conflicting metadata with overlapping scope are prevented or 715 deterministically handled. 717 MI-13 {HIGH} The CDNI Metadata interface shall allow signaling of 718 content distribution control policies. For example, this 719 could potentially include: 721 * geo-blocking information (i.e. Information defining 722 geographical areas where the content is to be made 723 available or blocked) 725 * availability windows (i.e. Information defining time 726 windows during which the content is to be made available 727 or blocked; expiration time may also be included to remove 728 content) 730 * delegation whitelist/blacklist (i.e. Information defining 731 which Downstream CDNs the content may/may not be delivered 732 through) 734 MI-14 {HIGH} The CDNI Metadata interface shall be able to exchange a 735 set of metadata elements with specified semantics (e.g. start 736 of time window, end of time window). 738 MI-15 {HIGH} The CDNI Metadata interface shall allow exchange of 739 opaque metadata element, whose semantic is not defined in CDNI 740 but established by private CDN agreement. 742 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 743 authorization checks and validation that are to be performed 744 by the surrogate before delivery. For example, this could 745 potentially include the need to validate information (e.g. 746 Expiry time, Client IP address) required for access 747 authorization. 749 MI-17 {MED} The CDNI Metadata interface should allow signaling of 750 CDNI-relevant surrogate cache behavior parameters. For 751 example, this could potentially include: 753 * control of whether the query string of HTTP URI is to be 754 ignored by surrogate cache 756 * enforcement of caching directives by Downstream CDN that 757 are different than the ones signalled in the HTTP headers 758 (e.g. "Expires" field) 760 * rate-pacing by Downstream CDN for content delivery (e.g. 761 Progressive Download) 763 MI-18 {HIGH} The CDNI Metadata interface shall provide indication of 764 related content (e.g. HTTP Adaptive Bit Rate chunks) by the 765 Content Collection ID (CCID) metadata. This could be used by 766 the Downstream CDN for operations on the group of content. 767 For example, this could potentially include: 769 * content acquisition for the entire set of files when one 770 piece of content is requested 772 * local file management and storage bundles all the files 773 for the content 775 * purging the entire set of files associated with the 776 content 778 * logging of the delivery of the content for the session 779 when at least one file in the set was delivered 781 MI-19 {MED} The CDNI Metadata interface should support an optional 782 mechanism allowing the Upstream CDN to indicate to the 783 Downstream CDN which CDNI Log fields are to be provided for 784 all content items, for specific sets of content items, or for 785 specific content items delivered using HTTP. A CDNI 786 implementation that does not support this optional CDNI 787 Metadata Distribution interface mechanism shall ignore this 788 log format indication and generate CDNI logging format for 789 HTTP Adaptive Streaming using the default set of CDNI Logging 790 fields. (Note: This function may be part of the CDNI Metadata 791 interface or the CDNI Control interface.) 793 MI-20 {MED} The CDNI Metadata interface should allow the Upstream 794 CDN to signal to the Downstream CDN the Content Collection ID 795 value for all, for specific sets of, or for specific content 796 items delivered using HTTP. Whenever the Downstream CDN is 797 instructed by the Upstream CDN to report the Content 798 Collection ID field in the log records, the Downstream CDN is 799 to use the value provided through the CDNI Metadata interface 800 for the corresponding content. Note the Session ID field 801 along with Content Collection ID may be used for HTTP Adaptive 802 Streaming content. 804 MI-21 {MED} The CDNI Metadata interface should allow the Upstream 805 CDN to signal to the Downstream CDN the Authorization Group ID 806 value for all the related HTTP Adaptive Streaming content 807 (i.e. manifest file and chunks). The authorization result of 808 a content (e.g. manifest file) is transferred over to related 809 content (e.g. chunks). 811 MI-22 {HIGH} The CDNI Metadata interface shall support extensible 812 format for CDNI metadata delivery from the Upstream CDN to the 813 Downstream CDN. 815 8. CDNI Logging Interface Requirements 817 This section identifies the requirements related to the CDNI Logging 818 interface (LI). We observe that while the CDNI Logging interface is 819 currently discussed as a single "protocol", further analysis will 820 determine whether the corresponding requirements are to be realized 821 over a single interface and protocol, or over multiple interfaces and 822 protocols. 824 LI-1 {HIGH} The CDNI logging architecture and interface shall 825 ensure reliable transfer of CDNI logging information across 826 CDNs. 828 LI-2 {HIGH} The CDNI Logging interface shall provide logging of 829 deliveries and incomplete deliveries to User Agents performed 830 by the Downstream CDN as a result of request redirection by 831 the Upstream CDN. 833 LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface 834 should allow the Downstream CDN to report to the Upstream CDN 835 logging for deliveries and incomplete deliveries performed by 836 the Downstream CDN itself as well as logging for deliveries 837 and incomplete deliveries performed by cascaded CDNs on behalf 838 of the Downstream CDN. 840 LI-4 {HIGH} The CDNI Logging interface shall support batch/offline 841 exchange of logging records. 843 LI-5 {MED} The CDNI Logging interface should also support an 844 additional mechanism taking into account the timing 845 constraints for some types of logging records (e.g. near-real 846 time for monitoring and analytics applications). 848 LI-6 {HIGH} The CDNI Logging interface shall define a log file 849 format and a set of fields to be exported for various CDNI 850 logging events. 852 LI-7 {HIGH} The CDNI Logging interface shall define a transport 853 mechanism to exchange CDNI Logging files. 855 LI-8 {MED} The CDNI Logging interface should allow a CDN to query 856 another CDN for relevant current logging records (e.g. For 857 on-demand access to real-time logging information). 859 LI-9 {LOW} The CDNI Logging interface may support aggregate/ 860 summarized logs (e.g. total bytes delivered for a content 861 regardless of individual User Agents to which it was 862 delivered). 864 LI-10 {LOW} The CDNI Logging interface may support logging of 865 performance data for deliveries to User Agents performed by 866 the Downstream CDN as a result of request redirection by the 867 Upstream CDN. Performance data may include various traffic 868 statistics (the specific parameters are to be determined). 869 The CDNI Logging interface may support the Upstream CDN to 870 indicate the nature and contents of the performance data to be 871 reported by the Downstream CDN. 873 LI-11 {MED} The CDNI Logging interface should support logging of 874 consumed resources (e.g. storage, bandwidth) to the Upstream 875 CDN for deliveries where content is stored by the Downstream 876 CDN for delivery to User Agents. The information logged may 877 include the type of storage (e.g., Origin, Intermediate, Edge, 878 Cache) as well as the amount of storage (e.g., total GB, GB 879 used, per time period, per content domain) all of which may 880 impact the cost of the services. 882 LI-12 {MED} In the case of cascaded CDNs, the CDNI Logging interface 883 should support the Downstream CDN to report consumed resources 884 (e.g. storage, bandwidth) to the Upstream CDN where content is 885 stored by the Downstream CDN itself as well as logging for 886 storage resources when content storage is performed by 887 cascaded CDNs on behalf of the Downstream CDN. 889 LI-13 {HIGH} The CDNI Logging interface shall support logging of 890 deleted objects from the Downstream CDN to the Upstream CDN as 891 a result of explicit delete requests on via the CDNI Control 892 interface from the Upstream CDN. 894 LI-14 {HIGH} The CDNI Logging interface shall support the exchange 895 of extensible log file formats to support proprietary 896 information fields. These information fields shall be agreed 897 upon ahead of time between the corresponding CDNs. 899 LI-15 {HIGH} The CDNI Logging interface shall allow a CDN to notify 900 another CDN about which CDNI logging information is available 901 for transfer and/or no longer available (e.g. it exceeded some 902 logging retention period or some logging retention volume). 904 LI-16 {MED} The CDNI Logging interface should support the ability 905 for the Downstream CDN to include the Content Collection ID 906 and Session ID fields in CDNI log entries generated for HTTP 907 Adaptive Streaming content. 909 LI-17 {MED} The CDNI Logging interface should provide privacy 910 protection by not disclosing information that can be used to 911 identify the user (e.g. method that anonymizes the IP address 912 carried in the logging field). The use of the privacy 913 protection mechanism is optional. 915 9. CDNI Security Requirements 917 This section identifies the requirements related to the CDNI 918 security. Some of these are expected to affect multiple or all 919 protocols. 921 SEC-1 {HIGH} All the CDNI interface shall support secure operation 922 over unsecured IP connectivity (e.g. The Internet). This 923 includes authentication, confidentiality, integrity protection 924 as well as protection against spoofing and replay. 926 SEC-2 {HIGH} The CDNI solution shall provide sufficient protection 927 against Denial of Service attacks. This includes protection 928 against spoofed delivery requests sent by User Agents directly 929 to a Downstream CDN attempting to appear as if they had been 930 redirected by a given Upstream CDN when they have not. 932 SEC-3 {MED} The CDNI solution should be able to ensure that for any 933 given request redirected to a Downstream CDN, the Downstream 934 CDN can determine the Upstream CDN that redirected the request 935 directly to the Downstream CDN (leading to that request being 936 served by that CDN, or being further redirected). 938 SEC-4 {MED} The CDNI solution should be able to ensure that for any 939 given transaction log generated by the Downstream CDN and 940 communicated to an Upstream CDN, the Upstream CDN can confirm 941 the transmitted log record corresponds to a request 942 redirection by the Upstream CDN. 944 SEC-5 {LOW} The CDNI solution may provide a mechanism allowing an 945 Upstream CDN that has credentials to acquire content from the 946 CSP origin server (or another CDN), to allow establishment of 947 credentials authorizing the Downstream CDN to acquire the 948 content from the CSP origin server (or the other CDN) (e.g. 949 In case the content cannot be acquired from the Upstream CDN). 951 10. IANA Considerations 953 This document makes no request of IANA. 955 Note to RFC Editor: this section may be removed on publication as an 956 RFC. 958 11. Security Considerations 960 This document discusses CDNI security requirements in Section 9. 962 12. Contributors 964 This document reflects the contributions from the following authors: 966 Francois Le Faucheur 968 Cisco Systems 970 flefauch@cisco.com 972 Mahesh Viveganandhan 974 Cisco Systems 976 mvittal@cisco.com 978 Grant Watson 980 Alcatel-Lucent (Velocix) 982 gwatson@velocix.com 984 13. Acknowledgements 986 This document leverages the earlier work of the IETF CDI working 987 group in particular as documented in [I-D.cain-request-routing-req], 989 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 991 The authors would like to thank Gilles Bertrand, Christophe Caillet, 992 Bruce Davie, Phil Eardley, Ben Niven-Jenkins, Agustin Schapira, Emile 993 Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana 994 Oprescu, and Spencer Dawkins for their input. Serge Manning along 995 with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and 996 Ramki Krishnan contributed to this document by addressing the 997 requirements of the ATIS Cloud Services Forum. 999 Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable 1000 inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI 1001 Logging interface, respectively. 1003 Stephen Farrell, Adrian Farrel, Benoit Claise, Sean Turner, Christer 1004 Holmberg, and Carlos Pignataro provided review comments that helped 1005 improve the document. 1007 14. References 1009 14.1. Normative References 1011 [I-D.ietf-cdni-framework] 1012 Peterson, L. and B. Davie, "Framework for CDN 1013 Interconnection", draft-ietf-cdni-framework-07 (work in 1014 progress), November 2013. 1016 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1017 Distribution Network Interconnection (CDNI) Problem 1018 Statement", RFC 6707, September 2012. 1020 14.2. Informative References 1022 [ATIS-0800042] 1023 "ATIS IPTV Content on Demand Service, 1024 https://www.atis.org/docstore/product.aspx?id=25670", 1025 December 2010. 1027 [I-D.amini-cdi-distribution-reqs] 1028 Amini, L., "Distribution Requirements for Content 1029 Internetworking", draft-amini-cdi-distribution-reqs-02 1030 (work in progress), November 2001. 1032 [I-D.cain-request-routing-req] 1033 Cain, B., "Request Routing Requirements for Content 1034 Internetworking", draft-cain-request-routing-req-03 (work 1035 in progress), November 2001. 1037 [I-D.gilletti-cdnp-aaa-reqs] 1038 "CDI AAA Requirements, 1039 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 1041 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1042 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1043 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1045 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1046 RFC 4949, August 2007. 1048 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1049 K., and G. Watson, "Use Cases for Content Delivery Network 1050 Interconnection", RFC 6770, November 2012. 1052 [RTMP] "Adobe's Real Time Messaging Protocol, http:// 1053 www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/ 1054 rtmp_specification_1.0.pdf", December 2012. 1056 Authors' Addresses 1058 Kent Leung (editor) 1059 Cisco Systems 1060 170 West Tasman Drive 1061 San Jose, CA 95134 1062 U.S.A. 1064 Phone: +1 408 526 5030 1065 Email: kleung@cisco.com 1067 Yiu Lee (editor) 1068 Comcast 1069 One Comcast Center 1070 Philadelphia, PA 19103 1071 U.S.A. 1073 Email: yiu_lee@cable.comcast.com