idnits 2.17.1 draft-ietf-cdni-requirements-05.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 726: '... support an OPTIONAL mechanism al...' RFC 2119 keyword, line 731: '...erface 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 (February 23, 2013) is 4074 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 880, but not defined == Missing Reference: 'HIGH' is mentioned on line 869, but not defined == Missing Reference: 'LOW' is mentioned on line 889, 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: August 27, 2013 Comcast 6 February 23, 2013 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-05 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 August 27, 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 Interface Requirements . . . . . . . . . 10 95 6. CDNI Metadata Distribution Interface Requirements . . . . . . 14 96 7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 17 97 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 104 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 The volume of video and multimedia content delivered over the 110 Internet is rapidly increasing and expected to continue doing so in 111 the future. In the face of this growth, Content Delivery Networks 112 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 113 content, improved quality of experience for end users, and increased 114 robustness of delivery. For these reasons CDNs are frequently used 115 for large-scale content delivery. As a result, existing CDN 116 providers are scaling up their infrastructure and many Network 117 Service Providers (NSPs) are deploying their own CDNs. It is 118 generally desirable that a given content item can be delivered to an 119 End User regardless of that End User's location or attachment 120 network. However, the footprint of a given CDN in charge of 121 delivering a given content may not expand close enough to the End 122 User's current location or attachment network to realize the cost 123 benefit and user experience that a more distributed CDN would 124 provide. This creates a requirement for interconnecting standalone 125 CDNs so that their collective CDN footprint can be leveraged for the 126 end-to-end delivery of content from Content Service Providers (CSPs) 127 to End Users. The Content Distribution Network Interconnection 128 (CDNI) working group has been chartered to develop an interoperable 129 and scalable solution for such CDN interconnection. 131 [I-D.ietf-cdni-problem-statement] outlines the problem area that the 132 CDNI working group is chartered to address. 133 [I-D.ietf-cdni-use-cases] discusses the use cases for CDN 134 Interconnection. [I-D.davie-cdni-framework] discusses the technology 135 framework for the CDNI solution and interfaces. 137 The goal of the present document is to document the requirements for 138 the CDNI solution and interfaces. In order to meet the timelines 139 defined in the working group charter, the present document 140 categorizes the CDNI requirements as "High Priority", "Medium 141 Priority", and "Low Priority". 143 1.1. Terminology 145 This document uses the terminology defined in section 1.1 of 146 [I-D.davie-cdni-framework]. 148 2. CDNI Model and CDNI Interfaces 150 For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating 151 the CDNI problem area and the CDNI protocols is replicated below. 153 -------- 154 / \ 155 | CSP | 156 \ / 157 -------- 158 * 159 * 160 * /\ 161 * / \ 162 ---------------------- |CDNI| ---------------------- 163 / Upstream CDN \ | | / Downstream CDN \ 164 | +-------------+ | Control Interface| +-------------+ | 165 |******* Control |<======|====|========>| Control *******| 166 |* +------*----*-+ | | | | +-*----*------+ *| 167 |* * * | | | | * * *| 168 |* +------*------+ | Logging Interface| +------*------+ *| 169 |* ***** Logging |<======|====|========>| Logging ***** *| 170 |* * +-*-----------+ | | | | +-----------*-+ * *| 171 |* * * * | Request Routing | * * * *| 172 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 173 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 174 . |* * * +-------------+.| | | | +-------------+ * * *| . 175 . |* * * . CDNI Metadata | * * *| . 176 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 177 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 178 . |* * * | | | . \ / | | | * * *| . 179 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 180 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 181 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 182 . |******* +---------+| | Acquisition | |+----------+ *******| . 183 . | +-------------+ | | +-------*-----+ | . 184 . \ / \ * / . 185 . ---------------------- ---------*------------ . 186 . * . 187 . * Delivery . 188 . * . 189 . +--*---+ . 190 ...............Request.............................| User |..Request.. 191 | Agent| 192 +------+ 194 <==> interfaces inside the scope of CDNI 196 **** interfaces outside the scope of CDNI 197 .... interfaces outside the scope of CDNI 199 Figure 1: CDNI Model and CDNI Interfaces 201 3. Generic CDNI Requirements 203 This section identifies generic requirements independent of the 204 individual CDNI interfaces. Some of those are expected to affect 205 multiple or all interfaces. 207 GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or 208 leverage existing IETF protocols. 210 GEN-2 [HIGH] The CDNI solution shall not require a change, or an 211 upgrade, to the User Agent to benefit from content delivery 212 through interconnected CDNs. 214 GEN-3 [HIGH] The CDNI solution shall not require a change, or an 215 upgrade, to the Content Service Provider to benefit from 216 content delivery through interconnected CDNs. 218 GEN-4 [HIGH] The CDNI solution shall not require intra-CDN 219 information to be exposed to other CDNs for effective and 220 efficient delivery of the content. Examples of intra-CDN 221 information include surrogate topology, surrogate status, 222 cached content, etc. 224 GEN-5 [HIGH] The CDNI solution shall support delivery to the user 225 agent based on HTTP [RFC2616]. (Note that while delivery and 226 acquisition "data plane" protocols are out of the CDNI 227 solution scope, the CDNI solution "control plane" protocols 228 are expected to participate in enabling, selecting or 229 facilitating operations of such acquisition and delivery 230 protocols. Hence it is useful to state requirements on the 231 CDNI solution in terms of which acquisition and delivery 232 protocols). 234 GEN-6 [HIGH] The CDNI solution shall support acquisition across 235 CDNs based on HTTP [RFC2616]. 237 GEN-7 [LOW] The CDNI solution may support delivery to the user 238 agent based on protocols other than HTTP. 240 GEN-8 [LOW] The CDNI solution may support acquisition across CDNs 241 based on protocols other than HTTP. 243 GEN-9 [MED] The CDNI solution should support cascaded CDN 244 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 245 to an arbitrary number of levels beyond the first level. 247 GEN-10 [MED] The CDNI solution should support an arbitrary topology 248 of interconnected CDNs (i.e. the CDN topology cannot be 249 restricted to a tree, a loop-free topology, etc.). 251 GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI 252 information exchange. 254 GEN-12 [HIGH] When making use of third party reference, the CDNI 255 solution shall consider the potential issues associated with 256 the use of various format of third-party references (e.g. 257 NAT or IPv4/IPv6 translation potentially breaking third-party 258 references based on an IP addresses such as URI containing 259 IPv4 or IPv6 address litterals, split DNS situations 260 potentially breaking third-party references based on DNS 261 fully qualified domain names) and wherever possible avoid, 262 minimize or mitigate the associated risks based on the 263 specifics of the environments where the reference is used 264 (e.g. likely or unlikely presence of NAT in the path). In 265 particular, this applies to situations where the CDNI 266 solution needs to construct and convey uniform resource 267 identifiers for directing/redirecting a content request, as 268 well as to situations where the CDNI solution needs to pass 269 on a third party reference (e.g. to identify a User Agent) in 270 order to allow another entity to make a more informed 271 decision (e.g. make a more informed request routing decision 272 by attempting to derive location information from the third 273 party reference). 275 GEN-13 Removed. 277 GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive 278 Streaming content. 280 4. CDNI Control Interface Requirements 282 The primary purpose of the CDNI Control interface is to initiate the 283 interconnection across CDNs, bootstrap the other CDNI interfaces and 284 trigger actions into the Downstream CDN by the Upstream CDN (such as 285 delete object from caches or trigger pre-positioned content 286 acquisition). We observe that while the CDNI Control interface is 287 currently discussed as a single "protocol", further analysis will 288 determine whether the corresponding requirements are to be realized 289 over a single interface and protocol, or over multiple interfaces and 290 protocols. 292 CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream 293 CDN to request that the Downstream CDN (and, if cascaded 294 CDNs are supported by the solution, that the potential 295 cascaded Downstream CDNs) perform the following actions on 296 an object or object set: 298 * Mark an object or set of objects and/or its CDNI 299 metadata as "stale" and revalidate them before they are 300 delivered again 302 * Delete an object or set of objects and/or its CDNI 303 metadata from the CDN surrogates and any storage. Only 304 the object(s) and CDNI metadata that pertain to the 305 requesting Upstream CDN are allowed to be purged. 307 CNTL-2 [HIGH] The CDNI Control interface shall allow the Downstream 308 CDN to report on the completion of these actions (by itself, 309 and if cascaded CDNs are supported by the solution, by 310 potential cascaded Downstream CDNs), in a manner appropriate 311 for the action (e.g. synchronously or asynchronously). The 312 confirmation receipt should include a success or failure 313 indication. The failure indication is used if the 314 Downstream CDN cannot delete the content in its storage. 316 CNTL-3 [HIGH] The CDNI Control interface shall support initiation 317 and control by the Upstream CDN of pre-positioned CDNI 318 metadata acquisition by the Downstream CDN. 320 CNTL-4 [MED] The CDNI Control interface should support initiation 321 and control by the Upstream CDN of pre-positioned content 322 acquisition by the Downstream CDN. 324 CNTL-5 [LOW] The CDNI Control interface may allow a CDN to 325 establish, update and terminate a CDN interconnection with 326 another CDN whereby one CDN can act as a Downstream CDN for 327 the other CDN (that acts as an Upstream CDN). 329 CNTL-6 [LOW] The CDNI Control interface may allow control of the 330 CDNI interconnection between any two CDNs independently for 331 each direction (i.e. For the direction where CDN1 is the 332 Upstream CDN and CDN2 is the Downstream CDN, and for the 333 direction where CDN2 is the Upstream CDN and CDN1 is the 334 Downstream CDN). 336 CNTL-7 [LOW] The CDNI Control interface may allow bootstrapping of 337 the Request-Routing interface. For example, this can 338 potentially include: 340 * negotiation of the Request-Routing method (e.g. DNS vs 341 HTTP, if more than one method is specified) 343 * discovery of the Request-Routing protocol endpoints 345 * information necessary to establish secure communication 346 between the Request-Routing protocol endpoints. 348 CNTL-8 [LOW] The CDNI Control interface may allow bootstrapping of 349 the CDNI Metadata interface. This information could, for 350 example, include: 352 * discovery of the CDNI Metadata signaling protocol 353 endpoints 355 * information necessary to establish secure communication 356 between the CDNI Metadata signaling protocol endpoints. 358 CNTL-9 [LOW] The CDNI Control interface may allow bootstrapping of 359 the Content Acquisition interface. This could, for example, 360 include exchange and negotiation of the Content Acquisition 361 protocols to be used across the CDNs (e.g. HTTP, HTTPS, 362 FTP, ATIS C2). 364 CNTL-10 [LOW] The CDNI Control interface may allow exchange and 365 negotiation of delivery authorization mechanisms to be 366 supported across the CDNs (e.g. URI signature based 367 validation). 369 CNTL-11 [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 CNTL-12 [MED] The CDNI Control interface should allow for multiple 387 content items identified by a Content Collection ID to be 388 purged using a single Content Purge action. 390 5. CDNI Request Routing Interface Requirements 392 The main function of the Request Routing interface is to allow the 393 Request-Routing systems in interconnected CDNs to communicate to 394 facilitate redirection of the request across CDNs. 396 REQ-1 [HIGH] The CDNI Request-Routing interface shall allow the 397 Downstream CDN to communicate to the Upstream CDN coarse 398 information about the Downstream CDN ability and/or 399 willingness to handle requests from the Upstream CDN. For 400 example, this could potentially include a binary signal 401 ("Downstream CDN ready/not-ready to take additional requests 402 from Upstream CDN") to be used in case of excessive load or 403 failure condition in the Downstream CDN. 405 REQ-2 [MED] The CDNI Request-Routing interface should allow the 406 Downstream CDN to communicate to the Upstream CDN aggregate 407 information to facilitate CDN selection during request 408 routing, such as Downstream CDN capabilities, resources and 409 affinities (i.e. Preferences or cost). This information 410 could, for example, include: 412 * supported content types and delivery protocols 414 * footprint (e.g. layer-3 coverage) 416 * a set of metrics/attributes (e.g. Streaming bandwidth, 417 storage resources, distribution and delivery priority) 419 * a set of affinities (e.g. Preferences, indication of 420 distribution/delivery fees) 422 * information to facilitate request redirection (e.g. 423 Reachability information of Downstream CDN Request 424 Routing system). 426 [Note: Some of this information - such as supported content 427 types and delivery protocols- may also potentially be taken 428 into account by the distribution system in the Upstream CDN 429 for pre-positioning of content and/or metadata in the 430 Downstream CDN in case of pre-positioned content acquisition 431 and/or pre-positioned CDNI metadata acquisition.] 433 REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- 434 Routing interface shall allow the Downstream CDN to also 435 include in the information communicated to the Upstream CDN, 436 information on the capabilities, resources and affinities of 437 CDNs to which the Downstream CDN may (in turn) redirect 438 requests received by the Upstream CDN. In that case, the 439 CDNI Request-Routing interface shall prevent looping of such 440 information exchange. 442 REQ-4 [LOW] The CDNI Request-Routing interface may allow the 443 Downstream CDN to communicate to the Upstream CDN aggregate 444 information on CDNI administrative limits and policy. This 445 information can be taken into account by the Upstream CDN 446 Request Routing system in its CDN Selection decisions. This 447 information could, for example, include: 449 * maximum number of requests redirected by the Upstream CDN 450 to be served simultaneously by the Downstream CDN 452 * maximum aggregate volume of content (e.g. in Terabytes) 453 to be delivered by the Downstream CDN over a time period. 455 REQ-5 [HIGH] The CDNI Request-Routing architecture and interface 456 shall support efficient request-routing for small objects. 457 This may, for example, call for a mode of operation (e.g. 458 DNS-based request routing) where freshness and accuracy of 459 CDN/Surrogate selection can be traded-off against reduced 460 request-routing load (e.g. Via lighter-weight queries and 461 caching of request-routing decisions). 463 REQ-6 [HIGH] The CDNI Request-Routing architecture and interface 464 shall support efficient request-routing for large objects. 465 This may, for example, call for a mode of operation (e.g. 466 HTTP-based request routing) where freshness and accuracy of 467 CDN/Surrogate selection justifies a per-request decision and 468 a per-request CDNI Request-Routing protocol call. 470 REQ-7 [HIGH] The CDNI Request-Routing architecture shall support 471 recursive CDNI request routing. 473 REQ-8 [HIGH] The CDNI Request-Routing architecture shall support 474 iterative CDNI request routing. 476 REQ-9 [MED] In case of detection of a request redirection loop, the 477 CDNI Request-Routing loop prevention mechanism should allow 478 routing of the request by avoiding the loop (as opposed to 479 the request loop being simply interrupted without routing the 480 request). 482 REQ-10 [MED] The CDNI Request-Routing protocol should support a 483 mechanism allowing enforcment of a limit on the number of 484 successive CDN redirections for a given request. 486 REQ-11 [LOW] The CDNI Request-Routing protocol may support a 487 mechanism allowing an Upstream CDN to avoid redirecting a 488 request to a Downstream CDN if that is likely to result in 489 the total redirection time exceeding some limit. 491 REQ-12 [HIGH] The CDNI Request-Routing protocol shall allow the 492 Upstream CDN to include, in the query to the Downstream CDN, 493 the necessary information to allow the Downstream CDN to 494 process the redirection query. This could, for example, 495 include: 497 * information from which the location of the user-agent 498 that originated the request can be inferred (e.g. User 499 Agent fully qualified domain name in case of HTTP-based 500 Request Routing, DNS Proxy fully qualified domain name in 501 case of DNS-based Request Routing) 503 * requested resource information (e.g. Resource URI in 504 case of HTTP-based Request Routing, Resource hostname in 505 case of DNS-based Request Routing) 507 * additional available request information (e.g. request 508 headers in case of HTTP-based Request Routing). 510 REQ-13 [LOW] The CDNI Request-Routing protocol may also allow the 511 Upstream CDN to convey information pointing to CDNI metadata 512 applicable (individually or through inheritance) to the 513 requested content. For illustration, the CDNI metadata 514 pointed to could potentially include metadata that is 515 applicable to any content, metadata that is applicable to a 516 content collection (to which the requested content belongs) 517 and/or metadata that is applicable individually to the 518 requested content. 520 REQ-14 [HIGH] The CDNI Request-Routing interface shall allow the 521 Downstream CDN to include the following information in the 522 response to the Upstream CDN: 524 * status code, in particular indicating acceptance or 525 rejection of request (e.g. Because the Downstream CDN is 526 unwilling or unable to serve the request). In case of 527 rejection, an error code is also to be provided, which 528 allows the Upstream CDN to react appropriately (e.g. 529 Select another Downstream CDN, or serve the request 530 itself) 532 * redirection information (e.g. Resource URI in case of 533 HTTP-based Request Routing, equivalent of a DNS record in 534 case of DNS-based Request Routing). 536 REQ-15 [HIGH] The CDNI Request-Routing interface shall allow for 537 per-chunk request routing of HTTP Adaptive Streaming content. 538 [Ed: chunk is treated as any content, is this needed?] 540 REQ-16 [MED] The CDNI Request-Routing interface should allow the 541 Upstream CDN to use the information conveyed by the 542 Downstream CDN during the Recursive Request Routing process 543 to rewrite an HTTP Adaptive Streaming manifest file. [Ed: 544 should this be LOW?] 546 REQ-17 [MED] The CDNI Request-Routing interface should allow the 547 Upstream CDN to re-sign the invariant portion of the chunk 548 URIs embedded in the HTTP Adaptive Streaming manifest file. 549 [Ed: should this be LOW?] 551 REQ-18 [MED] The CDNI Request-routing interface should allow the use 552 of HTTP cookie to associate the chunks with the HTTP Adaptive 553 Stream manifest file (which is verified by the URI signature) 554 basedon the Authorization Group ID (which is an identifier 555 used to correlate the manifest file to the related chunks). 556 [Ed: should this be LOW?] 558 REQ-19 [MED] The CDNI Request-Routing interface may allow for an 559 efficient method of transferring request routing information 560 for multiple chunks from the Downstream CDN to the Upstream 561 CDN as part of the recursive request routing process. [Ed: 562 should this be LOW?] 564 REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising 565 interface shall support advertisement of the following 566 capabilities: 568 * support for customized CDNI Logging 570 * support of Content Collection ID logging 572 * support for Session ID logging 574 6. CDNI Metadata Distribution Interface Requirements 576 The primary function of the CDNI Metadata Distribution interface is 577 to allow the Distribution system in interconnected CDNs to 578 communicate to ensure Content Distribution Metadata with inter-CDN 579 scope can be exchanged across CDNs. We observe that while the CDNI 580 Metadata Distribution protocol is currently discussed as a single 581 "protocol", further analysis will determine whether the corresponding 582 requirements are to be realized over a single interface and protocol, 583 or over multiple interfaces and protocols. For example, a subset of 584 the CDNI metadata might be conveyed in-band along with the actual 585 content acquisition across CDNs (e.g. content MD5 in HTTP header) 586 while another subset might require an out-of-band interface & 587 protocol (e.g. geo-blocking information). 589 META-1 [HIGH] The CDNI Metadata Distribution interface shall allow 590 the Upstream CDN to provide the Downstream CDN with content 591 distribution metadata of inter-CDN scope. 593 META-2 [HIGH] The CDNI Metadata Distribution interface shall 594 support exchange of CDNI metadata for both the dynamic 595 content acquisition model and the pre-positioning content 596 acquisition model. 598 META-3 [HIGH] The CDNI Metadata Distribution interface shall 599 support a mode where no, or a subset of, the Metadata is 600 initially communicated to the Downstream CDN along with 601 information about how/where to acquire the rest of the CDNI 602 Metadata (i.e. Dynamic CDNI metadata acquisition). 604 META-4 [MED] The CDNI Metadata Distribution interface should 605 support a mode where all the relevant Metadata is initially 606 communicated to the Downstream CDN (i.e. Pre-positioned 607 CDNI metadata acquisition). 609 META-5 [HIGH] Whether in the pre-positioned content acquisition 610 model or in the dynamic content acquisition model, the CDNI 611 Metadata Distribution interface shall provide the necessary 612 information to allow the Downstream CDN to acquire the 613 content from an upstream source (e.g. Acquisition protocol 614 and Uniform Resource Identifier in Upstream CDN- or rules to 615 construct this URI). 617 META-6 [HIGH] The CDNI metadata shall allow signaling of one or 618 more upstream sources, where each upstream source can be in 619 the Upstream CDN, in another CDN, the CSP origin server or 620 any arbitrary source designated by the Upstream CDN. Note 621 that some upstream sources (e.g. the content origin server) 622 may or may not be willing to serve the content to the 623 Downstream CDN, if this policy is known to the Upstream CDN 624 then it may omit those sources when exchanging CDNI 625 metadata. 627 META-7 [HIGH] The CDNI Metadata Distribution interface shall allow 628 the Upstream CDN to request addition and modification of 629 CDNI Metadata into the Downstream CDN. 631 META-8 [HIGH] The CDNI Metadata Distribution interface shall allow 632 removal of obsolete CDNI Metadata from the Downstream CDN 633 (this could, for example, be achieved via an explicit 634 removal request from the Upstream CDN or via expiration of a 635 Time-To-Live associated to the Metadata). 637 META-9 [HIGH] The CDNI Metadata Distribution interface shall allow 638 association of CDNI Metadata at the granularity of 639 individual object. This is necessary to achieve fine-grain 640 Metadata distribution at the level of an individual object 641 when necessary. 643 META-10 [HIGH] The CDNI Metadata Distribution interface shall allow 644 association of CDNI Metadata at the granularity of an object 645 set. This is necessary to achieve scalable distribution of 646 metadata when a large number of objects share the same 647 distribution policy. 649 META-11 [HIGH] The CDNI Metadata Distribution interface shall 650 support multiple levels of inheritance with precedence to 651 more specific metadata. For example, the CDNI Metadata 652 Distribution protocol may support metadata that is 653 applicable to any content, metadata that is applicable to a 654 content collection and metadata that is applicable to an 655 individual content where content level metadata overrides 656 content collection metadata that overrides metadata for any 657 content. 659 META-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 660 that conflicting metadata with overlapping scope are 661 prevented or deterministically handled. 663 META-13 Removed. 665 META-14 [HIGH] The CDNI Metadata Distribution interface shall allow 666 signaling of content distribution control policies. For 667 example, this could potentially include: 669 * geo-blocking information (i.e. Information defining 670 geographical areas where the content is to be made 671 available or blocked) 673 * availability windows (i.e. Information defining time 674 windows during which the content is to be made available 675 or blocked; expiration time may also be included to 676 remove content) 678 * delegation whitelist/blacklist (i.e. Information 679 defining which Downstream CDNs the content may/may not 680 be delivered through) 682 META-15 [HIGH] The CDNI Metadata interface shall be able to exchange 683 a set of well-accepted metadata elements with specified 684 semantics (e.g. start of time window, end of time window). 686 META-16 [HIGH] The CDNI Metadata interface shall allow exchange of 687 opaque metadata element, whose semantic is not defined in 688 CDNI but established by private CDN agreement. 690 META-17 [HIGH] The CDNI Metadata Distribution interface shall allow 691 signaling of authorization checks and validation that are to 692 be performed by the surrogate before delivery. For example, 693 this could potentially include: 695 * need to validate URI signed information (e.g. Expiry 696 time, Client IP address). 698 META-18 [LOW] The CDNI Metadata Distribution interface may allow 699 signaling of CDNI-relevant surrogate cache behavior 700 parameters. For example, this could potentially include: 702 * control of whether the query string of HTTP URI is to be 703 ignored by surrogate cache 705 * content revalidation parameters (e.g. TTL) 707 META-19 [HIGH] The CDNI Metadata interface shall provide indication 708 of related content (e.g. HTTP Adaptive Bit Rate chunks) by 709 the Content Collection ID (CCID) metadata. This could be 710 used by the Downstream CDN for operations on the group of 711 content. For example, this could potentially include: 713 * content acquisition for the entire set of files when one 714 piece of content is requested 716 * local file management and storage bundles all the files 717 for the content 719 * purging the entire set of files associated with the 720 content 722 * logging of the delivery of the content for the session 723 when at least one file in the set was delivered 725 META-20 [HIGH] The CDNI Metadata Distribution interface shall 726 support an OPTIONAL mechanism allowing the Upstream CDN to 727 indicate to the Downstream CDN which CDNI Log fields are to 728 be provided for all, for specific sets of, or for specific 729 content items delivered using HTTP. A CDNI implementation 730 that does not support this optional CDNI Metadata 731 Distribution Interface mechanism MUST ignore this log format 732 indication and generate CDNI logging format for HTTP 733 Adaptive Streaming using the default set of CDNI Logging 734 fields. 736 META-21 [MED] The CDNI Metadata Distribution interface shall allow 737 the Upstream CDN to signal to the Downstream CDN the Content 738 Collection ID value for all, for specific sets of, or for 739 specific content items delivered using HTTP. Whenever the 740 Downstream CDN is instructed by the Upstream CDN to report 741 the Content Collection ID field in the log records, the 742 Downstream CDN is to use the value provided through the CDNI 743 Metadata interface for the corresponding content. Note the 744 Session ID field along with Content Collection ID may be 745 used for HTTP Adaptive Streaming content. 747 META-22 [MED] The CDNI Metadata Distribution interface shall allow 748 the Upstream CDN to signal to the Downstream CDN the 749 Authorization Group ID value for all the related HTTP 750 Adaptive Streamin content (i.e. manifest file and chunks). 751 The authorization result of a content (e.g. manifest file) 752 is transferred over to related content (e.g. chunks). [Ed: 753 need to improve wording?] 755 7. CDNI Logging Interface Requirements 757 This section identifies the requirements related to the CDNI Logging 758 interface. We observe that while the CDNI Logging interface is 759 currently discussed as a single "protocol", further analysis will 760 determine whether the corresponding requirements are to be realized 761 over a single interface and protocol, or over multiple interfaces and 762 protocols. 764 LOG-1 [HIGH] The CDNI logging architecture and interface shall 765 ensure reliable logging of CDNI events. 767 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of 768 deliveries and incomplete deliveries to User Agents performed 769 by the Downstream CDN as a result of request redirection by 770 the Upstream CDN. 772 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging 773 interface shall allow the Downstream CDN to report to the 774 Upstream CDN logging for deliveries and incomplete deliveries 775 performed by the Downstream CDN itself as well as logging for 776 deliveries and incomplete deliveries performed by cascaded 777 CDNs on behalf of the Downstream CDN. 779 LOG-4 Removed. 781 LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline 782 exchange of logging records. 784 LOG-6 [MED] The CDNI Logging interface should also support 785 additional timing constraints for some types of logging 786 records (e.g. near-real time for monitoring and analytics 787 applications) 789 LOG-7 [HIGH] The CDNI Logging interface shall define a log file 790 format and a set of fields to be exported through the Logging 791 protocol, with some granularity (e.g. On a per content type 792 basis). 794 LOG-8 [HIGH] The CDNI Logging interface shall define a transport 795 mechanisms to exchange CDNI Logging files. 797 LOG-9 [MED] The CDNI Logging interface should allow a CDN to query 798 another CDN for relevant current logging records (e.g. For 799 on-demand access to real-time logging information). 801 LOG-10 [LOW] The CDNI Logging interface may support aggregate/ 802 summarized logs (e.g. total bytes delivered for a content 803 regardless of individual User Agents to which it was 804 delivered). 806 LOG-11 [LOW] The CDNI Logging interface may support logging of 807 performance data for deliveries to User Agents performed by 808 the Downstream CDN as a result of request redirection by the 809 Upstream CDN. Performance data may include various traffic 810 statistics (the specific parameters are to be determined). 811 The CDNI Logging interface may support the Upstream CDN to 812 indicate the nature and contents of the performance data to 813 be reported by the Downstream CDN. 815 LOG-12 [MED] The CDNI Logging interface shall support logging of 816 consumed resources (e.g. storage, bandwidth) to the Upstream 817 CDN for deliveries where content is stored by the Downstream 818 CDN for delivery to User Agents. The information logged may 819 include the type of storage (e.g., Origin, Intermediate, 820 Edge, Cache) as well as the amount of storage (e.g., total 821 GB, GB used, per time period, per content domain) all of 822 which may impact the cost of the services. 824 LOG-13 [MED] In the case of cascaded CDNs, the CDNI Logging 825 interface shall support the Downstream CDN to report consumed 826 resources (e.g. storage, bandwidth) to the Upstream CDN where 827 content is stored by the Downstream CDN itself as well as 828 logging for storage resources when content storage is 829 performed by cascaded CDNs on behalf of the Downstream CDN. 831 LOG-14 [HIGH] The CDNI Logging interface shall support logging of 832 deleted objects from the Downstream CDN to the Upstream CDN 833 as a result of explicit delete requests on via the CDNI 834 Control interface from the Upstream CDN. 836 LOG-15 [HIGH] The CDNI Logging interface shall support extensibility 837 to allow proprietary information fields to be carried. These 838 information fields must be agreed upon ahead of time between 839 the corresponding CDNs. 841 LOG-16 [HIGH] The CDNI Logging interface shall support the exchange 842 of extensible log file formats to support proprietary 843 information fields. These information fields must be agreed 844 upon ahead of time between the corresponding CDNs. 846 LOG-17 [HIGH] The CDNI Logging interface shall support the 847 notification from Downstream CDN to Upstream CDN for the 848 event that the logging retention duration or maximum size of 849 logging data has exceeded. 851 LOG-18 [MED] The CDNI Logging interface should support the ability 852 for the Downstream CDN to include the Content Collection ID 853 and Session ID fields in CDNI log entries generated for HTTP 854 Adaptive Streaming content. This fields can be supported by 855 the "customizable" log format which is expected to be defined 856 independently of HTTP Adaptive Streaming. 858 8. CDNI Security Requirements 860 This section identifies the requirements related to the CDNI 861 security. Some of those are expected to affect multiple or all 862 protocols. 864 SEC-1 [HIGH] All the CDNI interface shall support secure operation 865 over unsecured IP connectivity (e.g. The Internet). This 866 includes authentication, confidentiality, integrity protection 867 as well as protection against spoofing and replay. 869 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 870 against Denial of Service attacks. This includes protection 871 against spoofed delivery requests sent by user agents directly 872 to a Downstream CDN attempting to appear as if they had been 873 redirected by a given Upstream CDN when they have not. 875 SEC-3 [MED] The CDNI solution should be able to ensure that for any 876 given request redirected to a Downstream CDN, the chain of CDN 877 Delegation (leading to that request being served by that CDN) 878 can be established with non-repudiation. 880 SEC-4 [MED] The CDNI solution should be able to ensure that the 881 Downstream CDN cannot spoof a transaction log attempting to 882 appear as if it corresponds to a request redirected by a given 883 Upstream CDN when that request has not been redirected by this 884 Upstream CDN. This ensures non-repudiation by the Upstream 885 CDN of transaction logs generated by the Downstream CDN for 886 deliveries performed by the Downstream CDN on behalf of the 887 Upstream CDN. 889 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 890 Upstream CDN that has credentials to acquire content from the 891 CSP origin server (or another CDN), to allow establishment of 892 credentials authorizing the Downstream CDN to acquire the 893 content from the CSP origin server (or the other CDN) (e.g. 894 In case the content cannot be acquired from the Upstream CDN). 896 9. IANA Considerations 898 This document makes no request of IANA. 900 Note to RFC Editor: this section may be removed on publication as an 901 RFC. 903 10. Security Considerations 905 This document discusses CDNI security requirements in Section 8. 907 11. Authors 909 This document reflects the contributions from the following authors: 911 Francois Le Faucheur 913 Cisco Systems 915 flefauch@cisco.com 917 Mahesh Viveganandhan 919 Cisco Systems 921 mvittal@cisco.com 923 Grant Watson 925 BT 927 grant.watson@bt.com 929 12. Acknowledgements 931 This document leverages the earlier work of the IETF CDI working 932 group in particular as documented in [I-D.cain-request-routing-req], 933 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 935 The authors would like to thank Gilles Bertrand, Christophe Caillet, 936 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 937 Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their 938 input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy 939 Tarapore, Mike Geller, and Ramki Krishnan contributed to this 940 document by addressing the requirements of the ATIS Cloud Services 941 Forum. 943 Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles 944 Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI 945 Metadata interface, and CDNI Logging interface, respectively. 947 13. References 948 13.1. Normative References 950 [I-D.davie-cdni-framework] 951 Davie, B. and L. Peterson, "Framework for CDN 952 Interconnection", draft-davie-cdni-framework-01 (work in 953 progress), October 2011. 955 [I-D.ietf-cdni-problem-statement] 956 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 957 Distribution Network Interconnection (CDNI) Problem 958 Statement", draft-ietf-cdni-problem-statement-08 (work in 959 progress), June 2012. 961 [I-D.ietf-cdni-use-cases] 962 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 963 K., and G. Watson, "Use Cases for Content Delivery Network 964 Interconnection", draft-ietf-cdni-use-cases-10 (work in 965 progress), August 2012. 967 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 968 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 969 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 971 13.2. Informative References 973 [I-D.amini-cdi-distribution-reqs] 974 Amini, L., "Distribution Requirements for Content 975 Internetworking", draft-amini-cdi-distribution-reqs-02 976 (work in progress), November 2001. 978 [I-D.cain-request-routing-req] 979 Cain, B., "Request Routing Requirements for Content 980 Internetworking", draft-cain-request-routing-req-03 (work 981 in progress), November 2001. 983 [I-D.gilletti-cdnp-aaa-reqs] 984 "CDI AAA Requirements, 985 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 987 Authors' Addresses 989 Kent Leung (editor) 990 Cisco Systems 991 170 West Tasman Drive 992 San Jose, CA 95134 993 U.S.A. 995 Phone: +1 408 526 5030 996 Email: kleung@cisco.com 998 Yiu Lee (editor) 999 Comcast 1000 One Comcast Center 1001 Philadelphia, PA 19103 1002 U.S.A. 1004 Email: yiu_lee@cable.comcast.com