idnits 2.17.1 draft-ietf-cdni-requirements-14.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 (Dec 24, 2013) is 3770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RTMP' is defined on line 1048, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-06 -- 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 (~~), 3 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: June 27, 2014 Comcast 6 Dec 24, 2013 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-14 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 June 27, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 23 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 delivery to the User 270 Agent based on HTTP [RFC2616]. (Note that while delivery and 271 acquisition "data plane" protocols are out of the CDNI 272 solution scope, the CDNI solution "control plane" protocols 273 are expected to participate in enabling, selecting or 274 facilitating operations of such acquisition and delivery 275 protocols. Hence it is useful to state requirements on the 276 CDNI solution in terms of specifying which acquisition and 277 delivery protocols are to be supported). 279 GEN-6 {HIGH} The CDNI solution shall support acquisition across 280 CDNs based on HTTP [RFC2616]. (The note above applies to 281 this requirement too) 283 GEN-7 {LOW} The CDNI solution may support delivery to the User 284 Agent based on protocols other than HTTP. 286 GEN-8 {LOW} The CDNI solution may support acquisition across CDNs 287 based on protocols other than HTTP. 289 GEN-9 {MED} The CDNI solution should support cascaded CDN 290 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 291 to an arbitrary number of levels beyond the first level. 293 GEN-10 {MED} The CDNI solution should support an arbitrary topology 294 of interconnected CDNs (i.e. the topology of interconnected 295 CDNs cannot be restricted to a tree, ring, star, etc.). 297 GEN-11 {HIGH} The CDNI solution shall prevent looping of any CDNI 298 information exchange. 300 GEN-12 {HIGH} When making use of third party reference, the CDNI 301 solution shall consider the potential issues associated with 302 the use of various format of third-party references (e.g. 303 NAT or IPv4/IPv6 translation potentially breaking third-party 304 references based on an IP addresses such as URI containing 305 IPv4 or IPv6 address litterals, split DNS situations 306 potentially breaking third-party references based on DNS 307 fully qualified domain names) and wherever possible avoid, 308 minimize or mitigate the associated risks based on the 309 specifics of the environments where the reference is used 310 (e.g. likely or unlikely presence of NAT in the path). In 311 particular, this applies to situations where the CDNI 312 solution needs to construct and convey uniform resource 313 identifiers for directing/redirecting a content request, as 314 well as to situations where the CDNI solution needs to pass 315 on a third party reference (e.g. to identify a User Agent) in 316 order to allow another entity to make a more informed 317 decision (e.g. make a more informed request routing decision 318 by attempting to derive location information from the third 319 party reference). 321 GEN-13 {HIGH} The CDNI solution shall support HTTP Adaptive 322 Streaming content. 324 4. CDNI Control Interface Requirements 326 The primary purpose of the CDNI Control interface (CI) is to initiate 327 the interconnection across CDNs, bootstrap the other CDNI interfaces 328 and trigger actions into the Downstream CDN by the Upstream CDN (such 329 as delete object from caches or trigger pre-positioned content 330 acquisition). The working group attempts to align requirements with 331 the appropriate interface; however, solutions to these requirements 332 may apply to a different interface or another interface in addition 333 to the interface it is associated with. 335 CI-1 {HIGH} The CDNI Control interface shall allow the Upstream CDN 336 to request that the Downstream CDN, including downstream 337 cascaded CDNs, delete an object or set of objects and/or its 338 CDNI metadata from the CDN surrogates and any storage. Only 339 the object(s) and CDNI metadata that pertain to the requesting 340 Upstream CDN are allowed to be purged. 342 CI-2 {MED} The CDNI Control interface should allow for multiple 343 content items identified by a Content Collection ID to be 344 purged using a single Content Purge action. 346 CI-3 {MED} The CDNI Control interface should allow the Upstream CDN 347 to request that the Downstream CDN, including downstream 348 cascaded CDNs, mark an object or set of objects and/or its 349 CDNI metadata as "stale" and revalidate them before they are 350 delivered again. 352 CI-4 {HIGH} The CDNI Control interface shall allow the Downstream 353 CDN to report on the completion of these actions (by itself, 354 and including downstream cascaded CDNs), in a manner 355 appropriate for the action (e.g. synchronously or 356 asynchronously). The confirmation receipt should include a 357 success or failure indication. The failure indication and the 358 reason are included if the Downstream CDN cannot delete the 359 content in its storage. 361 CI-5 {MED} The CDNI Control interface should support initiation and 362 control by the Upstream CDN of pre-positioned CDNI metadata 363 acquisition by the Downstream CDN. 365 CI-6 {MED} The CDNI Control interface should support initiation and 366 control by the Upstream CDN of pre-positioned content 367 acquisition by the Downstream CDN. 369 CI-7 {LOW} The CDNI Control interface may allow a CDN to establish, 370 update and terminate a CDN interconnection with another CDN 371 whereby one CDN can act as a Downstream CDN for the other CDN 372 (that acts as an Upstream CDN). 374 CI-8 {LOW} The CDNI Control interface may allow control of the CDNI 375 interfaces between any two CDNs independently for each 376 direction (e.g. For the direction where CDN1 is the Upstream 377 CDN and CDN2 is the Downstream CDN, and for the direction 378 where CDN2 is the Upstream CDN and CDN1 is the Downstream 379 CDN). 381 CI-9 {LOW} The CDNI Control interface may allow bootstrapping of 382 the CDNI Request Routing interface. For example, this can 383 potentially include: 385 * negotiation of the request routing method (e.g. DNS vs 386 HTTP, if more than one method is specified) 388 * discovery of the CDNI Request Routing interface endpoints 390 * information necessary to establish secure communication 391 between the CDNI Request Routing interface endpoints. 393 CI-10 {LOW} The CDNI Control interface may allow bootstrapping of 394 the CDNI Metadata interface. This information could, for 395 example, include: 397 * discovery of the CDNI Metadata interface endpoints 399 * information necessary to establish secure communication 400 between the CDNI Metadata interface endpoints. 402 CI-11 {LOW} The CDNI Control interface may allow bootstrapping of 403 the Content Acquisition interface. This could, for example, 404 include exchange and negotiation of the Content Acquisition 405 methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, 406 ATIS C2[ATIS-0800042]). 408 CI-12 {LOW} The CDNI Control interface may allow bootstrapping of 409 the CDNI Logging interface. This information could, for 410 example, include: 412 * discovery of the CDNI Logging interface endpoints 414 * information necessary to establish secure communication 415 between the CDNI Logging interface endpoints 417 * negotiation/definition of the log file format and set of 418 fields to be exported through the logging protocol, with 419 some granularity (e.g. On a per content type basis). 421 * negotiation/definition of parameters related to 422 transaction logs export (e.g., export protocol, file 423 compression, export frequency, directory). 425 5. CDNI Request Routing Redirection Interface Requirements 427 The main function of the CDNI Request Routing Redirection interface 428 (RI) is to allow the Request-Routing systems in interconnected CDNs 429 to communicate to facilitate redirection of the request across CDNs. 431 RI-1 {HIGH} The CDNI Request Routing Redirection interface shall 432 support efficient request routing for small objects. This 433 may, for example, call for a mode of operation (e.g. DNS- 434 based request routing) where freshness and accuracy of CDN/ 435 Surrogate selection can be traded-off against reduced request 436 routing load (e.g. Via lighter-weight queries and caching of 437 request routing decisions). 439 RI-2 {HIGH} The CDNI Request Routing Redirection interface shall 440 support efficient request routing for large objects. This 441 may, for example, call for a mode of operation (e.g. HTTP- 442 based request routing) where freshness and accuracy of CDN/ 443 Surrogate selection justifies a per-request decision and a 444 per-request CDNI Request-Routing protocol call. 446 RI-3 {HIGH} The CDNI Request Routing Redirection interface shall 447 support recursive CDNI request routing. 449 RI-4 {HIGH} The CDNI Request Routing Redirection interface shall 450 support iterative CDNI request routing. 452 RI-5 {MED} In case of detection of a request redirection loop, the 453 CDNI Request Routing Redirection Interface's loop prevention 454 mechanism should allow redirection of the request on an 455 alternate CDN path (as opposed to the request not being 456 redirected at all). 458 RI-6 {MED} The CDNI Request Routing Redirection interface should 459 support a mechanism allowing enforcement of a limit on the 460 number of successive CDN redirections for a given request. 462 RI-7 {LOW} The CDNI Request Routing Redirection interface may 463 support a mechanism allowing an Upstream CDN to avoid 464 redirecting a request to a Downstream CDN if that is likely to 465 result in the total redirection time exceeding some limit. 467 RI-8 {HIGH} The CDNI Request Routing Redirection interface shall 468 allow the Upstream CDN to include, in the query to the 469 Downstream CDN, the necessary information to allow the 470 Downstream CDN to process the redirection query. This could, 471 for example, include: 473 * information from which the geographic region of the User 474 Agent that originated the request can be inferred (e.g. 475 User Agent fully qualified domain name in case of HTTP- 476 based Request Routing, DNS Proxy fully qualified domain 477 name in case of DNS-based Request Routing) 479 * requested resource information (e.g. Resource URI in case 480 of HTTP-based Request Routing, Resource hostname in case 481 of DNS-based Request Routing) 483 * additional available request information (e.g. request 484 headers in case of HTTP-based Request Routing). 486 RI-9 {LOW} The CDNI Request Routing Redirection interface may also 487 allow the Upstream CDN to convey information pointing to CDNI 488 metadata applicable (individually or through inheritance) to 489 the requested content. For illustration, the CDNI metadata 490 pointed to could potentially include metadata that is 491 applicable to any content, metadata that is applicable to a 492 content collection (to which the requested content belongs) 493 and/or metadata that is applicable individually to the 494 requested content. 496 RI-10 {HIGH} The CDNI Request Routing Redirection interface shall 497 allow the Downstream CDN to include the following information 498 in the response to the Upstream CDN: 500 * status code, in particular indicating acceptance or 501 rejection of request (e.g. Because the Downstream CDN is 502 unwilling or unable to serve the request). In case of 503 rejection, an error code is also to be provided, which 504 allows the Upstream CDN to react appropriately (e.g. 505 Select another Downstream CDN, or serve the request 506 itself) 508 * redirection information (e.g. Resource URI in case of 509 HTTP-based Request Routing, equivalent of a DNS record in 510 case of DNS-based Request Routing). 512 RI-11 {HIGH} The CDNI Request Routing Redirection interface shall 513 allow for per-chunk request routing of HTTP Adaptive Streaming 514 content. 516 RI-12 {LOW} The CDNI Request Routing Redirection interface may allow 517 the Upstream CDN to use the information conveyed by the 518 Downstream CDN during the Recursive Request Routing process to 519 rewrite an HTTP Adaptive Streaming manifest file. 521 RI-13 {LOW} The CDNI Request-Routing interface may allow the 522 Upstream CDN to re-sign the invariant portion of the chunk 523 URIs embedded in the HTTP Adaptive Streaming manifest file. 525 RI-14 {MED} The CDNI Request Routing Redirection interface should 526 correlate the HTTP Adaptive Stream manifest file to the 527 related chunks referenced in the manifest file. 529 RI-15 {MED} The CDNI Request Routing Redirection interface should 530 allow for an efficient method of transferring request routing 531 information for multiple chunks from the Downstream CDN to the 532 Upstream CDN as part of the recursive request routing process. 534 6. CDNI Footprint & Capabilities Advertisement Interface Requirements 536 The main function of the CDNI Footprint & Capabilities Advertisement 537 interface (FCI) is to allow the Downstream CDN to advertise the 538 information regarding its footprint and capabilities to the Upstream 539 CDN. 541 FCI-1 {HIGH} The CDNI Footprint & Capabilities Advertisement 542 interface shall allow the Downstream CDN to communicate to the 543 Upstream CDN coarse information about the Downstream CDN 544 ability and/or willingness to handle requests from the 545 Upstream CDN. For example, this could potentially include a 546 binary signal ("Downstream CDN ready/not-ready to take 547 additional requests from Upstream CDN") to be used in case of 548 excessive load or failure condition in the Downstream CDN. 550 FCI-2 {MED} The CDNI Footprint & Capabilities Advertisement 551 interface should allow the Downstream CDN to communicate to 552 the Upstream CDN aggregate information to facilitate CDN 553 selection during request routing, such as Downstream CDN 554 capabilities, resources and affinities (i.e. Preferences or 555 cost). This information could, for example, include: 557 * supported content types and delivery protocols 559 * footprint (e.g. layer-3 coverage) 561 * a set of metrics/attributes (e.g. Streaming bandwidth, 562 storage resources, distribution and delivery priority) 564 * a set of affinities (e.g. Preferences, indication of 565 distribution/delivery fees) 567 * information to facilitate request redirection (e.g. 568 Reachability information of Downstream CDN Request Routing 569 system). 571 [Note: Some of this information - such as supported content 572 types and delivery protocols- may also potentially be taken 573 into account by the distribution system in the Upstream CDN 574 for pre-positioning of content and/or metadata in the 575 Downstream CDN in case of pre-positioned content acquisition 576 and/or pre-positioned CDNI metadata acquisition.] 578 FCI-3 {MED} In the case of cascaded redirection, the CDNI Footprint 579 & Capabilities Advertisement interface should allow the 580 Downstream CDN to also include in the information communicated 581 to the Upstream CDN, information on the capabilities, 582 resources and affinities of CDNs to which the Downstream CDN 583 may (in turn) redirect requests received by the Upstream CDN. 584 In that case, the CDNI Request-Routing interface shall prevent 585 looping of such information exchange. 587 FCI-4 {LOW} The CDNI Footprint & Capabilities Advertisement 588 interface may allow the Downstream CDN to communicate to the 589 Upstream CDN aggregate information on CDNI administrative 590 limits and policy. This information can be taken into account 591 by the Upstream CDN Request Routing system in its CDN 592 Selection decisions. This information could, for example, 593 include: 595 * maximum number of requests redirected by the Upstream CDN 596 to be served simultaneously by the Downstream CDN 598 * maximum aggregate volume of content (e.g. in Terabytes) to 599 be delivered by the Downstream CDN over a time period. 601 FCI-5 {MED} The CDNI Footprint & Capabilities Advertisement 602 interface should support advertisement of the following types 603 of capabilities: 605 * delivery protocol (e.g., HTTP vs. RTMP) 607 * acquisition protocol (for acquiring content from an 608 Upstream CDN) 610 * redirection mode (e.g., DNS Redirection vs. HTTP 611 Redirection) 613 * capabilities related to CDNI Logging (e.g., supported 614 logging mechanisms) 616 * capabilities related to CDNI Metadata (e.g., authorization 617 algorithms or support for proprietary vendor metadata) 619 FCI-6 {LOW} The CDNI Control interface may allow exchange and 620 negotiation of delivery authorization mechanisms to be 621 supported across the CDNs (e.g. URI signature based 622 validation). 624 FCI-7 {HIGH} The CDNI Footprint & Capabilities Advertisement 625 interface shall support extensible fields used to convey the 626 CDN capabilities and methods to indicate the footprint in the 627 advertisement from the Downstream CDN to the Upstream CDN. 629 7. CDNI Metadata Interface Requirements 631 The primary function of the CDNI Metadata interface (MI) is to allow 632 the Distribution system in interconnected CDNs to communicate to 633 ensure Content Distribution Metadata with inter-CDN scope can be 634 exchanged across CDNs. We observe that while the CDNI Metadata 635 Distribution protocol is currently discussed as a single "protocol", 636 further analysis will determine whether the corresponding 637 requirements are to be realized over a single interface and protocol, 638 or over multiple interfaces and protocols. For example, a subset of 639 the CDNI metadata might be conveyed in-band along with the actual 640 content acquisition across CDNs (e.g. content MD5 in HTTP header) 641 while another subset might require an out-of-band interface & 642 protocol (e.g. geo-blocking information). 644 MI-1 {HIGH} The CDNI Metadata interface shall allow the Upstream 645 CDN to provide the Downstream CDN with content distribution 646 metadata of inter-CDN scope. 648 MI-2 {HIGH} The CDNI Metadata interface shall support exchange of 649 CDNI metadata for both the dynamic content acquisition model 650 and the pre-positioning content acquisition model. 652 MI-3 {HIGH} The CDNI Metadata interface shall support a mode where 653 no, or a subset of, the Metadata is initially communicated to 654 the Downstream CDN along with information about how/where to 655 acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI 656 metadata acquisition). 658 MI-4 {MED} The CDNI Metadata interface should support a mode where 659 all the relevant Metadata is initially communicated to the 660 Downstream CDN (i.e. Pre-positioned CDNI metadata 661 acquisition). 663 MI-5 {HIGH} Whether in the pre-positioned content acquisition model 664 or in the dynamic content acquisition model, the CDNI Metadata 665 interface shall provide the necessary information to allow the 666 Downstream CDN to acquire the content from an upstream source 667 (e.g. Acquisition protocol and Uniform Resource Identifier in 668 Upstream CDN- or rules to construct this URI). 670 MI-6 {HIGH} The CDNI metadata shall allow signaling of one or more 671 upstream sources, where each upstream source can be in the 672 Upstream CDN, in another CDN, the CSP origin server or any 673 arbitrary source designated by the Upstream CDN. Note that 674 some upstream sources (e.g. the content origin server) may or 675 may not be willing to serve the content to the Downstream CDN, 676 if this policy is known to the Upstream CDN then it may omit 677 those sources when exchanging CDNI metadata. 679 MI-7 {HIGH} The CDNI Metadata interface (possibly in conjunction 680 with the CDNI Control interface) shall allow the Upstream CDN 681 to request addition and modification of CDNI Metadata into the 682 Downstream CDN. 684 MI-8 {HIGH} The CDNI Metadata interface (possibly in conjunction 685 with the CDNI Control interface) shall allow removal of 686 obsolete CDNI Metadata from the Downstream CDN (this could, 687 for example, be achieved via an explicit removal request from 688 the Upstream CDN or via expiration of a Time-To-Live 689 associated to the Metadata). 691 MI-9 {HIGH} The CDNI Metadata interface shall allow association of 692 CDNI Metadata at the granularity of individual object. This 693 is necessary to achieve fine-grain Metadata distribution at 694 the level of an individual object when necessary. 696 MI-10 {HIGH} The CDNI Metadata interface shall allow association of 697 CDNI Metadata at the granularity of an object set. This is 698 necessary to achieve scalable distribution of metadata when a 699 large number of objects share the same distribution policy. 701 MI-11 {HIGH} The CDNI Metadata interface shall support multiple 702 levels of inheritance with precedence to more specific 703 metadata. For example, the CDNI Metadata Distribution 704 protocol may support metadata that is applicable to any 705 content, metadata that is applicable to a content collection 706 and metadata that is applicable to an individual content where 707 content level metadata overrides content collection metadata 708 that overrides metadata for any content. 710 MI-12 {HIGH} The CDNI Metadata interface shall ensure that 711 conflicting metadata with overlapping scope are prevented or 712 deterministically handled. 714 MI-13 {HIGH} The CDNI Metadata interface shall allow signaling of 715 content distribution control policies. For example, this 716 could potentially include: 718 * geo-blocking information (i.e. Information defining 719 geographical areas where the content is to be made 720 available or blocked) 722 * availability windows (i.e. Information defining time 723 windows during which the content is to be made available 724 or blocked; expiration time may also be included to remove 725 content) 727 * delegation whitelist/blacklist (i.e. Information defining 728 which Downstream CDNs the content may/may not be delivered 729 through) 731 MI-14 {HIGH} The CDNI Metadata interface shall be able to exchange a 732 set of metadata elements with specified semantics (e.g. start 733 of time window, end of time window). 735 MI-15 {HIGH} The CDNI Metadata interface shall allow exchange of 736 opaque metadata element, whose semantic is not defined in CDNI 737 but established by private CDN agreement. 739 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 740 authorization checks and validation that are to be performed 741 by the surrogate before delivery. For example, this could 742 potentially include the need to validate information (e.g. 743 Expiry time, Client IP address) required for access 744 authorization. 746 MI-17 {MED} The CDNI Metadata interface should allow signaling of 747 CDNI-relevant surrogate cache behavior parameters. For 748 example, this could potentially include: 750 * control of whether the query string of HTTP URI is to be 751 ignored by surrogate cache 753 * enforcement of caching directives by Downstream CDN that 754 are different than the ones signalled in the HTTP headers 755 (e.g. "Expires" field) 757 * rate-pacing by Downstream CDN for content delivery (e.g. 758 Progressive Download) 760 MI-18 {HIGH} The CDNI Metadata interface shall provide indication of 761 related content (e.g. HTTP Adaptive Bit Rate chunks) by the 762 Content Collection ID (CCID) metadata. This could be used by 763 the Downstream CDN for operations on the group of content. 764 For example, this could potentially include: 766 * content acquisition for the entire set of files when one 767 piece of content is requested 769 * local file management and storage bundles all the files 770 for the content 772 * purging the entire set of files associated with the 773 content 775 * logging of the delivery of the content for the session 776 when at least one file in the set was delivered 778 MI-19 {MED} The CDNI Metadata interface should support an optional 779 mechanism allowing the Upstream CDN to indicate to the 780 Downstream CDN which CDNI Log fields are to be provided for 781 all content items, for specific sets of content items, or for 782 specific content items delivered using HTTP. A CDNI 783 implementation that does not support this optional CDNI 784 Metadata Distribution interface mechanism shall ignore this 785 log format indication and generate CDNI logging format for 786 HTTP Adaptive Streaming using the default set of CDNI Logging 787 fields. (Note: This function may be part of the CDNI Metadata 788 interface or the CDNI Control interface.) 790 MI-20 {MED} The CDNI Metadata interface should allow the Upstream 791 CDN to signal to the Downstream CDN the Content Collection ID 792 value for all, for specific sets of, or for specific content 793 items delivered using HTTP. Whenever the Downstream CDN is 794 instructed by the Upstream CDN to report the Content 795 Collection ID field in the log records, the Downstream CDN is 796 to use the value provided through the CDNI Metadata interface 797 for the corresponding content. Note the Session ID field 798 along with Content Collection ID may be used for HTTP Adaptive 799 Streaming content. 801 MI-21 {MED} The CDNI Metadata interface should allow the Upstream 802 CDN to signal to the Downstream CDN the Authorization Group ID 803 value for all the related HTTP Adaptive Streaming content 804 (i.e. manifest file and chunks). The authorization result of 805 a content (e.g. manifest file) is transferred over to related 806 content (e.g. chunks). 808 MI-22 {HIGH} The CDNI Metadata interface shall support extensible 809 format for CDNI metadata delivery from the Upstream CDN to the 810 Downstream CDN. 812 8. CDNI Logging Interface Requirements 814 This section identifies the requirements related to the CDNI Logging 815 interface (LI). We observe that while the CDNI Logging interface is 816 currently discussed as a single "protocol", further analysis will 817 determine whether the corresponding requirements are to be realized 818 over a single interface and protocol, or over multiple interfaces and 819 protocols. 821 LI-1 {HIGH} The CDNI logging architecture and interface shall 822 ensure reliable transfer of CDNI logging information across 823 CDNs. 825 LI-2 {HIGH} The CDNI Logging interface shall provide logging of 826 deliveries and incomplete deliveries to User Agents performed 827 by the Downstream CDN as a result of request redirection by 828 the Upstream CDN. 830 LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface 831 should allow the Downstream CDN to report to the Upstream CDN 832 logging for deliveries and incomplete deliveries performed by 833 the Downstream CDN itself as well as logging for deliveries 834 and incomplete deliveries performed by cascaded CDNs on behalf 835 of the Downstream CDN. 837 LI-4 {HIGH} The CDNI Logging interface shall support batch/offline 838 exchange of logging records. 840 LI-5 {MED} The CDNI Logging interface should also support an 841 additional mechanism taking into account the timing 842 constraints for some types of logging records (e.g. near-real 843 time for monitoring and analytics applications). 845 LI-6 {HIGH} The CDNI Logging interface shall define a log file 846 format and a set of fields to be exported for various CDNI 847 logging events. 849 LI-7 {HIGH} The CDNI Logging interface shall define a transport 850 mechanism to exchange CDNI Logging files. 852 LI-8 {MED} The CDNI Logging interface should allow a CDN to query 853 another CDN for relevant current logging records (e.g. For 854 on-demand access to real-time logging information). 856 LI-9 {LOW} The CDNI Logging interface may support aggregate/ 857 summarized logs (e.g. total bytes delivered for a content 858 regardless of individual User Agents to which it was 859 delivered). 861 LI-10 {LOW} The CDNI Logging interface may support logging of 862 performance data for deliveries to User Agents performed by 863 the Downstream CDN as a result of request redirection by the 864 Upstream CDN. Performance data may include various traffic 865 statistics (the specific parameters are to be determined). 866 The CDNI Logging interface may support the Upstream CDN to 867 indicate the nature and contents of the performance data to be 868 reported by the Downstream CDN. 870 LI-11 {MED} The CDNI Logging interface should support logging of 871 consumed resources (e.g. storage, bandwidth) to the Upstream 872 CDN for deliveries where content is stored by the Downstream 873 CDN for delivery to User Agents. The information logged may 874 include the type of storage (e.g., Origin, Intermediate, Edge, 875 Cache) as well as the amount of storage (e.g., total GB, GB 876 used, per time period, per content domain) all of which may 877 impact the cost of the services. 879 LI-12 {MED} In the case of cascaded CDNs, the CDNI Logging interface 880 should support the Downstream CDN to report consumed resources 881 (e.g. storage, bandwidth) to the Upstream CDN where content is 882 stored by the Downstream CDN itself as well as logging for 883 storage resources when content storage is performed by 884 cascaded CDNs on behalf of the Downstream CDN. 886 LI-13 {HIGH} The CDNI Logging interface shall support logging of 887 deleted objects from the Downstream CDN to the Upstream CDN as 888 a result of explicit delete requests on via the CDNI Control 889 interface from the Upstream CDN. 891 LI-14 {HIGH} The CDNI Logging interface shall support the exchange 892 of extensible log file formats to support proprietary 893 information fields. These information fields shall be agreed 894 upon ahead of time between the corresponding CDNs. 896 LI-15 {HIGH} The CDNI Logging interface shall allow a CDN to notify 897 another CDN about which CDNI logging information is available 898 for transfer and/or no longer available (e.g. it exceeded some 899 logging retention period or some logging retention volume). 901 LI-16 {MED} The CDNI Logging interface should support the ability 902 for the Downstream CDN to include the Content Collection ID 903 and Session ID fields in CDNI log entries generated for HTTP 904 Adaptive Streaming content. 906 LI-17 {MED} The CDNI Logging interface should provide privacy 907 protection by not disclosing information that can be used to 908 identify the user (e.g. method that anonymizes the IP address 909 carried in the logging field). The use of the privacy 910 protection mechanism is optional. 912 9. CDNI Security Requirements 914 This section identifies the requirements related to the CDNI 915 security. Some of these are expected to affect multiple or all 916 protocols. 918 SEC-1 {HIGH} All the CDNI interface shall support secure operation 919 over unsecured IP connectivity (e.g. The Internet). This 920 includes authentication, confidentiality, integrity protection 921 as well as protection against spoofing and replay. 923 SEC-2 {HIGH} The CDNI solution shall provide sufficient protection 924 against Denial of Service attacks. This includes protection 925 against spoofed delivery requests sent by User Agents directly 926 to a Downstream CDN attempting to appear as if they had been 927 redirected by a given Upstream CDN when they have not. 929 SEC-3 {MED} The CDNI solution should be able to ensure that for any 930 given request redirected to a Downstream CDN, the chain of CDN 931 Delegation (leading to that request being served by that CDN) 932 can be established with non-repudiation (i.e. "non-repudiation 933 with proof of origin" as defined in [RFC4949]). 935 SEC-4 {MED} The CDNI solution should be able to ensure non- 936 repudiation by the Downstream CDN of transaction logs 937 generated by the Downstream CDN and communicated to an 938 Upstream CDN. This would ensure that the Downstream CDN 939 cannot repudiate transmitted Log records, therefore 940 discouraging the Downstream CDN from spoofing a transaction 941 log (attempting to appear as if it corresponds to a request 942 redirected by the Upstream CDN when that request has not been 943 redirected by this Upstream CDN). 945 SEC-5 {LOW} The CDNI solution may provide a mechanism allowing an 946 Upstream CDN that has credentials to acquire content from the 947 CSP origin server (or another CDN), to allow establishment of 948 credentials authorizing the Downstream CDN to acquire the 949 content from the CSP origin server (or the other CDN) (e.g. 950 In case the content cannot be acquired from the Upstream CDN). 952 10. IANA Considerations 954 This document makes no request of IANA. 956 Note to RFC Editor: this section may be removed on publication as an 957 RFC. 959 11. Security Considerations 961 This document discusses CDNI security requirements in Section 9. 963 12. Contributors 965 This document reflects the contributions from the following authors: 967 Francois Le Faucheur 969 Cisco Systems 971 flefauch@cisco.com 973 Mahesh Viveganandhan 975 Cisco Systems 977 mvittal@cisco.com 979 Grant Watson 981 Alcatel-Lucent (Velocix) 983 gwatson@velocix.com 985 13. Acknowledgements 987 This document leverages the earlier work of the IETF CDI working 988 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 14. References 1005 14.1. Normative References 1007 [I-D.ietf-cdni-framework] 1008 Peterson, L. and B. Davie, "Framework for CDN 1009 Interconnection", draft-ietf-cdni-framework-06 (work in 1010 progress), October 2013. 1012 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1013 Distribution Network Interconnection (CDNI) Problem 1014 Statement", RFC 6707, September 2012. 1016 14.2. Informative References 1018 [ATIS-0800042] 1019 "ATIS IPTV Content on Demand Service, 1020 https://www.atis.org/docstore/product.aspx?id=25670", 1021 December 2010. 1023 [I-D.amini-cdi-distribution-reqs] 1024 Amini, L., "Distribution Requirements for Content 1025 Internetworking", draft-amini-cdi-distribution-reqs-02 1026 (work in progress), November 2001. 1028 [I-D.cain-request-routing-req] 1029 Cain, B., "Request Routing Requirements for Content 1030 Internetworking", draft-cain-request-routing-req-03 (work 1031 in progress), November 2001. 1033 [I-D.gilletti-cdnp-aaa-reqs] 1034 "CDI AAA Requirements, 1035 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 1037 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1038 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1039 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1041 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1042 RFC 4949, August 2007. 1044 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1045 K., and G. Watson, "Use Cases for Content Delivery Network 1046 Interconnection", RFC 6770, November 2012. 1048 [RTMP] "Adobe's Real Time Messaging Protocol, http:// 1049 www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/ 1050 rtmp_specification_1.0.pdf", December 2012. 1052 Authors' Addresses 1054 Kent Leung (editor) 1055 Cisco Systems 1056 170 West Tasman Drive 1057 San Jose, CA 95134 1058 U.S.A. 1060 Phone: +1 408 526 5030 1061 Email: kleung@cisco.com 1063 Yiu Lee (editor) 1064 Comcast 1065 One Comcast Center 1066 Philadelphia, PA 19103 1067 U.S.A. 1069 Email: yiu_lee@cable.comcast.com