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