idnits 2.17.1 draft-ietf-cdni-requirements-01.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 (October 19, 2011) is 4544 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 744, but not defined == Missing Reference: 'HIGH' is mentioned on line 733, but not defined == Missing Reference: 'LOW' is mentioned on line 753, but not defined == Outdated reference: A later version (-01) exists of draft-davie-cdni-framework-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 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: April 21, 2012 Comcast 6 October 19, 2011 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-01 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 April 21, 2012. 72 Copyright Notice 74 Copyright (c) 2011 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 . . . . . . . . . 9 95 6. CDNI Metadata Distribution Interface Requirements . . . . . . 13 96 7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 15 97 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 17 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 104 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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.jenkins-cdni-problem-statement] outlines the problem area that 132 the CDNI working group is chartered to address. 133 [I-D.bertrand-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(s) and/or its CDNI metadata as "stale" 299 and revalidate them before they are delivered again 301 * Delete an object(s) and/or its CDNI metadata from the 302 CDN surrogates and any storage. Only the object(s) and 303 CDNI metadata that pertain to the requesting Upstream 304 CDN are allowed to be purged. 306 CNTL-2 [HIGH] The CDNI Control interface shall allow the downstream 307 CDN to report on the completion of these actions (by itself, 308 and if cascaded CDNs are supported by the solution, by 309 potential cascaded Downstream CDNs), in a manner appropriate 310 for the action (e.g. synchronously or asynchronously). 312 CNTL-3 [HIGH] The CDNI Control interface shall support initiation 313 and control by the Upstream CDN of pre-positioned CDNI 314 metadata acquisition by the Downstream CDN. 316 CNTL-4 [MED] The CDNI Control interface should support initiation 317 and control by the Upstream CDN of pre-positioned content 318 acquisition by the Downstream CDN. 320 CNTL-5 [LOW] The CDNI Control interface may allow a CDN to 321 establish, update and terminate a CDN interconnection with 322 another CDN whereby one CDN can act as a Downstream CDN for 323 the other CDN (that acts as an Upstream CDN). 325 CNTL-6 [LOW] The CDNI Control interface may allow control of the 326 CDNI interconnection between any two CDNs independently for 327 each direction (i.e. For the direction where CDN1 is the 328 Upstream CDN and CDN2 is the Downstream CDN, and for the 329 direction where CDN2 is the Upstream CDN and CDN1 is the 330 Downstream CDN). 332 CNTL-7 [LOW] The CDNI Control interface may allow bootstrapping of 333 the Request-Routing interface. For example, this can 334 potentially include: 336 * negotiation of the Request-Routing method (e.g. DNS vs 337 HTTP, if more than one method is specified) 339 * discovery of the Request-Routing protocol endpoints 341 * information necessary to establish secure communication 342 between the Request-Routing protocol endpoints. 344 CNTL-8 [LOW] The CDNI Control interface may allow bootstrapping of 345 the CDNI Metadata interface. This information could, for 346 example, include: 348 * discovery of the CDNI Metadata signaling protocol 349 endpoints 351 * information necessary to establish secure communication 352 between the CDNI Metadata signaling protocol endpoints. 354 CNTL-9 [LOW] The CDNI Control interface may allow bootstrapping of 355 the Content Acquisition interface. This could, for example, 356 include exchange and negotiation of the Content Acquisition 357 protocols to be used across the CDNs (e.g. HTTP, HTTPS, 358 FTP, ATIS C2). 360 CNTL-10 [LOW] The CDNI Control interface may allow exchange and 361 negotiation of delivery authorization mechanisms to be 362 supported across the CDNs (e.g. URI signature based 363 validation). 365 CNTL-11 [LOW] The CDNI Control interface may allow bootstrapping of 366 the CDNI Logging interface. This information could, for 367 example, include: 369 * discovery of the Logging protocol endpoints 371 * information necessary to establish secure communication 372 between the Logging protocol endpoints 374 * negotiation/definition of the log file format and set of 375 fields to be exported through the Logging protocol, with 376 some granularity (e.g. On a per content type basis). 378 * negotiation/definition of parameters related to 379 transaction Logs export (e.g., export protocol, file 380 compression, export frequency, directory). 382 5. CDNI Request Routing Interface Requirements 384 The main function of the Request Routing interface is to allow the 385 Request-Routing systems in interconnected CDNs to communicate to 386 facilitate redirection of the request across CDNs. 388 REQ-1 [HIGH] The CDNI Request-Routing interface shall allow the 389 Downstream CDN to communicate to the Upstream CDN coarse 390 information about the Downstream CDN ability and/or 391 willingness to handle requests from the Upstream CDN. For 392 example, this could potentially include a binary signal 393 ("Downstream CDN ready/not-ready to take additional requests 394 from Upstream CDN") to be used in case of excessive load or 395 failure condition in the Downstream CDN. 397 REQ-2 [MED] The CDNI Request-Routing interface should allow the 398 Downstream CDN to communicate to the Upstream CDN aggregate 399 information to facilitate CDN selection during request 400 routing, such as Downstream CDN capabilities, resources and 401 affinities (i.e. Preferences or cost). This information 402 could, for example, include: 404 * supported content types and delivery protocols 406 * footprint (e.g. layer-3 coverage) 408 * a set of metrics/attributes (e.g. Streaming bandwidth, 409 storage resources, distribution and delivery priority) 411 * a set of affinities (e.g. Preferences, indication of 412 distribution/delivery fees) 414 * information to facilitate request redirection (e.g. 415 Reachability information of Downstream CDN Request 416 Routing system). 418 [Note: Some of this information - such as supported content 419 types and delivery protocols- may also potentially be taken 420 into account by the distribution system in the Upstream CDN 421 for pre-positioning of content and/or metadata in the 422 Downstream CDN in case of pre-positioned content acquisition 423 and/or pre-positioned CDNI metadata acquisition.] 425 REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- 426 Routing interface shall allow the Downstream CDN to also 427 include in the information communicated to the Upstream CDN, 428 information on the capabilities, resources and affinities of 429 CDNs to which the Downstream CDN may (in turn) redirect 430 requests received by the Upstream CDN. In that case, the 431 CDNI Request-Routing interface shall prevent looping of such 432 information exchange. 434 REQ-4 [LOW] The CDNI Request-Routing interface may allow the 435 Downstream CDN to communicate to the Upstream CDN aggregate 436 information on CDNI administrative limits and policy. This 437 information can be taken into account by the Upstream CDN 438 Request Routing system in its CDN Selection decisions. This 439 information could, for example, include: 441 * maximum number of requests redirected by the Upstream CDN 442 to be served simultaneously by the Downstream CDN 444 * maximum aggregate volume of content (e.g. in Terabytes) 445 to be delivered by the Downstream CDN over a time period. 447 REQ-5 [HIGH] The CDNI Request-Routing architecture and interface 448 shall support efficient request-routing for small objects. 449 This may, for example, call for a mode of operation (e.g. 450 DNS-based request routing) where freshness and accuracy of 451 CDN/Surrogate selection can be traded-off against reduced 452 request-routing load (e.g. Via lighter-weight queries and 453 caching of request-routing decisions). 455 REQ-6 [HIGH] The CDNI Request-Routing architecture and interface 456 shall support efficient request-routing for large objects. 457 This may, for example, call for a mode of operation (e.g. 458 HTTP-based request routing) where freshness and accuracy of 459 CDN/Surrogate selection justifies a per-request decision and 460 a per-request CDNI Request-Routing protocol call. 462 REQ-7 [HIGH] The CDNI Request-Routing architecture shall support 463 recursive CDNI request routing. 465 REQ-8 [HIGH] The CDNI Request-Routing architecture shall support 466 iterative CDNI request routing. 468 REQ-9 [MED] In case of detection of a request redirection loop, the 469 CDNI Request-Routing loop prevention mechanism should allow 470 routing of the request by avoiding the loop (as opposed to 471 the request loop being simply interrupted without routing the 472 request). 474 REQ-10 [MED] The CDNI Request-Routing protocol should support a 475 mechanism allowing enforcment of a limit on the number of 476 successive CDN redirections for a given request. 478 REQ-11 [LOW] The CDNI Request-Routing protocol may support a 479 mechanism allowing an upstream CDN to avoid redirecting a 480 request to a downstream CDN if that is likely to result in 481 the total redirection time exceeding some limit. 483 REQ-12 [HIGH] The CDNI Request-Routing protocol shall allow the 484 Upstream CDN to include, in the query to the Downstream CDN, 485 the necessary information to allow the Downstream CDN to 486 process the redirection query. This could, for example, 487 include: 489 * information from which the location of the user-agent 490 that originated the request can be inferred (e.g. User 491 Agent fully qualified domain name in case of HTTP-based 492 Request Routing, DNS Proxy fully qualified domain name in 493 case of DNS-based Request Routing) 495 * requested resource information (e.g. Resource URI in 496 case of HTTP-based Request Routing, Resource hostname in 497 case of DNS-based Request Routing) 499 * additional available request information (e.g. request 500 headers in case of HTTP-based Request Routing). 502 REQ-13 [LOW] The CDNI Request-Routing protocol may also allow the 503 Upstream CDN to convey information pointing to CDNI metadata 504 applicable (individually or through inheritance) to the 505 requested content. For illustration, the CDNI metadata 506 pointed to could potentially include metadata that is 507 applicable to any content, metadata that is applicable to a 508 content collection (to which the requested content belongs) 509 and/or metadata that is applicable individually to the 510 requested content. 512 REQ-14 [HIGH] The CDNI Request-Routing interface shall allow the 513 Downstream CDN to include the following information in the 514 response to the Upstream CDN: 516 * status code, in particular indicating acceptance or 517 rejection of request (e.g. Because the Downstream CDN is 518 unwilling or unable to serve the request). In case of 519 rejection, an error code is also to be provided, which 520 allows the Upstream CDN to react appropriately (e.g. 521 Select another Downstream CDN, or serve the request 522 itself) 524 * redirection information (e.g. Resource URI in case of 525 HTTP-based Request Routing, equivalent of a DNS record in 526 case of DNS-based Request Routing). 528 6. CDNI Metadata Distribution Interface Requirements 530 The primary function of the CDNI Metadata Distribution interface is 531 to allow the Distribution system in interconnected CDNs to 532 communicate to ensure Content Distribution Metadata with inter-CDN 533 scope can be exchanged across CDNs. We observe that while the CDNI 534 Metadata Distribution protocol is currently discussed as a single 535 "protocol", further analysis will determine whether the corresponding 536 requirements are to be realized over a single interface and protocol, 537 or over multiple interfaces and protocols. For example, a subset of 538 the CDNI metadata might be conveyed in-band along with the actual 539 content acquisition across CDNs (e.g. content MD5 in HTTP header) 540 while another subset might require an out-of-band interface & 541 protocol (e.g. geo-blocking information). 543 META-1 [HIGH] The CDNI Metadata Distribution interface shall allow 544 the Upstream CDN to provide the Downstream CDN with content 545 distribution metadata of inter-CDN scope. 547 META-2 [HIGH] The CDNI Metadata Distribution interface shall 548 support exchange of CDNI metadata for both the dynamic 549 content acquisition model and the pre-positioning content 550 acquisition model. 552 META-3 [HIGH] The CDNI Metadata Distribution interface shall 553 support a mode where no, or a subset of, the Metadata is 554 initially communicated to the Downstream CDN along with 555 information about how/where to acquire the rest of the CDNI 556 Metadata (i.e. Dynamic CDNI metadata acquisition). 558 META-4 [MED] The CDNI Metadata Distribution interface should 559 support a mode where all the relevant Metadata is initially 560 communicated to the Downstream CDN (i.e. Pre-positioned 561 CDNI metadata acquisition). 563 META-5 [HIGH] Whether in the pre-positioned content acquisition 564 model or in the dynamic content acquisition model, the CDNI 565 Metadata Distribution interface shall provide the necessary 566 information to allow the Downstream CDN to acquire the 567 content from an upstream source (e.g. Acquisition protocol 568 and Uniform Resource Identifier in Upstream CDN- or rules to 569 construct this URI). 571 META-6 [HIGH] The CDNI metadata shall allow signaling of one or 572 more upstream sources, where each upstream source can be in 573 the Upstream CDN, in another CDN, the CSP origin server or 574 any arbitrary source designated by the Upstream CDN. Note 575 that some upstream sources (e.g. the content origin server) 576 may or may not be willing to serve the content to the 577 Downstream CDN, if this policy is known to the upstream CDN 578 then it may omit those sources when exchanging CDNI 579 metadata. 581 META-7 [HIGH] The CDNI Metadata Distribution interface shall allow 582 the Upstream CDN to request addition and modification of 583 CDNI Metadata into the Downstream CDN. 585 META-8 [HIGH] The CDNI Metadata Distribution interface shall allow 586 removal of obsolete CDNI Metadata from the Downstream CDN 587 (this could, for example, be achieved via an explicit 588 removal request from the Upstream CDN or via expiration of a 589 Time-To-Live associated to the Metadata). 591 META-9 [HIGH] The CDNI Metadata Distribution interface shall allow 592 association of CDNI Metadata at the granularity of 593 individual object. This is necessary to achieve fine-grain 594 Metadata distribution at the level of an individual object 595 when necessary. 597 META-10 [HIGH] The CDNI Metadata Distribution interface shall allow 598 association of CDNI Metadata at the granularity of an object 599 set. This is necessary to achieve scalable distribution of 600 metadata when a large number of objects share the same 601 distribution policy. 603 META-11 [HIGH] The CDNI Metadata Distribution interface shall 604 support multiple levels of inheritance with precedence to 605 more specific metadata. For example, the CDNI Metadata 606 Distribution protocol may support metadata that is 607 applicable to any content, metadata that is applicable to a 608 content collection and metadata that is applicable to an 609 individual content where content level metadata overrides 610 content collection metadata that overrides metadata for any 611 content. 613 META-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 614 that conflicting metadata with overlapping scope are 615 prevented or deterministically handled. 617 META-13 [HIGH] The CDNI Metadata Distribution interface shall 618 provide indication by the Downstream CDN to the Upstream CDN 619 of whether the CDNI metadata (and corresponding future 620 request redirections) is accepted or rejected. When 621 rejected, the CDNI Metadata Distribution protocol Must allow 622 the Downstream CDN to provide information about the cause of 623 the rejection. 625 META-14 [HIGH] The CDNI Metadata Distribution interface shall allow 626 signaling of content distribution control policies. For 627 example, this could potentially include: 629 * geo-blocking information (i.e. Information defining 630 geographical areas where the content is to be made 631 available or blocked) 633 * availability windows (i.e. Information defining time 634 windows during which the content is to be made available 635 or blocked; expiration time may also be included to 636 remove content) 638 * delegation whitelist/blacklist (i.e. Information 639 defining which downstream CDNs the content may/may not 640 be delivered through) 642 META-15 [HIGH] The CDNI Metadata interface shall be able to exchange 643 a set of well-accepted metadata elements with specified 644 semantics (e.g. start of time window, end of time window). 646 META-16 [HIGH] The CDNI Metadata interface shall allow exchange of 647 opaque metadata element, whose semantic is not defined in 648 CDNI but established by private CDN agreement. 650 META-17 [HIGH] The CDNI Metadata Distribution interface shall allow 651 signaling of authorization checks and validation that are to 652 be performed by the surrogate before delivery. For example, 653 this could potentially include: 655 * need to validate URI signed information (e.g. Expiry 656 time, Client IP address). 658 META-18 [LOW] The CDNI Metadata Distribution interface may allow 659 signaling of CDNI-relevant surrogate cache behavior 660 parameters. For example, this could potentially include: 662 * control of whether the query string of HTTP URI is to be 663 ignored by surrogate cache 665 * content revalidation parameters (e.g. TTL) 667 7. CDNI Logging Interface Requirements 669 This section identifies the requirements related to the CDNI Logging 670 interface. We observe that while the CDNI Logging interface is 671 currently discussed as a single "protocol", further analysis will 672 determine whether the corresponding requirements are to be realized 673 over a single interface and protocol, or over multiple interfaces and 674 protocols. 676 LOG-1 [HIGH] The CDNI logging architecture and interface shall 677 ensure reliable logging of CDNI events. 679 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of 680 deliveries to User Agents performed by the Downstream CDN as 681 a result of request redirection by the Upstream CDN. 683 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging 684 interface shall allow the Downstream CDN to report to the 685 Upstream CDN logging for deliveries performed by the 686 Downstream CDN itself as well as logging for deliveries 687 performed by cascaded CDNs on behalf of the Downstream CDN. 689 LOG-4 [HIGH] The CDNI Logging interface shall provide logging of 690 distribution performed by the Upstream CDN as a result of 691 acquisition request by the Downstream CDN. 693 LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline 694 exchange of logging records. 696 LOG-6 [MED] The CDNI Logging interface should also support 697 additional timing constraints for some types of logging 698 records (e.g. near-real time for monitoring and analytics 699 applications) 701 LOG-7 [HIGH] The CDNI Logging interface shall define a log file 702 format and a set of fields to be exported through the Logging 703 protocol, with some granularity (e.g. On a per content type 704 basis). 706 LOG-8 [HIGH] The CDNI Logging interface shall define a transport 707 mechanisms to exchange CDNI Logging files. 709 LOG-9 [LOW] The CDNI Logging interface may allow a CDN to query 710 another CDN for relevant current logging records (e.g. For 711 on-demand access to real-time logging information). 713 LOG-10 [LOW] The CDNI Logging interface may support aggregate/ 714 summarized logs (e.g. total bytes delivered for a content 715 regardless of individual User Agents to which it was 716 delivered). 718 LOG-11 [LOW] The CDNI Logging interface may provide "quality" 719 metrics in the logging of deliveries to User Agents performed 720 by the Downstream CDN. 722 8. CDNI Security Requirements 724 This section identifies the requirements related to the CDNI 725 security. Some of those are expected to affect multiple or all 726 protocols. 728 SEC-1 [HIGH] All the CDNI interface shall support secure operation 729 over unsecured IP connectivity (e.g. The Internet). This 730 includes authentication, confidentiality, integrity protection 731 as well as protection against spoofing and replay. 733 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 734 against Denial of Service attacks. This includes protection 735 against spoofed delivery requests sent by user agents directly 736 to a Downstream CDN attempting to appear as if they had been 737 redirected by a given Upstream CDN when they have not. 739 SEC-3 [MED] The CDNI solution should be able to ensure that for any 740 given request redirected to a Downstream CDN, the chain of CDN 741 Delegation (leading to that request being served by that CDN) 742 can be established with non-repudiation. 744 SEC-4 [MED] The CDNI solution should be able to ensure that the 745 Downstream CDN cannot spoof a transaction log attempting to 746 appear as if it corresponds to a request redirected by a given 747 Upstream CDN when that request has not been redirected by this 748 Upstream CDN. This ensures non-repudiation by the Upstream 749 CDN of transaction logs generated by the Downstream CDN for 750 deliveries performed by the Downstream CDN on behalf of the 751 Upstream CDN. 753 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 754 Upstream CDN that has credentials to acquire content from the 755 CSP origin server (or another CDN), to allow establishment of 756 credentials authorizing the Downstream CDN to acquire the 757 content from the CSP origin server (or the other CDN) (e.g. 758 In case the content cannot be acquired from the Upstream CDN). 760 9. IANA Considerations 762 This document makes no request of IANA. 764 Note to RFC Editor: this section may be removed on publication as an 765 RFC. 767 10. Security Considerations 769 This document discusses CDNI security requirements in Section 8. 771 11. Authors 773 This document reflects the contributions from the following authors: 775 Francois Le Faucheur 777 Cisco Systems 779 flefauch@cisco.com 781 Mahesh Viveganandhan 783 Cisco Systems 785 mvittal@cisco.com 787 Grant Watson 789 BT 791 grant.watson@bt.com 793 12. Acknowledgements 795 This document leverages the earlier work of the IETF CDI working 796 group in particular as documented in [I-D.cain-request-routing-req], 797 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 799 The authors would like to thank Gilles Bertrand, Christophe Caillet, 800 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 801 Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their 802 input. 804 13. References 805 13.1. Normative References 807 [I-D.bertrand-cdni-use-cases] 808 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 809 Eardley, P., and K. Ma, "Use Cases for Content Delivery 810 Network Interconnection", draft-bertrand-cdni-use-cases-02 811 (work in progress), July 2011. 813 [I-D.davie-cdni-framework] 814 Davie, B. and L. Peterson, "Framework for CDN 815 Interconnection", draft-davie-cdni-framework-00 (work in 816 progress), July 2011. 818 [I-D.jenkins-cdni-problem-statement] 819 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 820 Distribution Network Interconnection (CDNI) Problem 821 Statement", draft-jenkins-cdni-problem-statement-02 (work 822 in progress), March 2011. 824 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 825 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 826 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 828 13.2. Informative References 830 [I-D.amini-cdi-distribution-reqs] 831 Amini, L., "Distribution Requirements for Content 832 Internetworking", draft-amini-cdi-distribution-reqs-02 833 (work in progress), November 2001. 835 [I-D.cain-request-routing-req] 836 Cain, B., "Request Routing Requirements for Content 837 Internetworking", draft-cain-request-routing-req-03 (work 838 in progress), November 2001. 840 [I-D.gilletti-cdnp-aaa-reqs] 841 "CDI AAA Requirements, 842 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 844 Authors' Addresses 846 Kent Leung (editor) 847 Cisco Systems 848 170 West Tasman Drive 849 San Jose, CA 95134 850 U.S.A. 852 Phone: +1 408 526 5030 853 Email: kleung@cisco.com 855 Yiu Lee (editor) 856 Comcast 857 One Comcast Center 858 Philadelphia, PA 19103 859 U.S.A. 861 Email: yiu_lee@cable.comcast.com