idnits 2.17.1 draft-ietf-cdni-requirements-00.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 (September 9, 2011) is 4612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MED' is mentioned on line 751, but not defined == Missing Reference: 'HIGH' is mentioned on line 740, but not defined == Missing Reference: 'LOW' is mentioned on line 760, 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: March 12, 2012 Comcast 6 September 9, 2011 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-00 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 March 12, 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 . . . . . . . . . . . . . 16 97 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 17 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 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". (OPEN ISSUE: Should requirements in 142 each section be ordered by priority?) 144 1.1. Terminology 146 This document uses the terminology defined in section 1.1 of 147 [I-D.davie-cdni-framework]. 149 2. CDNI Model and CDNI Interfaces 151 For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating 152 the CDNI problem area and the CDNI protocols is replicated below. 154 -------- 155 / \ 156 | CSP | 157 \ / 158 -------- 159 * 160 * 161 * /\ 162 * / \ 163 ---------------------- |CDNI| ---------------------- 164 / Upstream CDN \ | | / Downstream CDN \ 165 | +-------------+ | Control Interface| +-------------+ | 166 |******* Control |<======|====|========>| Control *******| 167 |* +------*----*-+ | | | | +-*----*------+ *| 168 |* * * | | | | * * *| 169 |* +------*------+ | Logging Interface| +------*------+ *| 170 |* ***** Logging |<======|====|========>| Logging ***** *| 171 |* * +-*-----------+ | | | | +-----------*-+ * *| 172 |* * * * | Request Routing | * * * *| 173 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 174 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 175 . |* * * +-------------+.| | | | +-------------+ * * *| . 176 . |* * * . CDNI Metadata | * * *| . 177 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 178 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 179 . |* * * | | | . \ / | | | * * *| . 180 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 181 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 182 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 183 . |******* +---------+| | Acquisition | |+----------+ *******| . 184 . | +-------------+ | | +-------*-----+ | . 185 . \ / \ * / . 186 . ---------------------- ---------*------------ . 187 . * . 188 . * Delivery . 189 . * . 190 . +--*---+ . 191 ...............Request.............................| User |..Request.. 192 | Agent| 193 +------+ 195 <==> interfaces inside the scope of CDNI 197 **** interfaces outside the scope of CDNI 198 .... interfaces outside the scope of CDNI 200 Figure 1: CDNI Model and CDNI Interfaces 202 3. Generic CDNI Requirements 204 This section identifies generic requirements independent of the 205 individual CDNI interfaces. Some of those are expected to affect 206 multiple or all interfaces. 208 GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or 209 leverage existing IETF protocols. 211 GEN-2 [HIGH] The CDNI solution shall not require a change, or an 212 upgrade, to the User Agent to benefit from content delivery 213 through interconnected CDNs. 215 GEN-3 [HIGH] The CDNI solution shall not require a change, or an 216 upgrade, to the Content Service Provider to benefit from 217 content delivery through interconnected CDNs. 219 GEN-4 [HIGH] The CDNI solution shall not require intra-CDN 220 information to be exposed to other CDNs for effective and 221 efficient delivery of the content. Examples of intra-CDN 222 information include surrogate topology, surrogate status, 223 cached content, etc. 225 GEN-5 [HIGH] The CDNI solution shall support delivery to the user 226 agent based on HTTP [RFC2616]. (Note that while delivery and 227 acquisition "data plane" protocols are out of the CDNI 228 solution scope, the CDNI solution "control plane" protocols 229 are expected to participate in enabling, selecting or 230 facilitating operations of such acquisition and delivery 231 protocols. Hence it is useful to state requirements on the 232 CDNI solution in terms of which acquisition and delivery 233 protocols). 235 GEN-6 [HIGH] The CDNI solution shall support acquisition across 236 CDNs based on HTTP [RFC2616]. 238 GEN-7 [LOW] The CDNI solution may support delivery to the user 239 agent based on protocols other than HTTP. 241 GEN-8 [LOW] The CDNI solution may support acquisition across CDNs 242 based on protocols other than HTTP. 244 GEN-9 [MED] The CDNI solution should support cascaded CDN 245 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 246 to an arbitrary number of levels.(OPEN ISSUE: arbitrary 247 number should more than one level?) 249 GEN-10 [MED] The CDNI solution should support an arbitrary topology 250 of interconnected CDNs (i.e. the CDN topology cannot be 251 restricted to a tree, a loop-free topology, etc.). 253 GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI 254 information exchange. 256 GEN-12 [HIGH] When making use of third party reference, the CDNI 257 solution shall consider the potential issues associated with 258 the use of various format of third-party references (e.g. 259 NAT or IPv4/IPv6 translation potentially breaking third-party 260 references based on an IP addresses such as URI containing 261 IPv4 or IPv6 address litterals, split DNS situations 262 potentially breaking third-party references based on DNS 263 fully qualified domain names) and wherever possible avoid, 264 minimize or mitigate the associated risks based on the 265 specifics of the environments where the reference is used 266 (e.g. likely or unlikely presence of NAT in the path). In 267 particular, this applies to situations where the CDNI 268 solution needs to construct and convey uniform resource 269 identifiers for directing/redirecting a content request, as 270 well as to situations where the CDNI solution needs to pass 271 on a third party reference (e.g. to identify a User Agent) in 272 order to allow another entity to make a more informed 273 decision (e.g. make a more informed request routing decision 274 by attempting to derive location information from the third 275 party reference). 277 GEN-13 [LOW] The CDNI solution should support virtualization of the 278 Downstream CDN, so that the Downstream CDN can appear as 279 multiple logical Downstream CDNs. (OPEN ISSUE: 280 Virtualization is transparent to CDNI, remove requirement or 281 justify why uCDN/dCDN needs to be aware?) 283 GEN-14 (OPEN ISSUE: Add HTTP ABR requirements) 285 4. CDNI Control Interface Requirements 287 The primary purpose of the CDNI Control interface is to initiate the 288 interconnection across CDNs, bootstrap the other CDNI interfaces and 289 trigger actions into the Downstream CDN by the Upstream CDN (such as 290 delete object from caches or trigger pre-positioned content 291 acquisition). We observe that while the CDNI Control interface is 292 currently discussed as a single "protocol", further analysis will 293 determine whether the corresponding requirements are to be realized 294 over a single interface and protocol, or over multiple interfaces and 295 protocols. 297 CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream 298 CDN to request that the Downstream CDN (and, if cascaded 299 CDNs are supported by the solution, that the potential 300 cascaded Downstream CDNs) perform the following actions on 301 an object or object set: 303 * Mark an object(s) and/or its CDNI metadata as "stale" 304 and revalidate them before they are delivered again 306 * Delete an object(s) and/or its CDNI metadata from the 307 CDN surrogates and any storage. 309 CNTL-2 [HIGH] The CDNI Control interface shall allow the downstream 310 CDN to report on the completion of these actions (by itself, 311 and if cascaded CDNs are supported by the solution, by 312 potential cascaded Downstream CDNs), in a manner appropriate 313 for the action (e.g. synchronously or asynchronously). 315 CNTL-3 [HIGH] The CDNI Control interface shall support initiation 316 and control by the Upstream CDN of pre-positioned CDNI 317 metadata acquisition by the Downstream CDN. 319 CNTL-4 [MED] The CDNI Control interface should support initiation 320 and control by the Upstream CDN of pre-positioned content 321 acquisition by the Downstream CDN.(OPEN ISSUE: how much 322 influence the Upstream CDN ought to have on pre-positioning 323 of the content on surrogates inside the Downstream CDN is 324 TBD). 326 CNTL-5 [LOW] The CDNI Control interface may allow a CDN to 327 establish, update and terminate a CDN interconnection with 328 another CDN whereby one CDN can act as a Downstream CDN for 329 the other CDN (that acts as an Upstream CDN). 331 CNTL-6 [LOW] The CDNI Control interface may allow control of the 332 CDNI interconnection between any two CDNs independently for 333 each direction (i.e. For the direction where CDN1 is the 334 Upstream CDN and CDN2 is the Downstream CDN, and for the 335 direction where CDN2 is the Upstream CDN and CDN1 is the 336 Downstream CDN). 338 CNTL-7 [LOW] The CDNI Control interface may allow bootstrapping of 339 the Request-Routing interface. For example, this can 340 potentially include: 342 * negotiation of the Request-Routing method (e.g. DNS vs 343 HTTP, if more than one method is specified) 345 * discovery of the Request-Routing protocol endpoints 347 * information necessary to establish secure communication 348 between the Request-Routing protocol endpoints. 350 CNTL-8 [LOW] The CDNI Control interface may allow bootstrapping of 351 the CDNI Metadata interface. This information could, for 352 example, include: 354 * discovery of the CDNI Metadata signaling protocol 355 endpoints 357 * information necessary to establish secure communication 358 between the CDNI Metadata signaling protocol endpoints. 360 CNTL-9 [LOW] The CDNI Control interface may allow bootstrapping of 361 the Content Acquisition interface. This could, for example, 362 include exchange and negotiation of the Content Acquisition 363 protocols to be used across the CDNs (e.g. HTTP, HTTPS, 364 FTP, ATIS C2). 366 CNTL-10 [LOW] The CDNI Control interface may allow exchange and 367 negotiation of delivery authorization mechanisms to be 368 supported across the CDNs (e.g. URI signature based 369 validation). 371 CNTL-11 [LOW] The CDNI Control interface may allow bootstrapping of 372 the CDNI Logging interface. This information could, for 373 example, include: 375 * discovery of the Logging protocol endpoints 377 * information necessary to establish secure communication 378 between the Logging protocol endpoints 380 * negotiation/definition of the log file format and set of 381 fields to be exported through the Logging protocol, with 382 some granularity (e.g. On a per content type basis). 384 * negotiation/definition of parameters related to 385 transaction Logs export (e.g., export protocol, file 386 compression, export frequency, directory). 388 5. CDNI Request Routing Interface Requirements 390 The main function of the Request Routing interface is to allow the 391 Request-Routing systems in interconnected CDNs to communicate to 392 facilitate redirection of the request across CDNs. 394 REQ-1 [HIGH] The CDNI Control interface shall allow the Downstream 395 CDN to communicate to the Upstream CDN coarse information 396 about the Downstream CDN ability and/or willingness to handle 397 requests from the Upstream CDN. For example, this could 398 potentially include a binary signal ("Downstream CDN ready/ 399 not-ready to take additional requests from Upstream CDN") to 400 be used in case of excessive load or failure condition in the 401 Downstream CDN. (OPEN ISSUE: Belong to Control Interface 402 section?) 404 REQ-2 [MED] The CDNI Request-Routing interface should allow the 405 Downstream CDN to communicate to the Upstream CDN aggregate 406 information to facilitate CDN selection during request 407 routing, such as Downstream CDN capabilities, resources and 408 affinities (i.e. Preferences or cost). This information 409 could, for example, include: 411 * supported content types and delivery protocols 413 * footprint (e.g. layer-3 coverage) 415 * a set of metrics/attributes (e.g. Streaming bandwidth, 416 storage resources, distribution and delivery priority) 418 * a set of affinities (e.g. Preferences, indication of 419 distribution/delivery fees) 421 * information to facilitate request redirection (e.g. 422 Reachability information of Downstream CDN Request 423 Routing system). 425 [Note: Some of this information - such as supported content 426 types and delivery protocols- may also potentially be taken 427 into account by the distribution system in the Upstream CDN 428 for pre-positioning of content and/or metadata in the 429 Downstream CDN in case of pre-positioned content acquisition 430 and/or pre-positioned CDNI metadata acquisition.] 432 REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- 433 Routing interface shall allow the Downstream CDN to also 434 include in the information communicated to the Upstream CDN, 435 information on the capabilities, resources and affinities of 436 CDNs to which the Downstream CDN may (in turn) redirect 437 requests received by the Upstream CDN. In that case, the 438 CDNI Request-Routing interface shall prevent looping of such 439 information exchange. 441 REQ-4 [LOW] The CDNI Control interface may allow the Downstream CDN 442 to communicate to the Upstream CDN aggregate information on 443 CDNI administrative limits and policy. This information can 444 be taken into account by the Upstream CDN Request Routing 445 system in its CDN Selection decisions. This information 446 could, for example, include: 448 * maximum number of requests redirected by the Upstream CDN 449 to be served simultaneously by the Downstream CDN 451 * maximum aggregate volume of content (e.g. in Terabytes) 452 to be delivered by the Downstream CDN over a time period. 454 REQ-5 [HIGH] The CDNI Request-Routing architecture and interface 455 shall support efficient request-routing for small objects. 456 This may, for example, call for a mode of operation (e.g. 457 DNS-based request routing) where freshness and accuracy of 458 CDN/Surrogate selection can be traded-off against reduced 459 request-routing load (e.g. Via lighter-weight queries and 460 caching of request-routing decisions). (OPEN ISSUE: 461 Surrogate selection is out of scope?) 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. (OPEN 469 ISSUE: Surrogate selection is out of scope?) 471 REQ-7 [HIGH] The CDNI Request-Routing architecture shall support 472 recursive CDNI request routing. 474 REQ-8 [HIGH] The CDNI Request-Routing architecture shall support 475 iterative CDNI request routing. 477 REQ-9 [MED] In case of detection of a request redirection loop, the 478 CDNI Request-Routing loop prevention mechanism should allow 479 routing of the request (as opposed to the request loop being 480 simply interrupted without routing the request). (OPEN 481 ISSUE: Why route a looped request?) 483 REQ-10 [MED] The CDNI Request-Routing protocol should support a 484 mechanism allowing enforcment of a limit on the number of 485 successive CDN redirections for a given request. 487 REQ-11 [LOW] The CDNI Request-Routing protocol may support a 488 mechanism allowing an upstream CDN to avoid redirecting a 489 request to a downstream CDN if that is likely to result in 490 the total redirection time exceeding some limit. 492 REQ-12 [HIGH] The CDNI Request-Routing protocol shall allow the 493 Upstream CDN to include, in the query to the Downstream CDN, 494 the necessary information to allow the Downstream CDN to 495 process the redirection query. This could, for example, 496 include: 498 * information from which the location of the user-agent 499 that originated the request can be inferred (e.g. User 500 Agent fully qualified domain name in case of HTTP-based 501 Request Routing, DNS Proxy fully qualified domain name in 502 case of DNS-based Request Routing) 504 * requested resource information (e.g. Resource URI in 505 case of HTTP-based Request Routing, Resource hostname in 506 case of DNS-based Request Routing) 508 * additional available request information (e.g. request 509 headers in case of HTTP-based Request Routing). 511 REQ-13 [LOW] The CDNI Request-Routing protocol may also allow the 512 Upstream CDN to convey information pointing to CDNI metadata 513 applicable (individually or through inheritance) to the 514 requested content. For illustration, the CDNI metadata 515 pointed to could potentially include metadata that is 516 applicable to any content, metadata that is applicable to a 517 content collection (to which the requested content belongs) 518 and/or metadata that is applicable individually to the 519 requested content. 521 REQ-14 [HIGH] The CDNI Request-Routing interface shall allow the 522 Downstream CDN to include the following information in the 523 response to the Upstream CDN: 525 * status code, in particular indicating acceptance or 526 rejection of request (e.g. Because the Downstream CDN is 527 unwilling or unable to serve the request). In case of 528 rejection, an error code is also to be provided, which 529 allows the Upstream CDN to react appropriately (e.g. 530 Select another Downstream CDN, or serve the request 531 itself) 533 * redirection information (e.g. Resource URI in case of 534 HTTP-based Request Routing, equivalent of a DNS record in 535 case of DNS-based Request Routing). 537 6. CDNI Metadata Distribution Interface Requirements 539 The primary function of the CDNI Metadata Distribution interface is 540 to allow the Distribution system in interconnected CDNs to 541 communicate to ensure Content Distribution Metadata with inter-CDN 542 scope can be exchanged across CDNs. We observe that while the CDNI 543 Metadata Distribution protocol is currently discussed as a single 544 "protocol", further analysis will determine whether the corresponding 545 requirements are to be realized over a single interface and protocol, 546 or over multiple interfaces and protocols. For example, a subset of 547 the CDNI metadata might be conveyed in-band along with the actual 548 content acquisition across CDNs (e.g. content MD5 in HTTP header) 549 while another subset might require an out-of-band interface & 550 protocol (e.g. geo-blocking information). 552 META-1 [HIGH] The CDNI Metadata Distribution interface shall allow 553 the Upstream CDN to provide the Downstream CDN with content 554 distribution metadata of inter-CDN scope. 556 META-2 [HIGH] The CDNI Metadata Distribution interface shall 557 support exchange of CDNI metadata for both the dynamic 558 content acquisition model and the pre-positioning content 559 acquisition model. 561 META-3 [HIGH] The CDNI Metadata Distribution interface shall 562 support a mode where no, or a subset of, the Metadata is 563 initially communicated to the Downstream CDN along with 564 information about how/where to acquire the rest of the CDNI 565 Metadata (i.e. Dynamic CDNI metadata acquisition). (OPEN 566 ISSUE: Confirm high priority) 568 META-4 [MED] The CDNI Metadata Distribution interface should 569 support a mode where all the relevant Metadata is initially 570 communicated to the Downstream CDN (i.e. Pre-positioned 571 CDNI metadata acquisition). (OPEN ISSUE: Confirm medium 572 priority) 574 META-5 [HIGH] Whether in the pre-positioned content acquisition 575 model or in the dynamic content acquisition model, the CDNI 576 Metadata Distribution interface shall provide the necessary 577 information to allow the Downstream CDN to acquire the 578 content from an upstream source (e.g. Acquisition protocol 579 and Uniform Resource Identifier in Upstream CDN- or rules to 580 construct this URI). 582 META-6 [HIGH] The CDNI metadata shall allow signaling of one or 583 more upstream sources, where each upstream source can be in 584 the Upstream CDN, in another CDN, the CSP origin server or 585 any arbitrary source designated by the Upstream CDN. Note 586 that some upstream sources (e.g. the content origin server) 587 may or may not be willing to serve the content to the 588 Downstream CDN, if this policy is known to the upstream CDN 589 then it may omit those sources when exchanging CDNI 590 metadata. 592 META-7 [HIGH] The CDNI Metadata Distribution interface shall allow 593 the Upstream CDN to request addition and modification of 594 CDNI Metadata into the Downstream CDN. 596 META-8 [HIGH] The CDNI Metadata Distribution interface shall allow 597 removal of obsolete CDNI Metadata from the Downstream CDN 598 (this could, for example, be achieved via an explicit 599 removal request from the Upstream CDN or via expiration of a 600 Time-To-Live associated to the Metadata). 602 META-9 [HIGH] The CDNI Metadata Distribution interface shall allow 603 association of CDNI Metadata at the granularity of 604 individual object. This is necessary to achieve fine-grain 605 Metadata distribution at the level of an individual object 606 when necessary. 608 META-10 [HIGH] The CDNI Metadata Distribution interface shall allow 609 association of CDNI Metadata at the granularity of an object 610 set. This is necessary to achieve scalable distribution of 611 metadata when a large number of objects share the same 612 distribution policy. 614 META-11 [HIGH] The CDNI Metadata Distribution interface shall 615 support multiple levels of inheritance with precedence to 616 more specific metadata. For example, the CDNI Metadata 617 Distribution protocol may support metadata that is 618 applicable to any content, metadata that is applicable to a 619 content collection and metadata that is applicable to an 620 individual content where content level metadata overrides 621 content collection metadata that overrides metadata for any 622 content. 624 META-12 [HIGH] The CDNI Metadata Distribution interface shall ensure 625 that conflicting metadata with overlapping scope are 626 prevented or deterministically handled. 628 META-13 [HIGH] The CDNI Metadata Distribution interface shall 629 provide indication by the Downstream CDN to the Upstream CDN 630 of whether the CDNI metadata (and corresponding future 631 request redirections) is accepted or rejected. When 632 rejected, the CDNI Metadata Distribution protocol Must allow 633 the Downstream CDN to provide information about the cause of 634 the rejection. 636 META-14 [HIGH] The CDNI Metadata Distribution interface shall allow 637 signaling of content distribution control policies. For 638 example, this could potentially include: 640 * geo-blocking information (i.e. Information defining 641 geographical areas where the content is to be made 642 available or blocked) 644 * availability windows (i.e. Information defining time 645 windows during which the content is to be made available 646 or blocked; expiration time may also be included to 647 remove content) (OPEN ISSUE: Expiration time needed?) 649 * delegation whitelist/blacklist (i.e. Information 650 defining which downstream CDNs the content may/may not 651 be delivered through) 653 META-15 [HIGH] The CDNI Metadata interface shall be able to exchange 654 a set of well-accepted metadata elements with specified 655 semantics (e.g. start of time window, end of time window). 657 META-16 [HIGH] The CDNI Metadata interface shall allow exchange of 658 opaque metadata element, whose semantic is not defined in 659 CDNI but established by private CDN agreement. 661 META-17 [HIGH] The CDNI Metadata Distribution interface shall allow 662 signaling of authorization checks and validation that are to 663 be performed by the surrogate before delivery. For example, 664 this could potentially include: 666 * need to validate URI signed information (e.g. Expiry 667 time, Client IP address). 669 META-18 [LOW] The CDNI Metadata Distribution interface may allow 670 signaling of CDNI-relevant surrogate cache behavior 671 parameters. For example, this could potentially include: 673 * control of whether the query string of HTTP URI is to be 674 ignored by surrogate cache 676 * content revalidation parameters (e.g. TTL) 678 7. CDNI Logging Interface Requirements 680 This section identifies the requirements related to the CDNI Logging 681 interface. We observe that while the CDNI Logging interface is 682 currently discussed as a single "protocol", further analysis will 683 determine whether the corresponding requirements are to be realized 684 over a single interface and protocol, or over multiple interfaces and 685 protocols. 687 LOG-1 [HIGH] The CDNI logging architecture and interface shall 688 ensure reliable logging of CDNI events. 690 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of 691 deliveries to User Agents performed by the Downstream CDN as a 692 result of request redirection by the Upstream CDN. 694 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface 695 shall allow the Downstream CDN to report to the Upstream CDN 696 logging for deliveries performed by the Downstream CDN itself 697 as well as logging for deliveries performed by cascaded CDNs 698 on behalf of the Downstream CDN. 700 LOG-4 [HIGH] The CDNI Logging interface shall provide logging of 701 distribution performed by the Upstream CDN as a result of 702 acquisition request by the Downstream CDN. 704 LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline 705 exchange of logging records. 707 LOG-6 [MED] The CDNI Logging interface should also support 708 additional timing constraints for some types of logging 709 records (e.g. near-real time for monitoring and analytics 710 applications) 712 LOG-7 [HIGH] The CDNI Logging interface shall define a log file 713 format and a set of fields to be exported through the Logging 714 protocol, with some granularity (e.g. On a per content type 715 basis). 717 LOG-8 [HIGH] The CDNI Logging interface shall define a transport 718 mechanisms to exchange CDNI Logging files. 720 LOG-9 [LOW] The CDNI Logging interface may allow a CDN to query 721 another CDN for relevant current logging records (e.g. For 722 on-demand access to real-time logging information). 724 [Editor's note: should we add a requirement for support of aggregate/ 725 summarized logs (e.g. total bytes delivered for a content regardless 726 of individual User Agents to which it was delivered)] (OPEN ISSUE: 727 LOW for aggregate/summarized logs) 729 8. CDNI Security Requirements 731 This section identifies the requirements related to the CDNI 732 security. Some of those are expected to affect multiple or all 733 protocols. 735 SEC-1 [HIGH] All the CDNI interface shall support secure operation 736 over unsecured IP connectivity (e.g. The Internet). This 737 includes authentication, confidentiality, integrity protection 738 as well as protection against spoofing and replay. 740 SEC-2 [HIGH] The CDNI solution shall provide sufficient protection 741 against Denial of Service attacks. This includes protection 742 against spoofed delivery requests sent by user agents directly 743 to a Downstream CDN attempting to appear as if they had been 744 redirected by a given Upstream CDN when they have not. 746 SEC-3 [MED] The CDNI solution should be able to ensure that for any 747 given request redirected to a Downstream CDN, the chain of CDN 748 Delegation (leading to that request being served by that CDN) 749 can be established with non-repudiation. 751 SEC-4 [MED] The CDNI solution should be able to ensure that the 752 Downstream CDN cannot spoof a transaction log attempting to 753 appear as if it corresponds to a request redirected by a given 754 Upstream CDN when that request has not been redirected by this 755 Upstream CDN. This ensures non-repudiation by the Upstream 756 CDN of transaction logs generated by the Downstream CDN for 757 deliveries performed by the Downstream CDN on behalf of the 758 Upstream CDN. 760 SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an 761 Upstream CDN that has credentials to acquire content from the 762 CSP origin server (or another CDN), to allow establishment of 763 credentials authorizing the Downstream CDN to acquire the 764 content from the CSP origin server (or the other CDN) (e.g. 765 In case the content cannot be acquired from the Upstream CDN). 767 9. IANA Considerations 769 This document makes no request of IANA. 771 Note to RFC Editor: this section may be removed on publication as an 772 RFC. 774 10. Security Considerations 776 This document discusses CDNI security requirements in Section 8. 778 11. Authors 780 This document reflects the contributions from the following authors: 782 Francois Le Faucheur 784 Cisco Systems 786 flefauch@cisco.com 788 Mahesh Viveganandhan 790 Cisco Systems 792 mvittal@cisco.com 794 Grant Watson 796 BT 798 grant.watson@bt.com 800 12. Acknowledgements 802 This document leverages the earlier work of the IETF CDI working 803 group in particular as documented in [I-D.cain-request-routing-req], 804 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 806 The authors would like to thank Gilles Bertrand, Christophe Caillet, 807 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 808 Stephan, Eric Burger, Susan He, and Kevin Ma for their input. 810 13. References 811 13.1. Normative References 813 [I-D.bertrand-cdni-use-cases] 814 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 815 Eardley, P., and K. Ma, "Use Cases for Content Delivery 816 Network Interconnection", draft-bertrand-cdni-use-cases-02 817 (work in progress), July 2011. 819 [I-D.davie-cdni-framework] 820 Davie, B. and L. Peterson, "Framework for CDN 821 Interconnection", draft-davie-cdni-framework-00 (work in 822 progress), July 2011. 824 [I-D.jenkins-cdni-problem-statement] 825 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 826 Distribution Network Interconnection (CDNI) Problem 827 Statement", draft-jenkins-cdni-problem-statement-02 (work 828 in progress), March 2011. 830 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 831 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 832 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 834 13.2. Informative References 836 [I-D.amini-cdi-distribution-reqs] 837 Amini, L., "Distribution Requirements for Content 838 Internetworking", draft-amini-cdi-distribution-reqs-02 839 (work in progress), November 2001. 841 [I-D.cain-request-routing-req] 842 Cain, B., "Request Routing Requirements for Content 843 Internetworking", draft-cain-request-routing-req-03 (work 844 in progress), November 2001. 846 [I-D.gilletti-cdnp-aaa-reqs] 847 "CDI AAA Requirements, 848 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 850 Authors' Addresses 852 Kent Leung (editor) 853 Cisco Systems 854 170 West Tasman Drive 855 San Jose, CA 95134 856 U.S.A. 858 Phone: +1 408 526 5030 859 Email: kleung@cisco.com 861 Yiu Lee (editor) 862 Comcast 863 One Comcast Center 864 Philadelphia, PA 19103 865 U.S.A. 867 Email: yiu_lee@cable.comcast.com