idnits 2.17.1 draft-ietf-cdni-requirements-06.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 746: '... an OPTIONAL mechanism allowi...' RFC 2119 keyword, line 751: '... mechanism MUST ignore this log ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 9, 2013) is 4028 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 897, but not defined == Missing Reference: 'HIGH' is mentioned on line 886, but not defined == Missing Reference: 'LOW' is mentioned on line 906, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: October 11, 2013 Comcast 6 April 9, 2013 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-06 11 Abstract 13 Content Delivery Networks (CDNs) are frequently used for large-scale 14 content delivery. As a result, existing CDN providers are scaling up 15 their infrastructure and many Network Service Providers (NSPs) are 16 deploying their own CDNs. There is a requirement for interconnecting 17 standalone CDNs so that their collective CDN footprint can be 18 leveraged for the end-to-end delivery of content from Content Service 19 Providers (CSPs) to end users. The Content Distribution Network 20 Interconnection (CDNI) working group has been chartered to develop an 21 interoperable and scalable solution for such CDN interconnection. 23 The goal of the present document is to outline the requirements for 24 the solution and interfaces to be specified by the CDNI working 25 group. This draft is a work in progress and requirements may be 26 added, modified, or removed by the working group. 28 Requirements Language 30 The key words "High Priority", "Medium Priority" and "Low Priority" 31 in this document are to be interpreted in the following way: 33 o "High Priority" indicates requirements that are to be supported by 34 the CDNI interfaces. A requirement is stated as "High Priority" 35 when it is established by the working group that it can be met 36 without compromising the targeted schedule for WG deliverables, or 37 when it is established that specifying a solution without meeting 38 this requirement would not make sense and would justify re- 39 adjusting the WG schedule, or both. This is tagged as "[HIGH]". 41 o "Medium Priority" indicates requirements that are to be supported 42 by the CDNI interfaces unless the WG realizes at a later stage 43 that attempting to meet this requirement would compromise the 44 overall WG schedule (for example it would involve complexities 45 that would result in significantly delaying the deliverables). 46 This is tagged as "[MED]". 48 o "Low Priority" indicates requirements that are to be supported by 49 the CDNI interfaces provided that dedicating WG resources to this 50 work does not prevent addressing "High Priority" and "Medium 51 Priority" requirements and that attempting to meet this 52 requirement would not compromise the overall WG schedule. This is 53 tagged as "[LOW]". 55 Status of this Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on October 11, 2013. 72 Copyright Notice 74 Copyright (c) 2013 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 91 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 92 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6 93 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 94 5. CDNI Request Routing/Redirection Interface Requirements . . . 10 95 6. CDNI Request Routing/Footprint & Capabilities 96 Advertisement Interface Requirements . . . . . . . . . . . . . 12 97 7. CDNI Metadata Distribution Interface Requirements . . . . . . 14 98 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18 99 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 104 14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22 105 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 107 15.2. Informative References . . . . . . . . . . . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 110 1. Introduction 112 The volume of video and multimedia content delivered over the 113 Internet is rapidly increasing and expected to continue doing so in 114 the future. In the face of this growth, Content Delivery Networks 115 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 116 content, improved quality of experience for end users, and increased 117 robustness of delivery. For these reasons CDNs are frequently used 118 for large-scale content delivery. As a result, existing CDN 119 providers are scaling up their infrastructure and many Network 120 Service Providers (NSPs) are deploying their own CDNs. It is 121 generally desirable that a given content item can be delivered to an 122 End User regardless of that End User's location or attachment 123 network. However, the footprint of a given CDN in charge of 124 delivering a given content may not expand close enough to the End 125 User's current location or attachment network to realize the cost 126 benefit and user experience that a more distributed CDN would 127 provide. This creates a requirement for interconnecting standalone 128 CDNs so that their collective CDN footprint can be leveraged for the 129 end-to-end delivery of content from Content Service Providers (CSPs) 130 to End Users. The Content Distribution Network Interconnection 131 (CDNI) working group has been chartered to develop an interoperable 132 and scalable solution for such CDN interconnection. 134 [RFC6707] outlines the problem area that the CDNI working group is 135 chartered to address. [RFC6770] discusses the use cases for CDN 136 Interconnection. [I-D.davie-cdni-framework] discusses the technology 137 framework for the CDNI solution and interfaces. 139 The goal of the present document is to document the requirements for 140 the CDNI solution and interfaces. In order to meet the timelines 141 defined in the working group charter, the present document 142 categorizes the CDNI requirements as "High Priority", "Medium 143 Priority", and "Low Priority". 145 1.1. Terminology 147 This document uses the terminology defined in section 1.1 of 148 [I-D.davie-cdni-framework]. 150 2. CDNI Model and CDNI Interfaces 152 For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating 153 the CDNI problem area and the CDNI protocols is replicated below. 155 -------- 156 / \ 157 | CSP | 158 \ / 159 -------- 160 * 161 * 162 * /\ 163 * / \ 164 ---------------------- |CDNI| ---------------------- 165 / Upstream CDN \ | | / Downstream CDN \ 166 | +-------------+ | Control Interface| +-------------+ | 167 |******* Control |<======|====|========>| Control *******| 168 |* +------*----*-+ | | | | +-*----*------+ *| 169 |* * * | | | | * * *| 170 |* +------*------+ | Logging Interface| +------*------+ *| 171 |* ***** Logging |<======|====|========>| Logging ***** *| 172 |* * +-*-----------+ | | | | +-----------*-+ * *| 173 |* * * * | Request Routing | * * * *| 174 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 175 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 176 . |* * * +-------------+.| | | | +-------------+ * * *| . 177 . |* * * . CDNI Metadata | * * *| . 178 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 179 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 180 . |* * * | | | . \ / | | | * * *| . 181 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 182 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 183 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 184 . |******* +---------+| | Acquisition | |+----------+ *******| . 185 . | +-------------+ | | +-------*-----+ | . 186 . \ / \ * / . 187 . ---------------------- ---------*------------ . 188 . * . 189 . * Delivery . 190 . * . 191 . +--*---+ . 192 ...............Request.............................| User |..Request.. 193 | Agent| 194 +------+ 196 <==> interfaces inside the scope of CDNI 198 **** interfaces outside the scope of CDNI 199 .... interfaces outside the scope of CDNI 201 Figure 1: CDNI Model and CDNI Interfaces 203 3. Generic CDNI Requirements 205 This section identifies generic requirements independent of the 206 individual CDNI interfaces. Some of those are expected to affect 207 multiple or all interfaces. 209 GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or 210 leverage existing IETF protocols. 212 GEN-2 [HIGH] The CDNI solution shall not require a change, or an 213 upgrade, to the User Agent to benefit from content delivery 214 through interconnected CDNs. 216 GEN-3 [HIGH] The CDNI solution shall not require a change, or an 217 upgrade, to the Content Service Provider to benefit from 218 content delivery through interconnected CDNs. 220 GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN 221 information to be exposed to other CDNs for effective and 222 efficient delivery of the content. Examples of intra-CDN 223 information include surrogate topology, surrogate status, 224 cached content, etc. 226 GEN-5 [HIGH] The CDNI solution shall support delivery to the user 227 agent based on HTTP [RFC2616]. (Note that while delivery and 228 acquisition "data plane" protocols are out of the CDNI 229 solution scope, the CDNI solution "control plane" protocols 230 are expected to participate in enabling, selecting or 231 facilitating operations of such acquisition and delivery 232 protocols. Hence it is useful to state requirements on the 233 CDNI solution in terms of which acquisition and delivery 234 protocols). 236 GEN-6 [HIGH] The CDNI solution shall support acquisition across 237 CDNs based on HTTP [RFC2616]. (The note above applies to 238 this requirement too) 240 GEN-7 [LOW] The CDNI solution may support delivery to the user 241 agent based on protocols other than HTTP. 243 GEN-8 [LOW] The CDNI solution may support acquisition across CDNs 244 based on protocols other than HTTP. 246 GEN-9 [MED] The CDNI solution should support cascaded CDN 247 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 248 to an arbitrary number of levels beyond the first level. 250 GEN-10 [MED] The CDNI solution should support an arbitrary topology 251 of interconnected CDNs (i.e. the CDN topology cannot be 252 restricted to a tree, a loop-free topology, etc.). 254 GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI 255 information exchange. 257 GEN-12 [HIGH] When making use of third party reference, the CDNI 258 solution shall consider the potential issues associated with 259 the use of various format of third-party references (e.g. 260 NAT or IPv4/IPv6 translation potentially breaking third-party 261 references based on an IP addresses such as URI containing 262 IPv4 or IPv6 address litterals, split DNS situations 263 potentially breaking third-party references based on DNS 264 fully qualified domain names) and wherever possible avoid, 265 minimize or mitigate the associated risks based on the 266 specifics of the environments where the reference is used 267 (e.g. likely or unlikely presence of NAT in the path). In 268 particular, this applies to situations where the CDNI 269 solution needs to construct and convey uniform resource 270 identifiers for directing/redirecting a content request, as 271 well as to situations where the CDNI solution needs to pass 272 on a third party reference (e.g. to identify a User Agent) in 273 order to allow another entity to make a more informed 274 decision (e.g. make a more informed request routing decision 275 by attempting to derive location information from the third 276 party reference). 278 GEN-13 [HIGH] The CDNI solution shall support HTTP Adaptive 279 Streaming content. 281 4. CDNI Control Interface Requirements 283 The primary purpose of the CDNI Control interface (CI) is to initiate 284 the interconnection across CDNs, bootstrap the other CDNI interfaces 285 and trigger actions into the Downstream CDN by the Upstream CDN (such 286 as delete object from caches or trigger pre-positioned content 287 acquisition). We observe that while the CDNI Control interface is 288 currently discussed as a single "protocol", further analysis will 289 determine whether the corresponding requirements are to be realized 290 over a single interface and protocol, or over multiple interfaces and 291 protocols. 293 CI-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN 294 to request that the Downstream CDN (and, if cascaded CDNs are 295 supported by the solution, that the potential cascaded 296 Downstream CDNs) delete an object or set of objects and/or its 297 CDNI metadata from the CDN surrogates and any storage. Only 298 the object(s) and CDNI metadata that pertain to the requesting 299 Upstream CDN are allowed to be purged. 301 CI-2 [MED] The CDNI Control interface should allow for multiple 302 content items identified by a Content Collection ID to be 303 purged using a single Content Purge action. 305 CI-3 [MED] The CDNI Control interface should allow the Upstream CDN 306 to request that the Downstream CDN (and, if cascaded CDNs are 307 supported by the solution, that the potential cascaded 308 Downstream CDNs) mark an object or set of objects and/or its 309 CDNI metadata as "stale" and revalidate them before they are 310 delivered again. 312 CI-4 [HIGH] The CDNI Control interface shall allow the Downstream 313 CDN to report on the completion of these actions (by itself, 314 and if cascaded CDNs are supported by the solution, by 315 potential cascaded Downstream CDNs), in a manner appropriate 316 for the action (e.g. synchronously or asynchronously). The 317 confirmation receipt should include a success or failure 318 indication. The failure indication is used if the Downstream 319 CDN cannot delete the content in its storage. 321 CI-5 [MED] The CDNI Control interface should support initiation and 322 control by the Upstream CDN of pre-positioned CDNI metadata 323 acquisition by the Downstream CDN. 325 CI-6 [MED] The CDNI Control interface should support initiation and 326 control by the Upstream CDN of pre-positioned content 327 acquisition by the Downstream CDN. 329 CI-7 [LOW] The CDNI Control interface may allow a CDN to establish, 330 update and terminate a CDN interconnection with another CDN 331 whereby one CDN can act as a Downstream CDN for the other CDN 332 (that acts as an Upstream CDN). 334 CI-8 [LOW] The CDNI Control interface may allow control of the CDNI 335 interconnection between any two CDNs independently for each 336 direction (i.e. For the direction where CDN1 is the Upstream 337 CDN and CDN2 is the Downstream CDN, and for the direction 338 where CDN2 is the Upstream CDN and CDN1 is the Downstream 339 CDN). 341 CI-9 [LOW] The CDNI Control interface may allow bootstrapping of 342 the Request-Routing interface. For example, this can 343 potentially include: 345 * negotiation of the Request-Routing method (e.g. DNS vs 346 HTTP, if more than one method is specified) 348 * discovery of the Request-Routing protocol endpoints 350 * information necessary to establish secure communication 351 between the Request-Routing protocol endpoints. 353 CI-10 [LOW] The CDNI Control interface may allow bootstrapping of 354 the CDNI Metadata interface. This information could, for 355 example, include: 357 * discovery of the CDNI Metadata signaling protocol 358 endpoints 360 * information necessary to establish secure communication 361 between the CDNI Metadata signaling protocol endpoints. 363 CI-11 [LOW] The CDNI Control interface may allow bootstrapping of 364 the Content Acquisition interface. This could, for example, 365 include exchange and negotiation of the Content Acquisition 366 protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP, 367 ATIS C2). 369 CI-12 [LOW] The CDNI Control interface may allow bootstrapping of 370 the CDNI Logging interface. This information could, for 371 example, include: 373 * discovery of the Logging protocol endpoints 375 * information necessary to establish secure communication 376 between the Logging protocol endpoints 378 * negotiation/definition of the log file format and set of 379 fields to be exported through the Logging protocol, with 380 some granularity (e.g. On a per content type basis). 382 * negotiation/definition of parameters related to 383 transaction Logs export (e.g., export protocol, file 384 compression, export frequency, directory). 386 5. CDNI Request Routing/Redirection Interface Requirements 388 The main function of the CDNI request routing/ Redirection (RI) 389 interface is to allow the Request-Routing systems in interconnected 390 CDNs to communicate to facilitate redirection of the request across 391 CDNs. 393 RI-1 [HIGH] The CDNI request routing/Redirection interface shall 394 support efficient request-routing for small objects. This 395 may, for example, call for a mode of operation (e.g. DNS- 396 based request routing) where freshness and accuracy of CDN/ 397 Surrogate selection can be traded-off against reduced request- 398 routing load (e.g. Via lighter-weight queries and caching of 399 request-routing decisions). 401 RI-2 [HIGH] The CDNI request routing/Redirection interface shall 402 support efficient request-routing for large objects. This 403 may, for example, call for a mode of operation (e.g. HTTP- 404 based request routing) where freshness and accuracy of CDN/ 405 Surrogate selection justifies a per-request decision and a 406 per-request CDNI Request-Routing protocol call. 408 RI-3 [HIGH] The CDNI request routing/Redirection interface shall 409 support recursive CDNI request routing. 411 RI-4 [HIGH] The CDNI request routing/Redirection interface shall 412 support iterative CDNI request routing. 414 RI-5 [MED] In case of detection of a request redirection loop, the 415 CDNI request routing/Redirection interface's loop prevention 416 mechanism should allow routing of the request by avoiding the 417 loop (as opposed to the request loop being simply interrupted 418 without routing the request). 420 RI-6 [MED] The CDNI request routing/Redirection interface should 421 support a mechanism allowing enforcment of a limit on the 422 number of successive CDN redirections for a given request. 424 RI-7 [LOW] The CDNI request routing/Redirection interface may 425 support a mechanism allowing an Upstream CDN to avoid 426 redirecting a request to a Downstream CDN if that is likely to 427 result in the total redirection time exceeding some limit. 429 RI-8 [HIGH] The CDNI request routing/Redirection interface shall 430 allow the Upstream CDN to include, in the query to the 431 Downstream CDN, the necessary information to allow the 432 Downstream CDN to process the redirection query. This could, 433 for example, include: 435 * information from which the location of the user-agent that 436 originated the request can be inferred (e.g. User Agent 437 fully qualified domain name in case of HTTP-based Request 438 Routing, DNS Proxy fully qualified domain name in case of 439 DNS-based Request Routing) 441 * requested resource information (e.g. Resource URI in case 442 of HTTP-based Request Routing, Resource hostname in case 443 of DNS-based Request Routing) 445 * additional available request information (e.g. request 446 headers in case of HTTP-based Request Routing). 448 RI-9 [LOW] The CDNI request routing/Redirection interface may also 449 allow the Upstream CDN to convey information pointing to CDNI 450 metadata applicable (individually or through inheritance) to 451 the requested content. For illustration, the CDNI metadata 452 pointed to could potentially include metadata that is 453 applicable to any content, metadata that is applicable to a 454 content collection (to which the requested content belongs) 455 and/or metadata that is applicable individually to the 456 requested content. 458 RI-10 [HIGH] The CDNI request routing/Redirection interface shall 459 allow the Downstream CDN to include the following information 460 in the response to the Upstream CDN: 462 * status code, in particular indicating acceptance or 463 rejection of request (e.g. Because the Downstream CDN is 464 unwilling or unable to serve the request). In case of 465 rejection, an error code is also to be provided, which 466 allows the Upstream CDN to react appropriately (e.g. 467 Select another Downstream CDN, or serve the request 468 itself) 470 * redirection information (e.g. Resource URI in case of 471 HTTP-based Request Routing, equivalent of a DNS record in 472 case of DNS-based Request Routing). 474 RI-11 [HIGH] The CDNI request routing/Redirection interface shall 475 allow for per-chunk request routing of HTTP Adaptive Streaming 476 content. 478 RI-12 [LOW] The CDNI request routing/Redirection interface may allow 479 the Upstream CDN to use the information conveyed by the 480 Downstream CDN during the Recursive Request Routing process to 481 rewrite an HTTP Adaptive Streaming manifest file. 483 RI-13 [LOW] The CDNI Request-Routing interface may allow the 484 Upstream CDN to re-sign the invariant portion of the chunk 485 URIs embedded in the HTTP Adaptive Streaming manifest file. 487 RI-14 [MED] The CDNI request routing/Redirection interface should 488 allow the use of HTTP cookie to associate the chunks with the 489 HTTP Adaptive Stream manifest file (which is verified by the 490 URI signature) based on the Authorization Group ID (which is 491 an identifier used to correlate the manifest file to the 492 related chunks). 494 RI-15 [MED] The CDNI request routing/Redirection interface should 495 allow for an efficient method of transferring request routing 496 information for multiple chunks from the Downstream CDN to the 497 Upstream CDN as part of the recursive request routing process. 499 6. CDNI Request Routing/Footprint & Capabilities Advertisement 500 Interface Requirements 502 The main function of the CDNI Request Routing Footprint & 503 Capabilities Advertisement Interface (FCI) is to allow the Downstream 504 CDN to advertise the information regarding its footprint and 505 capabilities to the Upstream CDN. 507 FCI-1 [HIGH] The CDNI request routing/Footprint & Capabilities 508 advertisement interface shall allow the Downstream CDN to 509 communicate to the Upstream CDN coarse information about the 510 Downstream CDN ability and/or willingness to handle requests 511 from the Upstream CDN. For example, this could potentially 512 include a binary signal ("Downstream CDN ready/not-ready to 513 take additional requests from Upstream CDN") to be used in 514 case of excessive load or failure condition in the Downstream 515 CDN. 517 FCI-2 [MED] The CDNI request routing/Footprint & Capabilities 518 advertisement interface should allow the Downstream CDN to 519 communicate to the Upstream CDN aggregate information to 520 facilitate CDN selection during request routing, such as 521 Downstream CDN capabilities, resources and affinities (i.e. 522 Preferences or cost). This information could, for example, 523 include: 525 * supported content types and delivery protocols 527 * footprint (e.g. layer-3 coverage) 528 * a set of metrics/attributes (e.g. Streaming bandwidth, 529 storage resources, distribution and delivery priority) 531 * a set of affinities (e.g. Preferences, indication of 532 distribution/delivery fees) 534 * information to facilitate request redirection (e.g. 535 Reachability information of Downstream CDN Request Routing 536 system). 538 [Note: Some of this information - such as supported content 539 types and delivery protocols- may also potentially be taken 540 into account by the distribution system in the Upstream CDN 541 for pre-positioning of content and/or metadata in the 542 Downstream CDN in case of pre-positioned content acquisition 543 and/or pre-positioned CDNI metadata acquisition.] 545 FCI-3 [MED] In the case of cascaded redirection, the CDNI request 546 routing/Footprint & Capabilities advertisement interface 547 should allow the Downstream CDN to also include in the 548 information communicated to the Upstream CDN, information on 549 the capabilities, resources and affinities of CDNs to which 550 the Downstream CDN may (in turn) redirect requests received by 551 the Upstream CDN. In that case, the CDNI Request-Routing 552 interface shall prevent looping of such information exchange. 554 FCI-4 [LOW] The CDNI request routing/Footprint & Capabilities 555 advertisement interface may allow the Downstream CDN to 556 communicate to the Upstream CDN aggregate information on CDNI 557 administrative limits and policy. This information can be 558 taken into account by the Upstream CDN Request Routing system 559 in its CDN Selection decisions. This information could, for 560 example, include: 562 * maximum number of requests redirected by the Upstream CDN 563 to be served simultaneously by the Downstream CDN 565 * maximum aggregate volume of content (e.g. in Terabytes) to 566 be delivered by the Downstream CDN over a time period. 568 FCI-5 [MED] The CDNI request routing/Footprint & Capabilities 569 advertisement interface should support advertisement of the 570 following types of capabilities: 572 * delivery protocol (e.g., HTTP vs. RTMP) 574 * acquisition protocol (for acquiring content from an 575 Upstream CDN) 577 * redirection mode (e.g., DNS Redirection vs. HTTP 578 Redirection) 580 * capabilities related to CDNI Logging (e.g., supported 581 logging mechanisms) 583 * capabilities related to CDNI Metadata (e.g., authorization 584 algorithms or support for proprietary vendor metadata) 586 FCI-6 [LOW] The CDNI Control interface may allow exchange and 587 negotiation of delivery authorization mechanisms to be 588 supported across the CDNs (e.g. URI signature based 589 validation). 591 7. CDNI Metadata Distribution Interface Requirements 593 The primary function of the CDNI Metadata Distribution interface (MI) 594 is to allow the Distribution system in interconnected CDNs to 595 communicate to ensure Content Distribution Metadata with inter-CDN 596 scope can be exchanged across CDNs. We observe that while the CDNI 597 Metadata Distribution protocol is currently discussed as a single 598 "protocol", further analysis will determine whether the corresponding 599 requirements are to be realized over a single interface and protocol, 600 or over multiple interfaces and protocols. For example, a subset of 601 the CDNI metadata might be conveyed in-band along with the actual 602 content acquisition across CDNs (e.g. content MD5 in HTTP header) 603 while another subset might require an out-of-band interface & 604 protocol (e.g. geo-blocking information). 606 MI-1 [HIGH] The CDNI Metadata Distribution interface shall allow 607 the Upstream CDN to provide the Downstream CDN with content 608 distribution metadata of inter-CDN scope. 610 MI-2 [HIGH] The CDNI Metadata Distribution interface shall support 611 exchange of CDNI metadata for both the dynamic content 612 acquisition model and the pre-positioning content acquisition 613 model. 615 MI-3 [HIGH] The CDNI Metadata Distribution interface shall support 616 a mode where no, or a subset of, the Metadata is initially 617 communicated to the Downstream CDN along with information 618 about how/where to acquire the rest of the CDNI Metadata (i.e. 619 Dynamic CDNI metadata acquisition). 621 MI-4 [MED] The CDNI Metadata Distribution interface should support 622 a mode where all the relevant Metadata is initially 623 communicated to the Downstream CDN (i.e. Pre-positioned CDNI 624 metadata acquisition). 626 MI-5 [HIGH] Whether in the pre-positioned content acquisition model 627 or in the dynamic content acquisition model, the CDNI Metadata 628 Distribution interface shall provide the necessary information 629 to allow the Downstream CDN to acquire the content from an 630 upstream source (e.g. Acquisition protocol and Uniform 631 Resource Identifier in Upstream CDN- or rules to construct 632 this URI). 634 MI-6 [HIGH] The CDNI metadata shall allow signaling of one or more 635 upstream sources, where each upstream source can be in the 636 Upstream CDN, in another CDN, the CSP origin server or any 637 arbitrary source designated by the Upstream CDN. Note that 638 some upstream sources (e.g. the content origin server) may or 639 may not be willing to serve the content to the Downstream CDN, 640 if this policy is known to the Upstream CDN then it may omit 641 those sources when exchanging CDNI metadata. 643 MI-7 [HIGH] The CDNI Metadata Distribution interface (possibly in 644 conjunction with the CDNI Control interface) shall allow the 645 Upstream CDN to request addition and modification of CDNI 646 Metadata into the Downstream CDN. 648 MI-8 [HIGH] The CDNI Metadata Distribution interface (possibly in 649 conjunction with the CDNI Control interface) shall allow 650 removal of obsolete CDNI Metadata from the Downstream CDN 651 (this could, for example, be achieved via an explicit removal 652 request from the Upstream CDN or via expiration of a Time-To- 653 Live associated to the Metadata). 655 MI-9 [HIGH] The CDNI Metadata Distribution interface shall allow 656 association of CDNI Metadata at the granularity of individual 657 object. This is necessary to achieve fine-grain Metadata 658 distribution at the level of an individual object when 659 necessary. 661 MI-10 [HIGH] The CDNI Metadata Distribution interface shall allow 662 association of CDNI Metadata at the granularity of an object 663 set. This is necessary to achieve scalable distribution of 664 metadata when a large number of objects share the same 665 distribution policy. 667 MI-11 [HIGH] The CDNI Metadata Distribution interface shall support 668 multiple levels of inheritance with precedence to more 669 specific metadata. For example, the CDNI Metadata 670 Distribution protocol may support metadata that is applicable 671 to any content, metadata that is applicable to a content 672 collection and metadata that is applicable to an individual 673 content where content level metadata overrides content 674 collection metadata that overrides metadata for any content. 676 MI-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 677 that conflicting metadata with overlapping scope are prevented 678 or deterministically handled. 680 MI-13 [HIGH] The CDNI Metadata Distribution interface shall allow 681 signaling of content distribution control policies. For 682 example, this could potentially include: 684 * geo-blocking information (i.e. Information defining 685 geographical areas where the content is to be made 686 available or blocked) 688 * availability windows (i.e. Information defining time 689 windows during which the content is to be made available 690 or blocked; expiration time may also be included to remove 691 content) 693 * delegation whitelist/blacklist (i.e. Information defining 694 which Downstream CDNs the content may/may not be delivered 695 through) 697 MI-14 [HIGH] The CDNI Metadata interface shall be able to exchange a 698 set of metadata elements with specified semantics (e.g. start 699 of time window, end of time window). 701 MI-15 [HIGH] The CDNI Metadata interface shall allow exchange of 702 opaque metadata element, whose semantic is not defined in CDNI 703 but established by private CDN agreement. 705 MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow 706 signaling of authorization checks and validation that are to 707 be performed by the surrogate before delivery. For example, 708 this could potentially include: 710 * need to validate URI signed information (e.g. Expiry 711 time, Client IP address). 713 MI-17 [MED] The CDNI Metadata Distribution interface should allow 714 signaling of CDNI-relevant surrogate cache behavior 715 parameters. For example, this could potentially include: 717 * control of whether the query string of HTTP URI is to be 718 ignored by surrogate cache 720 * enforcement of caching directives by Downstream CDN that 721 are different than the ones signalled in the HTTP headers 722 (e.g. "Expires" field) 724 * rate-pacing by Downstream CDN for content delivery (e.g. 725 Progressive Download) 727 MI-18 [HIGH] The CDNI Metadata interface shall provide indication of 728 related content (e.g. HTTP Adaptive Bit Rate chunks) by the 729 Content Collection ID (CCID) metadata. This could be used by 730 the Downstream CDN for operations on the group of content. 731 For example, this could potentially include: 733 * content acquisition for the entire set of files when one 734 piece of content is requested 736 * local file management and storage bundles all the files 737 for the content 739 * purging the entire set of files associated with the 740 content 742 * logging of the delivery of the content for the session 743 when at least one file in the set was delivered 745 MI-19 [MED] The CDNI Metadata Distribution interface should support 746 an OPTIONAL mechanism allowing the Upstream CDN to indicate to 747 the Downstream CDN which CDNI Log fields are to be provided 748 for all, for specific sets of, or for specific content items 749 delivered using HTTP. A CDNI implementation that does not 750 support this optional CDNI Metadata Distribution Interface 751 mechanism MUST ignore this log format indication and generate 752 CDNI logging format for HTTP Adaptive Streaming using the 753 default set of CDNI Logging fields. (Note: this function is 754 not concluded to be in Metadata Interface or Control 755 Interface) 757 MI-20 [MED] The CDNI Metadata Distribution interface should allow 758 the Upstream CDN to signal to the Downstream CDN the Content 759 Collection ID value for all, for specific sets of, or for 760 specific content items delivered using HTTP. Whenever the 761 Downstream CDN is instructed by the Upstream CDN to report the 762 Content Collection ID field in the log records, the Downstream 763 CDN is to use the value provided through the CDNI Metadata 764 interface for the corresponding content. Note the Session ID 765 field along with Content Collection ID may be used for HTTP 766 Adaptive Streaming content. 768 MI-21 [MED] The CDNI Metadata Distribution interface should allow 769 the Upstream CDN to signal to the Downstream CDN the 770 Authorization Group ID value for all the related HTTP Adaptive 771 Streamin content (i.e. manifest file and chunks). The 772 authorization result of a content (e.g. manifest file) is 773 transferred over to related content (e.g. chunks). [Ed: need 774 to improve wording?] 776 8. CDNI Logging Interface Requirements 778 This section identifies the requirements related to the CDNI Logging 779 interface (LI). We observe that while the CDNI Logging interface is 780 currently discussed as a single "protocol", further analysis will 781 determine whether the corresponding requirements are to be realized 782 over a single interface and protocol, or over multiple interfaces and 783 protocols. 785 LI-1 [HIGH] The CDNI logging architecture and interface shall 786 ensure reliable transfer of CDNI logging information across 787 CDNs. 789 LI-2 [HIGH] The CDNI Logging interface shall provide logging of 790 deliveries and incomplete deliveries to User Agents performed 791 by the Downstream CDN as a result of request redirection by 792 the Upstream CDN. 794 LI-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface 795 should allow the Downstream CDN to report to the Upstream CDN 796 logging for deliveries and incomplete deliveries performed by 797 the Downstream CDN itself as well as logging for deliveries 798 and incomplete deliveries performed by cascaded CDNs on behalf 799 of the Downstream CDN. 801 LI-4 [HIGH] The CDNI Logging interface shall support batch/offline 802 exchange of logging records. 804 LI-5 [MED] The CDNI Logging interface should also support 805 additional timing constraints for some types of logging 806 records (e.g. near-real time for monitoring and analytics 807 applications) 809 LI-6 [HIGH] The CDNI Logging interface shall define a log file 810 format and a set of fields to be exported for various CDNI 811 logging events. 813 LI-7 [HIGH] The CDNI Logging interface shall define a transport 814 mechanism to exchange CDNI Logging files. 816 LI-8 [MED] The CDNI Logging interface should allow a CDN to query 817 another CDN for relevant current logging records (e.g. For 818 on-demand access to real-time logging information). 820 LI-9 [LOW] The CDNI Logging interface may support aggregate/ 821 summarized logs (e.g. total bytes delivered for a content 822 regardless of individual User Agents to which it was 823 delivered). 825 LI-10 [LOW] The CDNI Logging interface may support logging of 826 performance data for deliveries to User Agents performed by 827 the Downstream CDN as a result of request redirection by the 828 Upstream CDN. Performance data may include various traffic 829 statistics (the specific parameters are to be determined). 830 The CDNI Logging interface may support the Upstream CDN to 831 indicate the nature and contents of the performance data to be 832 reported by the Downstream CDN. 834 LI-11 [MED] The CDNI Logging interface should support logging of 835 consumed resources (e.g. storage, bandwidth) to the Upstream 836 CDN for deliveries where content is stored by the Downstream 837 CDN for delivery to User Agents. The information logged may 838 include the type of storage (e.g., Origin, Intermediate, Edge, 839 Cache) as well as the amount of storage (e.g., total GB, GB 840 used, per time period, per content domain) all of which may 841 impact the cost of the services. 843 LI-12 [MED] In the case of cascaded CDNs, the CDNI Logging interface 844 should support the Downstream CDN to report consumed resources 845 (e.g. storage, bandwidth) to the Upstream CDN where content is 846 stored by the Downstream CDN itself as well as logging for 847 storage resources when content storage is performed by 848 cascaded CDNs on behalf of the Downstream CDN. 850 LI-13 [HIGH] The CDNI Logging interface shall support logging of 851 deleted objects from the Downstream CDN to the Upstream CDN as 852 a result of explicit delete requests on via the CDNI Control 853 interface from the Upstream CDN. 855 LI-14 [HIGH] The CDNI Logging interface shall support extensibility 856 to allow proprietary information fields to be carried. These 857 information fields must be agreed upon ahead of time between 858 the corresponding CDNs. 860 LI-15 [HIGH] The CDNI Logging interface shall support the exchange 861 of extensible log file formats to support proprietary 862 information fields. These information fields must be agreed 863 upon ahead of time between the corresponding CDNs. 865 LI-16 [HIGH] The CDNI Logging interface shall allow a CDN to notify 866 another CDN about which CDNI logging information is available 867 for transfer and/or no longer available (e.g. it exceeded some 868 logging retention period or some logging retention volume). 870 LI-17 [MED] The CDNI Logging interface should support the ability 871 for the Downstream CDN to include the Content Collection ID 872 and Session ID fields in CDNI log entries generated for HTTP 873 Adaptive Streaming content. 875 9. CDNI Security Requirements 877 This section identifies the requirements related to the CDNI 878 security. Some of those are expected to affect multiple or all 879 protocols. 881 SEC-1 [HIGH] All the CDNI interface shall support secure operation 882 over unsecured IP connectivity (e.g. The Internet). This 883 includes authentication, confidentiality, integrity protection 884 as well as protection against spoofing and replay. 886 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 887 against Denial of Service attacks. This includes protection 888 against spoofed delivery requests sent by user agents directly 889 to a Downstream CDN attempting to appear as if they had been 890 redirected by a given Upstream CDN when they have not. 892 SEC-3 [MED] The CDNI solution should be able to ensure that for any 893 given request redirected to a Downstream CDN, the chain of CDN 894 Delegation (leading to that request being served by that CDN) 895 can be established with non-repudiation. 897 SEC-4 [MED] The CDNI solution should be able to ensure that the 898 Downstream CDN cannot spoof a transaction log attempting to 899 appear as if it corresponds to a request redirected by a given 900 Upstream CDN when that request has not been redirected by this 901 Upstream CDN. This ensures non-repudiation by the Upstream 902 CDN of transaction logs generated by the Downstream CDN for 903 deliveries performed by the Downstream CDN on behalf of the 904 Upstream CDN. 906 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 907 Upstream CDN that has credentials to acquire content from the 908 CSP origin server (or another CDN), to allow establishment of 909 credentials authorizing the Downstream CDN to acquire the 910 content from the CSP origin server (or the other CDN) (e.g. 911 In case the content cannot be acquired from the Upstream CDN). 913 10. IANA Considerations 915 This document makes no request of IANA. 917 Note to RFC Editor: this section may be removed on publication as an 918 RFC. 920 11. Security Considerations 922 This document discusses CDNI security requirements in Section 9. 924 12. Authors 926 This document reflects the contributions from the following authors: 928 Francois Le Faucheur 930 Cisco Systems 932 flefauch@cisco.com 934 Mahesh Viveganandhan 936 Cisco Systems 938 mvittal@cisco.com 940 Grant Watson 942 BT 943 grant.watson@bt.com 945 13. Acknowledgements 947 This document leverages the earlier work of the IETF CDI working 948 group in particular as documented in [I-D.cain-request-routing-req], 949 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 951 The authors would like to thank Gilles Bertrand, Christophe Caillet, 952 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 953 Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their 954 input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy 955 Tarapore, Mike Geller, and Ramki Krishnan contributed to this 956 document by addressing the requirements of the ATIS Cloud Services 957 Forum. 959 Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles 960 Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI 961 Metadata interface, and CDNI Logging interface, respectively. 963 14. Appendix: Requirements Mapping 965 The labels and numbers changed in version 6 of this document as part 966 of the requirements cleanup and structuring changes due to 967 introduction of the new CDNI request routing/Redirection Interface 968 and CDNI request routing/Footprint & Capabilities advertisement 969 interface. There are some CDNI drafts that have referenced the 970 requirements in this document. Therefore, the following table 971 provides the mapping of the requirement label and numbering. 973 +--------------------+-------------------------------+ 974 | Version 5 | Version 6 | 975 +--------------------+-------------------------------+ 976 | GEN-13 | Removed | 977 | GEN-14 | GEN-13 | 978 | CNTL-# | CI-# (label changed) | 979 | CNTL-1 | CI-1 and CI-3 | 980 | CNTL-2 to CNTL-9 | CI-4 to CI-11 | 981 | CNTL-10 | FCI-6 | 982 | CNTL-11 | CI-12 | 983 | CNTL-12 | CI-2 | 984 | REQ-# | RI-# or FCI-# (label changed) | 985 | REQ-1 to REQ-4 | FCI-1 to FCI-4 | 986 | REQ-5 to REQ-19 | RI-1 to RI-15 | 987 | REQ-20 | FCI-5 | 988 | META-# | MI-# (label changed) | 989 | META-13 | Removed | 990 | META-14 to META-22 | MI-13 to MI-21 | 991 | LOG-# | LI-# (label changed) | 992 | LOG-4 | Removed | 993 | LOG-5 to LOG-18 | LI-4 to LI-17 | 994 +--------------------+-------------------------------+ 996 Requirement Reference Mapping Table 998 15. References 1000 15.1. Normative References 1002 [I-D.davie-cdni-framework] 1003 Davie, B. and L. Peterson, "Framework for CDN 1004 Interconnection", draft-davie-cdni-framework-01 (work in 1005 progress), October 2011. 1007 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1008 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1009 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1011 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1012 Distribution Network Interconnection (CDNI) Problem 1013 Statement", RFC 6707, September 2012. 1015 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1016 K., and G. Watson, "Use Cases for Content Delivery Network 1017 Interconnection", RFC 6770, November 2012. 1019 15.2. Informative References 1021 [I-D.amini-cdi-distribution-reqs] 1022 Amini, L., "Distribution Requirements for Content 1023 Internetworking", draft-amini-cdi-distribution-reqs-02 1024 (work in progress), November 2001. 1026 [I-D.cain-request-routing-req] 1027 Cain, B., "Request Routing Requirements for Content 1028 Internetworking", draft-cain-request-routing-req-03 (work 1029 in progress), November 2001. 1031 [I-D.gilletti-cdnp-aaa-reqs] 1032 "CDI AAA Requirements, 1033 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 1035 Authors' Addresses 1037 Kent Leung (editor) 1038 Cisco Systems 1039 170 West Tasman Drive 1040 San Jose, CA 95134 1041 U.S.A. 1043 Phone: +1 408 526 5030 1044 Email: kleung@cisco.com 1046 Yiu Lee (editor) 1047 Comcast 1048 One Comcast Center 1049 Philadelphia, PA 19103 1050 U.S.A. 1052 Email: yiu_lee@cable.comcast.com