idnits 2.17.1 draft-ietf-cdni-requirements-09.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 737: '... an OPTIONAL mechanism allowi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2013) is 3951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 887, but not defined == Missing Reference: 'HIGH' is mentioned on line 876, but not defined == Missing Reference: 'LOW' is mentioned on line 896, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-03 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 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: January 2, 2014 Comcast 6 July 1, 2013 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-09 11 Abstract 13 Content Delivery Networks (CDNs) are frequently used for content 14 delivery. As a result of significant growth in content delivered 15 over IP networks, existing CDN providers are scaling up their 16 infrastructure. Many Network Service Providers and Enterprise 17 Service Providers are also deploying their own CDNs. To deliver 18 contents from the Content Service Protect (CSP) to end users, the 19 contents may traverse across multiple CDNs. This creates a need for 20 interconnecting (previously) standalone CDNs so that they can 21 collectively act as a single delivery platform from the CSP to the 22 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 January 2, 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 . . . . . . . . . . . . . . . . . . 6 66 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 67 5. CDNI Request Routing/Redirection Interface Requirements . . . 9 68 6. CDNI Request Routing/Footprint & Capabilities 69 Advertisement Interface Requirements . . . . . . . . . . . . . 12 70 7. CDNI Metadata Distribution Interface Requirements . . . . . . 14 71 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18 72 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 77 14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 80 15.2. Informative References . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 The volume of video and multimedia content delivered over the 86 Internet is rapidly increasing and expected to continue doing so in 87 the future. In the face of this growth, Content Delivery Networks 88 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 89 content, improved quality of experience for end users, and increased 90 robustness of delivery. For these reasons CDNs are frequently used 91 for large-scale content delivery. As a result of the significant 92 growth in content delivered over IP networks, existing CDN providers 93 are scaling up their infrastructure and many Network Service 94 Providers and Enterprise Service Providers are deploying their own 95 CDNs. Subject to the policy of the CSP, it is generally desirable 96 that a given item of content can be delivered to an end user 97 regardless of that end user's location or attachment network. This 98 creates a need for interconnecting (previously) standalone CDNs so 99 they can interoperate and collectively behave as a single delivery 100 infrastructure. The Content Distribution Network Interconnection 101 (CDNI) working group has been chartered to develop an interoperable 102 and scalable solution for such CDN interconnections. 104 CDNI Problem Statement [RFC6707] outlines the problem area that the 105 CDNI working group is chartered to address. CDNI Problem Statement 106 [RFC6770] discusses the use cases for CDN Interconnection. Framework 107 for CDNI [I-D.ietf-cdni-framework] discusses the technology framework 108 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 section 1.1 of 119 Framework for CDNI [I-D.ietf-cdni-framework]. In addition, the key 120 words "High Priority", "Medium Priority" and "Low Priority" in this 121 document are to be interpreted in the following way: 123 o "High Priority" indicates requirements that are to be supported by 124 the CDNI interfaces. A requirement is stated as "High Priority" 125 when it is established by the working group that it can be met to 126 achieve the goal of a deployable solution in a short timeframe 127 (18-24 months) as needed by the industry. This is tagged as 128 "[HIGH]". 130 o "Medium Priority" indicates requirements that are to be supported 131 by the CDNI interfaces unless the WG realizes at a later stage 132 that attempting to meet this requirement does not achieve the goal 133 of a deployable solution in a short timeframe (18-24 months) as 134 needed by the industry. This is tagged as "[MED]". 136 o "Low Priority" indicates requirements that are to be supported by 137 the CDNI interfaces provided that dedicating WG resources to this 138 work does not prevent addressing "High Priority" and "Medium 139 Priority" requirements and that attempting to meet this 140 requirement is not an obstacle to achieving the goal of a 141 deployable solution in a short timeframe (18-24 months) as needed 142 by the industry. This is tagged as "[LOW]". 144 2. CDNI Model and CDNI Interfaces 146 For convenience Figure 1 from Framework for CDNI 147 [I-D.ietf-cdni-framework] illustrating the CDNI problem area and the 148 CDNI protocols is replicated below. 150 -------- 151 / \ 152 | CSP | 153 \ / 154 -------- 155 * 156 * 157 * /\ 158 * / \ 159 ---------------------- |CDNI| ---------------------- 160 / Upstream CDN \ | | / Downstream CDN \ 161 | +-------------+ | Control Interface| +-------------+ | 162 |******* Control |<======|====|========>| Control *******| 163 |* +------*----*-+ | | | | +-*----*------+ *| 164 |* * * | | | | * * *| 165 |* +------*------+ | Logging Interface| +------*------+ *| 166 |* ***** Logging |<======|====|========>| Logging ***** *| 167 |* * +-*-----------+ | | | | +-----------*-+ * *| 168 |* * * * | Request Routing | * * * *| 169 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 170 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 171 . |* * * +-------------+.| | | | +-------------+ * * *| . 172 . |* * * . CDNI Metadata | * * *| . 173 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 174 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 175 . |* * * | | | . \ / | | | * * *| . 176 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 177 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 178 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 179 . |******* +---------+| | Acquisition | |+----------+ *******| . 180 . | +-------------+ | | +-------*-----+ | . 181 . \ / \ * / . 182 . ---------------------- ---------*------------ . 183 . * . 184 . * Delivery . 185 . * . 186 . +--*---+ . 187 ...............Request.............................| User |..Request.. 188 | Agent| 189 +------+ 191 <==> interfaces inside the scope of CDNI 193 **** interfaces outside the scope of CDNI 194 .... interfaces outside the scope of CDNI 196 Figure 1: CDNI Model and CDNI Interfaces 198 3. Generic CDNI Requirements 200 This section identifies generic requirements independent of the 201 individual CDNI interfaces. Some of those are expected to affect 202 multiple or all interfaces. 204 GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or 205 leverage existing IETF protocols. 207 GEN-2 [HIGH] The CDNI solution shall not require a change, or an 208 upgrade, to the User Agent to benefit from content delivery 209 through interconnected CDNs. 211 GEN-3 [HIGH] The CDNI solution shall not require a change, or an 212 upgrade, to the Content Service Provider to benefit from 213 content delivery through interconnected CDNs. 215 GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN 216 information to be exposed to other CDNs for effective and 217 efficient delivery of the content. Examples of intra-CDN 218 information include surrogate topology, surrogate status, 219 cached content, etc. 221 GEN-5 [HIGH] The CDNI solution shall support delivery to the user 222 agent based on HTTP [RFC2616]. (Note that while delivery and 223 acquisition "data plane" protocols are out of the CDNI 224 solution scope, the CDNI solution "control plane" protocols 225 are expected to participate in enabling, selecting or 226 facilitating operations of such acquisition and delivery 227 protocols. Hence it is useful to state requirements on the 228 CDNI solution in terms of which acquisition and delivery 229 protocols). 231 GEN-6 [HIGH] The CDNI solution shall support acquisition across 232 CDNs based on HTTP [RFC2616]. (The note above applies to 233 this requirement too) 235 GEN-7 [LOW] The CDNI solution may support delivery to the user 236 agent based on protocols other than HTTP. 238 GEN-8 [LOW] The CDNI solution may support acquisition across CDNs 239 based on protocols other than HTTP. 241 GEN-9 [MED] The CDNI solution should support cascaded CDN 242 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 243 to an arbitrary number of levels beyond the first level. 245 GEN-10 [MED] The CDNI solution should support an arbitrary topology 246 of interconnected CDNs (i.e. the CDN topology cannot be 247 restricted to a tree, a loop-free topology, etc.). 249 GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI 250 information exchange. 252 GEN-12 [HIGH] When making use of third party reference, the CDNI 253 solution shall consider the potential issues associated with 254 the use of various format of third-party references (e.g. 255 NAT or IPv4/IPv6 translation potentially breaking third-party 256 references based on an IP addresses such as URI containing 257 IPv4 or IPv6 address litterals, split DNS situations 258 potentially breaking third-party references based on DNS 259 fully qualified domain names) and wherever possible avoid, 260 minimize or mitigate the associated risks based on the 261 specifics of the environments where the reference is used 262 (e.g. likely or unlikely presence of NAT in the path). In 263 particular, this applies to situations where the CDNI 264 solution needs to construct and convey uniform resource 265 identifiers for directing/redirecting a content request, as 266 well as to situations where the CDNI solution needs to pass 267 on a third party reference (e.g. to identify a User Agent) in 268 order to allow another entity to make a more informed 269 decision (e.g. make a more informed request routing decision 270 by attempting to derive location information from the third 271 party reference). 273 GEN-13 [HIGH] The CDNI solution shall support HTTP Adaptive 274 Streaming content. 276 4. CDNI Control Interface Requirements 278 The primary purpose of the CDNI Control interface (CI) is to initiate 279 the interconnection across CDNs, bootstrap the other CDNI interfaces 280 and trigger actions into the Downstream CDN by the Upstream CDN (such 281 as delete object from caches or trigger pre-positioned content 282 acquisition). The working group attempts to align requirements with 283 the appropriate interface; however, solutions to these requirements 284 may apply to a different interface or another interface in addition 285 to the interface it is associated with. 287 CI-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN 288 to request that the Downstream CDN, including downstream 289 cascaded CDNs, delete an object or set of objects and/or its 290 CDNI metadata from the CDN surrogates and any storage. Only 291 the object(s) and CDNI metadata that pertain to the requesting 292 Upstream CDN are allowed to be purged. 294 CI-2 [MED] The CDNI Control interface should allow for multiple 295 content items identified by a Content Collection ID to be 296 purged using a single Content Purge action. 298 CI-3 [MED] The CDNI Control interface should allow the Upstream CDN 299 to request that the Downstream CDN, including downstream 300 cascaded CDNs, mark an object or set of objects and/or its 301 CDNI metadata as "stale" and revalidate them before they are 302 delivered again. 304 CI-4 [HIGH] The CDNI Control interface shall allow the Downstream 305 CDN to report on the completion of these actions (by itself, 306 and including downstream cascaded CDNs, in a manner 307 appropriate for the action (e.g. synchronously or 308 asynchronously). The confirmation receipt should include a 309 success or failure indication. The failure indication along 310 with the reason are used if the Downstream CDN cannot delete 311 the content in its storage. 313 CI-5 [MED] The CDNI Control interface should support initiation and 314 control by the Upstream CDN of pre-positioned CDNI metadata 315 acquisition by the Downstream CDN. 317 CI-6 [MED] The CDNI Control interface should support initiation and 318 control by the Upstream CDN of pre-positioned content 319 acquisition by the Downstream CDN. 321 CI-7 [LOW] The CDNI Control interface may allow a CDN to establish, 322 update and terminate a CDN interconnection with another CDN 323 whereby one CDN can act as a Downstream CDN for the other CDN 324 (that acts as an Upstream CDN). 326 CI-8 [LOW] The CDNI Control interface may allow control of the CDNI 327 interfaces between any two CDNs independently for each 328 direction (e.g. For the direction where CDN1 is the Upstream 329 CDN and CDN2 is the Downstream CDN, and for the direction 330 where CDN2 is the Upstream CDN and CDN1 is the Downstream 331 CDN). 333 CI-9 [LOW] The CDNI Control interface may allow bootstrapping of 334 the Request-Routing interface. For example, this can 335 potentially include: 337 * negotiation of the Request-Routing method (e.g. DNS vs 338 HTTP, if more than one method is specified) 340 * discovery of the Request-Routing protocol endpoints 342 * information necessary to establish secure communication 343 between the Request-Routing protocol endpoints. 345 CI-10 [LOW] The CDNI Control interface may allow bootstrapping of 346 the CDNI Metadata interface. This information could, for 347 example, include: 349 * discovery of the CDNI Metadata signaling protocol 350 endpoints 352 * information necessary to establish secure communication 353 between the CDNI Metadata signaling protocol endpoints. 355 CI-11 [LOW] The CDNI Control interface may allow bootstrapping of 356 the Content Acquisition interface. This could, for example, 357 include exchange and negotiation of the Content Acquisition 358 protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP, 359 ATIS C2). 361 CI-12 [LOW] The CDNI Control interface may allow bootstrapping of 362 the CDNI Logging interface. This information could, for 363 example, include: 365 * discovery of the Logging protocol endpoints 367 * information necessary to establish secure communication 368 between the Logging protocol endpoints 370 * negotiation/definition of the log file format and set of 371 fields to be exported through the Logging protocol, with 372 some granularity (e.g. On a per content type basis). 374 * negotiation/definition of parameters related to 375 transaction Logs export (e.g., export protocol, file 376 compression, export frequency, directory). 378 5. CDNI Request Routing/Redirection Interface Requirements 380 The main function of the CDNI request routing/ Redirection (RI) 381 interface is to allow the Request-Routing systems in interconnected 382 CDNs to communicate to facilitate redirection of the request across 383 CDNs. 385 RI-1 [HIGH] The CDNI request routing/Redirection interface shall 386 support efficient request-routing for small objects. This 387 may, for example, call for a mode of operation (e.g. DNS- 388 based request routing) where freshness and accuracy of CDN/ 389 Surrogate selection can be traded-off against reduced request- 390 routing load (e.g. Via lighter-weight queries and caching of 391 request-routing decisions). 393 RI-2 [HIGH] The CDNI request routing/Redirection interface shall 394 support efficient request-routing for large objects. This 395 may, for example, call for a mode of operation (e.g. HTTP- 396 based request routing) where freshness and accuracy of CDN/ 397 Surrogate selection justifies a per-request decision and a 398 per-request CDNI Request-Routing protocol call. 400 RI-3 [HIGH] The CDNI request routing/Redirection interface shall 401 support recursive CDNI request routing. 403 RI-4 [HIGH] The CDNI request routing/Redirection interface shall 404 support iterative CDNI request routing. 406 RI-5 [MED] In case of detection of a request redirection loop, the 407 CDNI request routing/Redirection interface's loop prevention 408 mechanism should allow routing of the request by avoiding the 409 loop (as opposed to the request loop being simply interrupted 410 without routing the request). 412 RI-6 [MED] The CDNI request routing/Redirection interface should 413 support a mechanism allowing enforcment of a limit on the 414 number of successive CDN redirections for a given request. 416 RI-7 [LOW] The CDNI request routing/Redirection interface may 417 support a mechanism allowing an Upstream CDN to avoid 418 redirecting a request to a Downstream CDN if that is likely to 419 result in the total redirection time exceeding some limit. 421 RI-8 [HIGH] The CDNI request routing/Redirection interface shall 422 allow the Upstream CDN to include, in the query to the 423 Downstream CDN, the necessary information to allow the 424 Downstream CDN to process the redirection query. This could, 425 for example, include: 427 * information from which the location of the user-agent that 428 originated the request can be inferred (e.g. User Agent 429 fully qualified domain name in case of HTTP-based Request 430 Routing, DNS Proxy fully qualified domain name in case of 431 DNS-based Request Routing) 433 * requested resource information (e.g. Resource URI in case 434 of HTTP-based Request Routing, Resource hostname in case 435 of DNS-based Request Routing) 437 * additional available request information (e.g. request 438 headers in case of HTTP-based Request Routing). 440 RI-9 [LOW] The CDNI request routing/Redirection interface may also 441 allow the Upstream CDN to convey information pointing to CDNI 442 metadata applicable (individually or through inheritance) to 443 the requested content. For illustration, the CDNI metadata 444 pointed to could potentially include metadata that is 445 applicable to any content, metadata that is applicable to a 446 content collection (to which the requested content belongs) 447 and/or metadata that is applicable individually to the 448 requested content. 450 RI-10 [HIGH] The CDNI request routing/Redirection interface shall 451 allow the Downstream CDN to include the following information 452 in the response to the Upstream CDN: 454 * status code, in particular indicating acceptance or 455 rejection of request (e.g. Because the Downstream CDN is 456 unwilling or unable to serve the request). In case of 457 rejection, an error code is also to be provided, which 458 allows the Upstream CDN to react appropriately (e.g. 459 Select another Downstream CDN, or serve the request 460 itself) 462 * redirection information (e.g. Resource URI in case of 463 HTTP-based Request Routing, equivalent of a DNS record in 464 case of DNS-based Request Routing). 466 RI-11 [HIGH] The CDNI request routing/Redirection interface shall 467 allow for per-chunk request routing of HTTP Adaptive Streaming 468 content. 470 RI-12 [LOW] The CDNI request routing/Redirection interface may allow 471 the Upstream CDN to use the information conveyed by the 472 Downstream CDN during the Recursive Request Routing process to 473 rewrite an HTTP Adaptive Streaming manifest file. 475 RI-13 [LOW] The CDNI Request-Routing interface may allow the 476 Upstream CDN to re-sign the invariant portion of the chunk 477 URIs embedded in the HTTP Adaptive Streaming manifest file. 479 RI-14 [MED] The CDNI request routing/Redirection interface should 480 allow the use of HTTP cookie to associate the chunks with the 481 HTTP Adaptive Stream manifest file (which is verified by the 482 URI signature) based on the Authorization Group ID (which is 483 an identifier used to correlate the manifest file to the 484 related chunks). 486 RI-15 [MED] The CDNI request routing/Redirection interface should 487 allow for an efficient method of transferring request routing 488 information for multiple chunks from the Downstream CDN to the 489 Upstream CDN as part of the recursive request routing process. 491 6. CDNI Request Routing/Footprint & Capabilities Advertisement 492 Interface Requirements 494 The main function of the CDNI Request Routing Footprint & 495 Capabilities Advertisement Interface (FCI) is to allow the Downstream 496 CDN to advertise the information regarding its footprint and 497 capabilities to the Upstream CDN. 499 FCI-1 [HIGH] The CDNI request routing/Footprint & Capabilities 500 advertisement interface shall allow the Downstream CDN to 501 communicate to the Upstream CDN coarse information about the 502 Downstream CDN ability and/or willingness to handle requests 503 from the Upstream CDN. For example, this could potentially 504 include a binary signal ("Downstream CDN ready/not-ready to 505 take additional requests from Upstream CDN") to be used in 506 case of excessive load or failure condition in the Downstream 507 CDN. 509 FCI-2 [MED] The CDNI request routing/Footprint & Capabilities 510 advertisement interface should allow the Downstream CDN to 511 communicate to the Upstream CDN aggregate information to 512 facilitate CDN selection during request routing, such as 513 Downstream CDN capabilities, resources and affinities (i.e. 514 Preferences or cost). This information could, for example, 515 include: 517 * supported content types and delivery protocols 519 * footprint (e.g. layer-3 coverage) 521 * a set of metrics/attributes (e.g. Streaming bandwidth, 522 storage resources, distribution and delivery priority) 524 * a set of affinities (e.g. Preferences, indication of 525 distribution/delivery fees) 527 * information to facilitate request redirection (e.g. 528 Reachability information of Downstream CDN Request Routing 529 system). 531 [Note: Some of this information - such as supported content 532 types and delivery protocols- may also potentially be taken 533 into account by the distribution system in the Upstream CDN 534 for pre-positioning of content and/or metadata in the 535 Downstream CDN in case of pre-positioned content acquisition 536 and/or pre-positioned CDNI metadata acquisition.] 538 FCI-3 [MED] In the case of cascaded redirection, the CDNI request 539 routing/Footprint & Capabilities advertisement interface 540 should allow the Downstream CDN to also include in the 541 information communicated to the Upstream CDN, information on 542 the capabilities, resources and affinities of CDNs to which 543 the Downstream CDN may (in turn) redirect requests received by 544 the Upstream CDN. In that case, the CDNI Request-Routing 545 interface shall prevent looping of such information exchange. 547 FCI-4 [LOW] The CDNI request routing/Footprint & Capabilities 548 advertisement interface may allow the Downstream CDN to 549 communicate to the Upstream CDN aggregate information on CDNI 550 administrative limits and policy. This information can be 551 taken into account by the Upstream CDN Request Routing system 552 in its CDN Selection decisions. This information could, for 553 example, include: 555 * maximum number of requests redirected by the Upstream CDN 556 to be served simultaneously by the Downstream CDN 558 * maximum aggregate volume of content (e.g. in Terabytes) to 559 be delivered by the Downstream CDN over a time period. 561 FCI-5 [MED] The CDNI request routing/Footprint & Capabilities 562 advertisement interface should support advertisement of the 563 following types of capabilities: 565 * delivery protocol (e.g., HTTP vs. RTMP) 567 * acquisition protocol (for acquiring content from an 568 Upstream CDN) 570 * redirection mode (e.g., DNS Redirection vs. HTTP 571 Redirection) 573 * capabilities related to CDNI Logging (e.g., supported 574 logging mechanisms) 576 * capabilities related to CDNI Metadata (e.g., authorization 577 algorithms or support for proprietary vendor metadata) 579 FCI-6 [LOW] The CDNI Control interface may allow exchange and 580 negotiation of delivery authorization mechanisms to be 581 supported across the CDNs (e.g. URI signature based 582 validation). 584 7. CDNI Metadata Distribution Interface Requirements 586 The primary function of the CDNI Metadata Distribution interface (MI) 587 is to allow the Distribution system in interconnected CDNs to 588 communicate to ensure Content Distribution Metadata with inter-CDN 589 scope can be exchanged across CDNs. We observe that while the CDNI 590 Metadata Distribution protocol is currently discussed as a single 591 "protocol", further analysis will determine whether the corresponding 592 requirements are to be realized over a single interface and protocol, 593 or over multiple interfaces and protocols. For example, a subset of 594 the CDNI metadata might be conveyed in-band along with the actual 595 content acquisition across CDNs (e.g. content MD5 in HTTP header) 596 while another subset might require an out-of-band interface & 597 protocol (e.g. geo-blocking information). 599 MI-1 [HIGH] The CDNI Metadata Distribution interface shall allow 600 the Upstream CDN to provide the Downstream CDN with content 601 distribution metadata of inter-CDN scope. 603 MI-2 [HIGH] The CDNI Metadata Distribution interface shall support 604 exchange of CDNI metadata for both the dynamic content 605 acquisition model and the pre-positioning content acquisition 606 model. 608 MI-3 [HIGH] The CDNI Metadata Distribution interface shall support 609 a mode where no, or a subset of, the Metadata is initially 610 communicated to the Downstream CDN along with information 611 about how/where to acquire the rest of the CDNI Metadata (i.e. 612 Dynamic CDNI metadata acquisition). 614 MI-4 [MED] The CDNI Metadata Distribution interface should support 615 a mode where all the relevant Metadata is initially 616 communicated to the Downstream CDN (i.e. Pre-positioned CDNI 617 metadata acquisition). 619 MI-5 [HIGH] Whether in the pre-positioned content acquisition model 620 or in the dynamic content acquisition model, the CDNI Metadata 621 Distribution interface shall provide the necessary information 622 to allow the Downstream CDN to acquire the content from an 623 upstream source (e.g. Acquisition protocol and Uniform 624 Resource Identifier in Upstream CDN- or rules to construct 625 this URI). 627 MI-6 [HIGH] The CDNI metadata shall allow signaling of one or more 628 upstream sources, where each upstream source can be in the 629 Upstream CDN, in another CDN, the CSP origin server or any 630 arbitrary source designated by the Upstream CDN. Note that 631 some upstream sources (e.g. the content origin server) may or 632 may not be willing to serve the content to the Downstream CDN, 633 if this policy is known to the Upstream CDN then it may omit 634 those sources when exchanging CDNI metadata. 636 MI-7 [HIGH] The CDNI Metadata Distribution interface (possibly in 637 conjunction with the CDNI Control interface) shall allow the 638 Upstream CDN to request addition and modification of CDNI 639 Metadata into the Downstream CDN. 641 MI-8 [HIGH] The CDNI Metadata Distribution interface (possibly in 642 conjunction with the CDNI Control interface) shall allow 643 removal of obsolete CDNI Metadata from the Downstream CDN 644 (this could, for example, be achieved via an explicit removal 645 request from the Upstream CDN or via expiration of a Time-To- 646 Live associated to the Metadata). 648 MI-9 [HIGH] The CDNI Metadata Distribution interface shall allow 649 association of CDNI Metadata at the granularity of individual 650 object. This is necessary to achieve fine-grain Metadata 651 distribution at the level of an individual object when 652 necessary. 654 MI-10 [HIGH] The CDNI Metadata Distribution interface shall allow 655 association of CDNI Metadata at the granularity of an object 656 set. This is necessary to achieve scalable distribution of 657 metadata when a large number of objects share the same 658 distribution policy. 660 MI-11 [HIGH] The CDNI Metadata Distribution interface shall support 661 multiple levels of inheritance with precedence to more 662 specific metadata. For example, the CDNI Metadata 663 Distribution protocol may support metadata that is applicable 664 to any content, metadata that is applicable to a content 665 collection and metadata that is applicable to an individual 666 content where content level metadata overrides content 667 collection metadata that overrides metadata for any content. 669 MI-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 670 that conflicting metadata with overlapping scope are prevented 671 or deterministically handled. 673 MI-13 [HIGH] The CDNI Metadata Distribution interface shall allow 674 signaling of content distribution control policies. For 675 example, this could potentially include: 677 * geo-blocking information (i.e. Information defining 678 geographical areas where the content is to be made 679 available or blocked) 681 * availability windows (i.e. Information defining time 682 windows during which the content is to be made available 683 or blocked; expiration time may also be included to remove 684 content) 686 * delegation whitelist/blacklist (i.e. Information defining 687 which Downstream CDNs the content may/may not be delivered 688 through) 690 MI-14 [HIGH] The CDNI Metadata interface shall be able to exchange a 691 set of metadata elements with specified semantics (e.g. start 692 of time window, end of time window). 694 MI-15 [HIGH] The CDNI Metadata interface shall allow exchange of 695 opaque metadata element, whose semantic is not defined in CDNI 696 but established by private CDN agreement. 698 MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow 699 signaling of authorization checks and validation that are to 700 be performed by the surrogate before delivery. For example, 701 this could potentially including the need to validate URI 702 signed information (e.g. Expiry time, Client IP address). 704 MI-17 [MED] The CDNI Metadata Distribution interface should allow 705 signaling of CDNI-relevant surrogate cache behavior 706 parameters. For example, this could potentially include: 708 * control of whether the query string of HTTP URI is to be 709 ignored by surrogate cache 711 * enforcement of caching directives by Downstream CDN that 712 are different than the ones signalled in the HTTP headers 713 (e.g. "Expires" field) 715 * rate-pacing by Downstream CDN for content delivery (e.g. 716 Progressive Download) 718 MI-18 [HIGH] The CDNI Metadata interface shall provide indication of 719 related content (e.g. HTTP Adaptive Bit Rate chunks) by the 720 Content Collection ID (CCID) metadata. This could be used by 721 the Downstream CDN for operations on the group of content. 722 For example, this could potentially include: 724 * content acquisition for the entire set of files when one 725 piece of content is requested 727 * local file management and storage bundles all the files 728 for the content 730 * purging the entire set of files associated with the 731 content 733 * logging of the delivery of the content for the session 734 when at least one file in the set was delivered 736 MI-19 [MED] The CDNI Metadata Distribution interface should support 737 an OPTIONAL mechanism allowing the Upstream CDN to indicate to 738 the Downstream CDN which CDNI Log fields are to be provided 739 for all, for specific sets of, or for specific content items 740 delivered using HTTP. A CDNI implementation that does not 741 support this optional CDNI Metadata Distribution Interface 742 mechanism shall ignore this log format indication and generate 743 CDNI logging format for HTTP Adaptive Streaming using the 744 default set of CDNI Logging fields. (Note: this function is 745 not concluded to be in Metadata Interface or Control 746 Interface) 748 MI-20 [MED] The CDNI Metadata Distribution interface should allow 749 the Upstream CDN to signal to the Downstream CDN the Content 750 Collection ID value for all, for specific sets of, or for 751 specific content items delivered using HTTP. Whenever the 752 Downstream CDN is instructed by the Upstream CDN to report the 753 Content Collection ID field in the log records, the Downstream 754 CDN is to use the value provided through the CDNI Metadata 755 interface for the corresponding content. Note the Session ID 756 field along with Content Collection ID may be used for HTTP 757 Adaptive Streaming content. 759 MI-21 [MED] The CDNI Metadata Distribution interface should allow 760 the Upstream CDN to signal to the Downstream CDN the 761 Authorization Group ID value for all the related HTTP Adaptive 762 Streaming content (i.e. manifest file and chunks). The 763 authorization result of a content (e.g. manifest file) is 764 transferred over to related content (e.g. chunks). 766 8. CDNI Logging Interface Requirements 768 This section identifies the requirements related to the CDNI Logging 769 interface (LI). We observe that while the CDNI Logging interface is 770 currently discussed as a single "protocol", further analysis will 771 determine whether the corresponding requirements are to be realized 772 over a single interface and protocol, or over multiple interfaces and 773 protocols. 775 LI-1 [HIGH] The CDNI logging architecture and interface shall 776 ensure reliable transfer of CDNI logging information across 777 CDNs. 779 LI-2 [HIGH] The CDNI Logging interface shall provide logging of 780 deliveries and incomplete deliveries to User Agents performed 781 by the Downstream CDN as a result of request redirection by 782 the Upstream CDN. 784 LI-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface 785 should allow the Downstream CDN to report to the Upstream CDN 786 logging for deliveries and incomplete deliveries performed by 787 the Downstream CDN itself as well as logging for deliveries 788 and incomplete deliveries performed by cascaded CDNs on behalf 789 of the Downstream CDN. 791 LI-4 [HIGH] The CDNI Logging interface shall support batch/offline 792 exchange of logging records. 794 LI-5 [MED] The CDNI Logging interface should also support 795 additional timing constraints for some types of logging 796 records (e.g. near-real time for monitoring and analytics 797 applications) 799 LI-6 [HIGH] The CDNI Logging interface shall define a log file 800 format and a set of fields to be exported for various CDNI 801 logging events. 803 LI-7 [HIGH] The CDNI Logging interface shall define a transport 804 mechanism to exchange CDNI Logging files. 806 LI-8 [MED] The CDNI Logging interface should allow a CDN to query 807 another CDN for relevant current logging records (e.g. For 808 on-demand access to real-time logging information). 810 LI-9 [LOW] The CDNI Logging interface may support aggregate/ 811 summarized logs (e.g. total bytes delivered for a content 812 regardless of individual User Agents to which it was 813 delivered). 815 LI-10 [LOW] The CDNI Logging interface may support logging of 816 performance data for deliveries to User Agents performed by 817 the Downstream CDN as a result of request redirection by the 818 Upstream CDN. Performance data may include various traffic 819 statistics (the specific parameters are to be determined). 820 The CDNI Logging interface may support the Upstream CDN to 821 indicate the nature and contents of the performance data to be 822 reported by the Downstream CDN. 824 LI-11 [MED] The CDNI Logging interface should support logging of 825 consumed resources (e.g. storage, bandwidth) to the Upstream 826 CDN for deliveries where content is stored by the Downstream 827 CDN for delivery to User Agents. The information logged may 828 include the type of storage (e.g., Origin, Intermediate, Edge, 829 Cache) as well as the amount of storage (e.g., total GB, GB 830 used, per time period, per content domain) all of which may 831 impact the cost of the services. 833 LI-12 [MED] In the case of cascaded CDNs, the CDNI Logging interface 834 should support the Downstream CDN to report consumed resources 835 (e.g. storage, bandwidth) to the Upstream CDN where content is 836 stored by the Downstream CDN itself as well as logging for 837 storage resources when content storage is performed by 838 cascaded CDNs on behalf of the Downstream CDN. 840 LI-13 [HIGH] The CDNI Logging interface shall support logging of 841 deleted objects from the Downstream CDN to the Upstream CDN as 842 a result of explicit delete requests on via the CDNI Control 843 interface from the Upstream CDN. 845 LI-14 [HIGH] The CDNI Logging interface shall support extensibility 846 to allow proprietary information fields to be carried. These 847 information fields shall be agreed upon ahead of time between 848 the corresponding CDNs. 850 LI-15 [HIGH] The CDNI Logging interface shall support the exchange 851 of extensible log file formats to support proprietary 852 information fields. These information fields shall be agreed 853 upon ahead of time between the corresponding CDNs. 855 LI-16 [HIGH] The CDNI Logging interface shall allow a CDN to notify 856 another CDN about which CDNI logging information is available 857 for transfer and/or no longer available (e.g. it exceeded some 858 logging retention period or some logging retention volume). 860 LI-17 [MED] The CDNI Logging interface should support the ability 861 for the Downstream CDN to include the Content Collection ID 862 and Session ID fields in CDNI log entries generated for HTTP 863 Adaptive Streaming content. 865 9. CDNI Security Requirements 867 This section identifies the requirements related to the CDNI 868 security. Some of these are expected to affect multiple or all 869 protocols. 871 SEC-1 [HIGH] All the CDNI interface shall support secure operation 872 over unsecured IP connectivity (e.g. The Internet). This 873 includes authentication, confidentiality, integrity protection 874 as well as protection against spoofing and replay. 876 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 877 against Denial of Service attacks. This includes protection 878 against spoofed delivery requests sent by user agents directly 879 to a Downstream CDN attempting to appear as if they had been 880 redirected by a given Upstream CDN when they have not. 882 SEC-3 [MED] The CDNI solution should be able to ensure that for any 883 given request redirected to a Downstream CDN, the chain of CDN 884 Delegation (leading to that request being served by that CDN) 885 can be established with non-repudiation. 887 SEC-4 [MED] The CDNI solution should be able to ensure that the 888 Downstream CDN cannot spoof a transaction log attempting to 889 appear as if it corresponds to a request redirected by a given 890 Upstream CDN when that request has not been redirected by this 891 Upstream CDN. This ensures non-repudiation by the Upstream 892 CDN of transaction logs generated by the Downstream CDN for 893 deliveries performed by the Downstream CDN on behalf of the 894 Upstream CDN. 896 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 897 Upstream CDN that has credentials to acquire content from the 898 CSP origin server (or another CDN), to allow establishment of 899 credentials authorizing the Downstream CDN to acquire the 900 content from the CSP origin server (or the other CDN) (e.g. 901 In case the content cannot be acquired from the Upstream CDN). 903 10. IANA Considerations 905 This document makes no request of IANA. 907 Note to RFC Editor: this section may be removed on publication as an 908 RFC. 910 11. Security Considerations 912 This document discusses CDNI security requirements in Section 9. 914 12. Authors 916 This document reflects the contributions from the following authors: 918 Francois Le Faucheur 920 Cisco Systems 922 flefauch@cisco.com 924 Mahesh Viveganandhan 926 Cisco Systems 928 mvittal@cisco.com 930 Grant Watson 932 Alcatel-Lucent (Velocix) 934 gwatson@velocix.com 936 13. Acknowledgements 938 This document leverages the earlier work of the IETF CDI working 939 group in particular as documented in [I-D.cain-request-routing-req], 940 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 942 The authors would like to thank Gilles Bertrand, Christophe Caillet, 943 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 944 Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their 945 input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy 946 Tarapore, Mike Geller, and Ramki Krishnan contributed to this 947 document by addressing the requirements of the ATIS Cloud Services 948 Forum. 950 Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles 951 Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI 952 Metadata interface, and CDNI Logging interface, respectively. 954 14. Appendix: Requirements Mapping 956 The labels and numbers changed in version 6 of this document as part 957 of the requirements cleanup and structuring changes due to 958 introduction of the new CDNI request routing/Redirection Interface 959 and CDNI request routing/Footprint & Capabilities advertisement 960 interface. There are some CDNI drafts that have referenced the 961 requirements in this document. Therefore, the following table 962 provides the mapping of the requirement label and numbering. 964 +--------------------+-------------------------------+ 965 | Version 5 | Version 6 | 966 +--------------------+-------------------------------+ 967 | GEN-13 | Removed | 968 | GEN-14 | GEN-13 | 969 | CNTL-# | CI-# (label changed) | 970 | CNTL-1 | CI-1 and CI-3 | 971 | CNTL-2 to CNTL-9 | CI-4 to CI-11 | 972 | CNTL-10 | FCI-6 | 973 | CNTL-11 | CI-12 | 974 | CNTL-12 | CI-2 | 975 | REQ-# | RI-# or FCI-# (label changed) | 976 | REQ-1 to REQ-4 | FCI-1 to FCI-4 | 977 | REQ-5 to REQ-19 | RI-1 to RI-15 | 978 | REQ-20 | FCI-5 | 979 | META-# | MI-# (label changed) | 980 | META-13 | Removed | 981 | META-14 to META-22 | MI-13 to MI-21 | 982 | LOG-# | LI-# (label changed) | 983 | LOG-4 | Removed | 984 | LOG-5 to LOG-18 | LI-4 to LI-17 | 985 +--------------------+-------------------------------+ 987 Requirement Reference Mapping Table 989 15. References 990 15.1. Normative References 992 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 993 Distribution Network Interconnection (CDNI) Problem 994 Statement", RFC 6707, September 2012. 996 15.2. Informative References 998 [I-D.amini-cdi-distribution-reqs] 999 Amini, L., "Distribution Requirements for Content 1000 Internetworking", draft-amini-cdi-distribution-reqs-02 1001 (work in progress), November 2001. 1003 [I-D.cain-request-routing-req] 1004 Cain, B., "Request Routing Requirements for Content 1005 Internetworking", draft-cain-request-routing-req-03 (work 1006 in progress), November 2001. 1008 [I-D.gilletti-cdnp-aaa-reqs] 1009 "CDI AAA Requirements, 1010 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 1012 [I-D.ietf-cdni-framework] 1013 Peterson, L. and B. Davie, "Framework for CDN 1014 Interconnection", draft-ietf-cdni-framework-03 (work in 1015 progress), February 2013. 1017 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1018 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1019 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1021 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1022 K., and G. Watson, "Use Cases for Content Delivery Network 1023 Interconnection", RFC 6770, November 2012. 1025 Authors' Addresses 1027 Kent Leung (editor) 1028 Cisco Systems 1029 170 West Tasman Drive 1030 San Jose, CA 95134 1031 U.S.A. 1033 Phone: +1 408 526 5030 1034 Email: kleung@cisco.com 1035 Yiu Lee (editor) 1036 Comcast 1037 One Comcast Center 1038 Philadelphia, PA 19103 1039 U.S.A. 1041 Email: yiu_lee@cable.comcast.com