idnits 2.17.1 draft-ietf-cdni-framework-06.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 : ---------------------------------------------------------------------------- == There are 79 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3838 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RI REPLY' is mentioned on line 475, but not defined == Unused Reference: 'I-D.lefaucheur-cdni-logging-delivery' is defined on line 2384, but no explicit reference was found in the text == Unused Reference: 'I-D.seedorf-alto-for-cdni' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: 'RFC3466' is defined on line 2410, but no explicit reference was found in the text == Unused Reference: 'RFC5693' is defined on line 2414, but no explicit reference was found in the text == Unused Reference: 'RFC6707' is defined on line 2418, but no explicit reference was found in the text == Unused Reference: 'RFC6770' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC6983' is defined on line 2426, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-02 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-10 -- Obsolete informational reference (is this intentional?): RFC 3466 (Obsoleted by RFC 7336) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Peterson, Ed. 3 Internet-Draft Akamai Technologies, Inc. 4 Obsoletes: 3466 (if approved) B. Davie 5 Intended status: Informational VMware, Inc. 6 Expires: April 24, 2014 October 21, 2013 8 Framework for CDN Interconnection 9 draft-ietf-cdni-framework-06 11 Abstract 13 This document presents a framework for Content Distribution Network 14 Interconnection (CDNI). The purpose of the framework is to provide 15 an overall picture of the problem space of CDNI and to describe the 16 relationships among the various components necessary to interconnect 17 CDNs. CDN Interconnection requires the specification of interfaces 18 and mechanisms to address issues such as request routing, 19 distribution metadata exchange, and logging information exchange 20 across CDNs. The intent of this document is to outline what each 21 interface needs to accomplish, and to describe how these interfaces 22 and mechanisms fit together, while leaving their detailed 23 specification to other documents. It obsoletes RFC 3466. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Structure Of This Document . . . . . . . . . . . . . . . 7 63 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 65 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 66 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 67 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 68 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 69 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 70 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 71 3.4. Iterative DNS-based Redirection Example . . . . . . 22 72 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 73 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 26 74 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 27 75 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 28 76 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 30 77 3.10. Content and Metadata Acquisition with Multiple Upstream 78 CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33 80 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 34 81 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 34 82 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 35 83 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 36 84 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 38 85 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 38 86 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 39 87 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 40 88 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 41 89 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 90 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 91 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 43 92 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 44 93 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 96 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 49 97 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 49 98 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 100 11. Informative References . . . . . . . . . . . . . . . . . . . 50 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 103 1. Introduction 105 This document provides an overview of the various components 106 necessary to interconnect CDNs, expanding on the problem statement 107 and use cases introduced in RFCs 6770 and 6707. It describes the 108 necessary interfaces and mechanisms in general terms and outlines how 109 they fit together to form a complete system for CDN Interconnection. 110 Detailed specifications are left to other documents. This document 111 makes extensive use of message flow examples to illustrate the 112 operation of interconnected CDNs, but these examples should be 113 considered illustrative rather than prescriptive. 115 RFC 3466 uses different terminology and models for "Content 116 Internetworking (CDI)". It is also less prescriptive in terms of 117 interfaces. To avoid confusion, this document obsoletes RFC 3466. 119 1.1. Terminology 121 This document uses the core terminology defined in RFC 6707. It also 122 introduces the following terms: 124 CDN-Domain: a host name (FQDN) at the beginning of a URL, 125 representing a set of content that is served by a given CDN. For 126 example, in the URL http://cdn.csp.com/...rest of url..., the CDN 127 domain is cdn.csp.com. A major role of CDN-Domain is to identify a 128 region (subset) of the URI space relative to which various CDN 129 Interconnection rules and policies are to apply. For example, a 130 record of CDN Metadata might be defined for the set of resources 131 corresponding to some CDN-Domain. 133 Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for 134 the purposes of communication with a peer CDN, but which is not found 135 in client requests. Such CDN-Domains may be used for inter-CDN 136 acquisition, or as redirection targets, and enable a CDN to 137 distinguish a request from a peer CDN from an end-user request. 139 Delivering CDN: the CDN that ultimately delivers a piece of content 140 to the end-user. The last in a potential sequence of downstream 141 CDNs. 143 Recursive CDNI Request Redirection: When an upstream CDN elects to 144 redirect a request towards a downstream CDN, the upstream CDN can 145 query the downstream CDN Request Routing system via the CDNI Request 146 Routing Redirection Interface (or use information cached from earlier 147 similar queries) to find out how the downstream CDN wants the request 148 to be redirected, which allows the upstream CDN to factor in the 149 downstream CDN response when redirecting the user agent. This 150 approach is referred to as "Recursive" CDNI Request Redirection. 151 Note that the downstream CDN may elect to have the request redirected 152 directly to a Surrogate inside the downstream CDN, to the Request 153 Routing System of the downstream CDN, to another CDN, or to whatever 154 system is necessary to handle the redirected request appropriately. 156 Iterative CDNI Request Redirection: When an upstream CDN elects to 157 redirect a request towards a downstream CDN, the upstream CDN can 158 base its redirection purely on a local decision (and without 159 attempting to take into account how the downstream CDN may in turn 160 redirect the user agent). In that case, the upstream CDN redirects 161 the request to the request routing system in the downstream CDN, 162 which in turn will decide how to redirect that request: this approach 163 is referred to as "Iterative" CDNI Request Redirection. 165 Synchronous CDNI operations: operations between CDNs that happen 166 during the process of servicing a user request, i.e. between the time 167 that the user agent begins its attempt to obtain content and the time 168 at which that request is served. 170 Asynchronous CDNI operations: operations between CDNs that happen 171 independently of any given user request, such as advertisement of 172 footprint information or pre-positioning of content for later 173 delivery. 175 Trigger Interface: a subset of the CDNI Control interface that 176 includes operations to pre-position, revalidate, and purge both 177 metadata and content. These operations are typically called in 178 response to some action (Trigger) by the CSP on the upstream CDN. 180 We also sometimes use uCDN and dCDN as shorthand for upstream CDN and 181 downstream CDN, respectively. 183 1.2. Reference Model 185 This document uses the reference model in Figure 1, which expands the 186 reference model originally defined in RFC 6707. (The difference is 187 that the expanded model splits the Request Routing Interface into its 188 two distinct parts: the Request Routing Redirection interface and the 189 Footprint and Capabilities Advertisement interface, as described 190 below.) 192 -------- 194 / \ 195 | CSP | 196 \ / 197 -------- 198 * 199 * 200 * /\ 201 * / \ 202 ---------------------- |CDNI| ---------------------- 203 / Upstream CDN \ | | / Downstream CDN \ 204 | +-------------+ | | CI | | +-------------+ | 205 |******* Control |<======|====|=======>| Control *******| 206 |* +------*----*-+ | | | | +-*----*------+ *| 207 |* * * | | | | * * *| 208 |* +------*------+ | | LI | | +------*------+ *| 209 |* ***** Logging |<======|====|=======>| Logging ***** *| 210 |* * +-*-----------+ | | | | +-----------*-+ * *| 211 |* * * * | | | | * * * *| 212 .....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*... 213 . |* * | |<======|====|=======>| | * *| . 214 . |* * | Req-Routing | | |FCI | | | Req-Routing | * *| . 215 . |* * *** |<======|====|=======>| |** * *| . 216 . |* * * +-------------+.| | | | +-------------+ * * *| . 217 . |* * * . | | | * * *| . 218 . |* * * +-------------+ |. | MI | | +-------------+ * * *| . 219 . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| . 220 . |* * * | | | . \ / | | | * * *| . 221 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 222 . |* * ***| +---------+| | ...Request......+---------+ |*** * *| . 223 . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| . 224 . |******* +---------+| | Acquisition | |+----------+ *******| . 225 . | +-------------+ | | +-------*-----+ | . 226 . \ / \ * / . 227 . ---------------------- ---------*------------ . 228 . * . 229 . * Delivery . 230 . * . 231 . +--*---+ . 232 ...............Request............................| User |..Request.. 233 | Agent| 234 +------+ 236 <==> interfaces inside the scope of CDNI 238 **** interfaces outside the scope of CDNI 239 .... interfaces outside the scope of CDNI 241 Figure 1: CDNI Expanded Model and CDNI Interfaces 243 We note that while some interfaces in the reference model are "out of 244 scope" for the CDNI WG (in the sense that there is no need to define 245 new protocols for those interfaces) we still need to refer to them in 246 this document to explain the overall operation of CDNI. 248 We also note that, while we generally show only one upstream CDN 249 serving a given CSP, it is entirely possible that multiple uCDNs can 250 serve a single CSP. In fact, this situation effectively exists today 251 in the sense that a single CSP can currently delegate its content 252 delivery to more than one CDN. 254 The following briefly describes the five CDNI interfaces, 255 paraphrasing the definitions given in RFC 6707. We discuss these 256 interfaces in more detail in Section 4. 258 o CDNI Control interface (CI): Operations to bootstrap and 259 parameterize the other CDNI interfaces, as well as operations to 260 pre-position, revalidate, and purge both metadata and content. 261 The latter subset of operations is sometimes collectively called 262 the "Trigger interface." 264 o CDNI Request Routing interface: Operations to determine what CDN 265 (and optionally what surrogate within a CDN) is to serve end- 266 user's requests. Is actually a logical bundling of two separate 267 but related interfaces: 269 * CDNI Footprint & Capabilities Advertisement interface (FCI): 270 Asynchronous operations to exchange routing information (e.g., 271 the network footprint and capabilities served by a given CDN) 272 that enables CDN selection for subsequent user requests; and 274 * CDNI Request Routing Redirection interface (RI): Synchronous 275 operations to select a delivery CDN (surrogate) for a given 276 user request. 278 o CDNI Metadata interface (MI): Operations to communicate metadata 279 that governs how the content is delivered by interconnected CDNs. 280 Examples of CDNI metadata include geo-blocking directives, 281 availability windows, access control mechanisms, and purge 282 directives. It may include a combination of: 284 * Asynchronous operations to exchange metadata that govern 285 subsequent user requests for content; and 287 * Synchronous operations that govern behavior for a given user 288 request for content. 290 o CDNI Logging interface (LI): Operations that allow interconnected 291 CDNs to exchange relevant activity logs. May include a 292 combination of: 294 * Real-time exchanges, suitable for runtime traffic monitoring; 295 and 297 * Offline exchanges, suitable for analytics and billing. 299 There is some potential overlap between the set of Trigger-based 300 operations in the CDNI Control interface and the CDNI Metadata 301 interface. For both cases, the information passed from the upstream 302 CDN to the downstream CDN can broadly be viewed as metadata that 303 describes how content is to be managed by the downstream CDN. For 304 example, the information conveyed by CI to pre-position, revalidate 305 or purge metadata is similar to the information conveyed by posting 306 updated metadata via the MI. Even the CI operation to purge content 307 could be viewed as an metadata update for that content: purge simply 308 says that the availability window for the named content ends now. 309 The two interfaces share much in common, so minimally, there will 310 need to be a consistent data model that spans both. 312 The distinction we draw has to do with what the uCDN knows about the 313 successful application of the metadata by the dCDN. In the case of 314 the CI, the downstream CDN returning a successful status message 315 guarantees that the operation has been successfully completed; e.g., 316 the content has been purged or pre-positioned. This implies that the 317 downstream CDN accepts responsibility for having successfully 318 completed the requested operation. In contrast, metadata passed 319 between CDNs via the MI carries no such completion guarantee. 320 Returning success implies successful receipt of the metadata, but 321 nothing can be inferred about precisely when the metadata will take 322 effect in the downstream CDN, only that it will take effect 323 eventually. This is because of the challenge in globally 324 synchronizing updates to metadata with end-user requests that are 325 currently in progress (or indistinguishable from currently being in 326 progress). Clearly, a CDN will not be viewed as a trusted peer if 327 "eventually" often becomes an indefinite period of time, but the 328 acceptance of responsibility cannot be as crisply defined for the MI. 330 Finally, there is a practical issue that impacts all of the CNDI 331 interfaces, and that is whether or not to optimize CDNI for HTTP 332 Adaptive Streaming (HAS). We highlight specific issues related to 333 delivering HAS content throughout this document, but for a more 334 thorough treatment of the topic, see RFC 6983. 336 1.3. Structure Of This Document 337 The remainder of this document is organized as follows: 339 o Section 2 describes some essential building blocks for CDNI, 340 notably the various options for redirecting user requests to a 341 given CDN. 343 o Section 3 provides a number of illustrative examples of various 344 CDNI operations. 346 o Section 4 describes the functionality of the main CDNI interfaces. 348 o Section 5 shows how various deployment models of CDNI may be 349 achieved using the defined interfaces. 351 o Section 6 describes the trust model of CDNI and the issues of 352 transitive trust in particular that CDNI raises. 354 2. Building Blocks 356 2.1. Request Redirection 358 At its core, CDN Interconnection requires the redirection of requests 359 from one CDN to another. For any given request that is received by 360 an upstream CDN, it will either respond to the request directly, or 361 somehow redirect the request to a downstream CDN. Two main 362 mechanisms are available for redirecting a request to a downstream 363 CDN. The first leverages the DNS name resolution process and the 364 second uses in-protocol redirection mechanisms such as the HTTP 302 365 or 307 redirection response. We discuss these below as background 366 before discussing some examples of their use in Section 3. 368 2.1.1. DNS Redirection 370 DNS redirection is based on returning different IP addresses for the 371 same DNS name, for example, to balance server load or to account for 372 the client's location in the network. A DNS server, sometimes called 373 the Local DNS (LDNS), resolves DNS names on behalf of an end-user. 374 The LDNS server in turn queries other DNS servers until it reaches 375 the authoritative DNS server for the CDN-Domain. The network 376 operator typically provides the LDNS server, although the user is 377 free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). 378 This latter possibility is important because the authoritative DNS 379 server sees only the IP address of the DNS server that queries it, 380 not the IP address of the original end-user. 382 The advantage of DNS redirection is that it is completely transparent 383 to the end user; the user sends a DNS name to the LDNS server and 384 gets back an IP address. On the other hand, DNS redirection is 385 problematic because the DNS request comes from the LDNS server, not 386 the end-user. This may affect the accuracy of server selection that 387 is based on the user's location. The transparency of DNS redirection 388 is also a problem in that there is no opportunity to take the 389 attributes of the user agent or the URI path component into account. 390 We consider two main forms of DNS redirection: simple and CNAME- 391 based. 393 In simple DNS redirection, the authoritative DNS server for the name 394 simply returns an IP address from a set of possible IP addresses. 395 The answer is chosen from the set based on characteristics of the set 396 (e.g., the relative loads on the servers) or characteristics of the 397 client (e.g., the location of the client relative to the servers). 398 Simple redirection is straightforward. The only caveats are (1) 399 there is a limit to the number of alternate IP addresses a single DNS 400 server can manage; and (2) DNS responses are cached by downstream 401 servers so the TTL on the response must be set to an appropriate 402 value so as to preserve the fresheness of the redirection. 404 In CNAME-based DNS redirection, the authoritative server returns a 405 CNAME response to the DNS request, telling the LDNS server to restart 406 the name lookup using a new name. A CNAME is essentially a symbolic 407 link in the DNS namespace, and like a symbolic link, redirection is 408 transparent to the client; the LDNS server gets the CNAME response 409 and re-executes the lookup. Only when the name has been resolved to 410 an IP address does it return the result to the user. Note that DNAME 411 would be preferable to CNAME if it becomes widely supported. 413 2.1.2. HTTP Redirection 415 HTTP redirection makes use of the redirection response of the HTTP 416 protocol (e.g.,"302" or "307"). This response contains a new URL 417 that the application should fetch instead of the original URL. By 418 changing the URL appropriately, the server can cause the user to 419 redirect to a different server. The advantages of HTTP redirection 420 are that (1) the server can change the URL fetched by the client to 421 include, for example, both the DNS name of the particular server to 422 use, as well as the original HTTP server that was being accessed; (2) 423 the client sends the HTTP request to the server, so that its IP 424 address is known and can be used in selecting the server; and (3) 425 other attributes (e.g., content type, user agent type) are visible to 426 the redirection mechanism. 428 The disadvantages of HTTP redirection are (1) it is visible to the 429 application, so it requires application support and may affect the 430 application behavior (e.g., web browsers will not send cookies if the 431 URL changes to a different domain); (2) HTTP is a heavyweight 432 protocol layered on TCP so it has relatively high overhead; and (3) 433 the results of HTTP redirection are not cached so that all 434 redirections must go through to the server. 436 3. Overview of CDNI Operation 438 To provide a big picture overview of the various components of CDN 439 Interconnection, we walk through a "day in the life" of a content 440 item that is made available via a pair of interconnected CDNs. This 441 will serve to illustrate many of the functions that need to be 442 supported in a complete CDNI solution. We give examples using both 443 DNS-based and HTTP-based redirection. We begin with very simple 444 examples and then how additional capabilities, such as recursive 445 request redirection and content removal, might be added. 447 Before walking through some specific examples, we present a high- 448 level view of the operations that may take place. This high-level 449 overview is illustrated in Figure 2. Note that most operations will 450 involve only a subset of all the messages shown below, and that the 451 order and number of operations may vary considerably, as more 452 detailed examples illustrate below. 454 The following shows Operator A as the upstream CDN (uCDN) and 455 Operator B as the downstream CDN (dCDN), where the former has a 456 relationship with a content provider and the latter being the CDN 457 selected by Operator A to deliver content to the end-user. The 458 interconnection relationship may be symmetric between these two CDN 459 operators, but each direction can be considered as operating 460 independently of the other so for simplicity we show the interaction 461 in one direction only. 463 End-User Operator B Operator A 464 | | | 465 | | | 466 | | [Async FCI Push] | (1) 467 | | | 468 | | [MI pre-positioning] | (2) 469 | | | 470 | CONTENT REQUEST | | 471 |-------------------------------------------------->| (3) 472 | | | 473 | | [Sync RI Pull] | (4) 474 | | | 475 | [RI REPLY] | | 476 |<--------------------------------------------------| (5) 477 | | | 478 | | | 479 | CONTENT REQUEST | | 480 |------------------------>| | (6) 481 | | | 482 | | [Sync MI Pull] | (7) 483 | | | 484 | | ACQUISITION REQUEST | 485 | X------------------------>| (8) 486 | X | 487 | X CONTENT DATA | 488 | X<------------------------| (9) 489 | | | 490 | CONTENT DATA | | 491 |<------------------------| | (10) 492 | | | 493 : : : 494 : [Other content requests] : 495 : : : 496 | | [CI: Content Purge] | (11) 497 : : : 498 | | [LI: Log exchange] | (12) 499 | | | 501 Figure 2: Overview of Operation 503 The operations shown in the Figure are as follows: 505 1. dCDN uses the FCI to advertise information relevant to its 506 delivery footprint and capabilities prior to any content 507 requests being redirected. 509 2. Prior to any content request, the uCDN uses the MI to 510 pre=position CDNI metadata to the dCDN, thereby making that 511 metadata available in readiness for later content requests. 513 3. A content request from a user agent arrives at uCDN. 515 4. uCDN may use the RI to synchronously request information from 516 dCDN regarding its delivery capabilities to decide if dCDN is a 517 suitable target for redirection of this request. 519 5. uCDN redirects the request to dCDN by sending some response 520 (DNS, HTTP) to the user agent. 522 6. The user agent requests the content from dCDN. 524 7. dCDN may use the MI to synchronously request metadata related to 525 this content from uCDN, e.g. to decide whether to serve it. 527 8. If the content is not already in a suitable cache in dCDN, dCDN 528 may acquire it from uCDN. 530 9. The content is delivered to dCDN from uCDN. 532 10. The content is delivered to the user agent by dCDN. 534 11. Some time later, perhaps at the request of the CSP (not shown) 535 uCDN may use the CI to instruct dCDN to purge the content, 536 thereby ensuring it is not delivered again. 538 12. After one or more content delivery actions by dCDN, a log of 539 delivery actions may be provided to uCDN using the LI. 541 The following sections show some more specific examples of how these 542 operations may be combined to perform various delivery, control and 543 logging operations across a pair of CDNs. 545 3.1. Preliminaries 547 Initially, we assume that there is at least one CSP that has 548 contracted with an upstream CDN (uCDN) to deliver content on its 549 behalf. We are not particularly concerned with the interface between 550 the CSP and uCDN, other than to note that it is expected to be the 551 same as in the "traditional" (non-interconnected) CDN case. Existing 552 mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be 553 used to direct a user request for a piece of content from the CSP 554 towards the CSP's chosen upstream CDN. 556 We assume Operator A provides an upstream CDN that serves content on 557 behalf of a CSP with CDN-Domain cdn.csp.com. We assume that Operator 558 B provides a downstream CDN. An end user at some point makes a 559 request for URL 561 http://cdn.csp.com/...rest of url... 563 It may well be the case that cdn.csp.com is just a CNAME for some 564 other CDN-Domain (such as csp.op-a.net). Nevertheless, the HTTP 565 request in the examples that follow is assumed to be for the example 566 URL above. 568 Our goal is to enable content identified by the above URL to be 569 served by the CDN of operator B. In the following sections we will 570 walk through some scenarios in which content is served, as well as 571 other CDNI operations such as the removal of content from a 572 downstream CDN. 574 3.2. Iterative HTTP Redirect Example 576 In this section we walk through a simple, illustrative example using 577 HTTP redirection from uCDN to dCDN. The example also assumes the use 578 of HTTP redirection inside uCDN and dCDN; however, this is 579 independent of the choice of redirection approach across CDNs, so an 580 alternative example could be constructed still showing HTTP 581 redirection from uCDN to dCDN but using DNS for handling of request 582 inside each CDN. 584 We assume for this example that Operators A and B have established an 585 agreement to interconnect their CDNs, with A being upstream and B 586 being downstream. 588 The operators agree that a CDN-Domain peer-a.op-b.net will be used as 589 the target of redirections from uCDN to dCDN. We assume the name of 590 this domain is communicated by some means to each CDN. (This could 591 be established out-of-band or via a CDNI interface.) We refer to 592 this domain as a "distinguished" CDN-Domain to convey the fact that 593 its use is limited to the interconnection mechanism; such a domain is 594 never used directly by a CSP. 596 We assume the operators also agree on some distinguished CDN-Domain 597 that will be used for inter-CDN acquisition of CSP's content from 598 uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net. 600 We assume the operators also exchange information regarding which 601 requests dCDN is prepared to serve. For example, dCDN may be 602 prepared to serve requests from clients in a given geographical 603 region or a set of IP address prefixes. This information may again 604 be provided out of band or via a defined CDNI interface. 606 We assume DNS is configured in the following way: 608 o The content provider is configured to make operator A the 609 authoritative DNS server for cdn.csp.com (or to return a CNAME for 610 cdn.csp.com for which operator A is the authoritative DNS server). 612 o Operator A is configured so that a DNS request for 613 op-b-acq.op-a.net returns a request router in Operator A. 615 o Operator B is configured so that a DNS request for peer-a.op-b.net 616 /cdn.csp.com returns a request router in Operator B. 618 Figure 3 illustrates how a client request for 620 http://cdn.csp.com/...rest of url... 622 is handled. 624 End-User Operator B Operator A 625 |DNS cdn.csp.com | | 626 |-------------------------------------------------->| 627 | | |(1) 628 |IPaddr of A's Request Router | 629 |<--------------------------------------------------| 630 |HTTP cdn.csp.com | | 631 |-------------------------------------------------->| 632 | | |(2) 633 |302 peer-a.op-b.net/cdn.csp.com | 634 |<--------------------------------------------------| 635 |DNS peer-a.op-b.net | | 636 |------------------------>| | 637 | |(3) | 638 |IPaddr of B's Request Router | 639 |<------------------------| | 640 | | | 641 |HTTP peer-a.op-b.net/cdn.csp.com | 642 |------------------------>| | 643 | |(4) | 644 |302 node1.peer-a.op-b.net/cdn.csp.com | 645 |<------------------------| | 646 |DNS node1.peer-a.op-b.net| | 647 |------------------------>| | 648 | |(5) | 649 |IPaddr of B's Delivery Node | 650 |<------------------------| | 651 | | | 652 |HTTP node1.peer-a.op-b.net/cdn.csp.com | 653 |------------------------>| | 654 | |(6) | 655 | |DNS op-b-acq.op-a.net | 656 | |------------------------>| 657 | | |(7) 658 | |IPaddr of A's Request Router 659 | |<------------------------| 660 | |HTTP op-b-acq.op-a.net | 661 | |------------------------>| 662 | | |(8) 663 | |302 node2.op-b.acq.op-A.net 664 | |<------------------------| 665 | |DNS node2.op-b-acq.op-a.net 666 | |------------------------>| 667 | | |(9) 668 | |IPaddr of A's Delivery Node 669 | |<------------------------| 670 | | | 671 | |HTTP node2.op-b-acq.op-a.net 672 | |------------------------>| 673 | | |(10) 674 | |Data | 675 | |<------------------------| 676 |Data | | 677 |<------------------------| | 679 Figure 3: Message Flow for Iterative HTTP Redirection 681 The steps illustrated in the figure are as follows: 683 1. A DNS resolver for Operator A processes the DNS request for its 684 customer based on CDN-Domain cdn.csp.com. It returns the IP 685 address of a request router in Operator A. 687 2. A Request Router for Operator A processes the HTTP request and 688 recognizes that the end-user is best served by another CDN, 689 specifically one provided by Operator B, and so it returns a 302 690 redirect message for a new URL constructed by "stacking" 691 Operator B's distinguished CDN-Domain (peer-a.op-b.net) on the 692 front of the original URL. (Note that more complex URL 693 manipulations are possible, such as replacing the initial CDN- 694 Domain by some opaque handle.) 696 3. The end-user does a DNS lookup using Operator B's distinguished 697 CDN-Domain (peer-a.op-b.net). B's DNS resolver returns the IP 698 address of a request router for Operator B. Note that if request 699 routing within dCDN was performed using DNS instead of HTTP 700 redirection, B's DNS resolver would also behave as the request 701 router and directly return the IP address of a delivery node. 703 4. The request router for Operator B processes the HTTP request and 704 selects a suitable delivery node to serve the end-user request, 705 and returns a 302 redirect message for a new URL constructed by 706 replacing the hostname with a subdomain of the Operator B's 707 distinguished CDN-Domain that points to the selected delivery 708 node. 710 5. The end-user does a DNS lookup using Operator B's delivery node 711 subdomain (node1.peer-a.op-b.net). B's DNS resolver returns the 712 IP address of the delivery node. 714 6. The end-user requests the content from B's delivery node. In 715 the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not 716 happen, and the content data is directly returned by the 717 delivery node to the end-user. In the case of a cache miss, the 718 content needs to be acquired by dCDN from uCDN (not the CSP). 719 The distinguished CDN-Domain peer-a.op-b.net indicates to dCDN 720 that this content is to be acquired from uCDN; stripping the 721 CDN-Domain reveals the original CDN-Domain cdn.csp.com and dCDN 722 may verify that this CDN-Domain belongs to a known peer (so as 723 to avoid being tricked into serving as an open proxy). It then 724 does a DNS request for an inter-CDN acquisition CDN-Domain as 725 agreed above (in this case, op-b-acq.op-a.net). 727 7. Operator A's DNS resolver processes the DNS request and returns 728 the IP address of a request router in operator A. 730 8. The request router for Operator A processes the HTTP request 731 from Operator B delivery node. Operator A request router 732 recognizes that the request is from a peer CDN rather than an 733 end-user because of the dedicated inter-CDN acquisition domain 734 (op-b-acq.op-a.net). (Note that without this specially defined 735 inter-CDN acquisition domain, operator A would be at risk of 736 redirecting the request back to operator B, resulting in an 737 infinite loop). The request router for Operator A selects a 738 suitable delivery node in uCDN to serve the inter-CDN 739 acquisition request and returns a 302 redirect message for a new 740 URL constructed by replacing the hostname with a subdomain of 741 the Operator A's distinguished inter-CDN acquisition domain that 742 points to the selected delivery node. 744 9. Operator A DNS resolver processes the DNS request and returns 745 the IP address of the delivery node in operator A. 747 10. Operator B requests (acquires) the content from Operator A. 748 Although not shown, Operator A processes the rest of the URL: it 749 extracts information identifying the origin server, validates 750 that this server has been registered, and determines the content 751 provider that owns the origin server. It may also perform its 752 own content acquisition steps if needed before returning the 753 content to dCDN. 755 The main advantage of this design is that it is simple: each CDN need 756 only know the distinguished CDN-Domain for each peer, with the 757 upstream CDN "pushing" the downstream CDN-Domain onto the URL as part 758 of its redirect (step 2) and the downstream CDN "popping" its CDN- 759 Domain off the URL to expose a CDN-Domain that the upstream CDN can 760 correctly process. Neither CDN needs to be aware of the internal 761 structure of the other's URLs. Moreover, the inter-CDN redirection 762 is entirely supported by a single HTTP redirect; neither CDN needs to 763 be aware of the other's internal redirection mechanism (i.e., whether 764 it is DNS or HTTP based). 766 One disadvantage is that the end-user's browser is redirected to a 767 new URL that is not in the same domain of the original URL. This has 768 implications on a number of security or validation mechanisms 769 sometimes used on endpoints. For example, it is important that any 770 redirected URL be in the same domain (e.g., csp.com) if the browser 771 is expected to send any cookies associated with that domain. As 772 another example, some video players enforce validation of a cross 773 domain policy that needs to allow for the domains involved in the CDN 774 redirection. These problems are generally soluble, but the solutions 775 complicate the example, so we do not discuss them further in this 776 version of the draft. 778 We note that this example begins to illustrate some of the interfaces 779 that may be required for CDNI, but does not require all of them. For 780 example, obtaining information from dCDN regarding the set of client 781 IP addresses or geographic regions it might be able to serve is an 782 aspect of request routing (specifically of the CDNI Footprint & 783 Capabilities Advertisement interface). Important configuration 784 information such as the distinguished names used for redirection and 785 inter-CDN acquisition could also be conveyed via a CDNI interface 786 (e.g., perhaps the CDNI Control interface). The example also shows 787 how existing HTTP-based methods suffice for the acquisition 788 interface. Arguably, the absolute minimum metadata required for CDNI 789 is the information required to acquire the content, and this 790 information was provided "in-band" in this example by means of the 791 URI handed to the client in the HTTP 302 response. The example also 792 assumes that the CSP does not require any distribution policy (e.g. 793 time window, geo-blocking) or delivery processing to be applied by 794 the interconnected CDNs. Hence, there is no explicit CDNI Metadata 795 interface invoked in this example. There is also no explicit CDNI 796 Logging interface discussed in this example. 798 We also note that the step of deciding when a request should be 799 redirected to dCDN rather than served by uCDN has been somewhat 800 glossed over. It may be as simple as checking the client IP address 801 against a list of prefixes, or it may be considerably more complex, 802 involving a wide range of factors, such as the geographic location of 803 the client (perhaps determined from a third party service), CDN load, 804 or specific business rules. 806 This example uses the "iterative" CDNI request redirection approach. 807 That is, uCDN performs part of the request redirection function by 808 redirecting the client to a request router in the dCDN, which then 809 performs the rest of the redirection function by redirecting to a 810 suitable surrogate. If request routing is performed in the dCDN 811 using HTTP redirection, this translates in the end-user experiencing 812 two successive HTTP redirections. By contrast, the alternative 813 approach of "recursive" CDNI request redirection effectively 814 coalesces these two successive HTTP redirections into a single one, 815 sending the end-user directly to the right delivery node in the dCDN. 816 This "recursive" CDNI request routing approach is discussed in the 817 next section. 819 3.3. Recursive HTTP Redirection Example 821 The following example builds on the previous one to illustrate the 822 use of the request routing interface (specifically the CDNI Request 823 Routing Redirection interface) to enable "recursive" CDNI request 824 routing. We build on the HTTP-based redirection approach because it 825 illustrates the principles and benefits clearly, but it is equally 826 possible to perform recursive redirection when DNS-based redirection 827 is employed. 829 In contrast to the prior example, the operators need not agree in 830 advance on a CDN-Domain to serve as the target of redirections from 831 uCDN to dCDN. We assume that the operators agree on some 832 distinguished CDN-Domain that will be used for inter-CDN acquisition 833 of CSP's content by dCDN. In this example, we'll use 834 op-b-acq.op-a.net. 836 We assume the operators also exchange information regarding which 837 requests dCDN is prepared to serve. For example, dCDN may be 838 prepared to serve requests from clients in a given geographical 839 region or a set of IP address prefixes. This information may again 840 be provided out of band or via a defined protocol. 842 We assume DNS is configured in the following way: 844 o The content provider is configured to make operator A the 845 authoritative DNS server for cdn.csp.com (or to return a CNAME for 846 cdn.csp.com for which operator A is the authoritative DNS server). 848 o Operator A is configured so that a DNS request for 849 op-b-acq.op-a.net returns a request router in Operator A. 851 o Operator B is configured so that a request for node1.op-b.net/ 852 cdn.csp.com returns the IP address of a delivery node. Note that 853 there might be a number of such delivery nodes. 855 Figure 3 illustrates how a client request for 857 http://cdn.csp.com/...rest of url... 859 is handled. 861 End-User Operator B Operator A 862 |DNS cdn.csp.com | | 863 |-------------------------------------------------->| 864 | | |(1) 865 |IPaddr of A's Request Router | 866 |<--------------------------------------------------| 867 |HTTP cdn.csp.com | | 868 |-------------------------------------------------->| 869 | | |(2) 870 | |RR/RI REQ cdn.csp.com | 871 | |<------------------------| 872 | | | 873 | |RR/RI RESP node1.op-b.net| 874 | |------------------------>| 875 | | |(3) 876 |302 node1.op-b.net/cdn.csp.com | 877 |<--------------------------------------------------| 878 |DNS node1.op-b.net | | 879 |------------------------>| | 880 | |(4) | 881 |IPaddr of B's Delivery Node | 882 |<------------------------| | 883 |HTTP node1.op-b.net/cdn.csp.com | 884 |------------------------>| | 885 | |(5) | 886 | |DNS op-b-acq.op-a.net | 887 | |------------------------>| 888 | | |(6) 889 | |IPaddr of A's Request Router 890 | |<------------------------| 891 | |HTTP op-b-acq.op-a.net | 892 | |------------------------>| 893 | | |(7) 894 | |302 node2.op-b.acq.op-A.net 895 | |<------------------------| 896 | |DNS node2.op-b-acq.op-a.net 897 | |------------------------>| 898 | | |(8) 899 | |IPaddr of A's Delivery Node 900 | |<------------------------| 901 | | | 902 | |HTTP node2.op-b-acq.op-a.net 903 | |------------------------>| 904 | | |(9) 905 | |Data | 906 | |<------------------------| 907 |Data | | 908 |<------------------------| | 910 Figure 4: Message Flow for Recursive HTTP Redirection 912 The steps illustrated in the figure are as follows: 914 1. A DNS resolver for Operator A processes the DNS request for its 915 customer based on CDN-Domain cdn.csp.com. It returns the IP 916 address of a Request Router in Operator A. 918 2. A Request Router for Operator A processes the HTTP request and 919 recognizes that the end-user is best served by another 920 CDN-\u002Dspecifically one provided by Operator B-\u002Dand so it 921 queries the CDNI Request Routing Redirection interface of 922 Operator B, providing a set of information about the request 923 including the URL requested. Operator B replies with the DNS 924 name of a delivery node. 926 3. Operator A returns a 302 redirect message for a new URL obtained 927 from the RI. 929 4. The end-user does a DNS lookup using the host name of the URL 930 just provided (node1.op-b.net). B's DNS resolver returns the IP 931 address of the corresponding delivery node. Note that, since the 932 name of the delivery node was already obtained from B using the 933 RI, there should not be any further redirection here (in contrast 934 to the iterative method described above.) 936 5. The end-user requests the content from B's delivery node, 937 potentially resulting in a cache miss. In the case of a cache 938 miss, the content needs to be acquired from uCDN (not the CSP.) 939 The distinguished CDN-Domain op-b.net indicates to dCDN that this 940 content is to be acquired from another CDN; stripping the CDN- 941 Domain reveals the original CDN-Domain cdn.csp.com, dCDN may 942 verify that this CDN-Domain belongs to a known peer (so as to 943 avoid being tricked into serving as an open proxy). It then does 944 a DNS request for the inter-CDN Acquisition "distinguished" CDN- 945 Domain as agreed above (in this case, op-b-acq.op-a.net). 947 6. Operator A DNS resolver processes the DNS request and returns the 948 IP address of a request router in operator A. 950 7. The request router for Operator A processes the HTTP request from 951 Operator B delivery node. Operator A request router recognizes 952 that the request is from a peer CDN rather than an end-user 953 because of the dedicated inter-CDN acquisition domain 954 (op-b-acq.op-a.net). (Note that without this specially defined 955 inter-CDN acquisition domain, operator A would be at risk of 956 redirecting the request back to operator B, resulting in an 957 infinite loop). The request router for Operator A selects a 958 suitable delivery node in uCDN to serve the inter-CDN acquisition 959 request and returns a 302 redirect message for a new URL 960 constructed by replacing the hostname with a subdomain of the 961 Operator A's distinguished inter-CDN acquisition domain that 962 points to the selected delivery node. 964 8. Operator A recognizes that the DNS request is from a peer CDN 965 rather than an end-user (due to the internal CDN-Domain) and so 966 returns the address of a delivery node. (Note that without this 967 specially defined internal domain, Operator A would be at risk of 968 redirecting the request back to Operator B, resulting in an 969 infinite loop.) 971 9. Operator B requests (acquires) the content from Operator A. 972 Operator A serves content for the requested CDN-Domain to dCDN. 973 Although not shown, it is at this point that Operator A processes 974 the rest of the URL: it extracts information identifying the 975 origin server, validates that this server has been registered, 976 and determines the content provider that owns the origin server. 977 It may also perform its own content acquisition steps if needed 978 before returning the content to dCDN. 980 Recursive redirection has the advantage over iterative of being more 981 transparent from the end-user's perspective, but the disadvantage of 982 each CDN exposing more of its internal structure (in particular, the 983 addresses of edge caches) to peer CDNs. By contrast, iterative 984 redirection does not require dCDN to expose the addresses of its edge 985 caches to uCDN. 987 This example happens to use HTTP-based redirection in both CDN A and 988 CDN B, but a similar example could be constructed using DNS-based 989 redirection in either CDN. Hence, the key point to take away here is 990 simply that the end user only sees a single redirection of some type, 991 as opposed to the pair of redirections in the prior (iterative) 992 example. 994 The use of the RI requires that the request routing mechanism be 995 appropriately configured and bootstrapped, which is not shown here. 996 More discussion on the bootstrapping of interfaces is provided in 997 Section 4 999 3.4. Iterative DNS-based Redirection Example 1001 In this section we walk through a simple example using DNS-based 1002 redirection for request redirection from uCDN to dCDN (as well as for 1003 request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- 1004 based redirection has certain advantages over HTTP-based redirection 1005 (notably, it is transparent to the end-user) as well as some 1006 drawbacks (notably the client IP address is not visible to the 1007 request router). 1009 As before, Operator A has to learn the set of requests that dCDN is 1010 willing or able to serve (e.g. which client IP address prefixes or 1011 geographic regions are part of the dCDN footprint). We assume 1012 Operator has and makes known to operator A some unique identifier 1013 that can be used for the construction of a distinguished CDN-Domain, 1014 as shown in more detail below. (This identifier strictly needs only 1015 to be unique within the scope of Operator A, but a globally unique 1016 identifier, such as an AS number assigned to B, is one easy way to 1017 achieve that.) Also, Operator A obtains the NS records for Operator 1018 B's externally visible redirection servers. Also, as before, a 1019 distinguished CDN-Domain, such as op-b-acq.op-a.net, must be assigned 1020 for inter-CDN acquisition. 1022 We assume DNS is configured in the following way: 1024 o The CSP is configured to make Operator A the authoritative DNS 1025 server for cdn.csp.com (or to return a CNAME for cdn.csp.com for 1026 which operator A is the authoritative DNS server). 1028 o When uCDN sees a request best served by dCDN, it returns CNAME and 1029 NS records for "b.cdn.csp.com", where "b" is the unique identifier 1030 assigned to Operator B. (It may, for example, be an AS number 1031 assigned to Operator B.) 1033 o dCDN is configured so that a request for "b.cdn.csp.com" returns a 1034 delivery node in dCDN. 1036 o uCDN is configured so that a request for "op-b-acq.op-a.net" 1037 returns a delivery node in uCDN. 1039 Figure 5 depicts the exchange of DNS and HTTP requests. The main 1040 differences from Figure 3 are the lack of HTTP redirection and 1041 transparency to the end-user. 1043 End-User Operator B Operator A 1044 |DNS cdn.csp.com | | 1045 |-------------------------------------------------->| 1046 | | |(1) 1047 |CNAME b.cdn.csp.com | | 1048 |NS records for b.cdn.csp.com | 1049 |<--------------------------------------------------| 1050 |DNS b.cdn.csp.com | | 1051 |------------------------>| | 1052 | |(2) | 1053 |IPaddr of B's Delivery Node | 1054 |<------------------------| | 1055 |HTTP cdn.csp.com | | 1056 |------------------------>| | 1057 | |(3) | 1058 | |DNS op-b-acq.op-a.net | 1059 | |------------------------>| 1060 | | |(4) 1061 | |IPaddr of A's Delivery Node 1062 | |<------------------------| 1063 | |HTTP op-b-acq.op-a.net | 1064 | |------------------------>| 1065 | | |(5) 1066 | |Data | 1067 | |<------------------------| 1068 |Data | | 1069 |<------------------------| | 1071 Figure 5: Message Flow for DNS-based Redirection 1073 The steps illustrated in the figure are as follows: 1075 1. Request Router for Operator A processes the DNS request for CDN- 1076 Domain cdn.csp.com and recognizes that the end-user is best 1077 served by another CDN. (This may depend on the IP address of the 1078 user's local DNS resolver, or other information discussed below.) 1079 The Request Router returns a DNS CNAME response by "stacking" the 1080 distinguished identifier for Operator B onto the original CDN- 1081 Domain (e.g., b.cdn.csp.com), plus an NS record that maps 1082 b.cdn.csp.com to B's Request Router. 1084 2. The end-user does a DNS lookup using the modified CDN-Domain 1085 (i.e., b.cdn.csp.com). This causes B's Request Router to respond 1086 with a suitable delivery node. 1088 3. The end-user requests the content from B's delivery node. The 1089 requested URL contains the name cdn.csp.com. (Note that the 1090 returned CNAME does not affect the URL.) At this point the 1091 delivery node has the correct IP address of the end-user and can 1092 do an HTTP 302 redirect if the redirections in steps 2 and 3 were 1093 incorrect. Otherwise B verifies that this CDN-Domain belongs to 1094 a known peer (so as to avoid being tricked into serving as an 1095 open proxy). It then does a DNS request for an "internal" CDN- 1096 Domain as agreed above (op-b-acq.op-a.net). 1098 4. Operator A recognizes that the DNS request is from a peer CDN 1099 rather than an end-user (due to the internal CDN-Domain) and so 1100 returns the address of a delivery node in uCDN. 1102 5. Operator A serves content to dCDN. Although not shown, it is at 1103 this point that Operator A processes the rest of the URL: it 1104 extracts information identifying the origin server, validates 1105 that this server has been registered, and determines the content 1106 provider that owns the origin server. 1108 The advantages of this approach are that it is more transparent to 1109 the end-user and requires fewer round trips than HTTP-based 1110 redirection (in its worst case, i.e., when none of the needed DNS 1111 information is cached). A potential problem is that the upstream CDN 1112 depends on being able to learn the correct downstream CDN that serves 1113 the end-user from the client address in the DNS request. In standard 1114 DNS operation, uCDN will only obtain the address of the client's 1115 local DNS resolver (LDNS), which is not guaranteed to be in the same 1116 network (or geographic region) as the client. If not-\u002De.g., the 1117 end-user uses a global DNS service-\u002Dthen the upstream CDN cannot 1118 determine the appropriate downstream CDN to serve the end-user. In 1119 this case, and assuming the uCDN is capable of detecting that 1120 situation, one option is for the upstream CDN to treat the end-user 1121 as it would any user not connected to a peer CDN. Another option is 1122 for the upstream CDN to "fall back" to a pure HTTP-based redirection 1123 strategy in this case (i.e., use the first method). Note that this 1124 problem affects existing CDNs that rely on DNS to determine where to 1125 redirect client requests, but the consequences are arguably less 1126 serious for CDNI since the LDNS is likely in the same network as the 1127 dCDN serves. One approach to ensuring that the client's IP address 1128 prefix is correctly determined in such situations is described in 1129 [I-D.vandergaast-edns-client-subnet]. 1131 As with the prior example, this example partially illustrates the 1132 various interfaces involved in CDNI. Operator A could learn 1133 dynamically from Operator B the set of prefixes or regions that B is 1134 willing and able to serve via the CDNI Footprint & Capabilities 1135 Advertisement interface. The distinguished name used for acquisition 1136 and the identifier for Operator B that is prepended to the CDN-Domain 1137 on redirection are examples of information elements that might also 1138 be conveyed by CDNI interfaces (or, alternatively, statically 1139 configured). As before, minimal metadata sufficient to obtain the 1140 content is carried "in-band" as part of the redirection process, and 1141 standard HTTP is used for inter-CDN acquisition. There is no 1142 explicit CDNI Logging interface discussed in this example. 1144 3.5. Dynamic Footprint Discovery Example 1146 There could be situations where being able to dynamically discover 1147 the set of requests that a given dCDN is willing and able to serve is 1148 beneficial. For example, a CDN might at one time be able to serve a 1149 certain set of client IP prefixes, but that set might change over 1150 time due to changes in the topology and routing policies of the IP 1151 network. The following example illustrates this capability. We have 1152 chosen the example of DNS-based redirection, but HTTP-based 1153 redirection could equally well use this approach. 1155 End-User Operator B Operator A 1156 |DNS cdn.csp.com | | 1157 |-------------------------------------------------->| 1158 | | |(1) 1159 | | RI REQ op-b.net | 1160 | |<------------------------| 1161 | | |(2) 1162 | | RI REPLY | 1163 | |------------------------>| 1164 | | |(3) 1165 |CNAME b.cdn.csp.com | | 1166 |NS records for b.cdn.csp.com | 1167 |<--------------------------------------------------| 1168 |DNS b.cdn.csp.com | | 1169 |------------------------>| | 1170 | |(2) | 1171 |IPaddr of B's Delivery Node | 1172 |<------------------------| | 1173 |HTTP cdn.csp.com | | 1174 |------------------------>| | 1175 | |(3) | 1176 | |DNS op-b-acq.op-a.net | 1177 | |------------------------>| 1178 | | |(4) 1179 | |IPaddr of A's Delivery Node 1180 | |<------------------------| 1181 | |HTTP op-b-acq.op-a.net | 1182 | |------------------------>| 1183 | | |(5) 1184 | |Data | 1185 | |<------------------------| 1186 |Data | | 1187 |<------------------------| | 1189 Figure 6: Message Flow for Dynamic Footprint Discovery 1191 This example differs from the one in Figure 5 only in the addition of 1192 a FCI request (step 2) and corresponding response (step 3). The RI 1193 REQ could be a message such as "Can you serve clients from this IP 1194 Prefix?" or it could be "Provide the list of client IP prefixes you 1195 can currently serve". In either case the response might be cached by 1196 operator A to avoid repeatedly asking the same question. 1197 Alternatively, or in addition, Operator B may spontaneously advertise 1198 to Operator A information (or changes) on the set of requests it is 1199 willing and able to serve on behalf of operator A; in that case, 1200 Operator B may spontaneously issue RR/RI REPLY messages that are not 1201 in direct response to a corresponding RR/RI REQ message. (Note that 1202 the issues of determining the client's subnet from DNS requests, as 1203 described above, are exactly the same here as in Section 3.4.) 1205 Once Operator A obtains the RI response, it is now able to determine 1206 that Operator B's CDN is an appropriate dCDN for this request and 1207 therefore a valid candidate dCDN to consider in its Redirection 1208 decision. If that dCDN is selected, the redirection and serving of 1209 the request proceeds as before (i.e. in the absence of dynamic 1210 footprint discovery). 1212 3.6. Content Removal Example 1214 The following example illustrates how the CDNI Control interface may 1215 be used to achieve pre-positioning of an item of content in the dCDN. 1216 In this example, user requests for a particular content, and 1217 corresponding redirection of such requests from Operator A to 1218 Operator B CDN, may (or may not) have taken place earlier. Then, at 1219 some point in time, the uCDN (for example, in response to a 1220 corresponding Trigger from the Content Provider) uses the CI to 1221 request that content identified by a particular URL be removed from 1222 dCDN. The following diagram illustrates the operation. 1224 End-User Operator B Operator A 1225 | |CI purge cdn.csp.com/... | 1226 | |<------------------------| 1227 | | | 1228 | |CI OK | 1229 | |------------------------>| 1230 | | | 1232 Figure 7: Message Flow for Content Removal 1234 The CI is used to convey the request from uCDN to dCDN that some 1235 previously acquired content should be deleted. The URL in the 1236 request specifies which content to remove. This example corresponds 1237 to a DNS-based redirection scenario such as Section 3.4. If HTTP- 1238 based redirection had been used, the URL for removal would be of the 1239 form peer-a.op-b.net/cdn.csp.com/... 1241 The dCDN is expected to confirm to the uCDN, as illustrated by the CI 1242 OK message, the completion of the removal of the targeted content 1243 from all the caches in dCDN. 1245 3.7. Pre-Positioned Content Acquisition Example 1247 The following example illustrates how the CI may be used to pre- 1248 position an item of content in the dCDN. In this example, Operator A 1249 uses the CDNI Metadata interface to request that content identified 1250 by a particular URL be pre-positioned into Operator B CDN. 1252 End-User Operator B Operator A 1254 | |CI pre-position cdn.csp.com/... 1255 | |<------------------------| 1256 | | |(1) 1257 | |CI OK | 1258 | |------------------------>| 1259 | | | 1260 | |DNS op-b-acq.op-a.net | 1261 | |------------------------>| 1262 | | |(2) 1263 | |IPaddr of A's Delivery Node 1264 | |<------------------------| 1265 | |HTTP op-b-acq.op-a.net | 1266 | |------------------------>| 1267 | | |(3) 1268 | |Data | 1269 | |<------------------------| 1270 |DNS cdn.csp.com | | 1271 |-------------------------------------------------->| 1272 | | |(4) 1273 |IPaddr of A's Request Router | 1274 |<--------------------------------------------------| 1275 |HTTP cdn.csp.com | | 1276 |-------------------------------------------------->| 1277 | | |(5) 1278 |302 peer-a.op-b.net/cdn.csp.com | 1279 |<--------------------------------------------------| 1280 |DNS peer-a.op-b.net | | 1281 |------------------------>| | 1282 | |(6) | 1283 |IPaddr of B's Delivery Node | 1284 |<------------------------| | 1285 |HTTP peer-a.op-b.net/cdn.csp.com | 1286 |------------------------>| | 1287 | |(7) | 1288 |Data | | 1289 |<------------------------| | 1291 Figure 8: Message Flow for Content Pre-Positioning 1293 The steps illustrated in the figure are as follows: 1295 1. Operator A uses the CI to request that Operator B pre-positions a 1296 particular content item identified by its URL. Operator B 1297 responds by confirming that it is willing to perform this 1298 operation. 1300 Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only 1301 this time those steps happen as the result of the Pre-positioning 1302 request instead of as the result of a cache miss. 1304 Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of Figure 1305 3, only this time Operator B CDN can serve the end-user request 1306 without triggering dynamic content acquisition, since the content has 1307 been pre-positioned in dCDN. Note that, depending on dCDN operations 1308 and policies, the content pre-positioned in the dCDN may be pre- 1309 positioned to all, or a subset of, dCDN caches. In the latter case, 1310 intra-CDN dynamic content acquisition may take place inside the dCDN 1311 serving requests from caches on which the content has not been pre- 1312 positioning; however, such intra-CDN dynamic acquisition would not 1313 involve the uCDN. 1315 3.8. Asynchronous CDNI Metadata Example 1317 In this section we walk through a simple example illustrating a 1318 scenario of asynchronously exchanging CDNI metadata, where the 1319 downstream CDN obtains CDNI metadata for content ahead of a 1320 corresponding content request. The example that follows assumes that 1321 HTTP-based inter-CDN redirection and recursive CDNI request-routing 1322 are used, as in Section 3.3. However, Asynchronous exchange of CDNI 1323 Metadata is similarly applicable to DNS-based inter-CDN redirection 1324 and iterative request routing (in which cases the CDNI metadata may 1325 be used at slightly different processing stages of the message 1326 flows). 1328 End-User Operator B Operator A 1329 | | | 1330 | |CI pre-position (Trigger)| 1331 | |<------------------------|(1) 1332 | | | 1333 | |CI OK | 1334 | |------------------------>|(2) 1335 | | | 1336 | |MI pull REQ | 1337 | |------------------------>|(3) 1338 | | | 1339 | |MI metadata REP |(4) 1340 | | | 1341 | | | 1342 | CONTENT REQUEST | | 1343 |-------------------------------------------------->|(5) 1344 | | | 1345 | | RI REQ | 1346 | |<------------------------|(6) 1347 | | | 1348 | | RI RESP | 1349 | |------------------------>|(7) 1350 | | | 1351 | CONTENT REDIRECTION | | 1352 |<--------------------------------------------------| (8) 1353 | | | 1354 | CONTENT REQUEST | | 1355 |------------------------>|(9) | 1356 | | | 1357 : : : 1358 | CONTENT DATA | | 1359 |<------------------------| |(10) 1361 Figure 9: Message Flow for Asynchronous CDNI Metadata 1363 The steps illustrated in the figure are as follows: 1365 1. Operator A uses the CI to Trigger to signal the availability of 1366 CDNI metadata to Operator B. 1368 2. Operator B acknowledges the receipt of this Trigger. 1370 3. Operator B requests the latest metadata from Operator A using 1371 the MI. 1373 4. Operator A replies with the requested metadata. This document 1374 does not constrain how the CDNI metadata information is actually 1375 represented. For the purposes of this example, we assume that 1376 Operator A provides CDNI metadata to Operator B indicating that: 1378 * this CDNI Metadata is applicable to any content referenced by 1379 some CDN-Domain. 1381 * this CDNI metadata consists of a distribution policy 1382 requiring enforcement by the delivery node of a specific per- 1383 request authorization mechanism (e.g. URI signature or token 1384 validation). 1386 5. A Content Request occurs as usual. 1388 6. A CDNI Request Routing Redirection request (RI REQ) is issued by 1389 operator A CDN, as discussed in Section 3.3. Operator B's 1390 request router can access the CDNI Metadata that are relevant to 1391 the requested content and that have been pre-positioned as per 1392 Steps 1-4, which may or may not affect the response. 1394 7. Operator B's request router issues a CDNI Request Routing 1395 Redirection response (RI RESP) as in Section 3.3. 1397 8. Operator B performs content redirection as discussed in 1398 Section 3.3. 1400 9. On receipt of the Content Request by the end user, the delivery 1401 node detects that previously acquired CDNI metadata is 1402 applicable to the requested content. In accordance with the 1403 specific CDNI metadata of this example, the delivery node will 1404 invoke the appropriate per-request authorization mechanism, 1405 before serving the content. (Details of this authorization are 1406 not shown.) 1408 10. Assuming successful per-request authorization, serving of 1409 Content Data (possibly preceded by inter-CDN acquisition) 1410 proceeds as in Section 3.3. 1412 3.9. Synchronous CDNI Metadata Acquisition Example 1414 In this section we walk through a simple example illustrating a 1415 scenario of Synchronous CDNI metadata acquisition, in which the 1416 downstream CDN obtains CDNI metadata for content at the time of 1417 handling a first request for the corresponding content. As in the 1418 preceding section, this example assumes that HTTP-based inter-CDN 1419 redirection and recursive CDNI request-routing are used (as in 1420 Section 3.3), but dynamic CDNI metadata acquisition is applicable to 1421 other variations of request routing. 1423 End-User Operator B Operator A 1424 | | | 1425 | CONTENT REQUEST | | 1426 |-------------------------------------------------->|(1) 1427 | | | 1428 | | RI REQ | 1429 | (2)|<------------------------| 1430 | | | 1431 | | MI REQ | 1432 | (3)|------------------------>| 1433 | | MI RESP | 1434 | |<------------------------|(4) 1435 | | | 1436 | | RI RESP | 1437 | |------------------------>|(5) 1438 | | | 1439 | | | 1440 | CONTENT REDIRECTION | | 1441 |<--------------------------------------------------|(6) 1442 | | | 1443 | CONTENT REQUEST | | 1444 |------------------------>| (7) | 1445 | | | 1446 | | MI REQ | 1447 | (8)|------------------------>| 1448 | | MI RESP | 1449 | |<------------------------|(9) 1450 | | | 1451 : : : 1452 | CONTENT DATA | | 1453 |<------------------------| | (10) 1455 Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition 1457 The steps illustrated in the figure are as follows: 1459 1. A Content Request arrives as normal. 1461 2. An RI request occurs as in the prior example. 1463 3. On receipt of the CDNI Request Routing Request, Operator B's CDN 1464 initiates Synchronous acquisition of CDNI Metadata that are 1465 needed for routing of the end-user request. We assume the URI 1466 for the a Metadata server is known ahead of time through some 1467 out-of-band means. 1469 4. On receipt of a CDNI Metadata Request, Operator A's CDN 1470 responds, making the corresponding CDNI metadata information 1471 available to Operator B's CDN. This metadata is considered by 1472 operator B's CDN before responding to the Request Routing 1473 request. (In a simple case, the metadata could simply be an 1474 allow or deny response for this particular request.) 1476 5. Response to the RI request as normal. 1478 6. Redirection message is sent to the end user. 1480 7. A delivery node of Operator B receives the end user request. 1482 8. The delivery node Triggers dynamic acquisition of additional 1483 CDNI metadata that are needed to process the end-user content 1484 request. Note that there may exist cases where this step need 1485 not happen, for example because the metadata were already 1486 acquired previously. 1488 9. Operator A's CDN responds to the CDNI Metadata Request and makes 1489 the corresponding CDNI metadata available to Operator B. This 1490 metadata influence how Operator B's CDN processes the end-user 1491 request. 1493 10. Content is served (possibly preceded by inter-CDN acquisition) 1494 as in Section 3.3. 1496 3.10. Content and Metadata Acquisition with Multiple Upstream CDNs 1498 A single dCDN may receive end-user requests from multiple uCDNs. 1499 When a dCDN receives an end-user request, it must determine the 1500 identity of the uCDN from which it should acquire the requested 1501 content. 1503 Ideally, the acquisition path of an end-user request will follow the 1504 redirection path of the request. The dCDN should acquire the content 1505 from the same uCDN which redirected the request. 1507 Determining the acquisition path requires the dCDN to reconstruct the 1508 redirection path based on information in the end-user request. The 1509 method for reconstructing the redirection path differs based on the 1510 redirection approach: HTTP or DNS. 1512 With HTTP-redirection, the rewritten URI should include sufficient 1513 information for the dCDN to directly or indirectly determine the uCDN 1514 when the end-user request is received. The HTTP-redirection approach 1515 can be further broken-down based on the how the URL is rewritten 1516 during redirection: HTTP-redirection with or without Site 1517 Aggregation. HTTP-redirection with Site Aggregation hides the 1518 identity of the original CSP. HTTP-redirection without Site 1519 Aggregation does not attempt to hide the identity of the original 1520 CSP. With both approaches, the rewritten URI includes enough 1521 information to identify the immediate neighbor uCDN. 1523 With DNS-redirection, the dCDN receives the published URI (instead of 1524 a rewritten URI) and does not have sufficient information for the 1525 dCDN to identify the appropriate uCDN. The dCDN may narrow the set 1526 of viable uCDNs by examining the CDNI metadata from each to determine 1527 which uCDNs are hosting metadata for the requested content. If there 1528 is a single uCDN hosting metadata for the requested content, the dCDN 1529 can assume that the request redirection is coming from this uCDN and 1530 can acquire content from that uCDN. If there are multiple uCDNs 1531 hosting metadata for the requested content, the dCDN may be ready to 1532 trust any of these uCDNs to acquire the content (provided the uCDN is 1533 in a position to serve it). If the dCDN is not ready to trust any of 1534 these uCDNs, it needs to ensure via out of band arrangements that, 1535 for a given content, only a single uCDN will ever redirect requests 1536 to the dCDN. 1538 Content acquisition may be preceded by content metadata acquisition. 1539 If possible, the acquisition path for metadata should also follow the 1540 redirection path. Additionally, we assume metadata is indexed based 1541 on rewritten URIs in the case of HTTP-redirection and is indexed 1542 based on published URIs in the case of DNS-redirection. Thus, the RI 1543 and the MI are tightly coupled in that the result of request routing 1544 (a rewritten URI pointing to the dCDN) serves as an input to metadata 1545 lookup. If the content metadata includes information for acquiring 1546 the content, then the MI is also tightly coupled with the acquisition 1547 interface in that the result of the metadata lookup (an acquisition 1548 URL likely hosted by the uCDN) should serve as input to the content 1549 acquisition. 1551 4. Main Interfaces 1553 Figure 1 illustrates the main interfaces that are in scope for the 1554 CDNI WG, along with several others. The detailed specifications of 1555 these interfaces are left to other documents, but see RFC 6707 and 1556 [I-D.ietf-cdni-requirements] for some discussion of the interfaces. 1558 One interface that is not shown in Figure 1 is the interface between 1559 the user and the CSP. While for the purposes of CDNI that interface 1560 is out of scope, it is worth noting that it does exist and can 1561 provide useful functions, such as end-to-end performance monitoring 1562 and some forms of authentication and authorization. 1564 There is also an important interface between the user and the Request 1565 Routing function of both uCDN and dCDN (shown as the "Request" 1566 Interface in Figure 1). As we saw in some of the preceding examples, 1567 that interface can be used as a way of passing information a subset 1568 of metadata such as the minimum information that is required for dCDN 1569 to obtain the content from uCDN. 1571 In this section we will provide an overview of the functions 1572 performed by each of the CDNI interfaces and discuss how they fit 1573 into the overall solution. We also examine some of the design 1574 tradeoffs, and explore several cross-interface concerns. We begin 1575 with an examination of one such tradeoff that affects all the 1576 interfaces - the use of in-band or out-of-band communication. 1578 4.1. In-Band versus Out-of-Band Interfaces 1580 Before getting to the individual interfaces, we observe that there is 1581 a high-level design choice for each, involving the use of existing 1582 in-band communication channels versus defining new out-of-band 1583 interfaces. 1585 It is possible that the information needed to carry out various 1586 interconnection functions can be communicated between peer CDNs using 1587 existing in-band protocols. The use of HTTP 302 redirect is an 1588 example of how certain aspects of request routing can be implemented 1589 in-band (embedded in URIs). Note that using existing in-band 1590 protocols does not imply that the CDNI interfaces are null; it is 1591 still necessary to establish the rules (conventions) by which such 1592 protocols are used to implement the various interface functions. 1594 There are other opportunities for in-band communication beyond HTTP 1595 redirects. For example, many of the HTTP directives used by proxy 1596 servers can also be used by peer CDNs to inform each other of caching 1597 activity. Of these, one that is particularly relevant is the If- 1598 Modified-Since directive, which is used with the GET method to make 1599 it conditional: if the requested object has not been modified since 1600 the time specified in this field, a copy of the object will not be 1601 returned, and instead, a 304 (not modified) response will be 1602 returned. 1604 4.2. Cross Interface Concerns 1606 Although the CDNI interfaces are largely independent, there are a set 1607 of conventions practiced consistently across all interfaces. Most 1608 important among these is how resources are named, for exampmle, how 1609 the CDNI Metadata and Control interfaces identify the set of 1610 resources to which a given directive applies, or the CDNI Logging 1611 interface identifies the set of resources for which a summary record 1612 applies. 1614 While in the limit the CDNI interfaces could explicitly identify 1615 every individual resource, in practice, they name resource aggregates 1616 (sets of URIs) that are to be treated in a similar way. For example, 1617 URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at 1618 the beginning of a URI) or by a URI-Filter (i.e., a regular 1619 expression that matches a subset of URIs contained in some CDN- 1620 Doman). In other words, CDN-Domains and URI-Filters provide a 1621 uniform means to aggregate sets (and subsets) of URIs for the purpose 1622 of defining the scope for some operation in one of the CDNI 1623 interfaces. 1625 4.3. Request Routing Interfaces 1627 The Request Routing interface comprises two parts: the Asynchronous 1628 interface used by a dCDN to advertize footprint and capabilities 1629 (denoted FCI) to a uCDN, allowing the uCDN to decide whether to 1630 redirect particular user requests to that dCDN; and the Synchronous 1631 interface used by the uCDN to redirect a user request to the dCDN 1632 (denoted RI). (These are somewhat analogous to the operations of 1633 routing and forwarding in IP.) 1635 As illustrated in Section 3, the RI part of request routing may be 1636 implemented in part by DNS and HTTP. Naming conventions may be 1637 established by which CDN peers communicate whether a request should 1638 be routed or content served. 1640 We also note that RI plays a key role in enabling recursive 1641 redirection, as illustrated in Section 3.3. It enables the user to 1642 be redirected to the correct delivery node in dCDN with only a single 1643 redirection step (as seen by the user). This may be particularly 1644 valuable as the chain of interconnected CDNs increases beyond two 1645 CDNs. 1647 In support of these redirection requests, it is necessary for CDN 1648 peers to exchange additional information with each other, and this is 1649 the role of the FCI part of request routing. Depending on the 1650 method(s) supported, this might includes 1652 o The operator's unique id (operator-id) or distinguished CDN-Domain 1653 (operator-domain); 1655 o NS records for the operator's set of externally visible request 1656 routers; 1658 o The set of requests the dCDN operator is prepared to serve (e.g. a 1659 set of client IP prefixes or geographic regions that may be served 1660 by dCDN). 1662 o Additional capabilities of the dCDN, such as its ability to 1663 support different CDNI Metadata requests. 1665 Note that the set of requests that dCDN is willing to serve could in 1666 some cases be relatively static (e.g., a set of IP prefixes) which 1667 could be exchanged off-line, or might even be negotiated as part of a 1668 peering agreement. However, it may also be more dynamic, in which 1669 case the exchange supported by FCI would be be helpful. A further 1670 discussion of the Footprint & Capability Advertisement interface can 1671 be found in [I-D.spp-cdni-rr-foot-cap-semantics]. 1673 4.4. CDNI Logging Interface 1675 It is necessary for the upstream CDN to have visibility into the 1676 delivery of content that it redirected to a downstream CDN. This 1677 allows the upstream CDN to properly bill its customers for multiple 1678 deliveries of content cached by the downstream CDN, as well as to 1679 report accurate traffic statistics to those content providers. This 1680 is one role of the LI. 1682 Other operational data that may be relevant to CDNI can also be 1683 exchanged by the LI. For example, dCDN may report the amount of 1684 content it has acquired from uCDN, and how much cache storage has 1685 been consumed by content cached on behalf of uCDN. 1687 Traffic logs are easily exchanged off-line. For example, the 1688 following traffic log is a small deviation from the Apache log file 1689 format, where entries include the following fields: 1691 o Domain - the full domain name of the origin server 1693 o IP address - the IP address of the client making the request 1695 o End time - the ending time of the transfer 1697 o Time zone - any time zone modifier for the end time 1699 o Method - the transfer command itself (e.g., GET, POST, HEAD) 1701 o URL - the requested URL 1703 o Version - the protocol version, such as HTTP/1.0 1705 o Response - a numeric response code indicating transfer result 1707 o Bytes Sent - the number of bytes in the body sent to the client 1709 o Request ID - a unique identifier for this transfer 1711 o User agent - the user agent, if supplied 1713 o Duration - the duration of the transfer in milliseconds 1714 o Cached Bytes - the number of body bytes served from the cache 1716 o Referrer - the referrer string from the client, if supplied 1718 Of these, only the Domain field is indirect in the downstream 1719 CDN-\u002Dit is set to the CDN-Domain used by the upstream CDN rather 1720 than the actual origin server. This field could then used to filter 1721 traffic log entries so only those entries matching the upstream CDN 1722 are reported to the corresponding operator. Further discussion of 1723 the LI can be found in [I-D.bertrand-cdni-logging]. 1725 One open question is who does the filtering. One option is that the 1726 downstream CDN filters its own logs, and passes the relevant records 1727 directly to each upstream peer. This requires that the downstream 1728 CDN knows the set of CDN-Domains that belong to each upstream peer. 1729 If this information is already exchanged between peers as part of 1730 another interface, then direct peer-to-peer reporting is 1731 straightforward. If it is not available, and operators do not wish 1732 to advertise the set of CDN-Domains they serve to their peers, then 1733 the second option is for each CDN to send both its non-local traffic 1734 records and the set of CDN-Domains it serves to an independent third- 1735 party (i.e., a CDN Exchange), which subsequently filters, merges, and 1736 distributes traffic records on behalf of each participating CDN 1737 operator. 1739 A second open question is how timely traffic information should be. 1740 For example, in addition to offline traffic logs, accurate real-time 1741 traffic monitoring might also be useful, but such information 1742 requires that the downstream CDN inform the upstream CDN each time it 1743 serves upstream content from its cache. The downstream CDN can do 1744 this, for example, by sending a conditional HTTP GET request (If- 1745 Modified-Since) to the upstream CDN each time it receives an HTTP GET 1746 request from one of its end-users. This allows the upstream CDN to 1747 record that a request has been issued for the purpose of real-time 1748 traffic monitoring. The upstream CDN can also use this information 1749 to validate the traffic logs received later from the downstream CDN. 1751 There is obviously a tradeoff between accuracy of such monitoring and 1752 the overhead of the downstream CDN having to go back to the upstream 1753 CDN for every request. 1755 Another design tradeoff in the LI is the degree of aggregation or 1756 summarization of data. One situation that lends itself to 1757 summarization is the delivery of HTTP adaptive streaming (HAS), since 1758 the large number of individual chunk requests potentially results in 1759 large volumes of logging information. This case is discussed below, 1760 but other forms of aggregation may also be useful. For example, 1761 there may be situations where bulk metrics such as bytes delivered 1762 per hour may suffice rather than the detailed per-request logs 1763 outlined above. It seems likely that a range of granularities of 1764 logging will be needed along with ways to specify the type and degree 1765 of aggregation required. 1767 4.5. CDNI Control Interface 1769 The CDNI Control interface is initially used to bootstrap the other 1770 interfaces. As a simple example, it could be used to provide the 1771 address of the logging server in dCDN to uCDN in order to bootstrap 1772 the CDNI Logging interface. It may also be used, for example, to 1773 establish security associations for the other interfaces. 1775 The other role the CI plays is to allow the uCDN to pre-position, 1776 revalidate, or purge metadata and content on a dCDN. These 1777 operations, sometimes collectively called the Trigger interface, are 1778 discussed further in [I-D.murray-cdni-triggers]. 1780 4.6. CDNI Metadata Interface 1782 The role of the CDNI Metadata interface is to enable CDNI 1783 distribution metadata to be conveyed to the downstream CDN by the 1784 upstream CDN. For example, see [I-D.ietf-cdni-metadata]. Such 1785 metadata includes geo-blocking restrictions, availability windows, 1786 access control policies, and so on. It may also include information 1787 to facilitate acquisition of content by dCDN (e.g., alternate sources 1788 for the content, authorization information needed to acquire the 1789 content from the source). 1791 Some distribution metadata may be partially emulated using in-band 1792 mechanisms. For example, in case of any geo-blocking restrictions or 1793 availability windows, the upstream CDN can elect to redirect a 1794 request to the downstream CDN only if that CDN's advertised delivery 1795 footprint is acceptable for the requested URL. Similarly, the 1796 request could be forwarded only if the current time is within the 1797 availability window. However, such approaches typically come with 1798 shortcomings such as inability to prevent from replay outside the 1799 time window or inability to make use of a downstream CDN that covers 1800 a broader footprint than the geo-blocking restrictions. 1802 Similarly, some forms of access control may also be performed on a 1803 per-request basis using HTTP directives. For example, being able to 1804 respond to a conditional GET request gives the upstream CDN an 1805 opportunity to influence how the downstream CDN delivers its content. 1806 Minimally, the upstream CDN can invalidate (purge) content previously 1807 cached by the downstream CDN. 1809 Fine-grain control over how the downstream CDN delivers content on 1810 behalf of the upstream CDN is also possible. For example, by 1811 including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded] 1812 with the conditional GET request, the downstream CDN can report the 1813 end-user's IP address to the upstream CDN, giving it an opportunity 1814 to control whether the downstream CDN should serve the content to 1815 this particular end-user. The upstream CDN would communicate its 1816 directive through its response to the conditional GET. The 1817 downstream CDN can cache information for a period of time specified 1818 by the upstream CDN, thereby reducing control overhead, but then 1819 preventing per-request control during the corresponding caching 1820 period. 1822 All of these in-band techniques serve to illustrate that uCDNs have 1823 the option of enforcing some of their access control policies 1824 themselves (at the expense of increased inter-CDN signaling load), 1825 rather than delegating enforcement to dCDNs using the MI. As a 1826 consequence, the MI could provide a means for the uCDN to express its 1827 desire to retain enforcement for itself. For example, this might be 1828 done by including a "check with me" flag in the metadata associated 1829 with certain content. The realization of such in-band techniques 1830 over the various inter-CDN acquisition protocols (e.g., HTTP) 1831 requires further investigation and may require small extensions or 1832 semantic changes to the acquisition protocol. 1834 4.7. HTTP Adaptive Streaming Concerns 1836 We consider HTTP Adaptive Streaming (HAS) and the impact it has on 1837 the CDNI interfaces because large objects (e.g., videos) are broken 1838 into a sequence of small, independent chunks. For each of the 1839 following, a more thorough discussion, including an overview of the 1840 tradeoffs involved in alternative designs, can be found in RFC 6983. 1842 First, with respect to Content Acquisition and File Management, which 1843 are out-of-scope for the CDNI interfaces but nontheless relevant to 1844 the overall operation, we assume no additional measures are required 1845 to deal with large numbers of chunks. This means that the dCDN is 1846 not explicitly made aware of any relationship between different 1847 chunks and the dCDN handles each chunk as if it were an individual 1848 and independent content item. The result is that content acquisition 1849 between uCDN and dCDN also happens on a per-chunk basis. This 1850 approach is in line with the recommendations made in RFC 6983, which 1851 also identifies potential improvements in this area that might be 1852 considered in the future. 1854 Second, with respect to Request Routing, we note that HAS manifest 1855 files have the potential to interfere with request routing since 1856 manifest files contain URLs pointing to the location of content 1857 chunks. To make sure that a manifest file does not hinder CDNI 1858 request routing and does not place excessive load on CDNI resources, 1859 the use of manifest files could either be limited to those containing 1860 relative URLs or the uCDN could modify the URLs in the manifest. Our 1861 approach for dealing with these issues is twofold. As a mandatory 1862 requirement, CDNs should be able to handle unmodified manifest files 1863 containing either relative or absolute URLs. To limit the number of 1864 redirects, and thus the load placed on the CDNI interfaces, as an 1865 optional feature uCDNs can use the information obtained through the 1866 CNDI Request Routing Redirection interface to modify the URLs in the 1867 manifest file. Since the modification of the manifest file is an 1868 optional uCDN-internal process, this does not require any 1869 standardization effort beyond being able to communicate chunk 1870 locations in the CDNI Request Routing Redirection interface. 1872 Third, with respect to the CDNI Logging interface, there are several 1873 potential issues, including the large number of individual chunk 1874 requests potentially resulting in large volumes of logging 1875 information, and the desire to correlate logging information for 1876 chunk requests that correspond to the same HAS session. For the 1877 initial CDNI specification, our approach is to expect participating 1878 CDNs to support per-chunk logging (e.g. logging each chunk request as 1879 if it were an independent content request) over the CDNI Logging 1880 interface. Optionally, the LI may include a Content Collection 1881 IDentifier (CCID) and/or a Session IDentifier (SID) as part of the 1882 logging fields, thereby facilitating correlation of per-chunk logs 1883 into per-session logs for applications benefiting from such session 1884 level information (e.g. session-based analytics). This approach is 1885 in line with the recommendations made in RFC 6983, which also 1886 identifies potential improvements in this area that might be 1887 considered in the future. 1889 Fourth, with respect to the CDNI Control interface, and in particular 1890 purging HAS chunks from a given CDN, our approach is to expect each 1891 CDN supports per-chunk content purge (e.g. purging of chunks as if 1892 they were individual content items). Optionally, a CDN may support 1893 content purge on the basis of a "Purge IDentifier (Purge-ID)" 1894 allowing the removal of all chunks related to a given Content 1895 Collection with a single reference. It is possible that this Purge- 1896 ID could be merged with the CCID discussed above for HAS Logging, or 1897 alternatively, they may remain distinct. 1899 4.8. URI Rewriting 1901 When using HTTP redirection, content URIs may be rewritten when 1902 redirection takes place within an uCDN, from an uCDN to a dCDN, and 1903 within the dCDN. In the case of cascaded CDNs, content URIs may be 1904 rewritten at every CDN hop (e.g., between the uCDN and the dCDN 1905 acting as the transit CDN, and between the transit CDN and the dCDN 1906 serving the request. The content URI used between any uCDN/dCDN pair 1907 becomes a common handle that can be referred without ambiguity by 1908 both CDNs in all their inter-CDN communications. This handle allows 1909 the uCDN and dCDN to correlate information exchanged using other CDNI 1910 interfaces in both the downstream direction (e.g., when using the MI) 1911 and the upstream direction (e.g., when using the LI). 1913 Consider the simple case of a single uCDN/dCDN pair using HTTP 1914 redirection. We introduce the following terminology for content URIs 1915 to simplify the discussion: 1917 "u-URI" represents a content URI in a request presented to the 1918 uCDN; 1920 "ud-URI" is a content URI acting as the common handle across uCDN 1921 and dCDN for requests redirected by the uCDN to a specific dCDN; 1923 "d-URI" represents a content URI in a request made within the 1924 delegate dCDN. 1926 In our simple pair-wise example, the "ud-URI" effectively becomes the 1927 handle that the uCDN/dCDN pair use to correlate all CDNI information. 1928 In particular, for a given pair of CDNs executing the HTTP 1929 redirection, the uCDN needs to map the u-URI to the ud-URI handle for 1930 all MI message exchanges, while the dCDN needs to map the d-URI to 1931 the ud-URI handle for all LI message exchanges. 1933 In the case of a cascaded CDNs, the transit CDN will rewrite the 1934 content URI when redirecting to the dCDN, thereby establishing a new 1935 handle between the transit CDN and the dCDN, that is different from 1936 the handle between the uCDN and transit CDN. It is the 1937 responsibility of the transit CDN to manage its mapping across 1938 handles so the right handle for all pairs of CDNs is always used in 1939 its CDNI communication. 1941 In summary, all CDNI interfaces between a given pair of CDNs need to 1942 always use the "ud-URI" handle for that specific CDN pair as their 1943 content URI reference. 1945 5. Deployment Models 1947 In this section we describe a number of possible deployment models 1948 that may be achieved using the CDNI interfaces described above. We 1949 note that these models are by no means exhaustive, and that many 1950 other models may be possible. 1952 Although the reference model of Figure 1 shows all CDN functions on 1953 each side of the CDNI interface, deployments can rely on entities 1954 that are involved in any subset of these functions, and therefore 1955 only support the relevant subset of CDNI interfaces. As already 1956 noted in Section 3, effective CDNI deployments can be built without 1957 necessarily implementing all the interfaces. Some examples of such 1958 deployments are shown below. 1960 Note that, while we refer to upstream and downstream CDNs, this 1961 distinction applies to specific content items and transactions. That 1962 is, a given CDN may be upstream for some transactions and downstream 1963 for others, depending on many factors such as location of the 1964 requesting client and the particular piece of content requested. 1966 5.1. Meshed CDNs 1968 Although the reference model illustrated in Figure 1 shows a 1969 unidirectional CDN interconnection with a single uCDN and a single 1970 dCDN, any arbitrary CDNI meshing can be built from this, such as the 1971 example meshing illustrated in Figure 11. (Support for arbitrary 1972 meshing may or may not be in the initial scope for the working group, 1973 but the model allows for it.) 1975 ------------- ----------- 1976 / CDN A \<==CDNI===>/ CDN B \ 1977 \ / \ / 1978 ------------- ----------- 1979 /\ \\ /\ 1980 || \\ || 1981 CDNI \==CDNI===\\ CDNI 1982 || \\ || 1983 \/ \/ \/ 1984 ------------- ----------- 1985 / CDN C \===CDNI===>/ CDN D \ 1986 \ / \ / 1987 ------------- ----------- 1988 /\ 1989 || 1990 CDNI 1991 || 1992 \/ 1993 ------------- 1994 / CDN E \ 1995 \ / 1996 ------------- 1998 ===> CDNI interfaces, with right-hand side CDN acting as dCDN 1999 to left-hand side CDN 2001 <==> CDNI interfaces, with right-hand side CDN acting as dCDN 2002 to left-hand side CDN and with left-hand side CDN acting 2003 as dCDN to right-hand side CDN 2005 Figure 11: CDNI Deployment Model: CDN Meshing Example 2007 5.2. CSP combined with CDN 2009 Note that our terminology refers to functional roles and not economic 2010 or business roles. That is, a given organization may be operating as 2011 both a CSP and a fully fledged uCDN when we consider the functions 2012 performed, as illustrated in Figure 12. 2014 ##################################### ################## 2015 # # # # 2016 # Organization A # # Organization B # 2017 # # # # 2018 # -------- ------------- # # ----------- # 2019 # / CSP \ / uCDN \ # # / dCDN \ # 2020 # | | | +----+ | # # | +----+ | # 2021 # | | | | C | | # # | | C | | # 2022 # | | | +----+ | # # | +----+ | # 2023 # | | | +----+ | # # | +----+ | # 2024 # | | | | L | | # # | | L | | # 2025 # | |*****| +----+ |===CDNI===>| +----+ | # 2026 # | | | +----+ | # # | +----+ | # 2027 # | | | | RR | | # # | | RR | | # 2028 # | | | +----+ | # # | +----+ | # 2029 # | | | +----+ | # # | +----+ | # 2030 # | | | | D | | # # | | D | | # 2031 # | | | +----+ | # # | +----+ | # 2032 # \ / \ / # # \ / # 2033 # -------- ------------- # # ----------- # 2034 # # # # 2035 ##################################### ################## 2037 ===> CDNI interfaces, with right-hand side CDN acting as dCDN 2038 to left-hand side CDN 2039 **** interfaces outside the scope of CDNI 2040 C Control component of the CDN 2041 L Logging component of the CDN 2042 RR Request Routing component of the CDN 2043 D Distribution component of the CDN 2045 Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN 2047 5.3. CSP using CDNI Request Routing Interface 2048 As another example, a content provider organization may choose to run 2049 its own request routing function as a way to select among multiple 2050 candidate CDN providers; In this case the content provider may be 2051 modeled as the combination of a CSP and of a special, restricted case 2052 of a CDN. In that case, as illustrated in Figure 13, the CDNI 2053 Request Routing interfaces can be used between the restricted CDN 2054 operated by the content provider Organization and the CDN operated by 2055 the full CDN organization acting as a dCDN in the request routing 2056 control plane. Interfaces outside the scope of the CDNI work can be 2057 used between the CSP functional entities of the content provider 2058 organization and the CDN operated by the full CDN organization acting 2059 as a uCDN) in the CDNI control planes other than the request routing 2060 plane (i.e. Control, Distribution, Logging). 2062 ##################################### ################## 2063 # # # # 2064 # Organization A # # Organization B # 2065 # # # # 2066 # -------- ------------- # # ----------- # 2067 # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # 2068 # | | | +----+ | # # | +----+ | # 2069 # | |*****| | RR |==========CDNI=====>| RR | | # 2070 # | | | +----+ | # RR # | +----+ | # 2071 # | | \ / # # | | # 2072 # | | ------------- # # |uCDN(C,L,D)| # 2073 # | | # # | +----+ | # 2074 # | | # # | | C | | # 2075 # | |*******************************| +----+ | # 2076 # | | # # | +----+ | # 2077 # | | # # | | L | | # 2078 # | | # # | +----+ | # 2079 # | | # # | +----+ | # 2080 # | | # # | | D | | # 2081 # | | # # | +----+ | # 2082 # \ / # # \ / # 2083 # -------- # # ----------- # 2084 # # # # 2085 ##################################### ################## 2087 ===> CDNI Request Routing Interface 2088 **** interfaces outside the scope of CDNI 2090 Figure 13: CDNI Deployment Model: Organization combining CSP and 2091 partial CDN 2093 5.4. CDN Federations and CDN Exchanges 2094 There are two additional concepts related to, but distinct from CDN 2095 Interconnection. The first is CDN Federation. Our view is that CDNI 2096 is the more general concept, involving two or more CDNs serving 2097 content to each other's users, while federation implies a multi- 2098 lateral interconnection arrangement, but other CDN interconnection 2099 agreements are also possible (e.g., symmetric bilateral, asymmetric 2100 bilateral). An important conclusion is that CDNI technology should 2101 not presume (or bake in) a particular interconnection agreement, but 2102 should instead be general enough to permit alternative 2103 interconnection arrangements to evolve. 2105 The second concept often used in the context of CDN Federation is CDN 2106 Exchange-\u002Da third party broker or exchange that is used to 2107 facilitate a CDN federation. Our view is that a CDN exchange offers 2108 valuable machinery to scale the number of CDN operators involved in a 2109 multi-lateral (federated) agreement, but that this machinery is built 2110 on top of the core CDNI interconnection mechanisms. For example, as 2111 illustrated in Figure 14, the exchange might aggregate and 2112 redistribute information about each CDN footprint and capacity, as 2113 well as collect, filter, and redistribute traffic logs that each 2114 participant needs for interconnection settlement, but inter-CDN 2115 request routing, inter-CDN content distribution (including inter-CDN 2116 acquisition) and inter-CDN control which fundamentally involve a 2117 direct interaction between an upstream CDN and a downstream 2118 CDN-\u002Doperate exactly as in a pair-wise peering arrangement. 2119 Turning to Figure 14, we observe that in this example: 2121 o each CDN supports a direct CDNI Control interface to every other 2122 CDN 2124 o each CDN supports a direct CDNI Metadata interface to every other 2125 CDN 2127 o each CDN supports a CDNI Logging interface with the CDN Exchange 2129 o each CDN supports both a CDNI Request Routing interfaces with the 2130 CDN Exchange (for aggregation and redistribution of dynamic CDN 2131 footprint discovery information) and a direct RI to every other 2132 CDN (for actual request redirection). 2134 ---------- --------- 2135 / CDN A \ / CDN B \ 2136 | +----+ | | +----+ | 2137 //========>| C |<==============CDNI============>| C |<==========\\ 2138 || | +----+ | C | +----+ | || 2139 || | +----+ | | +----+ | || 2140 || //=====>| D |<==============CDNI============>| D |<=======\\ || 2141 || || | +----+ | M | +----+ | || || 2142 || || | | /------------\ | | || || 2143 || || | +----+ | | +--+ CDN Ex| | +----+ | || || 2144 || || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || || 2145 || || || | +----+ | RR | +--+ | RR | +----+ | || || || 2146 || || || | | | /\ | | | || || || 2147 || || || | +----+ | | || +---+ | | +----+ | || || || 2148 || || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || || 2149 || || || | +----+ | L | || +---+ | L | +----+ | || || || 2150 || || || \ / \ || /\ / \ / || || || 2151 || || || ----------- --||----||-- ----------- || || || 2152 || || || || || || || || 2153 || || || CDNI RR || || || || 2154 || || || || CDNI L || || || 2155 || || || || || || || || 2156 || || || ---||----||---- || || || 2157 || || || / \/ || \ || || || 2158 || || || | +----+ || | || || || 2159 || || \\=====CDNI==========>| RR |<=============CDNI========// || || 2160 || || RR | +----+ \/ | RR || || 2161 || || | +----+ | || || 2162 || || | | L | | || || 2163 || || | +----+ | || || 2164 || || | +----+ | || || 2165 || \\=======CDNI===========>| D |<=============CDNI===========// || 2166 || M | +----+ | M || 2167 || | +----+ | || 2168 \\==========CDNI===========>| C |<=============CDNI==============// 2169 C | +----+ | C 2170 \ CDN C / 2171 -------------- 2173 <=CDNI RR=> CDNI Request Routing Interface 2174 <=CDNI M==> CDNI Metadata Interface 2175 <=CDNI C==> CDNI Control Interface 2176 <=CDNI L==> CDNI Logging Interface 2178 Figure 14: CDNI Deployment Model: CDN Exchange 2180 Note that a CDN exchange may alternatively support a different set of 2181 functionality (e.g. Logging only, or Logging and full request 2182 routing, or all the functionality of a CDN including content 2183 distribution). All these options are expected to be allowed by the 2184 IETF CDNI specifications. 2186 6. Trust Model 2188 There are a number of trust issues that need to be addressed by a 2189 CDNI solution. Many of them are in fact similar or identical to 2190 those in a simple CDN without interconnection. In a standard CDN 2191 environment (without CDNI), the CSP places a degree of trust in a 2192 single CDN operator to perform many functions. The CDN is trusted to 2193 deliver content with appropriate quality of experience for the end 2194 user. The CSP trusts the CDN operator not to corrupt or modify the 2195 content. The CSP often relies on the CDN operator to provide 2196 reliable accounting information regarding the volume of delivered 2197 content. The CSP may also trust the CDN operator to perform actions 2198 such as timely invalidation of content and restriction of access to 2199 content based on certain criteria such as location of the user and 2200 time of day, and to enforce per-request authorization performed by 2201 the CSP using techniques such as URI signing. 2203 A CSP also places trust in the CDN not to distribute any information 2204 that is confidential to the CSP (e.g., how popular a given piece of 2205 content is) or confidential to the end user (e.g., which content has 2206 been watched by which user). 2208 A CSP does not necessarily have to place complete trust in a CDN. A 2209 CSP will in some cases take steps to protect its content from 2210 improper distribution by a CDN, e.g. by encrypting it and 2211 distributing keys in some out of band way. A CSP also depends on 2212 monitoring (possibly by third parties) and reporting to verify that 2213 the CDN has performed adequately. A CSP may use techniques such as 2214 client-based metering to verify that accounting information provided 2215 by the CDN is reliable. HTTP conditional requests may be used to 2216 provide the CSP with some checks on CDN operation. In other words, 2217 while a CSP may trust a CDN to perform some functions in the short 2218 term, the CSP is able in most cases to verify whether these actions 2219 have been performed correctly and to take action (such as moving the 2220 content to a different CDN) if the CDN does not live up to 2221 expectations. 2223 The main trust issue raised by CDNI is that it introduces transitive 2224 trust. A CDN that has a direct relationship with a CSP can now 2225 "outsource" the delivery of content to another (downstream) CDN. 2226 That CDN may in term outsource delivery to yet another downstream 2227 CDN, and so on. 2229 The top level CDN in such a chain of delegation is responsible for 2230 ensuring that the requirements of the CSP are met. Failure to do so 2231 is presumably just as serious as in the traditional single CDN case. 2232 Hence, an upstream CDN is essentially trusting a downstream CDN to 2233 perform functions on its behalf in just the same way as a CSP trusts 2234 a single CDN. Monitoring and reporting can similarly be used to 2235 verify that the downstream CDN has performed appropriately. However, 2236 the introduction of multiple CDNs in the path between CSP and end 2237 user complicates the picture. For example, third party monitoring of 2238 CDN performance (or other aspects of operation, such as timely 2239 invalidation) might be able to identify the fact that a problem 2240 occurred somewhere in the chain but not point to the particular CDN 2241 at fault. 2243 In summary, we assume that an upstream CDN will invest a certain 2244 amount of trust in a downstream CDN, but that it will verify that the 2245 downstream CDN is performing correctly, and take corrective action 2246 (including potentially breaking off its relationship with that CDN) 2247 if behavior is not correct. We do not expect that the trust 2248 relationship between a CSP and its "top level" CDN will differ 2249 significantly from that found today in single CDN situations. 2250 However, it does appear that more sophisticated tools and techniques 2251 for monitoring CDN performance and behavior will be required to 2252 enable the identification of the CDN at fault in a particular 2253 delivery chain. 2255 We expect that the detailed designs for the specific interfaces for 2256 CDNI will need to take the transitive trust issues into account. For 2257 example, explicit confirmation that some action (such as content 2258 removal) has taken place in a downstream CDN may help to mitigate 2259 some issues of transitive trust. 2261 7. IANA Considerations 2263 This memo includes no request to IANA. 2265 8. Security Considerations 2267 While there is a variety of security issues introduced by a single 2268 CDN, we are concerned here specifically with the additional issues 2269 that arise when CDNs are interconnected. For example, when a single 2270 CDN has the ability to distribute content on behalf of a CSP, there 2271 may be concerns that such content could be distributed to parties who 2272 are not authorized to receive it, and there are mechanisms to deal 2273 with such concerns. Our focus in this section is on how CDN 2274 interconnection introduces new security issues not found in the 2275 single CDN case. 2277 Many of the security issues that arise in CDNI are related to the 2278 transitivity of trust (or lack thereof) described in Section 6. As 2279 noted above, the design of the various interfaces for CDNI must take 2280 account of the additional risks posed by the fact that a CDN with 2281 whom a CSP has no direct relationship is now potentially distributing 2282 content for that CSP. The mechanisms used to mitigate these risks 2283 may be similar to those used in the single CDN case, but their 2284 suitability in this more complex environment must be validated. 2286 Another concern that arises in any CDN is that information about the 2287 behavior of users (what content they access, how much content they 2288 consume, etc.) may be gathered by the CDN. This risk certainly 2289 exists in inter-connected CDNs, but it should be possible to apply 2290 the same techniques to mitigate it as in the single CDN case. 2292 CDNs today offer a variety of means to control access to content, 2293 such as time-of-day restrictions, geo-blocking, and URI signing. 2294 These mechanisms must continue to function in CDNI environments, and 2295 this consideration is likely to affect the design of certain CDNI 2296 interfaces (e.g. metadata, request routing.) 2298 Just as with a single CDN, each peer CDN must ensure that it is not 2299 used as an "open proxy" to deliver content on behalf of a malicious 2300 CSP. Whereas a single CDN typically addresses this problem by having 2301 CSPs explicitly register content (or origin servers) that is to be 2302 served, simply propagating this information to peer downstream CDNs 2303 may be problematic because it reveals more information than the 2304 upstream CDN is willing to specify. (To this end, the content 2305 acquisition step in the earlier examples force the dCDN to retrieve 2306 content from the uCDN rather than go directly to the origin server.) 2308 There are several approaches to this problem. One is for the uCDN to 2309 encoded a signed token generated from a shared secret in each URL 2310 routed to a dCDN, and for the dCDN to validate the request based on 2311 this token. Another one is to have each upstream CDN advertise the 2312 set of CDN-Domains they serve, where the downstream CDN checks each 2313 request against this set before caching and delivering the associated 2314 object. Although straightforward, this approach requires operators 2315 to reveal additional information, which may or may not be an issue. 2317 8.1. Security of CDNI Interfaces 2319 It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces 2320 must be able to operate securely over insecure IP networks. Since it 2321 is expected that the CDNI interfaces will be implemented using 2322 existing application protocols such as HTTP or XMPP, we also expect 2323 that the security mechanisms available to those protocols may be used 2324 by the CDNI interfaces. Details of how these interfaces are secured 2325 will be specified in the relevant interface documents. 2327 8.2. Digital Rights Management 2329 Issues of digital rights management (DRM, also sometimes called 2330 digital restrictions management) is often employed for content 2331 distributed via CDNs. In general, DRM relies on the CDN to 2332 distribute encrypted content, with decryption keys distributed to 2333 users by some other means (e.g. directly from the CSP to the end 2334 user.) For this reason, DRM is considered out of scope for the CDNI 2335 WG RFC 6707 and does not introduce additional security issues for 2336 CDNI. 2338 9. Contributors 2340 The following individuals contributed to this document: 2342 o Ray van Brandenburg 2344 o Matt Caulfield 2346 o Francois le Faucheur 2348 o Aaron Falk 2350 o David Ferguson 2352 o John Hartman 2354 o Ben Niven-Jenkins 2356 o Kent Leung 2358 10. Acknowledgements 2360 We thank Huw Jones for helpful input to the draft. 2362 11. Informative References 2364 [I-D.bertrand-cdni-logging] 2365 Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F., 2366 and P. Grochocki, "CDNI Logging Interface", draft- 2367 bertrand-cdni-logging-02 (work in progress), October 2012. 2369 [I-D.ietf-appsawg-http-forwarded] 2370 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 2371 draft-ietf-appsawg-http-forwarded-10 (work in progress), 2372 October 2012. 2374 [I-D.ietf-cdni-metadata] 2375 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 2376 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 2377 ietf-cdni-metadata-02 (work in progress), July 2013. 2379 [I-D.ietf-cdni-requirements] 2380 Leung, K. and Y. Lee, "Content Distribution Network 2381 Interconnection (CDNI) Requirements", draft-ietf-cdni- 2382 requirements-10 (work in progress), September 2013. 2384 [I-D.lefaucheur-cdni-logging-delivery] 2385 Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI 2386 Logging Formats for HTTP and HTTP Adaptive Streaming 2387 Deliveries", draft-lefaucheur-cdni-logging-delivery-01 2388 (work in progress), July 2012. 2390 [I-D.murray-cdni-triggers] 2391 Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / 2392 Triggers", draft-murray-cdni-triggers-03 (work in 2393 progress), April 2013. 2395 [I-D.seedorf-alto-for-cdni] 2396 Seedorf, J., "ALTO for CDNi Request Routing", draft- 2397 seedorf-alto-for-cdni-00 (work in progress), October 2011. 2399 [I-D.spp-cdni-rr-foot-cap-semantics] 2400 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 2401 and K. Ma, "CDNI Request Routing: Footprint and 2402 Capabilities Semantics", draft-spp-cdni-rr-foot-cap- 2403 semantics-04 (work in progress), February 2013. 2405 [I-D.vandergaast-edns-client-subnet] 2406 Contavalli, C., Gaast, W., Leach, S., and E. Lewis, 2407 "Client Subnet in DNS Requests", draft-vandergaast-edns- 2408 client-subnet-02 (work in progress), July 2013. 2410 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 2411 for Content Internetworking (CDI)", RFC 3466, February 2412 2003. 2414 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2415 Optimization (ALTO) Problem Statement", RFC 5693, October 2416 2009. 2418 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2419 Distribution Network Interconnection (CDNI) Problem 2420 Statement", RFC 6707, September 2012. 2422 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 2423 K., and G. Watson, "Use Cases for Content Delivery Network 2424 Interconnection", RFC 6770, November 2012. 2426 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 2427 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 2428 Content Distribution Network Interconnection (CDNI)", RFC 2429 6983, July 2013. 2431 Authors' Addresses 2433 Larry Peterson (editor) 2434 Akamai Technologies, Inc. 2435 8 Cambridge Center 2436 Cambridge, MA 02142 2437 USA 2439 Email: lapeters@akamai.com 2441 Bruce Davie 2442 VMware, Inc. 2443 3401 Hillview Ave. 2444 Palo Alto, CA 94304 2445 USA 2447 Email: bdavie@vmware.com