idnits 2.17.1 draft-ietf-cdni-requirements-13.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 (Nov 26, 2013) is 3776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-06 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: May 30, 2014 Comcast 6 Nov 26, 2013 8 Content Distribution Network Interconnection (CDNI) Requirements 9 draft-ietf-cdni-requirements-13 11 Abstract 13 Content Delivery Networks (CDNs) are frequently used for content 14 delivery. As a result of significant growth in content delivered 15 over IP networks, existing CDN providers are scaling up their 16 infrastructure. Many Network Service Providers and Enterprise 17 Service Providers are also deploying their own CDNs. To deliver 18 contents from the Content Service Provider (CSP) to end users, the 19 contents may traverse across multiple CDNs. This creates a need for 20 interconnecting (previously) standalone CDNs so that they can 21 collectively act as a single delivery platform from the CSP to the 22 end users. 24 The goal of the present document is to outline the requirements for 25 the solution and interfaces to be specified by the CDNI working 26 group. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 30, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 65 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 7 66 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 8 67 5. CDNI Request Routing Redirection Interface Requirements . . . 11 68 6. CDNI Footprint & Capabilities Advertisement Interface 69 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15 71 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 19 72 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 79 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 82 1. Introduction 84 The volume of video and multimedia content delivered over the 85 Internet is rapidly increasing and expected to continue doing so in 86 the future. In the face of this growth, Content Delivery Networks 87 (CDNs) provide numerous benefits: reduced delivery cost for cacheable 88 content, improved quality of experience for end users, and increased 89 robustness of delivery. For these reasons CDNs are frequently used 90 for large-scale content delivery. As a result of the significant 91 growth in content delivered over IP networks, existing CDN providers 92 are scaling up their infrastructure and many Network Service 93 Providers and Enterprise Service Providers are deploying their own 94 CDNs. Subject to the policy of the Content Service Provider (CSP), 95 it is generally desirable that a given item of content can be 96 delivered to an end user regardless of that end user's location or 97 attachment network. This creates a need for interconnecting 98 (previously) standalone CDNs so they can interoperate and 99 collectively behave as a single delivery infrastructure. The Content 100 Distribution Network Interconnection (CDNI) working group has been 101 chartered to develop an interoperable and scalable solution for such 102 CDN interconnections. 104 CDNI Problem Statement [RFC6707] outlines the problem area that the 105 CDNI working group is chartered to address. Use Cases for CDNI 106 [RFC6770] discusses the use cases for CDN Interconnection. Framework 107 for CDN Interconnection [I-D.ietf-cdni-framework] discusses the 108 technology framework for the CDNI solution and interfaces. 110 The goal of the present document is to document the requirements for 111 the CDNI solution and interfaces. In order to meet the timelines 112 defined in the working group charter, the present document 113 categorizes the CDNI requirements as "High Priority", "Medium 114 Priority", and "Low Priority". 116 1.1. Terminology 118 This document uses the terminology defined in [RFC6707] as well as in 119 section 1.1 of Framework for CDN Interconnection 120 [I-D.ietf-cdni-framework]. In addition, the key words "High 121 Priority", "Medium Priority" and "Low Priority" in this document are 122 to be interpreted in the following way: 124 o "High Priority" indicates requirements that are to be supported by 125 the CDNI interfaces. A requirement is stated as "High Priority" 126 when it is established by the working group that it can be met to 127 achieve the goal of a deployable solution in a short timeframe as 128 needed by the industry. This is tagged as "{HIGH}". 130 o "Medium Priority" indicates requirements that are to be supported 131 by the CDNI interfaces unless the WG realizes at a later stage 132 that attempting to meet this requirement does not achieve the goal 133 of a deployable solution in a short timeframe as needed by the 134 industry. This is tagged as "{MED}". 136 o "Low Priority" indicates requirements that are to be supported by 137 the CDNI interfaces provided that dedicating WG resources to this 138 work does not prevent addressing "High Priority" and "Medium 139 Priority" requirements and that attempting to meet this 140 requirement is not an obstacle to achieving the goal of a 141 deployable solution in a short timeframe as needed by the 142 industry. This is tagged as "{LOW}". 144 2. CDNI Model and CDNI Interfaces 146 For convenience, the "CDNI Expanded Model and CDNI Interfaces" figure 147 and brief descriptions of the CDNI interfaces in 148 [I-D.ietf-cdni-framework] are replicated below. 150 o CDNI Control interface (CI): Operations to bootstrap and 151 parameterize the other CDNI interfaces, as well as operations to 152 pre-position, revalidate, and purge both metadata and content. 153 The latter subset of operations is sometimes collectively called 154 the "trigger interface." 156 o CDNI Request Routing interface: Operations to determine what CDN 157 (and optionally what surrogate within a CDN) is to serve end- 158 user's requests. This interface is actually a logical bundling of 159 two separate but related interfaces: 161 * CDNI Footprint & Capabilities Advertisement interface (FCI): 162 Asynchronous operations to exchange routing information (e.g., 163 the network footprint and capabilities served by a given CDN) 164 that enables CDN selection for subsequent user requests; and 166 * CDNI Request Routing Redirection interface (RI): Synchronous 167 operations to select a delivery CDN (surrogate) for a given 168 user request. 170 o CDNI Metadata interface (MI): Operations to communicate metadata 171 that governs how the content is delivered by interconnected CDNs. 172 Examples of CDNI metadata include geo-blocking directives, 173 availability windows, access control mechanisms, and purge 174 directives. May include a combination of: 176 * Asynchronous operations to exchange metadata that govern 177 subsequent user requests for content; and 179 * Synchronous operations that govern behavior for a given user 180 request for content. 182 o CDNI Logging interface (LI): Operations that allow interconnected 183 CDNs to exchange relevant activity logs. May include a 184 combination of: 186 * Real-time exchanges, suitable for runtime traffic monitoring; 187 and 189 * Offline exchanges, suitable for analytics and billing. 191 -------- 192 / \ 193 | CSP | 194 \ / 195 -------- 196 * 197 * 198 * /\ 199 * / \ 200 ---------------------- |CDNI| ---------------------- 201 / Upstream CDN \ | | / Downstream CDN \ 202 | +-------------+ | | CI | | +-------------+ | 203 |******* Control |<======|====|=======>| Control *******| 204 |* +------*----*-+ | | | | +-*----*------+ *| 205 |* * * | | | | * * *| 206 |* +------*------+ | | LI | | +------*------+ *| 207 |* ***** Logging |<======|====|=======>| Logging ***** *| 208 |* * +-*-----------+ | | | | +-----------*-+ * *| 209 |* * * * | | | | * * * *| 210 .....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*... 211 . |* * | |<======|====|=======>| | * *| . 212 . |* * | Req-Routing | | |FCI | | | Req-Routing | * *| . 213 . |* * *** |<======|====|=======>| |** * *| . 214 . |* * * +-------------+.| | | | +-------------+ * * *| . 215 . |* * * . | | | * * *| . 216 . |* * * +-------------+ |. | MI | | +-------------+ * * *| . 217 . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| . 218 . |* * * | | | . \ / | | | * * *| . 219 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 220 . |* * ***| +---------+| | ...Request......+---------+ |*** * *| . 221 . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| . 222 . |******* +---------+| | Acquisition | |+----------+ *******| . 223 . | +-------------+ | | +-------*-----+ | . 224 . \ / \ * / . 225 . ---------------------- ---------*------------ . 226 . * . 227 . * Delivery . 228 . * . 229 . +--*---+ . 230 ...............Request............................| User |..Request.. 231 | Agent| 232 +------+ 234 <==> interfaces inside the scope of CDNI 236 **** and .... interfaces outside the scope of CDNI 238 Figure 1: CDNI Expanded Model and CDNI Interfaces 240 3. Generic CDNI Requirements 242 This section identifies generic requirements independent of the 243 individual CDNI interfaces. Some of those are expected to affect 244 multiple or all interfaces. Management is an important aspect of CDN 245 operation. The fault and performance management is covered in CDNI 246 Logging interface requirements. The other types of management are 247 specific to the CDN provider and not needed for interoperability 248 between CDN providers. 250 GEN-1 {MED} Wherever possible, the CDNI interfaces should reuse or 251 leverage existing IETF protocols. 253 GEN-2 {HIGH} The CDNI solution shall not require a change, or an 254 upgrade, to the User Agent to benefit from content delivery 255 through interconnected CDNs. 257 GEN-3 {HIGH} The CDNI solution shall not require a change, or an 258 upgrade, to the Content Service Provider delivering content 259 through a single CDN, to benefit from content delivery 260 through interconnected CDNs. 262 GEN-4 {HIGH} The CDNI solution shall not depend on intra-CDN 263 information to be exposed to other CDNs for effective and 264 efficient delivery of the content. Examples of intra-CDN 265 information include surrogate topology, surrogate status, 266 cached content, etc. 268 GEN-5 {HIGH} The CDNI solution shall support delivery to the user 269 agent based on HTTP [RFC2616]. (Note that while delivery and 270 acquisition "data plane" protocols are out of the CDNI 271 solution scope, the CDNI solution "control plane" protocols 272 are expected to participate in enabling, selecting or 273 facilitating operations of such acquisition and delivery 274 protocols. Hence it is useful to state requirements on the 275 CDNI solution in terms of which acquisition and delivery 276 protocols). 278 GEN-6 {HIGH} The CDNI solution shall support acquisition across 279 CDNs based on HTTP [RFC2616]. (The note above applies to 280 this requirement too) 282 GEN-7 {LOW} The CDNI solution may support delivery to the user 283 agent based on protocols other than HTTP. 285 GEN-8 {LOW} The CDNI solution may support acquisition across CDNs 286 based on protocols other than HTTP. 288 GEN-9 {MED} The CDNI solution should support cascaded CDN 289 redirection (CDN1 redirects to CDN2 that redirects to CDN3) 290 to an arbitrary number of levels beyond the first level. 292 GEN-10 {MED} The CDNI solution should support an arbitrary topology 293 of interconnected CDNs (i.e. the topology of interconnected 294 CDNs cannot be restricted to a tree, ring, star, etc.). 296 GEN-11 {HIGH} The CDNI solution shall prevent looping of any CDNI 297 information exchange. 299 GEN-12 {HIGH} When making use of third party reference, the CDNI 300 solution shall consider the potential issues associated with 301 the use of various format of third-party references (e.g. 302 NAT or IPv4/IPv6 translation potentially breaking third-party 303 references based on an IP addresses such as URI containing 304 IPv4 or IPv6 address litterals, split DNS situations 305 potentially breaking third-party references based on DNS 306 fully qualified domain names) and wherever possible avoid, 307 minimize or mitigate the associated risks based on the 308 specifics of the environments where the reference is used 309 (e.g. likely or unlikely presence of NAT in the path). In 310 particular, this applies to situations where the CDNI 311 solution needs to construct and convey uniform resource 312 identifiers for directing/redirecting a content request, as 313 well as to situations where the CDNI solution needs to pass 314 on a third party reference (e.g. to identify a User Agent) in 315 order to allow another entity to make a more informed 316 decision (e.g. make a more informed request routing decision 317 by attempting to derive location information from the third 318 party reference). 320 GEN-13 {HIGH} The CDNI solution shall support HTTP Adaptive 321 Streaming content. 323 4. CDNI Control Interface Requirements 325 The primary purpose of the CDNI Control interface (CI) is to initiate 326 the interconnection across CDNs, bootstrap the other CDNI interfaces 327 and trigger actions into the Downstream CDN by the Upstream CDN (such 328 as delete object from caches or trigger pre-positioned content 329 acquisition). The working group attempts to align requirements with 330 the appropriate interface; however, solutions to these requirements 331 may apply to a different interface or another interface in addition 332 to the interface it is associated with. 334 CI-1 {HIGH} The CDNI Control interface shall allow the Upstream CDN 335 to request that the Downstream CDN, including downstream 336 cascaded CDNs, delete an object or set of objects and/or its 337 CDNI metadata from the CDN surrogates and any storage. Only 338 the object(s) and CDNI metadata that pertain to the requesting 339 Upstream CDN are allowed to be purged. 341 CI-2 {MED} The CDNI Control interface should allow for multiple 342 content items identified by a Content Collection ID to be 343 purged using a single Content Purge action. 345 CI-3 {MED} The CDNI Control interface should allow the Upstream CDN 346 to request that the Downstream CDN, including downstream 347 cascaded CDNs, mark an object or set of objects and/or its 348 CDNI metadata as "stale" and revalidate them before they are 349 delivered again. 351 CI-4 {HIGH} The CDNI Control interface shall allow the Downstream 352 CDN to report on the completion of these actions (by itself, 353 and including downstream cascaded CDNs), in a manner 354 appropriate for the action (e.g. synchronously or 355 asynchronously). The confirmation receipt should include a 356 success or failure indication. The failure indication and the 357 reason are included if the Downstream CDN cannot delete the 358 content in its storage. 360 CI-5 {MED} The CDNI Control interface should support initiation and 361 control by the Upstream CDN of pre-positioned CDNI metadata 362 acquisition by the Downstream CDN. 364 CI-6 {MED} The CDNI Control interface should support initiation and 365 control by the Upstream CDN of pre-positioned content 366 acquisition by the Downstream CDN. 368 CI-7 {LOW} The CDNI Control interface may allow a CDN to establish, 369 update and terminate a CDN interconnection with another CDN 370 whereby one CDN can act as a Downstream CDN for the other CDN 371 (that acts as an Upstream CDN). 373 CI-8 {LOW} The CDNI Control interface may allow control of the CDNI 374 interfaces between any two CDNs independently for each 375 direction (e.g. For the direction where CDN1 is the Upstream 376 CDN and CDN2 is the Downstream CDN, and for the direction 377 where CDN2 is the Upstream CDN and CDN1 is the Downstream 378 CDN). 380 CI-9 {LOW} The CDNI Control interface may allow bootstrapping of 381 the Request-Routing interface. For example, this can 382 potentially include: 384 * negotiation of the Request-Routing method (e.g. DNS vs 385 HTTP, if more than one method is specified) 387 * discovery of the Request-Routing protocol endpoints 389 * information necessary to establish secure communication 390 between the Request-Routing protocol endpoints. 392 CI-10 {LOW} The CDNI Control interface may allow bootstrapping of 393 the CDNI Metadata interface. This information could, for 394 example, include: 396 * discovery of the CDNI Metadata signaling protocol 397 endpoints 399 * information necessary to establish secure communication 400 between the CDNI Metadata signaling protocol endpoints. 402 CI-11 {LOW} The CDNI Control interface may allow bootstrapping of 403 the Content Acquisition interface. This could, for example, 404 include exchange and negotiation of the Content Acquisition 405 methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, 406 ATIS C2[ATIS-0800042]). 408 CI-12 {LOW} The CDNI Control interface may allow bootstrapping of 409 the CDNI Logging interface. This information could, for 410 example, include: 412 * discovery of the Logging protocol endpoints 414 * information necessary to establish secure communication 415 between the Logging protocol endpoints 417 * negotiation/definition of the log file format and set of 418 fields to be exported through the Logging protocol, with 419 some granularity (e.g. On a per content type basis). 421 * negotiation/definition of parameters related to 422 transaction Logs export (e.g., export protocol, file 423 compression, export frequency, directory). 425 5. CDNI Request Routing Redirection Interface Requirements 427 The main function of the CDNI Request Routing Redirection interface 428 (RI) is to allow the Request-Routing systems in interconnected CDNs 429 to communicate to facilitate redirection of the request across CDNs. 431 RI-1 {HIGH} The CDNI Request Routing Redirection interface shall 432 support efficient request-routing for small objects. This 433 may, for example, call for a mode of operation (e.g. DNS- 434 based request routing) where freshness and accuracy of CDN/ 435 Surrogate selection can be traded-off against reduced request- 436 routing load (e.g. Via lighter-weight queries and caching of 437 request-routing decisions). 439 RI-2 {HIGH} The CDNI Request Routing Redirection interface shall 440 support efficient request-routing for large objects. This 441 may, for example, call for a mode of operation (e.g. HTTP- 442 based request routing) where freshness and accuracy of CDN/ 443 Surrogate selection justifies a per-request decision and a 444 per-request CDNI Request-Routing protocol call. 446 RI-3 {HIGH} The CDNI Request Routing Redirection interface shall 447 support recursive CDNI request routing. 449 RI-4 {HIGH} The CDNI Request Routing Redirection interface shall 450 support iterative CDNI request routing. 452 RI-5 {MED} In case of detection of a request redirection loop, the 453 CDNI Request Routing Redirection Interface's loop prevention 454 mechanism should allow redirection of the request on an 455 alternate CDN path (as opposed to the request not being 456 redirected at all). 458 RI-6 {MED} The CDNI Request Routing Redirection interface should 459 support a mechanism allowing enforcement of a limit on the 460 number of successive CDN redirections for a given request. 462 RI-7 {LOW} The CDNI Request Routing Redirection interface may 463 support a mechanism allowing an Upstream CDN to avoid 464 redirecting a request to a Downstream CDN if that is likely to 465 result in the total redirection time exceeding some limit. 467 RI-8 {HIGH} The CDNI Request Routing Redirection interface shall 468 allow the Upstream CDN to include, in the query to the 469 Downstream CDN, the necessary information to allow the 470 Downstream CDN to process the redirection query. This could, 471 for example, include: 473 * information from which the location of the user-agent that 474 originated the request can be inferred (e.g. User Agent 475 fully qualified domain name in case of HTTP-based Request 476 Routing, DNS Proxy fully qualified domain name in case of 477 DNS-based Request Routing) 479 * requested resource information (e.g. Resource URI in case 480 of HTTP-based Request Routing, Resource hostname in case 481 of DNS-based Request Routing) 483 * additional available request information (e.g. request 484 headers in case of HTTP-based Request Routing). 486 RI-9 {LOW} The CDNI Request Routing Redirection interface may also 487 allow the Upstream CDN to convey information pointing to CDNI 488 metadata applicable (individually or through inheritance) to 489 the requested content. For illustration, the CDNI metadata 490 pointed to could potentially include metadata that is 491 applicable to any content, metadata that is applicable to a 492 content collection (to which the requested content belongs) 493 and/or metadata that is applicable individually to the 494 requested content. 496 RI-10 {HIGH} The CDNI Request Routing Redirection interface shall 497 allow the Downstream CDN to include the following information 498 in the response to the Upstream CDN: 500 * status code, in particular indicating acceptance or 501 rejection of request (e.g. Because the Downstream CDN is 502 unwilling or unable to serve the request). In case of 503 rejection, an error code is also to be provided, which 504 allows the Upstream CDN to react appropriately (e.g. 505 Select another Downstream CDN, or serve the request 506 itself) 508 * redirection information (e.g. Resource URI in case of 509 HTTP-based Request Routing, equivalent of a DNS record in 510 case of DNS-based Request Routing). 512 RI-11 {HIGH} The CDNI Request Routing Redirection interface shall 513 allow for per-chunk request routing of HTTP Adaptive Streaming 514 content. 516 RI-12 {LOW} The CDNI Request Routing Redirection interface may allow 517 the Upstream CDN to use the information conveyed by the 518 Downstream CDN during the Recursive Request Routing process to 519 rewrite an HTTP Adaptive Streaming manifest file. 521 RI-13 {LOW} The CDNI Request-Routing interface may allow the 522 Upstream CDN to re-sign the invariant portion of the chunk 523 URIs embedded in the HTTP Adaptive Streaming manifest file. 525 RI-14 {MED} The CDNI Request Routing Redirection interface should 526 allow the use of HTTP cookie to associate the chunks with the 527 HTTP Adaptive Stream manifest file (which is verified by the 528 URI signature) based on the Authorization Group ID (which is 529 an identifier used to correlate the manifest file to the 530 related chunks). 532 RI-15 {MED} The CDNI Request Routing Redirection interface should 533 allow for an efficient method of transferring request routing 534 information for multiple chunks from the Downstream CDN to the 535 Upstream CDN as part of the recursive request routing process. 537 6. CDNI Footprint & Capabilities Advertisement Interface Requirements 539 The main function of the CDNI Footprint & Capabilities Advertisement 540 interface (FCI) is to allow the Downstream CDN to advertise the 541 information regarding its footprint and capabilities to the Upstream 542 CDN. 544 FCI-1 {HIGH} The CDNI Footprint & Capabilities Advertisement 545 interface shall allow the Downstream CDN to communicate to the 546 Upstream CDN coarse information about the Downstream CDN 547 ability and/or willingness to handle requests from the 548 Upstream CDN. For example, this could potentially include a 549 binary signal ("Downstream CDN ready/not-ready to take 550 additional requests from Upstream CDN") to be used in case of 551 excessive load or failure condition in the Downstream CDN. 553 FCI-2 {MED} The CDNI Footprint & Capabilities Advertisement 554 interface should allow the Downstream CDN to communicate to 555 the Upstream CDN aggregate information to facilitate CDN 556 selection during request routing, such as Downstream CDN 557 capabilities, resources and affinities (i.e. Preferences or 558 cost). This information could, for example, include: 560 * supported content types and delivery protocols 562 * footprint (e.g. layer-3 coverage) 564 * a set of metrics/attributes (e.g. Streaming bandwidth, 565 storage resources, distribution and delivery priority) 567 * a set of affinities (e.g. Preferences, indication of 568 distribution/delivery fees) 570 * information to facilitate request redirection (e.g. 571 Reachability information of Downstream CDN Request Routing 572 system). 574 [Note: Some of this information - such as supported content 575 types and delivery protocols- may also potentially be taken 576 into account by the distribution system in the Upstream CDN 577 for pre-positioning of content and/or metadata in the 578 Downstream CDN in case of pre-positioned content acquisition 579 and/or pre-positioned CDNI metadata acquisition.] 581 FCI-3 {MED} In the case of cascaded redirection, the CDNI Footprint 582 & Capabilities Advertisement interface should allow the 583 Downstream CDN to also include in the information communicated 584 to the Upstream CDN, information on the capabilities, 585 resources and affinities of CDNs to which the Downstream CDN 586 may (in turn) redirect requests received by the Upstream CDN. 587 In that case, the CDNI Request-Routing interface shall prevent 588 looping of such information exchange. 590 FCI-4 {LOW} The CDNI Footprint & Capabilities Advertisement 591 interface may allow the Downstream CDN to communicate to the 592 Upstream CDN aggregate information on CDNI administrative 593 limits and policy. This information can be taken into account 594 by the Upstream CDN Request Routing system in its CDN 595 Selection decisions. This information could, for example, 596 include: 598 * maximum number of requests redirected by the Upstream CDN 599 to be served simultaneously by the Downstream CDN 601 * maximum aggregate volume of content (e.g. in Terabytes) to 602 be delivered by the Downstream CDN over a time period. 604 FCI-5 {MED} The CDNI Footprint & Capabilities Advertisement 605 interface should support advertisement of the following types 606 of capabilities: 608 * delivery protocol (e.g., HTTP vs. RTMP) 610 * acquisition protocol (for acquiring content from an 611 Upstream CDN) 613 * redirection mode (e.g., DNS Redirection vs. HTTP 614 Redirection) 616 * capabilities related to CDNI Logging (e.g., supported 617 logging mechanisms) 619 * capabilities related to CDNI Metadata (e.g., authorization 620 algorithms or support for proprietary vendor metadata) 622 FCI-6 {LOW} The CDNI Control interface may allow exchange and 623 negotiation of delivery authorization mechanisms to be 624 supported across the CDNs (e.g. URI signature based 625 validation). 627 7. CDNI Metadata Interface Requirements 629 The primary function of the CDNI Metadata interface (MI) is to allow 630 the Distribution system in interconnected CDNs to communicate to 631 ensure Content Distribution Metadata with inter-CDN scope can be 632 exchanged across CDNs. We observe that while the CDNI Metadata 633 Distribution protocol is currently discussed as a single "protocol", 634 further analysis will determine whether the corresponding 635 requirements are to be realized over a single interface and protocol, 636 or over multiple interfaces and protocols. For example, a subset of 637 the CDNI metadata might be conveyed in-band along with the actual 638 content acquisition across CDNs (e.g. content MD5 in HTTP header) 639 while another subset might require an out-of-band interface & 640 protocol (e.g. geo-blocking information). 642 MI-1 {HIGH} The CDNI Metadata interface shall allow the Upstream 643 CDN to provide the Downstream CDN with content distribution 644 metadata of inter-CDN scope. 646 MI-2 {HIGH} The CDNI Metadata interface shall support exchange of 647 CDNI metadata for both the dynamic content acquisition model 648 and the pre-positioning content acquisition model. 650 MI-3 {HIGH} The CDNI Metadata interface shall support a mode where 651 no, or a subset of, the Metadata is initially communicated to 652 the Downstream CDN along with information about how/where to 653 acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI 654 metadata acquisition). 656 MI-4 {MED} The CDNI Metadata interface should support a mode where 657 all the relevant Metadata is initially communicated to the 658 Downstream CDN (i.e. Pre-positioned CDNI metadata 659 acquisition). 661 MI-5 {HIGH} Whether in the pre-positioned content acquisition model 662 or in the dynamic content acquisition model, the CDNI Metadata 663 interface shall provide the necessary information to allow the 664 Downstream CDN to acquire the content from an upstream source 665 (e.g. Acquisition protocol and Uniform Resource Identifier in 666 Upstream CDN- or rules to construct this URI). 668 MI-6 {HIGH} The CDNI metadata shall allow signaling of one or more 669 upstream sources, where each upstream source can be in the 670 Upstream CDN, in another CDN, the CSP origin server or any 671 arbitrary source designated by the Upstream CDN. Note that 672 some upstream sources (e.g. the content origin server) may or 673 may not be willing to serve the content to the Downstream CDN, 674 if this policy is known to the Upstream CDN then it may omit 675 those sources when exchanging CDNI metadata. 677 MI-7 {HIGH} The CDNI Metadata interface (possibly in conjunction 678 with the CDNI Control interface) shall allow the Upstream CDN 679 to request addition and modification of CDNI Metadata into the 680 Downstream CDN. 682 MI-8 {HIGH} The CDNI Metadata interface (possibly in conjunction 683 with the CDNI Control interface) shall allow removal of 684 obsolete CDNI Metadata from the Downstream CDN (this could, 685 for example, be achieved via an explicit removal request from 686 the Upstream CDN or via expiration of a Time-To-Live 687 associated to the Metadata). 689 MI-9 {HIGH} The CDNI Metadata interface shall allow association of 690 CDNI Metadata at the granularity of individual object. This 691 is necessary to achieve fine-grain Metadata distribution at 692 the level of an individual object when necessary. 694 MI-10 {HIGH} The CDNI Metadata interface shall allow association of 695 CDNI Metadata at the granularity of an object set. This is 696 necessary to achieve scalable distribution of metadata when a 697 large number of objects share the same distribution policy. 699 MI-11 {HIGH} The CDNI Metadata interface shall support multiple 700 levels of inheritance with precedence to more specific 701 metadata. For example, the CDNI Metadata Distribution 702 protocol may support metadata that is applicable to any 703 content, metadata that is applicable to a content collection 704 and metadata that is applicable to an individual content where 705 content level metadata overrides content collection metadata 706 that overrides metadata for any content. 708 MI-12 {HIGH} The CDNI Metadata interface shall ensure that 709 conflicting metadata with overlapping scope are prevented or 710 deterministically handled. 712 MI-13 {HIGH} The CDNI Metadata interface shall allow signaling of 713 content distribution control policies. For example, this 714 could potentially include: 716 * geo-blocking information (i.e. Information defining 717 geographical areas where the content is to be made 718 available or blocked) 720 * availability windows (i.e. Information defining time 721 windows during which the content is to be made available 722 or blocked; expiration time may also be included to remove 723 content) 725 * delegation whitelist/blacklist (i.e. Information defining 726 which Downstream CDNs the content may/may not be delivered 727 through) 729 MI-14 {HIGH} The CDNI Metadata interface shall be able to exchange a 730 set of metadata elements with specified semantics (e.g. start 731 of time window, end of time window). 733 MI-15 {HIGH} The CDNI Metadata interface shall allow exchange of 734 opaque metadata element, whose semantic is not defined in CDNI 735 but established by private CDN agreement. 737 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 738 authorization checks and validation that are to be performed 739 by the surrogate before delivery. For example, this could 740 potentially including the need to validate URI signed 741 information (e.g. Expiry time, Client IP address). 743 MI-17 {MED} The CDNI Metadata interface should allow signaling of 744 CDNI-relevant surrogate cache behavior parameters. For 745 example, this could potentially include: 747 * control of whether the query string of HTTP URI is to be 748 ignored by surrogate cache 750 * enforcement of caching directives by Downstream CDN that 751 are different than the ones signalled in the HTTP headers 752 (e.g. "Expires" field) 754 * rate-pacing by Downstream CDN for content delivery (e.g. 755 Progressive Download) 757 MI-18 {HIGH} The CDNI Metadata interface shall provide indication of 758 related content (e.g. HTTP Adaptive Bit Rate chunks) by the 759 Content Collection ID (CCID) metadata. This could be used by 760 the Downstream CDN for operations on the group of content. 761 For example, this could potentially include: 763 * content acquisition for the entire set of files when one 764 piece of content is requested 766 * local file management and storage bundles all the files 767 for the content 769 * purging the entire set of files associated with the 770 content 772 * logging of the delivery of the content for the session 773 when at least one file in the set was delivered 775 MI-19 {MED} The CDNI Metadata interface should support an optional 776 mechanism allowing the Upstream CDN to indicate to the 777 Downstream CDN which CDNI Log fields are to be provided for 778 all content items, for specific sets of content items, or for 779 specific content items delivered using HTTP. A CDNI 780 implementation that does not support this optional CDNI 781 Metadata Distribution interface mechanism shall ignore this 782 log format indication and generate CDNI logging format for 783 HTTP Adaptive Streaming using the default set of CDNI Logging 784 fields. (Note: This function may be part of the CDNI Metadata 785 interface or the CDNI Control interface.) 787 MI-20 {MED} The CDNI Metadata interface should allow the Upstream 788 CDN to signal to the Downstream CDN the Content Collection ID 789 value for all, for specific sets of, or for specific content 790 items delivered using HTTP. Whenever the Downstream CDN is 791 instructed by the Upstream CDN to report the Content 792 Collection ID field in the log records, the Downstream CDN is 793 to use the value provided through the CDNI Metadata interface 794 for the corresponding content. Note the Session ID field 795 along with Content Collection ID may be used for HTTP Adaptive 796 Streaming content. 798 MI-21 {MED} The CDNI Metadata interface should allow the Upstream 799 CDN to signal to the Downstream CDN the Authorization Group ID 800 value for all the related HTTP Adaptive Streaming content 801 (i.e. manifest file and chunks). The authorization result of 802 a content (e.g. manifest file) is transferred over to related 803 content (e.g. chunks). 805 8. CDNI Logging Interface Requirements 807 This section identifies the requirements related to the CDNI Logging 808 interface (LI). We observe that while the CDNI Logging interface is 809 currently discussed as a single "protocol", further analysis will 810 determine whether the corresponding requirements are to be realized 811 over a single interface and protocol, or over multiple interfaces and 812 protocols. 814 LI-1 {HIGH} The CDNI logging architecture and interface shall 815 ensure reliable transfer of CDNI logging information across 816 CDNs. 818 LI-2 {HIGH} The CDNI Logging interface shall provide logging of 819 deliveries and incomplete deliveries to User Agents performed 820 by the Downstream CDN as a result of request redirection by 821 the Upstream CDN. 823 LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface 824 should allow the Downstream CDN to report to the Upstream CDN 825 logging for deliveries and incomplete deliveries performed by 826 the Downstream CDN itself as well as logging for deliveries 827 and incomplete deliveries performed by cascaded CDNs on behalf 828 of the Downstream CDN. 830 LI-4 {HIGH} The CDNI Logging interface shall support batch/offline 831 exchange of logging records. 833 LI-5 {MED} The CDNI Logging interface should also support 834 additional timing constraints for some types of logging 835 records (e.g. near-real time for monitoring and analytics 836 applications) 838 LI-6 {HIGH} The CDNI Logging interface shall define a log file 839 format and a set of fields to be exported for various CDNI 840 logging events. 842 LI-7 {HIGH} The CDNI Logging interface shall define a transport 843 mechanism to exchange CDNI Logging files. 845 LI-8 {MED} The CDNI Logging interface should allow a CDN to query 846 another CDN for relevant current logging records (e.g. For 847 on-demand access to real-time logging information). 849 LI-9 {LOW} The CDNI Logging interface may support aggregate/ 850 summarized logs (e.g. total bytes delivered for a content 851 regardless of individual User Agents to which it was 852 delivered). 854 LI-10 {LOW} The CDNI Logging interface may support logging of 855 performance data for deliveries to User Agents performed by 856 the Downstream CDN as a result of request redirection by the 857 Upstream CDN. Performance data may include various traffic 858 statistics (the specific parameters are to be determined). 859 The CDNI Logging interface may support the Upstream CDN to 860 indicate the nature and contents of the performance data to be 861 reported by the Downstream CDN. 863 LI-11 {MED} The CDNI Logging interface should support logging of 864 consumed resources (e.g. storage, bandwidth) to the Upstream 865 CDN for deliveries where content is stored by the Downstream 866 CDN for delivery to User Agents. The information logged may 867 include the type of storage (e.g., Origin, Intermediate, Edge, 868 Cache) as well as the amount of storage (e.g., total GB, GB 869 used, per time period, per content domain) all of which may 870 impact the cost of the services. 872 LI-12 {MED} In the case of cascaded CDNs, the CDNI Logging interface 873 should support the Downstream CDN to report consumed resources 874 (e.g. storage, bandwidth) to the Upstream CDN where content is 875 stored by the Downstream CDN itself as well as logging for 876 storage resources when content storage is performed by 877 cascaded CDNs on behalf of the Downstream CDN. 879 LI-13 {HIGH} The CDNI Logging interface shall support logging of 880 deleted objects from the Downstream CDN to the Upstream CDN as 881 a result of explicit delete requests on via the CDNI Control 882 interface from the Upstream CDN. 884 LI-14 {HIGH} The CDNI Logging interface shall support the exchange 885 of extensible log file formats to support proprietary 886 information fields. These information fields shall be agreed 887 upon ahead of time between the corresponding CDNs. 889 LI-15 {HIGH} The CDNI Logging interface shall allow a CDN to notify 890 another CDN about which CDNI logging information is available 891 for transfer and/or no longer available (e.g. it exceeded some 892 logging retention period or some logging retention volume). 894 LI-16 {MED} The CDNI Logging interface should support the ability 895 for the Downstream CDN to include the Content Collection ID 896 and Session ID fields in CDNI log entries generated for HTTP 897 Adaptive Streaming content. 899 LI-17 {MED} The CDNI Logging interface should provide privacy 900 protection by not disclosing information that can be used to 901 identify the user (e.g. method that anonymize the IP address 902 carried in the logging field). The use of the privacy 903 protection mechanism is optional. 905 9. CDNI Security Requirements 907 This section identifies the requirements related to the CDNI 908 security. Some of these are expected to affect multiple or all 909 protocols. 911 SEC-1 {HIGH} All the CDNI interface shall support secure operation 912 over unsecured IP connectivity (e.g. The Internet). This 913 includes authentication, confidentiality, integrity protection 914 as well as protection against spoofing and replay. 916 SEC-2 {HIGH} The CDNI solution shall provide sufficient protection 917 against Denial of Service attacks. This includes protection 918 against spoofed delivery requests sent by user agents directly 919 to a Downstream CDN attempting to appear as if they had been 920 redirected by a given Upstream CDN when they have not. 922 SEC-3 {MED} The CDNI solution should be able to ensure that for any 923 given request redirected to a Downstream CDN, the chain of CDN 924 Delegation (leading to that request being served by that CDN) 925 can be established with non-repudiation. 927 SEC-4 {MED} The CDNI solution should be able to ensure non- 928 repudiation by the Downstream CDN of transaction logs 929 generated by the Downstream CDN and communicated to an 930 Upstream CDN. This would ensure that the Downstream CDN 931 cannot repudiate transmitted Log records, therefore 932 discouraging the Downstream CDN from spoofing a transaction 933 log (attempting to appear as if it corresponds to a request 934 redirected by the Upstream CDN when that request has not been 935 redirected by this Upstream CDN). 937 SEC-5 {LOW} The CDNI solution may provide a mechanism allowing an 938 Upstream CDN that has credentials to acquire content from the 939 CSP origin server (or another CDN), to allow establishment of 940 credentials authorizing the Downstream CDN to acquire the 941 content from the CSP origin server (or the other CDN) (e.g. 942 In case the content cannot be acquired from the Upstream CDN). 944 10. IANA Considerations 946 This document makes no request of IANA. 948 Note to RFC Editor: this section may be removed on publication as an 949 RFC. 951 11. Security Considerations 953 This document discusses CDNI security requirements in Section 9. 955 12. Authors 957 This document reflects the contributions from the following authors: 959 Francois Le Faucheur 961 Cisco Systems 963 flefauch@cisco.com 965 Mahesh Viveganandhan 967 Cisco Systems 969 mvittal@cisco.com 971 Grant Watson 973 Alcatel-Lucent (Velocix) 975 gwatson@velocix.com 977 13. Acknowledgements 979 This document leverages the earlier work of the IETF CDI working 980 group in particular as documented in [I-D.cain-request-routing-req], 981 [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. 983 The authors would like to thank Gilles Bertrand, Christophe Caillet, 984 Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile 985 Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana 986 Oprescu, and Spencer Dawkins for their input. Serge Manning along 987 with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and 988 Ramki Krishnan contributed to this document by addressing the 989 requirements of the ATIS Cloud Services Forum. 991 Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable 992 inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI 993 Logging interface, respectively. 995 14. References 997 14.1. Normative References 999 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1000 Distribution Network Interconnection (CDNI) Problem 1001 Statement", RFC 6707, September 2012. 1003 14.2. Informative References 1005 [ATIS-0800042] 1006 "ATIS IPTV Content on Demand Service, 1007 https://www.atis.org/docstore/product.aspx?id=25670", 1008 December 2010. 1010 [I-D.amini-cdi-distribution-reqs] 1011 Amini, L., "Distribution Requirements for Content 1012 Internetworking", draft-amini-cdi-distribution-reqs-02 1013 (work in progress), November 2001. 1015 [I-D.cain-request-routing-req] 1016 Cain, B., "Request Routing Requirements for Content 1017 Internetworking", draft-cain-request-routing-req-03 (work 1018 in progress), November 2001. 1020 [I-D.gilletti-cdnp-aaa-reqs] 1021 "CDI AAA Requirements, 1022 draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. 1024 [I-D.ietf-cdni-framework] 1025 Peterson, L. and B. Davie, "Framework for CDN 1026 Interconnection", draft-ietf-cdni-framework-06 (work in 1027 progress), October 2013. 1029 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1030 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1031 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1033 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1034 K., and G. Watson, "Use Cases for Content Delivery Network 1035 Interconnection", RFC 6770, November 2012. 1037 Authors' Addresses 1039 Kent Leung (editor) 1040 Cisco Systems 1041 170 West Tasman Drive 1042 San Jose, CA 95134 1043 U.S.A. 1045 Phone: +1 408 526 5030 1046 Email: kleung@cisco.com 1048 Yiu Lee (editor) 1049 Comcast 1050 One Comcast Center 1051 Philadelphia, PA 19103 1052 U.S.A. 1054 Email: yiu_lee@cable.comcast.com