idnits 2.17.1 draft-ietf-cdni-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2012) is 4335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 786, but not defined == Missing Reference: 'HIGH' is mentioned on line 775, but not defined == Missing Reference: 'LOW' is mentioned on line 795, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-06 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-06 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 6 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: December 7, 2012 Comcast 6 June 5, 2012 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-03 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 December 7, 2012. 72 Copyright Notice 74 Copyright (c) 2012 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 . . . . . . 13 96 7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 16 97 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 18 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 104 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 277 GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate 278 (ABR) 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 5. CDNI Request Routing Interface Requirements 388 The main function of the Request Routing interface is to allow the 389 Request-Routing systems in interconnected CDNs to communicate to 390 facilitate redirection of the request across CDNs. 392 REQ-1 [HIGH] The CDNI Request-Routing interface shall allow the 393 Downstream CDN to communicate to the Upstream CDN coarse 394 information about the Downstream CDN ability and/or 395 willingness to handle requests from the Upstream CDN. For 396 example, this could potentially include a binary signal 397 ("Downstream CDN ready/not-ready to take additional requests 398 from Upstream CDN") to be used in case of excessive load or 399 failure condition in the Downstream CDN. 401 REQ-2 [MED] The CDNI Request-Routing interface should allow the 402 Downstream CDN to communicate to the Upstream CDN aggregate 403 information to facilitate CDN selection during request 404 routing, such as Downstream CDN capabilities, resources and 405 affinities (i.e. Preferences or cost). This information 406 could, for example, include: 408 * supported content types and delivery protocols 410 * footprint (e.g. layer-3 coverage) 412 * a set of metrics/attributes (e.g. Streaming bandwidth, 413 storage resources, distribution and delivery priority) 415 * a set of affinities (e.g. Preferences, indication of 416 distribution/delivery fees) 418 * information to facilitate request redirection (e.g. 419 Reachability information of Downstream CDN Request 420 Routing system). 422 [Note: Some of this information - such as supported content 423 types and delivery protocols- may also potentially be taken 424 into account by the distribution system in the Upstream CDN 425 for pre-positioning of content and/or metadata in the 426 Downstream CDN in case of pre-positioned content acquisition 427 and/or pre-positioned CDNI metadata acquisition.] 429 REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- 430 Routing interface shall allow the Downstream CDN to also 431 include in the information communicated to the Upstream CDN, 432 information on the capabilities, resources and affinities of 433 CDNs to which the Downstream CDN may (in turn) redirect 434 requests received by the Upstream CDN. In that case, the 435 CDNI Request-Routing interface shall prevent looping of such 436 information exchange. 438 REQ-4 [LOW] The CDNI Request-Routing interface may allow the 439 Downstream CDN to communicate to the Upstream CDN aggregate 440 information on CDNI administrative limits and policy. This 441 information can be taken into account by the Upstream CDN 442 Request Routing system in its CDN Selection decisions. This 443 information could, for example, include: 445 * maximum number of requests redirected by the Upstream CDN 446 to be served simultaneously by the Downstream CDN 448 * maximum aggregate volume of content (e.g. in Terabytes) 449 to be delivered by the Downstream CDN over a time period. 451 REQ-5 [HIGH] The CDNI Request-Routing architecture and interface 452 shall support efficient request-routing for small objects. 453 This may, for example, call for a mode of operation (e.g. 454 DNS-based request routing) where freshness and accuracy of 455 CDN/Surrogate selection can be traded-off against reduced 456 request-routing load (e.g. Via lighter-weight queries and 457 caching of request-routing decisions). 459 REQ-6 [HIGH] The CDNI Request-Routing architecture and interface 460 shall support efficient request-routing for large objects. 461 This may, for example, call for a mode of operation (e.g. 462 HTTP-based request routing) where freshness and accuracy of 463 CDN/Surrogate selection justifies a per-request decision and 464 a per-request CDNI Request-Routing protocol call. 466 REQ-7 [HIGH] The CDNI Request-Routing architecture shall support 467 recursive CDNI request routing. 469 REQ-8 [HIGH] The CDNI Request-Routing architecture shall support 470 iterative CDNI request routing. 472 REQ-9 [MED] In case of detection of a request redirection loop, the 473 CDNI Request-Routing loop prevention mechanism should allow 474 routing of the request by avoiding the loop (as opposed to 475 the request loop being simply interrupted without routing the 476 request). 478 REQ-10 [MED] The CDNI Request-Routing protocol should support a 479 mechanism allowing enforcment of a limit on the number of 480 successive CDN redirections for a given request. 482 REQ-11 [LOW] The CDNI Request-Routing protocol may support a 483 mechanism allowing an Upstream CDN to avoid redirecting a 484 request to a Downstream CDN if that is likely to result in 485 the total redirection time exceeding some limit. 487 REQ-12 [HIGH] The CDNI Request-Routing protocol shall allow the 488 Upstream CDN to include, in the query to the Downstream CDN, 489 the necessary information to allow the Downstream CDN to 490 process the redirection query. This could, for example, 491 include: 493 * information from which the location of the user-agent 494 that originated the request can be inferred (e.g. User 495 Agent fully qualified domain name in case of HTTP-based 496 Request Routing, DNS Proxy fully qualified domain name in 497 case of DNS-based Request Routing) 499 * requested resource information (e.g. Resource URI in 500 case of HTTP-based Request Routing, Resource hostname in 501 case of DNS-based Request Routing) 503 * additional available request information (e.g. request 504 headers in case of HTTP-based Request Routing). 506 REQ-13 [LOW] The CDNI Request-Routing protocol may also allow the 507 Upstream CDN to convey information pointing to CDNI metadata 508 applicable (individually or through inheritance) to the 509 requested content. For illustration, the CDNI metadata 510 pointed to could potentially include metadata that is 511 applicable to any content, metadata that is applicable to a 512 content collection (to which the requested content belongs) 513 and/or metadata that is applicable individually to the 514 requested content. 516 REQ-14 [HIGH] The CDNI Request-Routing interface shall allow the 517 Downstream CDN to include the following information in the 518 response to the Upstream CDN: 520 * status code, in particular indicating acceptance or 521 rejection of request (e.g. Because the Downstream CDN is 522 unwilling or unable to serve the request). In case of 523 rejection, an error code is also to be provided, which 524 allows the Upstream CDN to react appropriately (e.g. 525 Select another Downstream CDN, or serve the request 526 itself) 528 * redirection information (e.g. Resource URI in case of 529 HTTP-based Request Routing, equivalent of a DNS record in 530 case of DNS-based Request Routing). 532 6. CDNI Metadata Distribution Interface Requirements 534 The primary function of the CDNI Metadata Distribution interface is 535 to allow the Distribution system in interconnected CDNs to 536 communicate to ensure Content Distribution Metadata with inter-CDN 537 scope can be exchanged across CDNs. We observe that while the CDNI 538 Metadata Distribution protocol is currently discussed as a single 539 "protocol", further analysis will determine whether the corresponding 540 requirements are to be realized over a single interface and protocol, 541 or over multiple interfaces and protocols. For example, a subset of 542 the CDNI metadata might be conveyed in-band along with the actual 543 content acquisition across CDNs (e.g. content MD5 in HTTP header) 544 while another subset might require an out-of-band interface & 545 protocol (e.g. geo-blocking information). 547 META-1 [HIGH] The CDNI Metadata Distribution interface shall allow 548 the Upstream CDN to provide the Downstream CDN with content 549 distribution metadata of inter-CDN scope. 551 META-2 [HIGH] The CDNI Metadata Distribution interface shall 552 support exchange of CDNI metadata for both the dynamic 553 content acquisition model and the pre-positioning content 554 acquisition model. 556 META-3 [HIGH] The CDNI Metadata Distribution interface shall 557 support a mode where no, or a subset of, the Metadata is 558 initially communicated to the Downstream CDN along with 559 information about how/where to acquire the rest of the CDNI 560 Metadata (i.e. Dynamic CDNI metadata acquisition). 562 META-4 [MED] The CDNI Metadata Distribution interface should 563 support a mode where all the relevant Metadata is initially 564 communicated to the Downstream CDN (i.e. Pre-positioned 565 CDNI metadata acquisition). 567 META-5 [HIGH] Whether in the pre-positioned content acquisition 568 model or in the dynamic content acquisition model, the CDNI 569 Metadata Distribution interface shall provide the necessary 570 information to allow the Downstream CDN to acquire the 571 content from an upstream source (e.g. Acquisition protocol 572 and Uniform Resource Identifier in Upstream CDN- or rules to 573 construct this URI). 575 META-6 [HIGH] The CDNI metadata shall allow signaling of one or 576 more upstream sources, where each upstream source can be in 577 the Upstream CDN, in another CDN, the CSP origin server or 578 any arbitrary source designated by the Upstream CDN. Note 579 that some upstream sources (e.g. the content origin server) 580 may or may not be willing to serve the content to the 581 Downstream CDN, if this policy is known to the Upstream CDN 582 then it may omit those sources when exchanging CDNI 583 metadata. 585 META-7 [HIGH] The CDNI Metadata Distribution interface shall allow 586 the Upstream CDN to request addition and modification of 587 CDNI Metadata into the Downstream CDN. 589 META-8 [HIGH] The CDNI Metadata Distribution interface shall allow 590 removal of obsolete CDNI Metadata from the Downstream CDN 591 (this could, for example, be achieved via an explicit 592 removal request from the Upstream CDN or via expiration of a 593 Time-To-Live associated to the Metadata). 595 META-9 [HIGH] The CDNI Metadata Distribution interface shall allow 596 association of CDNI Metadata at the granularity of 597 individual object. This is necessary to achieve fine-grain 598 Metadata distribution at the level of an individual object 599 when necessary. 601 META-10 [HIGH] The CDNI Metadata Distribution interface shall allow 602 association of CDNI Metadata at the granularity of an object 603 set. This is necessary to achieve scalable distribution of 604 metadata when a large number of objects share the same 605 distribution policy. 607 META-11 [HIGH] The CDNI Metadata Distribution interface shall 608 support multiple levels of inheritance with precedence to 609 more specific metadata. For example, the CDNI Metadata 610 Distribution protocol may support metadata that is 611 applicable to any content, metadata that is applicable to a 612 content collection and metadata that is applicable to an 613 individual content where content level metadata overrides 614 content collection metadata that overrides metadata for any 615 content. 617 META-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 618 that conflicting metadata with overlapping scope are 619 prevented or deterministically handled. 621 META-13 [HIGH] The CDNI Metadata Distribution interface shall 622 provide indication by the Downstream CDN to the Upstream CDN 623 of whether the CDNI metadata (and corresponding future 624 request redirections) is accepted or rejected. When 625 rejected, the CDNI Metadata Distribution protocol Must allow 626 the Downstream CDN to provide information about the cause of 627 the rejection. 629 META-14 [HIGH] The CDNI Metadata Distribution interface shall allow 630 signaling of content distribution control policies. For 631 example, this could potentially include: 633 * geo-blocking information (i.e. Information defining 634 geographical areas where the content is to be made 635 available or blocked) 637 * availability windows (i.e. Information defining time 638 windows during which the content is to be made available 639 or blocked; expiration time may also be included to 640 remove content) 642 * delegation whitelist/blacklist (i.e. Information 643 defining which Downstream CDNs the content may/may not 644 be delivered through) 646 META-15 [HIGH] The CDNI Metadata interface shall be able to exchange 647 a set of well-accepted metadata elements with specified 648 semantics (e.g. start of time window, end of time window). 650 META-16 [HIGH] The CDNI Metadata interface shall allow exchange of 651 opaque metadata element, whose semantic is not defined in 652 CDNI but established by private CDN agreement. 654 META-17 [HIGH] The CDNI Metadata Distribution interface shall allow 655 signaling of authorization checks and validation that are to 656 be performed by the surrogate before delivery. For example, 657 this could potentially include: 659 * need to validate URI signed information (e.g. Expiry 660 time, Client IP address). 662 META-18 [LOW] The CDNI Metadata Distribution interface may allow 663 signaling of CDNI-relevant surrogate cache behavior 664 parameters. For example, this could potentially include: 666 * control of whether the query string of HTTP URI is to be 667 ignored by surrogate cache 669 * content revalidation parameters (e.g. TTL) 671 7. CDNI Logging Interface Requirements 673 This section identifies the requirements related to the CDNI Logging 674 interface. We observe that while the CDNI Logging interface is 675 currently discussed as a single "protocol", further analysis will 676 determine whether the corresponding requirements are to be realized 677 over a single interface and protocol, or over multiple interfaces and 678 protocols. 680 LOG-1 [HIGH] The CDNI logging architecture and interface shall 681 ensure reliable logging of CDNI events. 683 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of 684 deliveries and incomplete deliveries to User Agents performed 685 by the Downstream CDN as a result of request redirection by 686 the Upstream CDN. 688 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging 689 interface shall allow the Downstream CDN to report to the 690 Upstream CDN logging for deliveries and incomplete deliveries 691 performed by the Downstream CDN itself as well as logging for 692 deliveries and incomplete deliveries performed by cascaded 693 CDNs on behalf of the Downstream CDN. 695 LOG-4 [HIGH] The CDNI Logging interface shall provide logging of 696 distribution performed by the Upstream CDN as a result of 697 acquisition request by the Downstream CDN. 699 LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline 700 exchange of logging records. 702 LOG-6 [MED] The CDNI Logging interface should also support 703 additional timing constraints for some types of logging 704 records (e.g. near-real time for monitoring and analytics 705 applications) 707 LOG-7 [HIGH] The CDNI Logging interface shall define a log file 708 format and a set of fields to be exported through the Logging 709 protocol, with some granularity (e.g. On a per content type 710 basis). 712 LOG-8 [HIGH] The CDNI Logging interface shall define a transport 713 mechanisms to exchange CDNI Logging files. 715 LOG-9 [MED] The CDNI Logging interface may allow a CDN to query 716 another CDN for relevant current logging records (e.g. For 717 on-demand access to real-time logging information). 719 LOG-10 [LOW] The CDNI Logging interface may support aggregate/ 720 summarized logs (e.g. total bytes delivered for a content 721 regardless of individual User Agents to which it was 722 delivered). 724 LOG-11 [LOW] The CDNI Logging interface shall support logging of 725 performance data for deliveries to User Agents performed by 726 the Downstream CDN as a result of request redirection by the 727 Upstream CDN. Performance data may include various traffic 728 statistics (the specific parameters are to be determined). 729 The CDNI Logging interface shall support the Upstream CDN to 730 indicate the nature and contents of the performance data to 731 be reported by the Downstream CDN. 733 LOG-12 [MED] The CDNI Logging interface shall support logging of 734 consumed resources (e.g. storage, bandwidth) to the Upstream 735 CDN for deliveries where content is stored by the Downstream 736 CDN for delivery to User Agents. The information logged may 737 include the type of storage (e.g., Origin, Intermediate, 738 Edge, Cache) as well as the amount of storage (e.g., total 739 GB, GB used, per time period, per content domain) all of 740 which may impact the cost of the services. 742 LOG-13 [MED] In the case of cascaded CDNs, the CDNI Logging 743 interface shall support the Downstream CDN to report consumed 744 resources (e.g. storage, bandwidth) to the Upstream CDN where 745 content is stored by the Downstream CDN itself as well as 746 logging for storage resources when content storage is 747 performed by cascaded CDNs on behalf of the Downstream CDN. 749 LOG-14 [HIGH] The CDNI Logging interface shall support logging of 750 deleted objects from the Downstream CDN to the Upstream CDN 751 as a result of explicit delete requests on via the CDNI 752 Control interface from the Upstream CDN. 754 LOG-15 [HIGH] The CDNI Logging interface shall support extensibility 755 to allow proprietary information fields to be carried. These 756 information fields must be agreed upon ahead of time between 757 the corresponding CDNs. 759 LOG-16 [HIGH] The CDNI Logging interface shall support the exchange 760 of extensible log file formats to support proprietary 761 information fields. These information fields must be agreed 762 upon ahead of time between the corresponding CDNs. 764 8. CDNI Security Requirements 766 This section identifies the requirements related to the CDNI 767 security. Some of those are expected to affect multiple or all 768 protocols. 770 SEC-1 [HIGH] All the CDNI interface shall support secure operation 771 over unsecured IP connectivity (e.g. The Internet). This 772 includes authentication, confidentiality, integrity protection 773 as well as protection against spoofing and replay. 775 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 776 against Denial of Service attacks. This includes protection 777 against spoofed delivery requests sent by user agents directly 778 to a Downstream CDN attempting to appear as if they had been 779 redirected by a given Upstream CDN when they have not. 781 SEC-3 [MED] The CDNI solution should be able to ensure that for any 782 given request redirected to a Downstream CDN, the chain of CDN 783 Delegation (leading to that request being served by that CDN) 784 can be established with non-repudiation. 786 SEC-4 [MED] The CDNI solution should be able to ensure that the 787 Downstream CDN cannot spoof a transaction log attempting to 788 appear as if it corresponds to a request redirected by a given 789 Upstream CDN when that request has not been redirected by this 790 Upstream CDN. This ensures non-repudiation by the Upstream 791 CDN of transaction logs generated by the Downstream CDN for 792 deliveries performed by the Downstream CDN on behalf of the 793 Upstream CDN. 795 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 796 Upstream CDN that has credentials to acquire content from the 797 CSP origin server (or another CDN), to allow establishment of 798 credentials authorizing the Downstream CDN to acquire the 799 content from the CSP origin server (or the other CDN) (e.g. 800 In case the content cannot be acquired from the Upstream CDN). 802 9. IANA Considerations 804 This document makes no request of IANA. 806 Note to RFC Editor: this section may be removed on publication as an 807 RFC. 809 10. Security Considerations 811 This document discusses CDNI security requirements in Section 8. 813 11. Authors 815 This document reflects the contributions from the following authors: 817 Francois Le Faucheur 819 Cisco Systems 821 flefauch@cisco.com 823 Mahesh Viveganandhan 825 Cisco Systems 827 mvittal@cisco.com 829 Grant Watson 831 BT 833 grant.watson@bt.com 835 12. Acknowledgements 837 This document leverages the earlier work of the IETF CDI working 838 group in particular as documented in [I-D.cain-request-routing-req], 839 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 841 The authors would like to thank Gilles Bertrand, Christophe Caillet, 842 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 843 Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their 844 input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy 845 Tarapore, Mike Geller, and Ramki Krishnan contributed to this 846 document by addressing the requirements of the ATIS Cloud Services 847 Forum. 849 13. References 850 13.1. Normative References 852 [I-D.davie-cdni-framework] 853 Davie, B. and L. Peterson, "Framework for CDN 854 Interconnection", draft-davie-cdni-framework-01 (work in 855 progress), October 2011. 857 [I-D.ietf-cdni-problem-statement] 858 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 859 Distribution Network Interconnection (CDNI) Problem 860 Statement", draft-ietf-cdni-problem-statement-06 (work in 861 progress), May 2012. 863 [I-D.ietf-cdni-use-cases] 864 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 865 K., and G. Watson, "Use Cases for Content Delivery Network 866 Interconnection", draft-ietf-cdni-use-cases-06 (work in 867 progress), May 2012. 869 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 870 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 871 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 873 13.2. Informative References 875 [I-D.amini-cdi-distribution-reqs] 876 Amini, L., "Distribution Requirements for Content 877 Internetworking", draft-amini-cdi-distribution-reqs-02 878 (work in progress), November 2001. 880 [I-D.cain-request-routing-req] 881 Cain, B., "Request Routing Requirements for Content 882 Internetworking", draft-cain-request-routing-req-03 (work 883 in progress), November 2001. 885 [I-D.gilletti-cdnp-aaa-reqs] 886 "CDI AAA Requirements, 887 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 889 Authors' Addresses 891 Kent Leung (editor) 892 Cisco Systems 893 170 West Tasman Drive 894 San Jose, CA 95134 895 U.S.A. 897 Phone: +1 408 526 5030 898 Email: kleung@cisco.com 900 Yiu Lee (editor) 901 Comcast 902 One Comcast Center 903 Philadelphia, PA 19103 904 U.S.A. 906 Email: yiu_lee@cable.comcast.com