idnits 2.17.1 draft-lefaucheur-cdni-requirements-02.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 (July 9, 2011) is 4675 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Leung 3 Internet-Draft Cisco 4 Intended status: Informational Y. Lee 5 Expires: January 10, 2012 Comcast 6 F. Le Faucheur 7 M. Viveganandhan 8 Cisco 9 G. Watson 10 BT 11 July 9, 2011 13 Content Distribution Network Interconnection (CDNI) Requirements 14 draft-lefaucheur-cdni-requirements-02 16 Abstract 18 Content Delivery Networks (CDNs) are frequently used for large-scale 19 content delivery. As a result, existing CDN providers are scaling up 20 their infrastructure and many Network Service Providers (NSPs) are 21 deploying their own CDNs. There is a requirement for interconnecting 22 standalone CDNs so that their collective CDN footprint can be 23 leveraged for the end-to-end delivery of content from Content Service 24 Providers (CSPs) to end users. The Content Distribution Network 25 Interconnection (CDNI) working group has been chartered to develop an 26 interoperable and scalable solution for such CDN interconnection. 28 The goal of the present document is to outline the requirements for 29 the solution and interfaces to be specified by the CDNI working 30 group. 32 Requirements Language 34 The key words "Must", "Should" and "May" in this document are to be 35 interpreted in the following way: 37 o "Must" indicates requirements that are to be supported by the CDNI 38 protocols in the stated scope (aka "within initial CDNI scope" or 39 "beyond initial scope"). A requirement is stated as a "Must" when 40 it is established by that it can be met without compromising the 41 targeted schedule for WG deliverables, or when it is established 42 that specifying a solution without meeting this requirement would 43 not make sense and would justify re-adjusting the WG schedule, or 44 both. 46 o "Should" indicates requirements that are to be supported by the 47 CDNI protocols in the stated scope (aka "within initial CDNI 48 scope" or "beyond initial scope") unless the WG realizes at a 49 later stage that attempting to meet this requirement would 50 compromise the overall WG schedule (for example it would involve 51 complexities that would result in significantly delaying the 52 deliverables). 54 o "May" indicates requirements that are to be supported by the CDNI 55 protocols in the stated scope (aka "within initial CDNI scope" or 56 "beyond initial scope") provided that dedicating WG resources to 57 this work does not prevent addressing "Should" and "Must" 58 requirements and that attempting to meet this requirement would 59 not compromise the overall WG schedule. 61 Status of this Memo 63 This Internet-Draft is submitted in full conformance with the 64 provisions of BCP 78 and BCP 79. 66 Internet-Drafts are working documents of the Internet Engineering 67 Task Force (IETF). Note that other groups may also distribute 68 working documents as Internet-Drafts. The list of current Internet- 69 Drafts is at http://datatracker.ietf.org/drafts/current/. 71 Internet-Drafts are draft documents valid for a maximum of six months 72 and may be updated, replaced, or obsoleted by other documents at any 73 time. It is inappropriate to use Internet-Drafts as reference 74 material or to cite them other than as "work in progress." 76 This Internet-Draft will expire on January 10, 2012. 78 Copyright Notice 80 Copyright (c) 2011 IETF Trust and the persons identified as the 81 document authors. All rights reserved. 83 This document is subject to BCP 78 and the IETF Trust's Legal 84 Provisions Relating to IETF Documents 85 (http://trustee.ietf.org/license-info) in effect on the date of 86 publication of this document. Please review these documents 87 carefully, as they describe your rights and restrictions with respect 88 to this document. Code Components extracted from this document must 89 include Simplified BSD License text as described in Section 4.e of 90 the Trust Legal Provisions and are provided without warranty as 91 described in the Simplified BSD License. 93 Table of Contents 95 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 96 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 97 2. CDNI Model and CDNI protocols . . . . . . . . . . . . . . . . 5 98 3. Generic Requirements . . . . . . . . . . . . . . . . . . . . . 7 99 3.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 7 100 3.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 8 101 4. CDNI Control Protocol Requirements . . . . . . . . . . . . . . 8 102 4.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 9 103 4.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 9 104 5. CDNI Request Routing Protocol Requirements . . . . . . . . . . 11 105 5.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 11 106 5.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 14 107 6. CDNI Metadata Distribution Protocol Requirements . . . . . . . 15 108 6.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 15 109 6.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 17 110 7. CDNI Logging Protocol Requirements . . . . . . . . . . . . . . 18 111 7.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 18 112 7.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 19 113 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 19 114 8.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 19 115 8.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 20 116 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 117 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 118 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 120 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 121 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 124 1. Introduction 126 The volume of video and multimedia content delivered over the 127 Internet is rapidly increasing and expected to continue doing so in 128 the future. In the face of this growth, Content Delivery Networks 129 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 130 content, improved quality of experience for end users, and increased 131 robustness of delivery. For these reasons CDNs are frequently used 132 for large-scale content delivery. As a result, existing CDN 133 providers are scaling up their infrastructure and many Network 134 Service Providers (NSPs) are deploying their own CDNs. It is 135 generally desirable that a given content item can be delivered to an 136 End User regardless of that End User's location or attachment 137 network. However, the footprint of a given CDN in charge of 138 delivering a given content may not expand close enough to the End 139 User's current location or attachment network to realize the cost 140 benefit and user experience that a more distributed CDN would 141 provide. This creates a requirement for interconnecting standalone 142 CDNs so that their collective CDN footprint can be leveraged for the 143 end-to-end delivery of content from Content Service Providers (CSPs) 144 to End Users. However, no standards or open specifications currently 145 exist to facilitate such CDN interconnection. 147 [I-D.jenkins-cdni-problem-statement] outlines the problem area that 148 the CDNI working group is chartered to address. 149 [I-D.bertrand-cdni-use-cases] discusses the use cases for CDN 150 Interconnection. [I-D.davie-cdni-framework] discusses the technology 151 framework for the CDNI solution and interfaces. 153 The goal of the present document is to document the requirements for 154 the CDNI solution and interfaces. In accordance with the working 155 group charter, the work is prioritized in a "walk before you run" 156 approach: the present document separates the CDNI requirements into a 157 set of more urgent requirements that are within the initial scope of 158 the CDNI working group, and a set of less urgent additional 159 requirements that are left to potential future rechartering of the 160 working group. 162 1.1. Terminology 164 This document uses the terminology defined in section 1.1 of 165 [I-D.jenkins-cdni-problem-statement]. 167 This also defined the following additional terms [Editor's Note: 168 these definitions may be better located in another document such as 169 the Problem Statement]: 171 o Recursive CDNI request routing: When an Upstream CDN elects to 172 redirect a request towards a Downstream CDN, the Upstream CDN can 173 query the Downstream CDN Request Routing system via the CDNI 174 Request Routing protocol (or use information cached from earlier 175 similar queries) to find out how the Downstream CDN wants the 176 request to be redirected, which allows the Upstream CDN to factor 177 in the Downstream CDN response when redirecting the user agent. 178 This approach is referred to as "recursive" CDNI request routing. 179 Note that the Downstream CDN may elect to have the request 180 redirected directly to a Surrogate inside the Downstream CDN, to 181 the Request-Routing System of the Downstream CDN, to another CDN, 182 or to any other system that the Downstream CDN sees as fit for 183 handling the redirected request. 185 o Iterative CDNI Request Routing: When an Upstream CDN elects to 186 redirect a request towards a Downstream CDN, the Upstream CDN can 187 base its redirection purely on a local decision (and without 188 attempting to take into account how the Downstream CDN may in turn 189 redirect the user agent). In that case, the Upstream CDN 190 redirects the request to the request routing system in the 191 Downstream CDN, which in turn will decide how to redirect that 192 request: this approach is referred to as "iterative" CDNI request 193 routing. 195 2. CDNI Model and CDNI protocols 197 For convenience Figure 1 from [I-D.jenkins-cdni-problem-statement] 198 illustrating the CDNI problem area and the CDNI protocols is 199 replicated below. 201 -------- 202 / \ 203 | CSP | 204 \ / 205 -------- 206 * 207 * 208 * /\ 209 * / \ 210 --------------------- |CDNI| --------------------- 211 / Upstream CDN \ | | / Downstream CDN \ 212 | +-------------+ | Control protocol| +-------------+ | 213 | |CDN Control |<======|====|=======>| CDN Control | | 214 | +------*-*-*--+ | | | | +-*-*-*-------+ | 215 | * * * | | | | * * * | 216 | +------*------+ | Logging protocol| +-----*-------+ | 217 | ****| Logging |<======|====|=======>| Logging |**** | 218 | * --------------+ | | | | +-------------+ * | 219 | * * * | Request Routing | * * * | 220 ....*...+--------*----+ | protocol | +---*---------+...*..... 221 . | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | . 222 . | * * +-------------+.| | | | +-------------+ * * | . 223 . | * * * . CDNI Metatdata | * * * | . 224 . | * * +----------*--+ |. protocol | +-*-----------+ * * | . 225 . | * * |Distribution |<==.===|====|=======>| Distribution| * * | . 226 . | * * | | | . \ / | | | * * | . 227 . | * * | | | . \/ | | | * * | . 228 . | * ****+---------+ | | ....Request......+---------+**** * | . 229 . | ******|Surrogate|*************************|Surrogate|****** | . 230 . | | +---------+ | | Acquisition | | +-----*---+ | | . 231 . | +-------------+ | | +-------*-----+ | . 232 . \ / \ * / . 233 . --------------------- ---------*----------- . 234 . * . 235 . * Delivery . 236 . * . 237 . +------+ . 238 ...............Request...........................| User |..Request.. 239 | Agent| 240 +------+ 242 <==> interfaces inside the scope of CDNI 244 **** interfaces outside the scope of CDNI 245 .... interfaces outside the scope of CDNI 247 Figure 1: CDNI Model and CDNI APIs 249 3. Generic Requirements 251 This section identifies generic requirements independent of the 252 individual CDNI protocols. Some of those are expected to affect 253 multiple or all protocols. 255 3.1. Within Initial CDNI Scope 257 R1 Wherever possible, the CDNI protocols Should reuse or leverage 258 existing IETF protocols. 260 R2 The CDNI solution Must not require a change, or an upgrade, to 261 the User Agent to benefit from content delivery through 262 interconnected CDNs. 264 R3 The CDNI solution Must not require intra-CDN information to be 265 exposed to other CDNs for effective and efficient delivery of 266 the content. Examples of intra-CDN information include 267 surrogate topology, surrogate status, cached content, etc. 269 R4 The CDNI solution Must support delivery to the user agent based 270 on HTTP [RFC2616]. [Note that while delivery and acquisition 271 "data plane" protocols are out of the CDNI solution scope, the 272 CDNI solution "control plane" protocols are expected to 273 participate in enabling, selecting or facilitating operations of 274 such acquisition and delivery protocols. Hence it is useful to 275 state requirements on the CDNI solution in terms of which 276 acquisition and delivery protocols]. 278 R5 The CDNI solution Must support acquisition across CDNs based on 279 HTTP [RFC2616]. 281 R6 The CDNI solution May support delivery to the user agent based 282 on protocols other than HTTP. 284 R7 The CDNI solution May support acquisition across CDNs based on 285 protocols other than HTTP. 287 R8 The CDNI solution Should support cascaded CDN redirection (CDN1 288 redirects to CDN2 that redirects to CDN3) to an arbitrary number 289 of levels. 291 R9 The CDNI solution Should support an arbitrary topology of 292 interconnected CDNs (i.e. the CDN topology cannot be restricted 293 to a tree, a loop-free topology, etc.). 295 R10 The CDNI solution Must prevent looping of any CDNI information 296 exchange. 298 R11 When making use of third party reference, the CDNI solution Must 299 consider the potential issues associated with the use of various 300 format of third-party references (e.g. NAT or IPv4/IPv6 301 translation potentially breaking third-party references based on 302 an IP addresses such as URI containing IPv4 or IPv6 address 303 litterals, split DNS situations potentially breaking third-party 304 references based on DNS fully qualified domain names) and 305 wherever possible avoid, minimize or mitigate the associated 306 risks based on the specifics of the environments where the 307 reference is used (e.g. likely or unlikely presence of NAT in 308 the path). In particular, this applies to situations where the 309 CDNI solution needs to construct and convey uniform resource 310 identifiers for directing/redirecting a content request, as well 311 as to situations where the CDNI solution needs to pass on a 312 third party reference (e.g. to identify a User Agent) in order 313 to allow another entity to make a more informed decision (e.g. 314 make a more informed request routing decision by attempting to 315 derive location information from the third party reference). 317 3.2. Beyond Initial CDNI Scope 319 R12 The CDNI solution Must support cascaded CDN redirection (CDN1 320 redirects to CDN2 that redirects to CDN3) to an arbitrary number 321 of levels. [Note: this "Must" requirement appeared as a 322 "Should" requirement in Section 3.1] 324 R13 The CDNI solution Must support an arbitrary topology of 325 interconnected CDNs (i.e. the CDN topology cannot be restricted 326 to a tree, a loop-free topology, etc.). [Note: this "Must" 327 requirement appeared as a "Should" requirement in Section 3.1] 329 R14 The CDNI solution Should support virtualization of the 330 Downstream CDN, so that the Downstream CDN can appear as 331 multiple logical Downstream CDNs. 333 4. CDNI Control Protocol Requirements 335 The primary purpose of the CDNI Control protocol is to initiate the 336 interconnection across CDNs, bootstrap the other CDNI interfaces and 337 trigger actions into the Downstream CDN by the Upstream CDN (such as 338 delete object from caches or trigger pre-positioned content 339 acquisition). We observe that while the CDNI Control protocol is 340 currently discussed as a single "protocol", further analysis will 341 determine whether the corresponding requirements are to be realized 342 over a single interface and protocol, or over multiple interfaces and 343 protocols. 345 4.1. Within Initial CDNI Scope 347 R15 The CDNI Control protocol Must allow the Upstream CDN to request 348 that the Downstream CDN (and, if cascaded CDNs are supported by 349 the solution, that the potential cascaded Downstream CDNs) 350 perform the following actions on an object or object set: 352 * Mark an object(s) and/or its CDNI metadata as "stale" and 353 revalidate them before they are delivered again 355 * Delete an object(s) and/or its CDNI metadata from the CDN 356 surrogates and any storage. 358 R16 The CDNI Control protocol Must allow the downstream CDN to 359 report on the completion of these actions (by itself, and if 360 cascaded CDNs are supported by the solution, by potential 361 cascaded Downstream CDNs), in a manner appropriate for the 362 action (e.g. synchronously or asynchronously). 364 R17 The CDNI Control protocol Must support initiation and control by 365 the Upstream CDN of pre-positioned CDNI metadata acquisition by 366 the Downstream CDN. 368 R18 The CDNI Control protocol Should support initiation and control 369 by the Upstream CDN of pre-positioned content acquisition by the 370 Downstream CDN.[Editor's Note: how much influence the Upstream 371 CDN ought to have on pre-positioning of the content on 372 surrogates inside the Downstream CDN is TBD]. 374 4.2. Beyond Initial CDNI Scope 376 R19 The CDNI Control protocol Must support support initiation and 377 control by the Upstream CDN of pre-positioned content 378 acquisition.[Editor's Note: how much influence the Upstream CDN 379 ought to have on pre-positioning of the content on surrogates 380 inside the Downstream CDN is TBD]. [Note: this "Must" 381 requirement appeared as a "Should" requirement in Section 4.1] 383 R20 The CDNI Control protocol Must allow a CDN to establish, update 384 and terminate a CDN interconnection with another CDN whereby one 385 CDN can act as a Downstream CDN for the other CDN (that acts as 386 an Upstream CDN). 388 R21 The CDNI Control protocol Must allow control of the CDNI 389 interconnection between any two CDNs independently for each 390 direction (i.e. For the direction where CDN1 is the Upstream 391 CDN and CDN2 is the Downstream CDN, and for the direction where 392 CDN2 is the Upstream CDN and CDN1 is the Downstream CDN). 394 R22 The CDNI Control protocol Should allow bootstrapping of the 395 Request-Routing protocol. For example, this can potentially 396 include: 398 * negotiation of the Request-Routing method (e.g. DNS vs 399 HTTP, if more than one method is specified) 401 * discovery of the Request-Routing protocol endpoints 403 * information necessary to establish secure communication 404 between the Request-Routing protocol endpoints. 406 R23 The CDNI Control protocol Should allow bootstrapping of the 407 Metadata Signaling protocol. This information could, for 408 example, include: 410 * discovery of the Metadata Signaling protocol endpoints 412 * information necessary to establish secure communication 413 between the Metadata Signaling protocol endpoints. 415 R24 The CDNI Control protocol Should allow bootstrapping of the 416 Content Acquisition protocol. This could, for example, include 417 exchange and negotiation of the Content Acquisition protocols to 418 be used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2). 420 R25 The CDNI Control protocol Should allow exchange and negotiation 421 of delivery authorization mechanisms to be supported across the 422 CDNs (e.g. URI signature based validation). 424 R26 The CDNI Control protocol Should allow bootstrapping of the CDNI 425 Logging protocol. This information could, for example, include: 427 * discovery of the Logging protocol endpoints 429 * information necessary to establish secure communication 430 between the Logging protocol endpoints 432 * negotiation/definition of the log file format and set of 433 fields to be exported through the Logging protocol, with 434 some granularity (e.g. On a per content type basis). 436 * negotiation/definition of parameters related to transaction 437 Logs export (e.g., export protocol, file compression, export 438 frequency, directory). 440 5. CDNI Request Routing Protocol Requirements 442 5.1. Within Initial CDNI Scope 444 The main function of the Request Routing protocol is to allow the 445 Request-Routing systems in interconnected CDNs to communicate to 446 facilitate redirection of the request across CDNs. 448 R27 The CDNI Control protocol Must allow the Downstream CDN to 449 communicate to the Upstream CDN coarse information about the 450 Downstream CDN ability and/or willingness to handle requests 451 from the Upstream CDN. For example, this could potentially 452 include a binary signal ("Downstream CDN ready/not-ready to take 453 additional requests from Upstream CDN") to be used in case of 454 excessive load or failure condition in the Downstream CDN. 456 R28 The CDNI Request-Routing protocol Should allow the Downstream 457 CDN to communicate to the Upstream CDN aggregate information to 458 facilitate CDN selection during request routing, such as 459 Downstream CDN capabilities, resources and affinities (i.e. 460 Preferences or cost). This information could, for example, 461 include: 463 * supported content types and delivery protocols 465 * footprint (e.g. layer-3 coverage) 467 * a set of metrics/attributes (e.g. Streaming bandwidth, 468 storage resources, distribution and delivery priority) 470 * a set of affinities (e.g. Preferences, indication of 471 distribution/delivery fees) 473 * information to facilitate request redirection (e.g. 474 Reachability information of Downstream CDN Request Routing 475 system). 477 [Note: Some of this information - such as supported content 478 types and delivery protocols- may also potentially be taken into 479 account by the distribution system in the Upstream CDN for pre- 480 positioning of content and/or metadata in the Downstream CDN in 481 case of pre-positioned content acquisition and/or pre-positioned 482 CDNI metadata acquisition.] 484 R29 If cascaded redirection is supported by the CDNI solution, the 485 CDNI Request-Routing protocol Must allow the Downstream CDN to 486 also include in the information communicated to the Upstream 487 CDN, information on the capabilities, resources and affinities 488 of CDNs to which the Downstream CDN may (in turn) redirect 489 requests received by the Upstream CDN. In that case, the CDNI 490 Request-Routing protocol Must prevent looping of such 491 information exchange. 493 R30 The CDNI Control protocol May allow the Downstream CDN to 494 communicate to the Upstream CDN aggregate information on CDNI 495 administrative limits and policy. This information can be taken 496 into account by the Upstream CDN Request Routing system in its 497 CDN Selection decisions. This information could, for example, 498 include: 500 * maximum number of requests redirected by the Upstream CDN to 501 be served simultaneously by the Downstream CDN 503 * maximum aggregate volume of content (e.g. in Terabytes) to 504 be delivered by the Downstream CDN over a time period. 506 R31 The CDNI Request-Routing architecture and protocol Must support 507 efficient request-routing for small objects. This may, for 508 example, call for a mode of operation (e.g. DNS-based request 509 routing) where freshness and accuracy of CDN/Surrogate selection 510 can be traded-off against reduced request-routing load (e.g. 511 Via lighter-weight queries and caching of request-routing 512 decisions). 514 R32 The CDNI Request-Routing architecture and protocol Must support 515 efficient request-routing for large objects. This may, for 516 example, call for a mode of operation (e.g. HTTP-based request 517 routing) where freshness and accuracy of CDN/Surrogate selection 518 justifies a per-request decision and a per-request CDNI Request- 519 Routing protocol call. 521 R33 The CDNI Request-Routing architecture Must support recursive 522 CDNI request routing. 524 R34 The CDNI Request-Routing architecture Must support iterative 525 CDNI request routing. 527 R35 In case of detection of a request redirection loop, the CDNI 528 Request-Routing loop prevention mechanism Should allow routing 529 of the request (as opposed to the request loop being simply 530 interrupted without routing the request). 532 R36 The CDNI Request-Routing protocol Should support an optional 533 mechanism allowing enforcment of a limit on the number of 534 successive CDN redirections for a given request. 536 R37 The CDNI Request-Routing protocol May support an optional 537 mechanism allowing an upstream CDN to avoid redirecting a 538 request to a downstream CDN if that is likely to result in the 539 total redirection time exceeding some limit. 541 R38 The CDNI Request-Routing protocol Must allow the Upstream CDN to 542 include, in the query to the Downstream CDN, the necessary 543 information to allow the Downstream CDN to process the 544 redirection query. This could, for example, include: 546 * information from which the location of the user-agent that 547 originated the request can be inferred (e.g. User Agent 548 fully qualified domain name in case of HTTP-based Request 549 Routing, DNS Proxy fully qualified domain name in case of 550 DNS-based Request Routing) 552 * requested resource information (e.g. Resource URI in case 553 of HTTP-based Request Routing, Resource hostname in case of 554 DNS-based Request Routing) 556 * additional available request information (e.g. request 557 headers in case of HTTP-based Request Routing). 559 R39 The CDNI Request-Routing protocol May also allow the Upstream 560 CDN to convey information pointing to CDNI metadata applicable 561 (individually or through inheritance) to the requested content. 562 For illustration, the CDNI metadata pointed to could potentially 563 include metadata that is applicable to any content, metadata 564 that is applicable to a content collection (to which the 565 requested content belongs) and/or metadata that is applicable 566 individually to the requested content. 568 R40 The CDNI Request-Routing protocol Must allow the Downstream CDN 569 to include the following information in the response to the 570 Upstream CDN: 572 * status code, in particular indicating acceptance or 573 rejection of request (e.g. Because the Downstream CDN is 574 unwilling or unable to serve the request). In case of 575 rejection, an error code is also to be provided, which 576 allows the Upstream CDN to react appropriately (e.g. Select 577 another Downstream CDN, or serve the request itself) 579 * redirection information (e.g. Resource URI in case of HTTP- 580 based Request Routing, equivalent of a DNS record in case of 581 DNS-based Request Routing). 583 5.2. Beyond Initial CDNI Scope 585 R41 The CDNI Request-Routing protocol Must allow the Downstream CDN 586 to communicate to the Upstream CDN aggregate information to 587 facilitate CDN selection during request routing, such as 588 Downstream CDN capabilities, resources and affinities (i.e. 589 Preferences or cost). This information could, for example, 590 include: 592 * supported content types and delivery protocols 594 * footprint (e.g. layer-3 coverage) 596 * a set of metrics/attributes (e.g. Streaming bandwidth, 597 storage resources, distribution and delivery priority) 599 * a set of affinities (e.g. Preferences, indication of 600 distribution/delivery fees) 602 * information to facilitate request redirection (e.g. 603 Reachability information of Downstream CDN Request Routing 604 system). 606 [Note: this "Must" requirement appeared as a "Should" 607 requirement in Section 5.1] 609 R42 The CDNI Request-Routing protocol Must allow the Downstream CDN 610 to also include in the information communicated to the Upstream 611 CDN, information on the capabilities, resources and affinities 612 of CDNs to which the Downstream CDN may (in turn) redirect 613 requests received by the Upstream CDN. The CDNI Control 614 protocol Must prevent looping of such information exchange. 615 [Note: this "Must" requirement appeared as a conditional "Must" 616 requirement in Section 5.1] 618 R43 The CDNI Request-Routing protocol Should allow the Downstream 619 CDN to communicate to the Upstream CDN aggregate information on 620 CDNI administrative limits and policy. This information can be 621 taken into account by the Upstream CDN Request Routing system in 622 its CDN Selection decisions. This information could, for 623 example, include: 625 * maximum number of requests redirected by the Upstream CDN 626 that to be served simultaneously by the Downstream CDN 628 * maximum aggregate volume of content (e.g. in Terabytes) to 629 be delivered by the Downstream CDN over a time period 631 [Note: this "Should" requirement appeared as a "May" requirement 632 in Section 5.1] 634 R44 The CDNI Request-Routing loop prevention mechanism Must allow 635 routing of the request (as opposed to the request loop being 636 simply interrupted without routing the request). [Note: this 637 "Must" requirement appeared as a "Should" requirement in 638 Section 5.1] 640 R45 The CDNI Request-Routing protocol Must support optional 641 enforcement of a limit on the number of successive CDN 642 redirections for a given request. [Note: this "Must" 643 requirement appeared as a "Should" requirement in Section 5.1] 645 6. CDNI Metadata Distribution Protocol Requirements 647 The primary function of the CDNI Metadata Distribution protocol is to 648 allow the Distribution system in interconnected CDNs to communicate 649 to ensure Content Distribution Metadata with inter-CDN scope can be 650 exchanged across CDNs. We observe that while the CDNI Metadata 651 Distribution protocol is currently discussed as a single "protocol", 652 further analysis will determine whether the corresponding 653 requirements are to be realized over a single interface and protocol, 654 or over multiple interfaces and protocols. For example, a subset of 655 the CDNI metadata might be conveyed in-band along with the actual 656 content acquisition across CDNs (e.g. content MD5 in HTTP header) 657 while another subset might require an out-of-band interface & 658 protocol (e.g. geo-blocking information). 660 6.1. Within Initial CDNI Scope 662 R46 The CDNI Metadata Distribution protocol Must allow the Upstream 663 CDN to provide the Downstream CDN with content distribution 664 metadata of inter-CDN scope. 666 R47 The CDNI Metadata Distribution protocol Must support exchange of 667 CDNI metadata for both the dynamic content acquisition model and 668 the pre-positioning content acquisition model. 670 R48 The CDNI Metadata Distribution protocol Must/Should/May? support 671 a mode where no, or a subset of, the Metadata is initially 672 communicated to the Downstream CDN along with information about 673 how/where to acquire the rest of the CDNI Metadata (i.e. 674 Dynamic CDNI metadata acquisition). 676 R49 The CDNI Metadata Distribution protocol Must/Should/May? support 677 a mode where all the relevant Metadata is initially communicated 678 to the Downstream CDN (i.e. Pre-positioned CDNI metadata 679 acquisition). 681 R50 Whether in the pre-positioned content acquisition model or in 682 the dynamic content acquisition model, the CDNI Metadata 683 Distribution protocol Must provide the necessary information to 684 allow the Downstream CDN to acquire the content from an upstream 685 source (e.g. Acquisition protocol and Uniform Resource 686 Identifier in Upstream CDN- or rules to construct this URI). 688 R51 The CDNI metadata Must allow signaling of one or more upstream 689 sources, where each upstream source can be in the Upstream CDN, 690 in another CDN, the CSP origin server or any arbitrary source 691 designated by the Upstream CDN. Note that some upstream sources 692 (e.g. the content origin server) may or may not be willing to 693 serve the content to the Downstream CDN, if this policy is known 694 to the upstream CDN then it may omit those sources when 695 exchanging CDNI metadata. 697 R52 The CDNI Metadata Distribution protocol Must allow the Upstream 698 CDN to request addition and modification of CDNI Metadata into 699 the Downstream CDN. 701 R53 The CDNI Metadata Distribution protocol Must allow removal of 702 obsolete CDNI Metadata from the Downstream CDN (this could, for 703 example, be achieved via an explicit removal request from the 704 Upstream CDN or via expiration of a Time-To-Live associated to 705 the Metadata). 707 R54 The CDNI Metadata Distribution protocol Must allow association 708 of CDNI Metadata at the granularity of individual object. This 709 is necessary to achieve fine-grain Metadata distribution at the 710 level of an individual object when necessary. 712 R55 The CDNI Metadata Distribution protocol Must allow association 713 of CDNI Metadata at the granularity of an object set. This is 714 necessary to achieve scalable distribution of metadata when a 715 large number of objects share the same distribution policy. 717 R56 The CDNI Metadata Distribution protocol Must support multiple 718 levels of inheritance with precedence to more specific metadata. 719 For example, the CDNI Metadata Distribution protocol may support 720 metadata that is applicable to any content, metadata that is 721 applicable to a content collection and metadata that is 722 applicable to an individual content where content level metadata 723 overrides content collection metadata that overrides metadata 724 for any content. 726 R57 The CDNI Metadata Distribution protocol Must ensure that 727 conflicting metadata with overlapping scope are prevented or 728 deterministically handled. 730 R58 The CDNI Metadata Distribution protocol Must provide indication 731 by the Downstream CDN to the Upstream CDN of whether the CDNI 732 metadata (and corresponding future request redirections) is 733 accepted or rejected. When rejected, the CDNI Metadata 734 Distribution protocol Must allow the Downstream CDN to provide 735 information about the cause of the rejection. 737 R59 The CDNI Metadata Distribution protocol Must allow signaling of 738 content distribution control policies. For example, this could 739 potentially include: 741 * geo-blocking information (i.e. Information defining 742 geographical areas where the content is to be made available 743 or blocked) 745 * availability windows (i.e. Information defining time 746 windows during which the content is to be made available or 747 blocked) 749 * delegation whitelist/blacklist (i.e. Information defining 750 which downstream CDNs the content may/may not be delivered 751 through) 753 R60 The CDNI Metadata Distribution protocol Must allow signaling of 754 authorization checks and validation that are to be performed by 755 the surrogate before delivery. For example, this could 756 potentially include: 758 * need to validate URI signed information (e.g. Expiry time, 759 Client IP address). 761 6.2. Beyond Initial CDNI Scope 763 R61 The CDNI Metadata Distribution protocol Must support a mode 764 where no, or a subset of, the Metadata is initially communicated 765 to the Downstream CDN along with information about how/where to 766 acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI 767 metadata acquisition). [Note: this "Must" requirement appeared 768 as a "Must/Should/May?" requirement in Section 6.1] 770 R62 The CDNI Metadata Distribution protocol Must support a mode 771 where all the relevant Metadata is initially communicated to the 772 Downstream CDN (i.e.Pre-positioned CDNI metadata acquisition). 773 [Note: this "Must" requirement appeared as a "Must/Should/May?" 774 requirement in Section 6.1] 776 R63 The CDNI Metadata Distribution protocol Must allow signaling of 777 CDNI-relevant surrogate cache behavior parameters. For example, 778 this could potentially include: 780 * control of whether the query string of HTTP URI is to be 781 ignored by surrogate cache 783 * content revalidation parameters (e.g. TTL) 785 7. CDNI Logging Protocol Requirements 787 This section identifies the requirements related to the CDNI Logging 788 protocol. We observe that while the CDNI Logging protocol is 789 currently discussed as a single "protocol", further analysis will 790 determine whether the corresponding requirements are to be realized 791 over a single interface and protocol, or over multiple interfaces and 792 protocols. 794 7.1. Within Initial CDNI Scope 796 R64 The CDNI logging architecture and protocol Must ensure reliable 797 logging of CDNI events. 799 R65 The CDNI Logging protocol Must provide logging of deliveries to 800 User Agents performed by the Downstream CDN as a result of 801 request redirection by the Upstream CDN. 803 R66 If cascaded CDNs are supported, the CDNI logging protocol Must 804 allow the Downstream CDN to report to the Upstream CDN logging 805 for deliveries performed by the Downstream CDN itself as well as 806 logging for deliveries performed by cascaded CDNs on behalf of 807 the Downstream CDN. 809 R67 The CDNI Logging protocol Must provide logging of distribution 810 performed by the Upstream CDN as a result of acquisition request 811 by the Downstream CDN. 813 R68 The CDNI Logging protocol Must support batch/offline exchange of 814 logging records. 816 R69 The CDNI Logging protocol Should also support additional timing 817 constraints for some types of logging records (e.g. near-real 818 time for monitoring and analytics applications) 820 R70 The CDNI Logging protocol Must define a log file format and a 821 set of fields to be exported through the Logging protocol, with 822 some granularity (e.g. On a per content type basis). 824 R71 The CDNI Logging protocol Must define a transport mechanisms to 825 exchange CDNI Logging files. 827 [Editor's note: should we add a requirement for support of aggregate/ 828 summarized logs (e.g. total bytes delivered for a content regardless 829 of individual USer Agents to which it was delivered)] 831 7.2. Beyond Initial CDNI Scope 833 R72 The CDNI logging protocol Must allow the Downstream CDN to 834 report to the Upstream CDN logging for deliveries performed by 835 the Downstream CDN itself as well as logging for deliveries 836 performed by cascaded CDNs on behalf of the Downstream CDN. 837 [Note: this "Must" requirement appeared as a conditional "Must" 838 requirement in Section 7.1] 840 R73 The CDNI Logging protocol Must support real-time exchange of 841 some types of logging records (e.g. For real-time monitoring of 842 deliveries across CDNs). [Note: this "Must" requirement 843 appeared as a "Should" requirement in Section 7.1] 845 R74 The CDNI Logging protocol Must allow a CDN to query another CDN 846 for relevant current logging records (e.g. For on-demand access 847 to real-time logging information). 849 8. CDNI Security Requirements 851 This section identifies the requirements related to the CDNI 852 security. Some of those are expected to affect multiple or all 853 protocols. 855 8.1. Within Initial CDNI Scope 857 R75 All the CDNI protocols Must support secure operation over 858 unsecured IP connectivity (e.g. The Internet). This includes 859 authentication, confidentiality, integrity protection as well as 860 protection against spoofing and replay. 862 R76 The CDNI solution Must provide sufficient protection against 863 Denial of Service attacks. This includes protection against 864 spoofed delivery requests sent by user agents directly to a 865 Downstream CDN attempting to appear as if they had been 866 redirected by a given Upstream CDN when they have not. 868 R77 The CDNI solution Should be able to ensure that for any given 869 request redirected to a Downstream CDN, the chain of CDN 870 Delegation (leading to that request being served by that CDN) 871 can be established with non-repudiation. 873 R78 The CDNI solution Should be able to ensure that the Downstream 874 CDN cannot spoof a transaction log attempting to appear as if it 875 corresponds to a request redirected by a given Upstream CDN when 876 that request has not been redirected by this Upstream CDN. This 877 ensures non-repudiation by the Upstream CDN of transaction logs 878 generated by the Downstream CDN for deliveries performed by the 879 Downstream CDN on behalf of the Upstream CDN. 881 R79 The CDNI solution May provide a mechanism allowing an Upstream 882 CDN that has credentials to acquire content from the CSP origin 883 server (or another CDN), to allow establishment of credentials 884 authorizing the Downstream CDN to acquire the content from the 885 CSP origin server (or the other CDN) (e.g. In case the content 886 cannot be acquired from the Upstream CDN). 888 8.2. Beyond Initial CDNI Scope 890 R80 The CDNI solution Must provide a mechanism allowing an Upstream 891 CDN that has credentials to acquire content from the CSP origin 892 server (or another CDN), to allow establishment of credentials 893 authorizing the Downstream CDN to acquire the content from the 894 CSP origin server (or the other CDN) (e.g. In case the content 895 cannot be acquired from the Upstream CDN). [Note: this "Must" 896 requirement appeared as a "May" requirement in Section 8.1] 898 9. IANA Considerations 900 This document makes no request of IANA. 902 Note to RFC Editor: this section may be removed on publication as an 903 RFC. 905 10. Security Considerations 907 This document discusses CDNI security requirements in Section 8. 909 11. Acknowledgements 911 This document leverages the earlier work of the IETF CDI working 912 group in particular as documented in [I-D.cain-request-routing-req], 913 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 915 The authors would like to thank Gilles Bertrand, Christophe Caillet, 916 Bruce Davie, Phil Eardly, Agustin Schapira and Emile Stephan for 917 their input. We also want to thank Ben Niven-Jenkins for his review 918 and comments. 920 12. References 922 12.1. Normative References 924 [I-D.bertrand-cdni-use-cases] 925 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., 926 Eardley, P., and K. Ma, "Use Cases for Content Delivery 927 Network Interconnection", draft-bertrand-cdni-use-cases-02 928 (work in progress), July 2011. 930 [I-D.davie-cdni-framework] 931 Davie, B. and L. Peterson, "Framework for CDN 932 Interconnection", draft-davie-cdni-framework-00 (work in 933 progress), July 2011. 935 [I-D.jenkins-cdni-problem-statement] 936 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 937 Distribution Network Interconnection (CDNI) Problem 938 Statement", draft-jenkins-cdni-problem-statement-02 (work 939 in progress), March 2011. 941 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 942 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 943 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 945 12.2. Informative References 947 [I-D.amini-cdi-distribution-reqs] 948 Amini, L., "Distribution Requirements for Content 949 Internetworking", draft-amini-cdi-distribution-reqs-02 950 (work in progress), November 2001. 952 [I-D.cain-request-routing-req] 953 Cain, B., "Request Routing Requirements for Content 954 Internetworking", draft-cain-request-routing-req-03 (work 955 in progress), November 2001. 957 [I-D.gilletti-cdnp-aaa-reqs] 958 "CDI AAA Requirements, 959 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 961 Authors' Addresses 963 Kent Leung 964 Cisco Systems 965 3625 Cisco Way 966 San Jose 95134 967 USA 969 Phone: +1 408 526 5030 970 Email: kleung@cisco.com 972 Yiu Lee 973 Comcast 975 Email: yiu_lee@cable.comcast.com 977 Francois Le Faucheur 978 Cisco Systems 979 Greenside, 400 Avenue de Roumanille 980 Sophia Antipolis 06410 981 France 983 Phone: +33 4 97 23 26 19 984 Email: flefauch@cisco.com 986 Mahesh Viveganandhan 987 Cisco Systems 988 375 East Tasman Drive 989 San Jose 95134 990 USA 992 Email: mvittal@cisco.com 993 Grant Watson 994 BT 996 Email: grant.watson@bt.com