idnits 2.17.1 draft-ietf-cdni-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 75 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 (April 27, 2012) is 4375 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bertrand-cdni-logging-00 == Outdated reference: A later version (-05) exists of draft-brandenburg-cdni-has-00 == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-04 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-02 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-04 == Outdated reference: A later version (-01) exists of draft-lefaucheur-cdni-logging-delivery-00 == Outdated reference: A later version (-03) exists of draft-ma-cdni-metadata-02 == Outdated reference: A later version (-03) exists of draft-murray-cdni-triggers-00 == Outdated reference: A later version (-02) exists of draft-previdi-cdni-footprint-advertisement-01 == 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 (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Peterson, Ed. 3 Internet-Draft Verivue, Inc. 4 Intended status: Informational B. Davie 5 Expires: October 29, 2012 Nicira Networks, Inc. 6 April 27, 2012 8 Framework for CDN Interconnection 9 draft-ietf-cdni-framework-00 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 metadata exchange, and the acquisition of content by one CDN from 20 another. 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. 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 October 29, 2012. 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 . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 10 68 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13 69 3.2. HTTP Redirect Example . . . . . . . . . . . . . . . . . . 14 70 3.2.1. Comments on the example . . . . . . . . . . . . . . . 18 71 3.3. Recursive Redirection Example . . . . . . . . . . . . . . 19 72 3.3.1. Comments on the example . . . . . . . . . . . . . . . 23 73 3.4. DNS-based redirection example . . . . . . . . . . . . . . 23 74 3.4.1. Comments on the example . . . . . . . . . . . . . . . 26 75 3.5. Dynamic Footprint Discovery . . . . . . . . . . . . . . . 27 76 3.6. Content Removal . . . . . . . . . . . . . . . . . . . . . 29 77 3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29 78 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31 79 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33 80 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 36 81 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 36 82 4.2. Request Routing Interface . . . . . . . . . . . . . . . . 37 83 4.3. Logging Interface . . . . . . . . . . . . . . . . . . . . 38 84 4.4. Control Interface . . . . . . . . . . . . . . . . . . . . 40 85 4.5. Metadata Interface . . . . . . . . . . . . . . . . . . . . 41 86 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 42 87 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 88 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 89 5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 44 90 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45 91 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 48 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 94 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 50 95 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 51 96 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 98 11. Informative References . . . . . . . . . . . . . . . . . . . . 51 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 101 1. Introduction 103 The interconnection of Content Distribution Networks (CDNs) is 104 motivated by several use cases, such as those described in 105 [I-D.ietf-cdni-use-cases]. The overall problem space for CDN 106 Interconnection is described in [I-D.ietf-cdni-problem-statement]. 107 The purpose of this document is to provide an overview of the various 108 components necessary to interconnect CDNs. CDN Interconnection 109 requires the specification of several interfaces and mechanisms to 110 address issues such as request routing, metadata exchange, and the 111 acquisition of content by one CDN from another. The intent of this 112 document is to describe how these interfaces and mechanisms fit 113 together, leaving their detailed specification to other documents. 114 We make extensive use of message flow examples to illustrate the 115 operation of interconnected CDNs, but these examples should be 116 considered illustrative rather than prescriptive. 118 1.1. Terminology 120 This document draws freely on the terminology defined in [RFC3466] 121 and [I-D.ietf-cdni-problem-statement]. 123 We also introduce the following terms: 125 CDN Domain: a host name (FQDN) at the beginning of a URL, 126 representing a set of content that is served by a given CDN. For 127 example, in the URL http://cdn.csp.com/...rest of url..., the CDN 128 domain is cdn.csp.com. 130 Distinguished CDN Domain: a CDN domain that is allocated by a CDN for 131 the purposes of communication with a peer CDN, but which is not found 132 in client requests. Such CDN domains may be used for inter-CDN 133 acquisition, or as redirection targets, and enable a CDN to 134 distinguish a request from a peer CDN from an end-user request. 136 Recursive CDNI request routing: When an Upstream CDN elects to 137 redirect a request towards a Downstream CDN, the Upstream CDN can 138 query the Downstream CDN Request Routing system via the CDNI Request 139 Routing interface (or use information cached from earlier similar 140 queries) to find out how the Downstream CDN wants the request to be 141 redirected, which allows the Upstream CDN to factor in the Downstream 142 CDN response when redirecting the user agent. This approach is 143 referred to as "recursive" CDNI request routing. Note that the 144 Downstream CDN may elect to have the request redirected directly to a 145 Surrogate inside the Downstream CDN, to the Request-Routing System of 146 the Downstream CDN, to another CDN, or to any other system that the 147 Downstream CDN sees as fit for handling the redirected request. 149 Iterative CDNI Request Routing: When an Upstream CDN elects to 150 redirect a request towards a Downstream CDN, the Upstream CDN can 151 base its redirection purely on a local decision (and without 152 attempting to take into account how the Downstream CDN may in turn 153 redirect the user agent). In that case, the Upstream CDN redirects 154 the request to the request routing system in the Downstream CDN, 155 which in turn will decide how to redirect that request: this approach 156 is referred to as "iterative" CDNI request routing. 158 Synchronous CDNI operations: operations between CDNs that happen 159 during the process of servicing a user request, i.e. between the time 160 that the user agent begins its attempt to obtain content and the time 161 at which that request is served. 163 Asynchronous CDNI operations: operations between CDNs that happen 164 independently of any given user request, such as advertisement of 165 footprint information or pre-positioning of content for later 166 delivery. 168 Trigger Interface: a sub-set of the Control Interface that includes 169 operations to pre-position, revalidate, and purge both metadata and 170 content. These operations are typically called in response to some 171 action (trigger) by the CSP on the upstream CDN. 173 1.2. Reference Model 175 This document uses the reference model in Figure 1 as originally 176 created in [I-D.ietf-cdni-problem-statement]. 178 -------- 179 / \ 180 | CSP | 181 \ / 182 -------- 183 * 184 * 185 * /\ 186 * / \ 187 ---------------------- |CDNI| ---------------------- 188 / Upstream CDN \ | | / Downstream CDN \ 189 | +-------------+ | Control Interface| +-------------+ | 190 |******* Control |<======|====|========>| Control *******| 191 |* +------*----*-+ | | | | +-*----*------+ *| 192 |* * * | | | | * * *| 193 |* +------*------+ | Logging Interface| +------*------+ *| 194 |* ***** Logging |<======|====|========>| Logging ***** *| 195 |* * +-*-----------+ | | | | +-----------*-+ * *| 196 |* * * * | Request Routing | * * * *| 197 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 198 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 199 . |* * * +-------------+.| | | | +-------------+ * * *| . 200 . |* * * . CDNI Metadata | * * *| . 201 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 202 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 203 . |* * * | | | . \ / | | | * * *| . 204 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 205 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 206 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 207 . |******* +---------+| | Acquisition | |+----------+ *******| . 208 . | +-------------+ | | +-------*-----+ | . 209 . \ / \ * / . 210 . ---------------------- ---------*------------ . 211 . * . 212 . * Delivery . 213 . * . 214 . +--*---+ . 215 ...............Request.............................| User |..Request.. 216 | Agent| 217 +------+ 219 <==> interfaces inside the scope of CDNI 221 **** interfaces outside the scope of CDNI 222 .... interfaces outside the scope of CDNI 224 Figure 1: CDNI Model and CDNI Interfaces 226 We note that while some interfaces in the reference model are "out of 227 scope" for the CDNI WG (in the sense that there is no need to define 228 new protocols for those interfaces) we still need to refer to them in 229 this document to explain the overall operation of CDNI. 231 We also note that, while we generally show only one uCDN serving a 232 given CSP, it is entirely possible that multiple uCDNs can serve a 233 single CSP. In fact, this situation effectively exists today in the 234 sense that a single CSP can currently connect to more than one CDN. 236 Definitions of the four CDNI interfaces follow. More discussion of 237 these interfaces appears in Section 4. 239 o Control Interface: Operations to discover, initialize, and 240 parameterize the other CDNI interfaces, as well as operations to 241 pre-position, revalidate, and purge both metadata and content. 242 The latter sub-set of operations is sometimes collectively called 243 the "trigger interface." 245 o Request Routing Interface: Operations to determine what CDN (and 246 optionally what surrogate within a CDN) is to serve end-user's 247 requests. May include a combination of: 249 * Asynchronous operations to exchange routing information (e.g., 250 the network footprint served by a given CDN) that enables CDN 251 selection for subsequent user requests; and 253 * Synchronous operations to select a delivery CDN (surrogate) for 254 a given user request. 256 o Metadata Interface: Operations to communicate metadata that 257 governs the how content is delivered by interconnected CDNs. 258 Examples of CDNI metadata include geo-blocking directives, 259 availability windows, access control mechanisms, and purge 260 directives. May include a combination of: 262 * Asynchronous operations to exchange metadata that govern 263 subsequent user requests for content; and 265 * Synchronous operations that govern behavior for a given user 266 request for content. 268 o Logging Interface: Operations that allow interconnected CDNs to 269 exchange relevant activity logs. May include a combination of: 271 * Real-time exchanges, suitable for runtime traffic monitoring; 272 and 274 * Off-line exchanges, suitable for analytics and billing. 276 There is some ambiguity as to the line between the set of trigger- 277 based operations in the Control interface and the Metadata interface. 278 For both cases, the information passed from the upstream CDN to the 279 downstream CDN can broadly be viewed as metadata that describes how 280 content is to be managed by the downstream CDN. For example, the 281 information conveyed by Control operations to pre-position, 282 revalidate or purge metadata is similar to the information conveyed 283 by posting updated metadata via the Metadata interface? Even the 284 Control operation to purge content could be viewed as an metadata 285 update for that content: purge simply says that the availability 286 window for the named content ends now. The two interfaces share much 287 in common, so minimally, there will need to be a consistent data 288 model that spans both. 290 The distinction we draw has to do with what the caller knows the 291 metadata being applied to content delivery by the callee. In the 292 case of the Control interface, the downstream CDN returning a 293 successful status message guarantees that the operation has been 294 successfully completed; e.g., the content has been purged or pre- 295 positioned. This implies that the downstream CDN accepts 296 responsibility for having successfully completed the requested 297 operation. In contrast, metadata passed between CDNs via the 298 Metadata interface carries no such completion guarantee. Returning 299 success implies successful receipt of the metadata, but nothing can 300 be inferred about precisely when the metadata will take effect in the 301 downstream CDN, only that it will take effect eventually. This is 302 because of the challenge in globally synchronizing updates to 303 metadata with end-user requests that are currently in progress (or 304 indistinguishable from currently being in progress). Clearly, a CDN 305 will not be viewed as a trusted peer if "eventually" often becomes an 306 indefinite period of time, but the acceptance of responsibility 307 cannot be as crisp for the Metadata interface. 309 1.3. Structure Of This Document 311 The remainder of this document is organized as follows: 313 o Section 2 describes some essential building blocks for CDNI, 314 notably the various options for redirecting user requests to a 315 given CDN. 317 o Section 3 provides a number of illustrative examples of various 318 CDNI operations. 320 o Section 4 describes the functionality of the four main CDNI 321 interfaces. 323 o Section 5 shows how various deployment models of CDNI may be 324 achieved using the defined interfaces. 326 o Section 6 describes the trust model of CDNI and the issues of 327 transitive trust in particular that CDNI raises. 329 2. Building Blocks 331 2.1. Request Redirection 333 At its core, CDN Interconnection requires the redirection of requests 334 from one CDN to another. For any given request that is received by 335 an upstream CDN, it will either respond to the request directly, or 336 somehow redirect the request to a downstream CDN. Two main 337 mechanisms are available for redirecting a request to a downstream 338 CDN. The first leverages the DNS name resolution process and the 339 second uses in-protocol redirection mechanisms such as the HTTP 302 340 redirection response. We discuss these below as background before 341 discussing some examples of their use in Section 3. 343 2.1.1. DNS Redirection 345 DNS redirection is based on returning different IP addresses for the 346 same DNS name, for example, to balance server load or to account for 347 the client's location in the network. A DNS server, sometimes called 348 the Local DNS (LDNS), resolves DNS names on behalf of an end-user. 349 The LDNS server in turn queries other DNS servers until it reaches 350 the authoritative DNS server for the CDN-domain. The network 351 operator typically provides the LDNS server, although the user is 352 free to choose other DNS servers (e.g., OpenDNS, Google Public DNS). 354 The advantage of DNS redirection is that it is completely transparent 355 to the end user--the user sends a DNS name to the LDNS server and 356 gets back an IP address. On the other hand, DNS redirection is 357 problematic because the DNS request comes from the LDNS server, not 358 the end-user. This may affect the accuracy of server selection that 359 is based on the user's location. The transparency of DNS redirection 360 is also a problem in that there is no opportunity to modify the path 361 component of the URL being accessed by the client. We consider two 362 main forms of DNS redirection: simple and CNAME-based. 364 In simple DNS redirection, the authoritative DNS server for the name 365 simply returns an IP address from a set of possible IP addresses. 366 The answer is chosen from the set based on characteristics of the set 367 (e.g., the relative loads on the servers) or characteristics of the 368 client (e.g., the location of the client relative to the servers). 369 Simple redirection is straightforward. The only caveats are (1) 370 there is a limit to the number of delivery nodes a single DNS server 371 can manage; and (2) DNS responses are cached by downstream servers so 372 the TTL on the response must be set to an appropriate value so as to 373 preserve the timeliness of the redirection. 375 In CNAME-based DNS redirection, the authoritative server returns a 376 CNAME response to the DNS request, telling the LDNS server to restart 377 the name lookup using a new name. A CNAME is essentially a symbolic 378 link in the DNS namespace, and like a symbolic link, redirection is 379 transparent to the client--the LDNS server gets the CNAME response 380 and re-executes the lookup. Only when the name has been resolved to 381 an IP address does it return the result to the user. Note that DNAME 382 would be preferable to CNAME if it becomes widely supported. 384 2.1.2. HTTP Redirection 386 HTTP redirection makes use of the "302" redirection response of the 387 HTTP protocol. This response contains a new URL that the application 388 should fetch instead of the original URL. By changing the URL 389 appropriately, the server can cause the user to redirect to a 390 different server. The advantages of 302 redirection are that (1) the 391 server can change the URL fetched by the client to include, for 392 example, both the DNS name of the particular server to use, as well 393 as the original HTTP server that was being accessed; and (2) the 394 client sends the HTTP request to the server, so that its IP address 395 is known and can be used in selecting the server. 397 The disadvantages of HTTP redirection are (1) it is visible to the 398 application, so it requires application support and may affect the 399 application behavior (e.g., web browsers will not send cookies if the 400 URL changes to a different domain); (2) HTTP is a heavy-weight 401 protocol layered on TCP so it has relatively high overhead; and (3) 402 the results of HTTP redirection are not cached so that all 403 redirections must go through to the server. 405 3. Overview of CDNI Operation 407 To provide a big-picture overview of the various components of CDN 408 Interconnection, we walk through a "day in the life" of a content 409 item that is made available via a pair of interconnected CDNs. This 410 will serve to illustrate many of the functions that need to be 411 supported in a complete CDNI solution. We give examples using both 412 DNS-based and HTTP-based redirection. We begin with very simple 413 examples and then how additional capabilities, such as recursive 414 request redirection and content removal, might be added. 416 Before walking through some specific examples, we present a high- 417 level view of the operations that may take place. This high-level 418 overview is illustrated in Figure 2. Note that most operations will 419 involve only a subset of all the messages shown below, and that the 420 order and number of operations may vary considerably, as more 421 detailed examples illustrate below. 423 The following shows Operator A as the upstream CDN (uCDN) and 424 Operator B as the downstream CDN (dCDN), where the former has a 425 relationship with a content provider and the latter being the best 426 CDN to deliver content to the end-user. The interconnection 427 relationship may be symmetric between these two CDN operators, but 428 for simplicity we show the interaction in one direction only. 430 End-User Operator B Operator A 431 | | | 432 | | | 433 | | [Async Metadata Push] | (1) 434 | | | 435 | | [Async RRI Push] | (2) 436 | | | 437 | CONTENT REQUEST | | 438 |-------------------------------------------------->| (3) 439 | | | 440 | | [Sync RRI Pull] | (4) 441 | | | 442 | CONTENT REDIRECTION | | 443 |<--------------------------------------------------| (5) 444 | | | 445 | | | 446 | CONTENT REQUEST | | 447 |------------------------>| | (6) 448 | | | 449 | | [Sync Metadata Pull] | (7) 450 | | | 451 | | ACQUISITION REQUEST | 452 | X------------------------>| (8) 453 | X | 454 | X CONTENT DATA | 455 | X<------------------------| (9) 456 | | | 457 | CONTENT DATA | | 458 |<------------------------| | (10) 459 | | | 460 : : : 461 : [Other content requests ] : 462 : : : 463 | | [Content Purge] | (11) 464 : : : 465 | | [Logging exchange] | (12) 466 | | | 468 Figure 2: Overview of Operation 470 The operations shown in the Figure are as follows: 472 1. Prior to any content request, metadata may be asynchronously 473 pushed from uCDN to dCDN so that it is available in readiness 474 for later content requests. 476 2. dCDN may advertise information relevant to its delivery 477 capabilities (e.g. geographic footprint, reachable address 478 prefixes) prior to any content requests being redirected. 480 3. A content request from a user agent arrives at uCDN. 482 4. uCDN may synchronously request information from dCDN regarding 483 its delivery capabilities to decide if dCDN is a suitable target 484 for redirection of this request. 486 5. uCDN redirects the request to dCDN by sending some response 487 (DNS, HTTP) to the user agent. 489 6. The user agent requests the content from dCDN. 491 7. dCDN may synchronously request metadata related to this content 492 from uCDN, e.g. to decide whether to serve it. 494 8. If the content is not already in a suitable cache in dCDN, dCDN 495 may acquire it from uCDN. 497 9. The content is delivered to dCDN from uCDN. 499 10. The content is delivered to the user agent by dCDN. 501 11. Some time later, perhaps at the request of the CSP (not shown) 502 uCDN may instruct dCDN to purge the content to ensure it is not 503 delivered again. 505 12. After one or more content delivery actions by dCDN, a log of 506 delivery actions may be provided to uCDN. 508 The following sections show some more specific examples of how these 509 operations may be combined to perform various delivery, control and 510 logging operations across a pair of CDNs. 512 3.1. Preliminaries 514 Initially, we assume that there is at least one CSP that has 515 contracted with an upstream CDN (uCDN) to deliver content on its 516 behalf. We are not particularly concerned with the interface between 517 the CSP and uCDN, other than to note that it is expected to be the 518 same as in the "traditional" (non-interconnected) CDN case. Existing 519 mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be 520 used to direct a user request for a piece of content from the CSP 521 towards the CSP's chosen upstream CDN. 523 We use the term "CDN-domain" to refer to the host name (a FQDN) at 524 the beginning of each URL. We assume Operator A provides an upstream 525 CDN that serves content on behalf of a CSP with CDN-domain 526 cdn.csp.com. We assume that Operator B provides a downstream CDN. 527 An end user at some point makes a request for URL 529 http://cdn.csp.com/...rest of url... 531 It may well be the case that cdn.csp.com is just a CNAME for some 532 other CDN-domain (such as csp.op-a.net). Nevertheless, the HTTP 533 request in the examples that follow is assumed to be for the example 534 URL above. 536 Our goal is to enable content identified by the above URL to be 537 served by the CDN of operator B. In the following sections we will 538 walk through some scenarios in which content is served, as well as 539 other CDNI operations such as the removal of content from a 540 downstream CDN. 542 3.2. HTTP Redirect Example 544 In this section we walk through a simple, illustrative example using 545 HTTP redirection from uCDN to dCDN. The example also assumes the use 546 of HTTP redirection inside uCDN and dCDN; however, this is 547 independent of the choice of redirection approach across CDNs, so an 548 alternative example could be constructed still showing HTTP 549 redirection from uCDN to dCDN but using DNS for handling of request 550 inside each CDN. 552 We assume for this example that Operators A and B have established an 553 agreement to interconnect their CDNs, with A being upstream and B 554 being downstream. (It is likely that the agreement would be made in 555 both directions, but we focus on just one here for clarity.) 557 The operators agree that a CDN-domain peer-a.op-b.net will be used as 558 the target of redirections from uCDN to dCDN. The name of this 559 domain must be communicated by some means to each CDN. (This could 560 be established out-of-band or via a CDNI interface.) We refer to 561 this domain as a "distinguished" CDN domain to convey the fact that 562 its use is limited to the interconnection mechanism; such a domain is 563 never embedded in URLs that end-users request. 565 The operators must also agree on some distinguished CDN-domain that 566 will be used for inter-CDN acquisition of CSP's content from uCDN by 567 dCDN. In this example, we'll use op-b-acq.op-a.net. 569 The operators must also exchange information regarding which requests 570 dCDN is prepared to serve. For example, dCDN may be prepared to 571 serve requests from clients in a given geographical region or a set 572 of IP address prefixes. This information may again be provided out 573 of band or via a defined interface. 575 DNS must be configured in the following way: 577 o The content provider must be configured to make operator A the 578 authoritative DNS server for cdn.csp.com (or to return a CNAME for 579 cdn.csp.com for which operator A is the authoritative DNS server). 581 o Operator A must be configured so that a DNS request for op-b- 582 acq.op-a.net returns a request router in Operator A. 584 o Operator B must be configured so that a DNS request for peer-a.op- 585 b.net/cdn.csp.com returns a request router in Operator B. 587 Figure 3 illustrates how a client request for 589 http://cdn.csp.com/...rest of url... 591 is handled. 593 End-User Operator B Operator A 594 |DNS cdn.csp.com | | 595 |-------------------------------------------------->| 596 | | |(1) 597 |IPaddr of A's Request Router | 598 |<--------------------------------------------------| 599 |HTTP cdn.csp.com | | 600 |-------------------------------------------------->| 601 | | |(2) 602 |302 peer-a.op-b.net/cdn.csp.com | 603 |<--------------------------------------------------| 604 |DNS peer-a.op-b.net | | 605 |------------------------>| | 606 | |(3) | 607 |IPaddr of B's Request Router | 608 |<------------------------| | 609 | | | 610 |HTTP peer-a.op-b.net/cdn.csp.com | 611 |------------------------>| | 612 | |(4) | 613 |302 node1.peer-a.op-b.net/cdn.csp.com | 614 |<------------------------| | 615 |DNS node1.peer-a.op-b.net| | 616 |------------------------>| | 617 | |(5) | 618 |IPaddr of B's Delivery Node | 619 |<------------------------| | 620 | | | 621 |HTTP node1.peer-a.op-b.net/cdn.csp.com | 622 |------------------------>| | 623 | |(6) | 624 | |DNS op-b-acq.op-a.net | 625 | |------------------------>| 626 | | |(7) 627 | |IPaddr of A's Request Router 628 | |<------------------------| 629 | |HTTP op-b-acq.op-a.net | 630 | |------------------------>| 631 | | |(8) 632 | |302 node2.op-b.acq.op-A.net 633 | |<------------------------| 634 | |DNS node2.op-b-acq.op-a.net 635 | |------------------------>| 636 | | |(9) 637 | |IPaddr of A's Delivery Node 638 | |<------------------------| 639 | | |(10) 640 | |Data | 641 | |<------------------------| 642 |Data | | 643 |<------------------------| | 645 Figure 3: Request Trace for HTTP redirection method 647 The steps illustrated in the figure are as follows: 649 1. A DNS resolver for Operator A processes the DNS request for its 650 customer based on CDN-domain cdn.csp.com. It returns the IP 651 address of a request router in Operator A. 653 2. A Request Router for Operator A processes the HTTP request and 654 recognizes that the end-user is best served by another CDN-- 655 specifically one provided by Operator B--and so it returns a 302 656 redirect message for a new URL constructed by "stacking" 657 Operator B's distinguished CDN-domain (peer-a.op-b.net) on the 658 front of the original URL. (Note that more complex URL 659 manipulations are possible, such as replacing the initial CDN- 660 domain by some opaque handle.) 662 3. The end-user does a DNS lookup using Operator B's distinguished 663 CDN-domain (peer-a.op-b.net). B's DNS resolver returns the IP 664 address of a request router for Operator B. Note that if request 665 routing within dCDN was performed using DNS instead of HTTP 666 redirection, B's DNS resolver would also behave as the request 667 router and directly return the IP address of a delivery node. 669 4. The request router for Operator B processes the HTTP request and 670 selects a suitable delivery node to serve the end-user request, 671 and returns a 302 redirect message for a new URL constructed by 672 replacing the hostname by a subdomain of the Operator B's 673 distinguished CDN-domain that points to the selected delivery 674 node. 676 5. The end-user does a DNS lookup using Operator B's delivery node 677 subdomain (node1.peer-a.op-b.net). B's DNS resolver returns the 678 IP address of the delivery node. 680 6. The end-user requests the content from B's delivery node. In 681 the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not 682 happen, and the content data is directly returned by the 683 delivery node to the end-user. In the case of a cache miss, the 684 content needs to be acquired by dCDN from uCDN (not the CSP). 685 The distinguished CDN-domain peer-a.op-b.net indicates to dCDN 686 that this content is to be acquired from uCDN; stripping the 687 CDN-domain reveals the original CDN-domain cdn.csp.com and dCDN 688 may verify that this CDN-domain belongs to a known peer (so as 689 to avoid being tricked into serving as an open proxy). It then 690 does a DNS request for an inter-CDN acquisition CDN-domain as 691 agreed above (in this case, op-b-acq.op-a.net). 693 7. Operator A's DNS resolver processes the DNS request and returns 694 the IP address of a request router in operator A. 696 8. The request router for Operator A processes the HTTP request 697 from Operator B delivery node. Operator A request router 698 recognizes that the request is from a peer CDN rather than an 699 end-user because of the dedicated inter-CDN acquisition domain 700 (op-b-acq.op-a.net). (Note that without this specially defined 701 inter-CDN acquisition domain, operator A would be at risk of 702 redirecting the request back to operator B, resulting in an 703 infinite loop). The request router for Operator A selects a 704 suitable delivery node in uCDN to serve the inter-CDN 705 acquisition request and returns a 302 redirect message for a new 706 URL constructed by replacing the hostname by a subdomain of the 707 Operator A's distinguished inter-CDN acquisition domain that 708 points to the selected delivery node. 710 9. Operator A DNS resolver processes the DNS request and returns 711 the IP address of the delivery node in operator A. 713 10. Operator A serves content for the requested CDN-domain to dCDN. 714 Although not shown, it is at this point that Operator A 715 processes the rest of the URL: it extracts information 716 identifying the origin server, validates that this server has 717 been registered, and determines the content provider that owns 718 the origin server. It may also perform its own content 719 acquisition steps if needed before returning the content to 720 dCDN. 722 3.2.1. Comments on the example 724 The main advantage of this design is that it is simple: each CDN need 725 only know the distinguished CDN-domain for each peer, with the 726 upstream CDN "pushing" the downstream CDN-domain onto the URL as part 727 of its redirect (step 2) and the downstream CDN "popping" its CDN- 728 domain off the URL to expose a CDN-domain that the upstream CDN can 729 correctly process. Neither CDN needs to be aware of the internal 730 structure of the other's URLs. Moreover, the inter-CDN redirection 731 is entirely supported by a single HTTP redirect; neither CDN needs to 732 be aware of the other's internal redirection mechanism (i.e., whether 733 it is DNS or HTTP based). 735 One disadvantage is that the end-user's browser is redirected to a 736 new URL that is not in the same domain of the original URL. This has 737 implications on a number of security or validation mechanisms 738 sometimes used on endpoints. For example, it is important that any 739 redirected URL be in the same domain (e.g., csp.com) if the browser 740 is expected to send any cookies associated with that domain. As 741 another example, some video players enforce validation of a cross 742 domain policy that needs to allow for the domains involved in the CDN 743 redirection. These problems are generally soluble, but the solutions 744 complicate the example, so we do not discuss them further in this 745 version of the draft. 747 We note that this example begins to illustrate some of the interfaces 748 that may be required for CDNI, but does not require all of them. For 749 example, obtaining information from dCDN regarding the set of client 750 IP addresses or geographic regions it might be able to serve is an 751 aspect of the request routing interface. Important configuration 752 information such as the distinguished names used for redirection and 753 inter-CDN acquisition could also be conveyed via a CDNI interface 754 (e.g., perhaps the control interface). The example also shows how 755 existing HTTP-based methods suffice for the acquisition interface. 756 Arguably, the absolute minimum metadata required for CDNI is the 757 information required to acquire the content, and this information was 758 provided "in-band" in this example by means of the URI handed to the 759 client in the HTTP 302 response. Hence, there is no explicit 760 metadata interface invoked in this example. There is also no 761 explicit logging interface discussed in this example. 763 We also note that the step of deciding when a request should be 764 redirected to dCDN rather than served by uCDN has been somewhat 765 glossed over. It may be as simple as checking the client IP address 766 against a list of prefixes, or it may be considerably more complex, 767 involving a wide range of factors, such as the geographic location of 768 the client (perhaps determined from a third party service), CDN load, 769 or specific business rules. 771 This example uses the "iterative" CDNI request routing approach. 772 That is, uCDN performs part of the request routing function to 773 determine that dCDN should serve the request, and then redirects the 774 client to a request router in dCDN to perform the rest of the request 775 routing function. If request routing is performed in the dCDN using 776 HTTP redirection, this translates in the end-user experiencing two 777 successive HTTP redirections. By contrast, the alternative approach 778 of "recursive" CDNI request routing effectively coalesces these two 779 successive HTTP redirections into a single one, sending the end-user 780 directly to the right delivery node in the dCDN. This "recursive" 781 CDNI request routing approach is discussed in the next section. 783 3.3. Recursive Redirection Example 785 The following example builds on the previous one to illustrate the 786 use of the Request Routing interface to enable "recursive" CDNI 787 request routing. We build on the HTTP-based redirection approach 788 because it illustrates the principles and benefits clearly, but it is 789 equally possible to perform recursive redirection when DNS-based 790 redirection is employed. 792 In contrast to the prior example, the operators need not agree in 793 advance on a CDN-domain to serve as the target of redirections from 794 uCDN to dCDN. The operators still must agree on some distinguished 795 CDN-domain that will be used for inter-CDN acquisition of CSP's 796 content by dCDN. In this example, we'll use op-b-acq.op-a.net. 798 The operators must also exchange information regarding which requests 799 dCDN is prepared to serve. For example, dCDN may be prepared to 800 serve requests from clients in a given geographical region or a set 801 of IP address prefixes. This information may again be provided out 802 of band or via a defined protocol. 804 DNS must be configured in the following way: 806 o The content provider must be configured to make operator A the 807 authoritative DNS server for cdn.csp.com (or to return a CNAME for 808 cdn.csp.com for which operator A is the authoritative DNS server). 810 o Operator A must be configured so that a DNS request for op-b- 811 acq.op-a.net returns a request router in Operator A. 813 o Operator B must be configured so that a request for node1.op- 814 b.net/cdn.csp.com returns the IP address of a delivery node. Note 815 that there might be a number of such delivery nodes. 817 Figure 3 illustrates how a client request for 819 http://cdn.csp.com/...rest of url... 821 is handled. 823 End-User Operator B Operator A 824 |DNS cdn.csp.com | | 825 |-------------------------------------------------->| 826 | | |(1) 827 |IPaddr of A's Request Router | 828 |<--------------------------------------------------| 829 |HTTP cdn.csp.com | | 830 |-------------------------------------------------->| 831 | | |(2) 832 | |RRI REQ cdn.csp.com | 833 | |<------------------------| 834 | | | 835 | |RRI RESP node1.op-b.net | 836 | |------------------------>| 837 | | |(3) 838 |302 node1.op-b.net/cdn.csp.com | 839 |<--------------------------------------------------| 840 |DNS mode1.op-b.net | | 841 |------------------------>| | 842 | |(4) | 843 |IPaddr of B's Delivery Node | 844 |<------------------------| | 845 |HTTP node1.op-b.net/cdn.csp.com | 846 |------------------------>| | 847 | |(5) | 848 | |DNS op-b-acq.op-a.net | 849 | |------------------------>| 850 | | |(6) 851 | |IPaddr of A's Request Router 852 | |<------------------------| 853 | |HTTP op-b-acq.op-a.net | 854 | |------------------------>| 855 | | |(7) 856 | |302 node2.op-b.acq.op-A.net 857 | |<------------------------| 858 | |DNS node2.op-b-acq.op-a.net 859 | |------------------------>| 860 | | |(8) 861 | |IPaddr of A's Delivery Node 862 | |<------------------------| 863 | | |(9) 864 | |Data | 865 | |<------------------------| 866 |Data | | 867 |<------------------------| | 869 Figure 4: Request Trace for Recursive HTTP redirection method 871 The steps illustrated in the figure are as follows: 873 1. A DNS resolver for Operator A processes the DNS request for its 874 customer based on CDN-domain cdn.csp.com. It returns the IP 875 address of a Request Router in Operator A. 877 2. A Request Router for Operator A processes the HTTP request and 878 recognizes that the end-user is best served by another CDN-- 879 specifically one provided by Operator B--and so it queries the 880 CDNI Request Routing interface of Operator B, providing a set of 881 information about the request including the URL requested. 882 Operator B replies with the DNS name of a delivery node. 884 3. Operator A returns a 302 redirect message for a new URL obtained 885 from the Request Routing Interface. 887 4. The end-user does a DNS lookup using the host name of the URL 888 just provided (node1.op-b.net). B's DNS resolver returns the IP 889 address of the corresponding delivery node. Note that, since the 890 name of the delivery node was already obtained from B using the 891 CDNI Request Routing Interface, there should not be any further 892 redirection here (in contrast to the iterative method described 893 above.) 895 5. The end-user requests the content from B's delivery node, 896 potentially resulting in a cache miss. In the case of a cache 897 miss, the content needs to be acquired from uCDN (not the CSP.) 898 The distinguished CDN-domain op-b.net indicates to dCDN that this 899 content is to be acquired from another CDN; stripping the CDN- 900 domain reveals the original CDN-domain cdn.csp.com, dCDN may 901 verify that this CDN-domain belongs to a known peer (so as to 902 avoid being tricked into serving as an open proxy). It then does 903 a DNS request for the inter-CDN Acquisition "distinguished" CDN- 904 domain as agreed above (in this case, op-b-acq.op-a.net). 906 6. Operator A DNS resolver processes the DNS request and returns the 907 IP address of a request router in operator A. 909 7. The request router for Operator A processes the HTTP request from 910 Operator B delivery node. Operator A request router recognizes 911 that the request is from a peer CDN rather than an end-user 912 because of the dedicated inter-CDN acquisition domain (op-b- 913 acq.op-a.net). (Note that without this specially defined inter- 914 CDN acquisition domain, operator A would be at risk of 915 redirecting the request back to operator B, resulting in an 916 infinite loop). The request router for Operator A selects a 917 suitable delivery node in uCDN to serve the inter-CDN acquisition 918 request and returns a 302 redirect message for a new URL 919 constructed by replacing the hostname by a subdomain of the 920 Operator A's distinguished inter-CDN acquisition domain that 921 points to the selected delivery node. 923 8. Operator A recognizes that the DNS request is from a peer CDN 924 rather than an end-user (due to the internal CDN-domain) and so 925 returns the address of a delivery node. (Note that without this 926 specially defined internal domain, Operator A would be at risk of 927 redirecting the request back to Operator B, resulting in an 928 infinite loop.) 930 9. Operator A serves content for the requested CDN-domain to dCDN. 931 Although not shown, it is at this point that Operator A processes 932 the rest of the URL: it extracts information identifying the 933 origin server, validates that this server has been registered, 934 and determines the content provider that owns the origin server. 935 It may also perform its own content acquisition steps if needed 936 before returning the content to dCDN. 938 3.3.1. Comments on the example 940 Recursive redirection has the advantage over iterative of being more 941 transparent from the end-user's perspective, but the disadvantage of 942 each CDN exposing more of its internal structure (in particular, the 943 addresses of edge caches) to peer CDNs. By contrast, iterative 944 redirection does not require dCDN to expose the addresses of its edge 945 caches to uCDN. 947 This example happens to use HTTP-based redirection in both CDN A and 948 CDN B, but a similar example could be constructed using DNS-based 949 redirection in either CDN. Hence, the key point to take away here is 950 simply that the end user only sees a single redirection of some type, 951 as opposed to the pair of redirections in the prior (iterative) 952 example. 954 The use of the Request Routing Interface requires that interface to 955 be appropriately configured and bootstrapped, which is not shown 956 here. More discussion on the bootstrapping of interfaces is provided 957 in Section 4 959 3.4. DNS-based redirection example 961 In this section we walk through a simple example using DNS-based 962 redirection for request redirection from uCDN to dCDN (as well as for 963 request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- 964 based redirection has certain advantages over HTTP-based redirection 965 (notably, it is transparent to the end-user) as well as some 966 drawbacks (notably the client IP address is not visible to the 967 request router). 969 As before, Operator A must learn the set of requests that dCDN is 970 willing or able to serve (e.g. which client IP address prefixes or 971 geographic regions are part of the dCDN footprint). Operator B must 972 have and make known to operator A some unique identifier that can be 973 used for the construction of a distinguished CDN domain, as shown in 974 more detail below. (This identifier strictly needs only to be unique 975 within the scope of Operator A, but a globally unique identifier, 976 such as an AS number assigned to B, is one easy way to achieve that.) 977 Also, Operator A must obtain the NS records for Operator B's 978 externally visible redirection servers. Also, as before, a 979 distinguished CDN-domain, such as op-b-acq.op-a.net, must be assigned 980 for inter-CDN acquisition. 982 DNS must be configured in the following way: 984 o The CSP must be configured to make Operator A the authoritative 985 DNS server for cdn.csp.com (or to return a CNAME for cdn.csp.com 986 for which operator A is the authoritative DNS server). 988 o When uCDN sees a request best served by dCDN, it returns CNAME and 989 NS records for "b.cdn.csp.com", where "b" is the unique identifier 990 assigned to Operator B. (It may, for example, be an AS number 991 assigned to Operator B.) 993 o dCDN must be configured so that a request for "b.cdn.csp.com" 994 returns a delivery node in dCDN. 996 o uCDN must be configured so that a request for "op-b-acq.op-a.net" 997 returns a delivery node in uCDN. 999 Figure 5 depicts the exchange of DNS and HTTP requests. The main 1000 differences from Figure 3 are the lack of HTTP redirection and 1001 transparency to the end-user. 1003 End-User Operator B Operator A 1004 |DNS cdn.csp.com | | 1005 |-------------------------------------------------->| 1006 | | |(1) 1007 |CNAME b.cdn.csp.com | | 1008 |NS records for b.cdn.csp.com | 1009 |<--------------------------------------------------| 1010 |DNS b.cdn.csp.com | | 1011 |------------------------>| | 1012 | |(2) | 1013 |IPaddr of B's Delivery Node | 1014 |<------------------------| | 1015 |HTTP cdn.csp.com | | 1016 |------------------------>| | 1017 | |(3) | 1018 | |DNS op-b-acq.op-a.net | 1019 | |------------------------>| 1020 | | |(4) 1021 | |IPaddr of A's Delivery Node 1022 | |<------------------------| 1023 | |HTTP op-b-acq.op-a.net | 1024 | |------------------------>| 1025 | | |(5) 1026 | |Data | 1027 | |<------------------------| 1028 |Data | | 1029 |<------------------------| | 1031 Figure 5: Request Trace for DNS-based Redirection Example 1033 The steps illustrated in the figure are as follows: 1035 1. Request Router for Operator A processes the DNS request for CDN- 1036 domain cdn.csp.com and recognizes that the end-user is best 1037 served by another CDN. (This may depend on the IP address of the 1038 user's local DNS resolver, or other information discussed below.) 1039 The Request Router returns a DNS CNAME response by "stacking" the 1040 distinguished identifier for Operator B onto the original CDN- 1041 domain (e.g., b.cdn.csp.com), plus an NS record that maps 1042 b.cdn.csp.com to B's Request Router. 1044 2. The end-user does a DNS lookup using the modified CDN-domain 1045 (i.e., b.cdn.csp.com). This causes B's Request Router to respond 1046 with a suitable delivery node. 1048 3. The end-user requests the content from B's delivery node. The 1049 requested URL contains the name cdn.csp.com. (Note that the 1050 returned CNAME does not affect the URL.) At this point the 1051 delivery node has the correct IP address of the end-user and can 1052 do an HTTP 302 redirect if the redirections in steps 2 and 3 were 1053 incorrect. Otherwise B verifies that this CDN-domain belongs to 1054 a known peer (so as to avoid being tricked into serving as an 1055 open proxy). It then does a DNS request for an "internal" CDN- 1056 domain as agreed above (op-b-acq.op-a.net). 1058 4. Operator A recognizes that the DNS request is from a peer CDN 1059 rather than an end-user (due to the internal CDN-domain) and so 1060 returns the address of a delivery node in uCDN. 1062 5. Operator A serves content to dCDN. Although not shown, it is at 1063 this point that Operator A processes the rest of the URL: it 1064 extracts information identifying the origin server, validates 1065 that this server has been registered, and determines the content 1066 provider that owns the origin server. 1068 3.4.1. Comments on the example 1070 The advantages of this approach are that it is more transparent to 1071 the end-user and requires fewer round trips than HTTP-based 1072 redirection. A potential problem is that the upstream CDN depends on 1073 being able to learn the correct downstream CDN that serves the end- 1074 user from the client address in the DNS request. In standard DNS 1075 operation, uCDN will only obtain the address of the client's local 1076 DNS resolver (LDNS), which is not guaranteed to be in the same 1077 network (or geographic region) as the client. If not--e.g., the end- 1078 user uses a global DNS service--then the upstream CDN cannot 1079 determine the appropriate downstream CDN to serve the end-user. In 1080 this case, one option is for the upstream CDN to treat the end-user 1081 as it would any user not connected to a peer CDN. Another option is 1082 for the upstream CDN to "fall back" to a pure HTTP-based redirection 1083 strategy in this case (i.e., use the first method). Note that this 1084 problem affects existing CDNs that rely on DNS to determine where to 1085 redirect client requests, but the consequences are arguably less 1086 serious since the LDNS is likely in the same network as the dCDN 1087 serves. One approach to ensuring that the client's IP address prefix 1088 is correctly determined in such situations is described in 1089 [I-D.vandergaast-edns-client-subnet]. 1091 As with the prior example, this example partially illustrates the 1092 various interfaces involved in CDNI. Operator A could learn 1093 dynamically from Operator B the set of prefixes or regions that B is 1094 willing and able to serve via the request routing interface. The 1095 distinguished name used for acquisition and the identifier for 1096 Operator B that is prepended to the CDN domain on redirection are 1097 examples of information elements that might also be conveyed by CDNI 1098 interfaces (or, alternatively, statically configured). As before, 1099 minimal metadata sufficient to obtain the content is carried "in- 1100 band" as part of the redirection process, and standard HTTP is used 1101 for inter-CDN acquisition. There is no explicit logging interface 1102 discussed in this example. 1104 3.5. Dynamic Footprint Discovery 1106 There could be situations where being able to dynamically discover 1107 the set of requests that a given dCDN is willing and able to serve is 1108 beneficial. For example, a CDN might at one time be able to serve a 1109 certain set of client IP prefixes, but that set might change over 1110 time due to changes in the topology and routing policies of the IP 1111 network. The following example illustrates this capability. We have 1112 chosen the example of DNS-based redirection, but HTTP-based 1113 redirection could equally well use this approach. 1115 End-User Operator B Operator A 1116 |DNS cdn.csp.com | | 1117 |-------------------------------------------------->| 1118 | | |(1) 1119 | | RRI REQ op-b.net | 1120 | |<------------------------| 1121 | | |(2) 1122 | | RRI REPLY | 1123 | |------------------------>| 1124 | | |(3) 1125 |CNAME b.cdn.csp.com | | 1126 |NS records for b.cdn.csp.com | 1127 |<--------------------------------------------------| 1128 |DNS b.cdn.csp.com | | 1129 |------------------------>| | 1130 | |(2) | 1131 |IPaddr of B's Delivery Node | 1132 |<------------------------| | 1133 |HTTP cdn.csp.com | | 1134 |------------------------>| | 1135 | |(3) | 1136 | |DNS op-b-acq.op-a.net | 1137 | |------------------------>| 1138 | | |(4) 1139 | |IPaddr of A's Delivery Node 1140 | |<------------------------| 1141 | |HTTP op-b-acq.op-a.net | 1142 | |------------------------>| 1143 | | |(5) 1144 | |Data | 1145 | |<------------------------| 1146 |Data | | 1147 |<------------------------| | 1149 Figure 6: Request Trace for Dynamic Footprint Discovery Example 1151 This example differs from the one in Figure 5 only in the addition of 1152 a CDNI Request Routing Interface request (step 2) and corresponding 1153 response (step 3). The RRI Req could be a message such as "Can you 1154 serve clients from this IP Prefix?" or it could be "Provide the list 1155 of client IP prefixes you can currently serve". In either case the 1156 response might be cached by operator A to avoid repeatedly asking the 1157 same question. Alternatively, or in addition, Operator B may 1158 spontaneously advertise to Operator A information (or changes) on the 1159 set of requests it is willing and able to serve on behalf of operator 1160 A; in that case, Operator B may spontaneously issue RRI REPLY 1161 messages that are not in direct response to a corresponding RRI REQ 1162 message. (Note that the issues of determining the client's subnet 1163 from DNS requests, as described above, are exactly the same here as 1164 in Section 3.4.) 1166 Once Operator A obtains the RRI response, it is now able to determine 1167 that Operator B's CDN is an appropriate dCDN for this request and 1168 therefore a valid candidate dCDN to consider in its Redirection 1169 decision. If that dCDN is selected, the redirection and serving of 1170 the request proceeds as before (i.e. in the absence of dynamic 1171 footprint discovery). 1173 3.6. Content Removal 1175 The following example illustrates how the Control interface may be 1176 used to remove an item of content. In this example, user requests 1177 for a particular content, and corresponding redirection of such 1178 requests from Operator A to Operator B CDN, may (or may not) have 1179 taken place earlier. Then, at some point in time, the uCDN (for 1180 example, in response to a corresponding trigger from the Content 1181 Provider) uses the Control Interface to request that content 1182 identified by a particular URL be removed from dCDN. The following 1183 diagram illustrates the operation. 1184 End-User Operator B Operator A 1185 | |CI purge cdn.csp.com/... | 1186 | |<------------------------| 1187 | | |(1) 1188 | |CI OK | 1189 | |------------------------>| 1190 | | |(2) 1192 Figure 7: Request Trace for Content Removal 1194 The Control interface is used to convey the request from uCDN to dCDN 1195 that some previously acquired content should be deleted. The URL in 1196 the request specifies which content to remove. This example 1197 corresponds to a DNS-based redirection scenario such as Section 3.4. 1198 If HTTP-based redirection had been used, the URL for removal would be 1199 of the form peer-a.op-b.net/cdn.csp.com/... 1201 The dCDN is expected to confirm to the uCDN, as illustrated by the CI 1202 OK message, the completion of the removal of the targeted content 1203 from all the caches in dCDN. 1205 3.7. Pre-Positioned Content Acquisition Example 1207 The following example illustrates how the Control interface may be 1208 used to pre-position an item of content in the dCDN. In this 1209 example, Operator A uses the Metadata interface to request that 1210 content identified by a particular URL be pre-positioned into 1211 Operator B CDN. 1213 End-User Operator B Operator A 1215 | |CI pre-position cdn.csp.com/... 1216 | |<------------------------| 1217 | | |(1) 1218 | |CI OK | 1219 | |------------------------>| 1220 | | | 1221 | |DNS op-b-acq.op-a.net | 1222 | |------------------------>| 1223 | | |(2) 1224 | |IPaddr of A's Delivery Node 1225 | |<------------------------| 1226 | |HTTP op-b-acq.op-a.net | 1227 | |------------------------>| 1228 | | |(3) 1229 | |Data | 1230 | |<------------------------| 1231 |DNS cdn.csp.com | | 1232 |-------------------------------------------------->| 1233 | | |(4) 1234 |IPaddr of A's Request Router | 1235 |<--------------------------------------------------| 1236 |HTTP cdn.csp.com | | 1237 |-------------------------------------------------->| 1238 | | |(5) 1239 |302 peer-a.op-b.net/cdn.csp.com | 1240 |<--------------------------------------------------| 1241 |DNS peer-a.op-b.net | | 1242 |------------------------>| | 1243 | |(6) | 1244 |IPaddr of B's Delivery Node | 1245 |<------------------------| | 1246 |HTTP peer-a.op-b.net/cdn.csp.com | 1247 |------------------------>| | 1248 | |(7) | 1249 |Data | | 1250 |<------------------------| | 1252 Figure 8: Request Trace for Content Pre-Positioning 1254 The steps illustrated in the figure are as follows: 1256 1. Operator A uses the Control Interface to request that Operator B 1257 pre-positions a particular content item identified by its URL. 1259 Operator B responds by confirming that it is willing to perform 1260 this operation. 1262 Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only 1263 this time those steps happen as the result of the Pre-positioning 1264 request instead of as the result of a cache miss. 1266 Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of 1267 Figure 3, only this time Operator B CDN can serve the end-user 1268 request without triggering dynamic content acquisition, since the 1269 content has been pre-positioned in dCDN. Note that, depending on 1270 dCDN operations and policies, the content pre-positioned in the dCDN 1271 may be pre-positioned to all, or a subset of, dCDN caches. In the 1272 latter case, intra-CDN dynamic content acquisition may take place 1273 inside the dCDN serving requests from caches on which the content has 1274 not been pre-positioning; however, such intra-CDN dynamic acquisition 1275 would not involve the uCDN. 1277 3.8. Asynchronous CDNI Metadata Example 1279 In this section we walk through a simple example illustrating a 1280 scenario of asynchronously exchanging CDNI metadata, where the 1281 downstream CDN obtains CDNI metadata for content ahead of a 1282 corresponding content request. The example that follows assumes that 1283 HTTP-based inter-CDN redirection and recursive CDNI request-routing 1284 are used, as in Section 3.3. However, asynchronous exchange of CDNI 1285 Metadata is similarly applicable to DNS-based inter-CDN redirection 1286 and iterative request routing (in which cases the CDNI metadata may 1287 be used at slightly different processing stages of the message 1288 flows). 1290 End-User Operator B Operator A 1291 | | | 1292 | |MI push (cdn.csp.com/...,| 1293 | | distribution policy) | 1294 | |<------------------------|(1) 1295 | | | 1296 | | | 1297 | CONTENT REQUEST | | 1298 |-------------------------------------------------->| (2) 1299 | | | 1300 | |RRI REQ | 1301 | (3)|<------------------------| 1302 | | | 1303 | | | 1304 | |RRI RESP | 1305 | |------------------------>|(4) 1306 | | | 1307 | CONTENT REDIRECTION | | 1308 |<--------------------------------------------------| (5) 1309 | | | 1310 | CONTENT REQUEST | | 1311 |------------------------>| (6) | 1312 | | | 1313 : : : 1314 | CONTENT DATA | | 1315 |<------------------------| | (7) 1317 Figure 9: Request Trace for Asynchronous CDNI Metadata 1319 The steps illustrated in the figure are as follows: 1321 1. Operator A uses the Metadata Interface to asynchronously push 1322 CDNI metadata to Operator B. The present document does not 1323 constrain how the CDNI metadata information is actually 1324 represented. For the purposes of this example, we assume that 1325 Operator A provides CDNI metadata to Operator B indicating that: 1327 * this CDNI Metadata is applicable to any content referenced by 1328 "cdn.csp.com/op-b.net/..." (assuming HTTP redirection is used 1329 - it would be applicable to "cdn.csp.com/..." if DNS 1330 redirection were used as in Section 3.4). 1332 * this CDNI metadata consists of a distribution policy requiring 1333 enforcement by the delivery node of a specific per-request 1334 authorization mechanism (e.g. URI signature or token 1335 validation). 1337 2. A Content Request occurs as usual. 1339 3. A CDNI Request Routing Request (RRI REQ) is issued by operator A 1340 CDN, as discussed in Section 3.3. Operator B's request router 1341 can access the CDNI Metadata that are relevant to the requested 1342 content and that have been pre-positioned as per Step 1, which 1343 may or may not affect the response. 1345 4. Operator B's request router issues a CDNI Request Routing 1346 Response (RRI RESP) as in Section 3.3. 1348 5. Operator B performs content redirection as discussed in 1349 Section 3.3. 1351 6. On receipt of the Content Request by the end user, the delivery 1352 node detects that previously acquired CDNI metadata is applicable 1353 to the requested content. In accordance with the specific CDNI 1354 metadata of this example, the delivery node will invoke the 1355 appropriate per-request authorization mechanism, before serving 1356 the content. (Details of this authorization are not shown.) 1358 7. Assuming successful per-request authorization, serving of Content 1359 Data (possibly preceded by inter-CDN acquisition) proceeds as in 1360 Section 3.3. 1362 3.9. Synchronous CDNI Metadata Acquisition Example 1364 In this section we walk through a simple example illustrating a 1365 scenario of synchronous CDNI metadata acquisition, in which the 1366 downstream CDN obtains CDNI metadata for content at the time of 1367 handling a first request for the corresponding content. As in the 1368 preceding section, this example assumes that HTTP-based inter-CDN 1369 redirection and recursive CDNI request-routing are used (as in 1370 Section 3.3), but dynamic CDNI metadata acquisition is applicable to 1371 other variations of request routing. 1373 End-User Operator B Operator A 1374 | | | 1375 | |MI push (cdn.csp.com/...,| 1376 | | CDNI metadata acquisition info) 1377 | |<------------------------|(1) 1378 | | | 1379 : : : 1380 | CONTENT REQUEST | | 1381 |-------------------------------------------------->|(2) 1382 | | | 1383 | |RRI REQ | 1384 | (3)|<------------------------| 1385 | | | 1386 | |MI REQ | 1387 | (4)|------------------------>| 1388 | |MI RESP | 1389 | |<------------------------|(5) 1390 | | | 1391 | |RRI RESP | 1392 | |------------------------>|(6) 1393 | | | 1394 | | | 1395 | CONTENT REDIRECTION | | 1396 |<--------------------------------------------------|(7) 1397 | | | 1398 | CONTENT REQUEST | | 1399 |------------------------>| (8) | 1400 | | | 1401 | |MI REQ | 1402 | (9)|------------------------>| 1403 | |MI RESP | 1404 | |<------------------------|(10) 1405 | | | 1406 : : : 1407 | CONTENT DATA | | 1408 |<------------------------| | (11) 1410 Figure 10: Request Trace for Synchronous CDNI Metadata Acquisition 1412 The steps illustrated in the figure are as follows: 1414 1. Operator A initially uses the Metadata Interface to 1415 asynchronously push seed metadata to Operator B. For example, 1416 this seed information may include a URI indicating where CDNI 1417 Metadata can later be pulled from for some content set. (There 1418 are alternative ways that this seeding information may be 1419 provided, such as piggybacking on the CDNI RRI REQ message of 1420 Step 3.) 1422 2. A Content Request arrives as normal. 1424 3. A Request Routing Interface request occurs as in the prior 1425 example. 1427 4. On receipt of the CDNI Request Routing Request, Operator B's CDN 1428 initiates synchronous acquisition of CDNI Metadata that are 1429 needed for routing of the end-user request. The seeding 1430 information provided in Step 1 is used to determine how to 1431 obtain the metadata. Note that there may exist cases in which 1432 this step does not occur (e.g., because the CDNI metadata 1433 seeding information indicates CDNI metadata are not needed at 1434 that stage). 1436 5. On receipt of a CDNI Metadata MI Request, Operator A's CDN 1437 responds, making the corresponding CDNI metadata information 1438 available to Operator B's CDN. This metadata is considered by 1439 operator B's CDN before responding to the Request Routing 1440 request. (In a simple case, the metadata could simply be an 1441 allow or deny response for this particular request.) 1443 6. Response to the RRI request as normal. 1445 7. Redirection message is sent to the end user. 1447 8. A delivery node of Operator B receives the end user request. 1449 9. The delivery node triggers dynamic acquisition of additional 1450 CDNI metadata that are needed to process the end-user content 1451 request. Again the seeding information provided in Step 1 is 1452 used to determine how to acquire the needed CDNI metadata. Note 1453 that there may exist cases where this step need not happen, 1454 either because the metadata were already acquired previously, or 1455 because the seeding information indicates no metadata are 1456 required. 1458 10. Operator A's CDN responds to the CDNI Metadata Request and makes 1459 the corresponding CDNI metadata available to Operator B. This 1460 metadata influence how Operator B's CDN processes the end-user 1461 request. 1463 11. Content is served (possibly preceded by inter-CDN acquisition) 1464 as in Section 3.3. 1466 4. Main Interfaces 1468 Figure 1 illustrates the four main interfaces that are in scope for 1469 the CDNI WG, along with several others. The detailed specifications 1470 of these interfaces are left to other documents (mostly still to be 1471 written, but see [I-D.ietf-cdni-problem-statement] and 1472 [I-D.ietf-cdni-requirements] for some discussion of the interfaces). 1474 One interface that is not shown in Figure 1 is the interface between 1475 the user and the CSP. While for the purposes of CDNI that interface 1476 is out of scope, it is worth noting that it does exist and can 1477 provide useful functions, such as end-to-end performance monitoring 1478 and some forms of authentication and authorization. 1480 There is also an important interface between the user and the Request 1481 Routing function of both uCDN and dCDN. As we saw in some of the 1482 preceding examples, that interface can be used as a way of passing 1483 information such as the metadata that is required to obtain the 1484 content in dCDN from uCDN. 1486 In this section we will provide an overview of the functions 1487 performed by each of the CDNI interfaces and discuss how they fit 1488 into the overall solution. We also examine some of the design 1489 tradeoffs. We begin with an examination of one such tradeoff that 1490 affects all the interfaces - the use of in-band or out-of-band 1491 communication. 1493 4.1. In-Band versus Out-of-Band Interfaces 1495 Before getting to the individual interfaces, we observe that there is 1496 a high-level design choice for each, involving the use of existing 1497 in-band communication channels versus defining new out-of-band 1498 interfaces. 1500 It is possible that the information needed to carry out various 1501 interconnection functions can be communicated between peer CDNs using 1502 existing in-band protocols. The use of HTTP 302 redirect is an 1503 example of how certain aspects of request routing can be implemented 1504 in-band (embedded in URIs). Note that using existing in-band 1505 protocols does not imply that the CDNI interfaces are null; it is 1506 still necessary to establish the rules (conventions) by which such 1507 protocols are used to implement the various interface functions. 1509 There are other opportunities for in-band communication beyond HTTP 1510 redirects. For example, many of the HTTP directives used by proxy 1511 servers can also be used by peer CDNs to inform each other of caching 1512 activity. Of these, one that is particularly relevant is the If- 1513 Modified-Since directive, which is used with the GET method to make 1514 it conditional: if the requested object has not been modified since 1515 the time specified in this field, a copy of the object will not be 1516 returned, and instead, a 304 (not modified) response will be 1517 returned. 1519 4.2. Request Routing Interface 1521 We may think of the request routing interface as comprising two 1522 parts: the asynchronous advertisement of footprint and capabilities 1523 by a dCDN that allows a uCDN to decide whether to redirect particular 1524 user requests to that dCDN; and the synchronous operation of actually 1525 redirecting a user request. (These are somewhat analogous to the 1526 operations of routing and forwarding in IP.) 1528 As illustrated in Section 3, the synchronous part of the request 1529 routing interface may be implemented in part by DNS and HTTP. Naming 1530 conventions may be established by which CDN peers communicate whether 1531 a request should be routed or content served. 1533 In support of these exchanges, it is necessary for CDN peers to 1534 exchange additional information with each other. Depending on the 1535 method(s) supported, this includes 1537 o The operator's unique id (operator-id) or distinguished CDN-domain 1538 (operator-domain); 1540 o NS records for the operator's set of externally visible request 1541 routers; 1543 o The set of requests the dCDN operator is prepared to serve (e.g. a 1544 set of client IP prefixes or geographic regions that may be served 1545 by dCDN). 1547 Of these, the two operator identifiers are fixed, and can be 1548 exchanged off-line as part of a peering agreement. The NS records 1549 potentially change with some frequency, but an existing protocol-- 1550 DNS--can be used to dynamically track this information. That is, a 1551 peer can do a DNS lookup on operator-domain to retrieve the set of NS 1552 records corresponding to the peer's redirection service. 1554 The set of requests that dCDN is willing to serve could in some cases 1555 be relatively static (e.g., a set of IP prefixes) which could be 1556 exchanged off-line, or might even be negotiated as part of a peering 1557 agreement. However, it may also be more dynamic, in which case an 1558 explicit protocol for its exchange would be be helpful. 1560 A variety of options exist for the dCDN operator to advertise its 1561 footprint to uCDN. As discussed in 1563 [I-D.previdi-cdni-footprint-advertisement], footprint is comprised of 1564 two components: 1566 o a class of end user requests (represented, for example, by a set 1567 of IP prefixes, or a geographic region) that the dCDN is willing 1568 and able to serve directly, without use of another dCDN; 1570 o the connectivity of the dCDN to other CDNs that may be able to 1571 serve content to users on behalf of dCDN. 1573 [I-D.previdi-cdni-footprint-advertisement] describes an approach to 1574 advertising such footprint information asynchronously using BGP. In 1575 addition to this sort of information, a dCDN might also advertise 1576 "capabilities" such as the ability to handle certain types of content 1577 (e.g. specific streaming formats) or quality of service (QoS) 1578 capabilities. [I-D.xiaoyan-cdni-request-routing-protocol] describes 1579 an approach that exchanges CDN "capabilities" over HTTP, while 1580 [I-D.seedorf-alto-for-cdni] describes how ALTO [RFC5693] may be used 1581 to obtain request routing information. 1583 We also note that the Request Routing interface plays a key role in 1584 enabling recursive redirection, as illustrated in Section 3.3. It 1585 enables the user to be redirected to the correct delivery node in 1586 dCDN with only a single redirection step (as seen by the user). This 1587 may be particularly valuable as the chain of interconnected CDNs 1588 increases beyond two CDNs. 1590 One final issue is how HTTP adaptive streaming impacts the Request 1591 Routing interface, and in particular, the interplay between the 1592 request router and manifest files, which may contain either absolute 1593 or relative URLs. These issues are discussed in more detail in 1594 [I-D.brandenburg-cdni-has]. 1596 4.3. Logging Interface 1598 It is necessary for the upstream CDN to have visibility into the 1599 delivery of content it originates to end-users connected to the 1600 downstream CDN. This allows the upstream CDN to properly bill its 1601 customers for multiple deliveries of content cached by the downstream 1602 CDN, as well as to report accurate traffic statistics to those 1603 content providers. This is one role of the Logging interface. 1605 Other operational data that may be relevant to CDNI can also be 1606 exchanged by the Logging interface. For example, dCDN may report the 1607 amount of content it has acquired from uCDN, and how much cache 1608 storage has been consumed by content cached on behalf of uCDN. 1610 Traffic logs are easily exchanged off-line. For example, the 1611 following traffic log is a small deviation from the Apache log file 1612 format, where entries include the following fields: 1614 o Domain - the full domain name of the origin server 1616 o IP address - the IP address of the client making the request 1618 o End time - the ending time of the transfer 1620 o Time zone - any time zone modifier for the end time 1622 o Method - the transfer command itself (e.g., GET, POST, HEAD) 1624 o URL - the requested URL 1626 o Version - the protocol version, such as HTTP/1.0 1628 o Response - a numeric response code indicating transfer result 1630 o Bytes Sent - the number of bytes in the body sent to the client 1632 o Request ID - a unique identifier for this transfer 1634 o User agent - the user agent, if supplied 1636 o Duration - the duration of the transfer in milliseconds 1638 o Cached Bytes - the number of body bytes served from the cache 1640 o Referrer - the referrer string from the client, if supplied 1642 Of these, only the Domain field is indirect in the downstream CDN--it 1643 is set to the CDN-domain used by the upstream CDN rather than the 1644 actual origin server. This field could then used to filter traffic 1645 log entries so only those entries matching the upstream CDN are 1646 reported to the corresponding operator. Further discussion of the 1647 Logging interface can be found in [I-D.bertrand-cdni-logging] and 1648 [I-D.lefaucheur-cdni-logging-delivery]. 1650 One open question is who does the filtering. One option is that the 1651 downstream CDN filters its own logs, and passes the relevant records 1652 directly to each upstream peer. This requires that the downstream 1653 CDN knows the set of CDN-domains that belong to each upstream peer. 1654 If this information is already exchanged between peers as part of the 1655 request routing interface, then direct peer-to-peer reporting is 1656 straightforward. If it is not available, and operators do not wish 1657 to advertise the set of CDN-domains they serve to their peers, then 1658 the second option is for each CDN to send both its non-local traffic 1659 records and the set of CDN-domains it serves to an independent third- 1660 party (i.e., a CDN Exchange), which subsequently filters, merges, and 1661 distributes traffic records on behalf of each participating CDN 1662 operator. 1664 A second open question is how timely traffic information should be. 1665 For example, in addition to off-line traffic logs, accurate real-time 1666 traffic monitoring might also be useful, but such information 1667 requires that the downstream CDN inform the upstream CDN each time it 1668 serves upstream content from its cache. The downstream CDN can do 1669 this, for example, by sending a conditional HTTP GET request (If- 1670 Modified-Since) to the upstream CDN each time it receives an HTTP GET 1671 request from one of its end-users. This allows the upstream CDN to 1672 record that a request has been issued for the purpose of real-time 1673 traffic monitoring. The upstream CDN can also use this information 1674 to validate the traffic logs received later from the downstream CDN. 1676 There is obviously a tradeoff between accuracy of such monitoring and 1677 the overhead of the downstream CDN having to go back to the upstream 1678 CDN for every request. 1680 Another design tradeoff in the Logging interface is the degree of 1681 aggregation or summarization of data. One situation that lends 1682 itself to summarization is the delivery of HTTP-based adaptive bit- 1683 rate video. Most schemes to deliver such video use a large number of 1684 relatively small HTTP requests (e.g. one request per two-second chunk 1685 of video.) It may be desirable to aggregate logging information so 1686 that a single log entry is provided for the entire video rather than 1687 for each chunk. Note however that such aggregation requires a degree 1688 of application awareness in dCDN to recognize that the many HTTP 1689 requests correspond to a single video. The implications of HTTP 1690 adaptive streaming are discussed further in 1691 [I-D.brandenburg-cdni-has]. 1693 Other forms of aggregation may also be useful. For example, there 1694 may be situations where bulk metrics such as bytes delivered per hour 1695 may suffice rather than the detailed per-request logs outlined above. 1696 It seems likely that a range of granularities of logging will be 1697 needed along with ways to specify the type and degree of aggregation 1698 required. 1700 4.4. Control Interface 1702 The control interface is initially used to bootstrap the other 1703 interfaces. As a simple example, it could be used to provide the 1704 address of the logging server in dCDN to uCDN in order to bootstrap 1705 the logging interface. It may also be used, for example, to 1706 establish security associations for the other interfaces. 1708 The other role the Control interface plays is to allow the uCDN to 1709 pre-position, revalidate, or purge metadata and content on a dCDN. 1710 These operations, sometimes collectively called the trigger 1711 interface, are discussed further in [I-D.murray-cdni-triggers]. 1713 4.5. Metadata Interface 1715 The role of the metadata interface is to enable CDNI distribution 1716 metadata to be conveyed to the downstream CDN by the upstream CDN. 1717 For example, see [I-D.ma-cdni-metadata] and 1718 [I-D.caulfield-cdni-metadata-core]. Such metadata includes geo- 1719 blocking restrictions, availability windows, access control policies, 1720 and so on. It may also include policy information such as the desire 1721 to pre-position content rather than fetch it on demand. 1723 Some metadata may be able to be conveyed using in-band mechanisms. 1724 For example, to inform the downstream CDN of any geo-blocking 1725 restrictions or availability windows, the upstream can elect to 1726 redirect a request to the downstream CDN only if that CDN's 1727 advertised delivery footprint is acceptable for the requested URL. 1728 Similarly, the request could be forwarded only if the current time is 1729 within the availability window. 1731 Similarly, some forms of access control may also be performed on a 1732 per-request basis using HTTP directives. For example, being able to 1733 respond to a conditional GET request gives the upstream CDN an 1734 opportunity to influence how the downstream CDN delivers its content. 1735 Minimally, the upstream CDN can invalidate (purge) content previously 1736 cached by the downstream CDN. 1738 Fine-grain control over how the downstream CDN delivers content on 1739 behalf of the upstream CDN is also possible. For example, by 1740 including the X-Forwarded-For HTTP header with the conditional GET 1741 request, the downstream CDN can report the end-user's IP address to 1742 the upstream CDN, giving it an opportunity to control whether the 1743 downstream CDN should serve the content to this particular end-user. 1744 The upstream CDN would communicate its directive through its response 1745 to the conditional GET. The downstream CDN can cache information for 1746 a period of time specified by the upstream CDN, thereby reducing 1747 control overhead. 1749 All of these in-band techniques serve to illustrate that uCDNs have 1750 the option of enforcing their access control policies themselves, 1751 rather than delegating enforcement to dCDNs using the Metadata 1752 interface. As a consequence, the Metadata interface must provide a 1753 means for the uCDN to express this its desire to retain enforcement 1754 for itself. For example, this might be done by including a "check 1755 with me" flag in the metadata associated with certain content. 1757 5. Deployment Models 1759 In this section we describe a number of possible deployment models 1760 that may be achieved using the CDNI interfaces described above. We 1761 note that these models are by no means exhaustive, and that may other 1762 models may be possible. 1764 Although the reference model of Figure 1 shows all CDN functions on 1765 each side of the CDNI interface, deployments can rely on entities 1766 that are involved in any subset of these functions, and therefore 1767 only support the relevant subset of CDNI interfaces. As already 1768 noted in Section 3, effective CDNI deployments can be built without 1769 necessarily implementing all four interfaces. Some examples of such 1770 deployments are shown below. 1772 Note that, while we refer to upstream and downstream CDNs, this 1773 distinction applies to specific content items and transactions. That 1774 is, a given CDN may be upstream for some transactions and downstream 1775 for others, depending on many factors such as location of the 1776 requesting client and the particular piece of content requested. 1778 5.1. Meshed CDNs 1780 Although the reference model illustrated in Figure 1 shows a 1781 unidirectional CDN interconnection with a single uCDN and a single 1782 dCDN, any arbitrary CDNI meshing can be built from this, such as the 1783 example meshing illustrated in Figure 11. (Support for arbitrary 1784 meshing may or may not be in the initial scope for the working group, 1785 but the model allows for it.) 1786 ------------- ----------- 1787 / CDN A \<==CDNI===>/ CDN B \ 1788 \ / \ / 1789 ------------- ----------- 1790 /\ \\ /\ 1791 || \\ || 1792 CDNI \==CDNI===\\ CDNI 1793 || \\ || 1794 \/ \/ \/ 1795 ------------- ----------- 1796 / CDN C \===CDNI===>/ CDN D \ 1797 \ / \ / 1798 ------------- ----------- 1799 /\ 1800 || 1801 CDNI 1802 || 1803 \/ 1804 ------------- 1805 / CDN E \ 1806 \ / 1807 ------------- 1809 ===> CDNI interfaces, with right-hand side CDN acting as dCDN 1810 to left-hand side CDN 1811 <==> CDNI interfaces, with right-hand side CDN acting as dCDN 1812 to left-hand side CDN and with left-hand side CDN acting 1813 as dCDN to right-hand side CDN 1815 Figure 11: CDNI Deployment Model: CDN Meshing Example 1817 5.2. CSP combined with CDN 1819 Note that our terminology refers to functional roles and not economic 1820 or business roles. That is, a given organization may be operating as 1821 both a CSP and a fully-fledged uCDN when we consider the functions 1822 performed, as illustrated in Figure 12. 1824 ##################################### ################## 1825 # # # # 1826 # Organization A # # Organization B # 1827 # # # # 1828 # -------- ------------- # # ----------- # 1829 # / CSP \ / uCDN \ # # / dCDN \ # 1830 # | | | +----+ | # # | +----+ | # 1831 # | | | | C | | # # | | C | | # 1832 # | | | +----+ | # # | +----+ | # 1833 # | | | +----+ | # # | +----+ | # 1834 # | | | | L | | # # | | L | | # 1835 # | |*****| +----+ |===CDNI===>| +----+ | # 1836 # | | | +----+ | # # | +----+ | # 1837 # | | | | RR | | # # | | RR | | # 1838 # | | | +----+ | # # | +----+ | # 1839 # | | | +----+ | # # | +----+ | # 1840 # | | | | D | | # # | | D | | # 1841 # | | | +----+ | # # | +----+ | # 1842 # \ / \ / # # \ / # 1843 # -------- ------------- # # ----------- # 1844 # # # # 1845 ##################################### ################## 1847 ===> CDNI interfaces, with right-hand side CDN acting as dCDN 1848 to left-hand side CDN 1849 **** interfaces outside the scope of CDNI 1850 C Control component of the CDN 1851 L Logging component of the CDN 1852 RR Request Routing component of the CDN 1853 D Distribution component of the CDN 1855 Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN 1857 5.3. CSP using CDNI Request Routing Interface 1859 As another example, a content provider organization may choose to run 1860 its own request routing function as a way to select among multiple 1861 candidate CDN providers; In this case the content provider may be 1862 modeled as the combination of a CSP and of a special, restricted case 1863 of a CDN. In that case, as illustrated in Figure 13, the CDNI 1864 Request Routing interface can be used between the restricted CDN 1865 operated by the content provider Organization and the CDN operated by 1866 the full-CDN organization acting as a dCDN in the request routing 1867 control plane. Interfaces outside the scope of the CDNI work can be 1868 used between the CSP functional entities of the content provider 1869 organization and the CDN operated by the full-CDN organization acting 1870 as a uCDN) in the CDNI control planes other than the request routing 1871 plane (i.e. Control, Distribution, Logging). 1873 ##################################### ################## 1874 # # # # 1875 # Organization A # # Organization B # 1876 # # # # 1877 # -------- ------------- # # ----------- # 1878 # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # 1879 # | | | +----+ | # # | +----+ | # 1880 # | |*****| | RR |==========CDNI=====>| RR | | # 1881 # | | | +----+ | # RR # | +----+ | # 1882 # | | \ / # # | | # 1883 # | | ------------- # # |uCDN(C,L,D)| # 1884 # | | # # | +----+ | # 1885 # | | # # | | C | | # 1886 # | |*******************************| +----+ | # 1887 # | | # # | +----+ | # 1888 # | | # # | | L | | # 1889 # | | # # | +----+ | # 1890 # | | # # | +----+ | # 1891 # | | # # | | D | | # 1892 # | | # # | +----+ | # 1893 # \ / # # \ / # 1894 # -------- # # ----------- # 1895 # # # # 1896 ##################################### ################## 1898 ===> CDNI Request Routing interface 1899 **** interfaces outside the scope of CDNI 1901 Figure 13: CDNI Deployment Model: Organization combining CSP and 1902 partial CDN 1904 5.4. CDN Federations and CDN Exchanges 1906 There are two additional concepts related to, but distinct from CDN 1907 Interconnection. The first is CDN Federation. Our view is that CDNI 1908 is the more general concept, involving two or more CDNs serving 1909 content to each other's users, while federation implies a multi- 1910 lateral interconnection arrangement, but other CDN interconnection 1911 agreements are also possible (e.g., symmetric bilateral, asymmetric 1912 bilateral). An important conclusion is that CDNI technology should 1913 not presume (or bake in) a particular interconnection agreement, but 1914 should instead be general enough to permit alternative 1915 interconnection arrangements to evolve. 1917 The second concept often used in the context of CDN Federation is CDN 1918 Exchange--a third party broker or exchange that is used to facilitate 1919 a CDN federation. Our view is that a CDN exchange offers valuable 1920 machinery to scale the number of CDN operators involved in a multi- 1921 lateral (federated) agreement, but that this machinery is built on 1922 top of the core CDNI interconnection mechanisms. For example, as 1923 illustrated in Figure 14, the exchange might aggregate and 1924 redistribute information about each CDN footprint and capacity, as 1925 well as collect, filter, and re-distribute traffic logs that each 1926 participant needs for interconnection settlement, but inter-CDN 1927 request routing, inter-CDN content distribution (including inter-CDN 1928 acquisition) and inter-CDN control which fundamentally involve a 1929 direct interaction between an upstream CDN and a downstream CDN-- 1930 operate exactly as in a pair-wise peering arrangement. Turning to 1931 Figure 14, we observe that in this example: 1933 o each CDN supports a direct CDNI Control interface to every other 1934 CDN 1936 o each CDN supports a direct CDNI Metadata interface to every other 1937 CDN 1939 o each CDN supports a CDNI Logging interface with the CDN Exchange 1941 o each CDN supports both a CDNI request Routing interface with the 1942 CDN Exchange (for aggregation and redistribution of dynamic CDN 1943 footprint discovery information) and a direct CDNI Request Routing 1944 interface to every other CDN (for actual request redirection). 1946 ---------- --------- 1947 / CDN A \ / CDN B \ 1948 | +----+ | | +----+ | 1949 //========>| C |<==============CDNI============>| C |<==========\\ 1950 || | +----+ | C | +----+ | || 1951 || | +----+ | | +----+ | || 1952 || //=====>| D |<==============CDNI============>| D |<=======\\ || 1953 || || | +----+ | M | +----+ | || || 1954 || || | | /------------\ | | || || 1955 || || | +----+ | | +--+ CDN Ex| | +----+ | || || 1956 || || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || || 1957 || || || | +----+ | RR | +--+ | RR | +----+ | || || || 1958 || || || | | | /\ | | | || || || 1959 || || || | +----+ | | || +---+ | | +----+ | || || || 1960 || || || | | L |<===CDNI=======>| L |<=CDNI====>| L | | || || || 1961 || || || | +----+ | L | || +---+ | L | +----+ | || || || 1962 || || || \ / \ || /\ / \ / || || || 1963 || || || ----------- --||----||-- ----------- || || || 1964 || || || || || || || || 1965 || || || CDNI RR || || || || 1966 || || || || CDNI L || || || 1967 || || || || || || || || 1968 || || || ---||----||---- || || || 1969 || || || / \/ || \ || || || 1970 || || || | +----+ || | || || || 1971 || || \\=====CDNI==========>| RR |<=============CDNI========// || || 1972 || || RR | +----+ \/ | RR || || 1973 || || | +----+ | || || 1974 || || | | L | | || || 1975 || || | +----+ | || || 1976 || || | +----+ | || || 1977 || \\=======CDNI===========>| D |<=============CDNI===========// || 1978 || M | +----+ | M || 1979 || | +----+ | || 1980 \\==========CDNI===========>| C |<=============CDNI==============// 1981 C | +----+ | C 1982 \ CDN C / 1983 -------------- 1985 <=CDNI RR=> CDNI Request Routing interface 1986 <=CDNI M==> CDNI Metadata interface 1987 <=CDNI C==> CDNI Control interface 1988 <=CDNI L==> CDNI Logging interface 1990 Figure 14: CDNI Deployment Model: CDN Exchange 1992 Note that a CDN exchange may alternatively support a different set of 1993 functionality (e.g. Logging only, or Logging and full request 1994 routing, or all the functionality of a CDN including content 1995 distribution). All these options are expected to be allowed by the 1996 IETF CDNI specifications. 1998 6. Trust Model 2000 There are a number of trust issues that need to be addressed by a 2001 CDNI solution. Many of them are in fact similar or identical to 2002 those in a simple CDN without interconnection. In a standard CDN 2003 environment (without CDNI), the CSP places a degree of trust in a 2004 single CDN operator to perform many functions. The CDN is trusted to 2005 deliver content with appropriate quality of experience for the end 2006 user. The CSP trusts the CDN operator not to corrupt or modify the 2007 content. The CSP often relies on the CDN operator to provide 2008 reliable accounting information regarding the volume of delivered 2009 content. The CSP may also trust the CDN operator to perform actions 2010 such as timely invalidation of content and restriction of access to 2011 content based on certain criteria such as location of the user and 2012 time of day, and to enforce per-request authorization performed by 2013 the CSP using techniques such as URI signing. 2015 A CSP also places trust in the CDN not to distribute any information 2016 that is confidential to the CSP (e.g., how popular a given piece of 2017 content is) or confidential to the end user (e.g., which content has 2018 been watched by which user). 2020 A CSP does not necessarily have to place complete trust in a CDN. A 2021 CSP will in some cases take steps to protect its content from 2022 improper distribution by a CDN, e.g. by encrypting it and 2023 distributing keys in some out of band way. A CSP also depends on 2024 monitoring (possibly by third parties) and reporting to verify that 2025 the CDN has performed adequately. A CSP may use techniques such as 2026 client-based metering to verify that accounting information provided 2027 by the CDN is reliable. HTTP conditional requests may be used to 2028 provide the CSP with some checks on CDN operation. In other words, 2029 while a CSP may trust a CDN to perform some functions in the short 2030 term, the CSP is able in most cases to verify whether these actions 2031 have been performed correctly and to take action (such as moving the 2032 content to a different CDN) if the CDN does not live up to 2033 expectations. 2035 The main trust issue raised by CDNI is that it introduces transitive 2036 trust. A CDN that has a direct relationship with a CSP can now 2037 "outsource" the delivery of content to another (downstream) CDN. 2038 That CDN may in term outsource delivery to yet another downstream 2039 CDN, and so on. 2041 The top level CDN in such a chain of delegation is responsible for 2042 ensuring that the requirements of the CSP are met. Failure to do so 2043 is presumably just as serious as in the traditional single CDN case. 2044 Hence, an upstream CDN is essentially trusting a downstream CDN to 2045 perform functions on its behalf in just the same way as a CSP trusts 2046 a single CDN. Monitoring and reporting can similarly be used to 2047 verify that the downstream CDN has performed appropriately. However, 2048 the introduction of multiple CDNs in the path between CSP and end 2049 user complicates the picture. For example, third party monitoring of 2050 CDN performance (or other aspects of operation, such as timely 2051 invalidation) might be able to identify the fact that a problem 2052 occurred somewhere in the chain but not point to the particular CDN 2053 at fault. 2055 In summary, we assume that an upstream CDN will invest a certain 2056 amount of trust in a downstream CDN, but that it will verify that the 2057 downstream CDN is performing correctly, and take corrective action 2058 (including potentially breaking off its relationship with that CDN) 2059 if behavior is not correct. We do not expect that the trust 2060 relationship between a CSP and its "top level" CDN will differ 2061 significantly from that found today in single CDN situations. 2062 However, it does appear that more sophisticated tools and techniques 2063 for monitoring CDN performance and behavior will be required to 2064 enable the identification of the CDN at fault in a particular 2065 delivery chain. 2067 We expect that the detailed designs for the specific interfaces for 2068 CDNI will need to take the transitive trust issues into account. For 2069 example, explicit confirmation that some action (such as content 2070 removal) has taken place in a downstream CDN may help to mitigate 2071 some issues of transitive trust. 2073 7. IANA Considerations 2075 This memo includes no request to IANA. 2077 8. Security Considerations 2079 While there is a variety of security issues introduced by a single 2080 CDN, we are concerned here specifically with the additional issues 2081 that arise when CDNs are interconnected. For example, when a single 2082 CDN has the ability to distribute content on behalf of a CSP, there 2083 may be concerns that such content could be distributed to parties who 2084 are not authorized to receive it, and there are mechanisms to deal 2085 with such concerns. Our focus in this section is on how CDN 2086 interconnection introduces new security issues not found in the 2087 single CDN case. 2089 Many of the security issues that arise in CDNI are related to the 2090 transitivity of trust (or lack thereof) described in Section 6. As 2091 noted above, the design of the various interfaces for CDNI must take 2092 account of the additional risks posed by the fact that a CDN with 2093 whom a CSP has no direct relationship is now potentially distributing 2094 content for that CSP. The mechanisms used to mitigate these risks 2095 may be similar to those used in the single CDN case, but their 2096 suitability in this more complex environment must be validated. 2098 Another concern that arises in any CDN is that information about the 2099 behavior of users (what content they access, how much content they 2100 consume, etc.) may be gathered by the CDN. This risk certainly 2101 exists in inter-connected CDNs, but it should be possible to apply 2102 the same techniques to mitigate it as in the single CDN case. 2104 CDNs today offer a variety of means to control access to content, 2105 such as time-of-day restrictions, geo-blocking, and URI signing. 2106 These mechanisms must continue to function in CDNI environments, and 2107 this consideration is likely to affect the design of certain CDNI 2108 interfaces (e.g. metadata, request routing.) 2110 Just as with a single CDN, each peer CDN must ensure that it is not 2111 used as an "open proxy" to deliver content on behalf of a malicious 2112 CSP. Whereas a single CDN typically addresses this problem by having 2113 CSPs explicitly register content (or origin servers) that is to be 2114 served, simply propagating this information to peer downstream CDNs 2115 may be problematic because it reveals more information than the 2116 upstream CDN is willing to specify. (To this end, the content 2117 acquisition step in the earlier examples force the dCDN to retrieve 2118 content from the uCDN rather than go directly to the origin server.) 2120 There are several approaches to this problem. One is for the uCDN to 2121 encoded a signed token generated from a shared secret in each URL 2122 routed to a dCDN, and for the dCDN to validate the request based on 2123 this token. Another one is to have each upstream CDN advertise the 2124 set of CDN-domains they serve, where the downstream CDN checks each 2125 request against this set before caching and delivering the associated 2126 object. Although straightforward, this approach requires operators 2127 to reveal additional information, which may or may not be an issue. 2129 8.1. Security of CDNI Interfaces 2131 It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces 2132 must be able to operate securely over insecure IP networks. Since it 2133 is expected that the CDNI interfaces will be implemented using 2134 existing application protocols such as HTTP or XMPP, we also expect 2135 that the security mechanisms available to those protocols may be used 2136 by the CDNI interfaces. Details of how these interfaces are secured 2137 will be specified in the relevant interface documents. 2139 8.2. Digital Rights Management 2141 Issues of digital rights management (DRM, also sometimes called 2142 digital restrictions management) is often employed for content 2143 distributed via CDNs. In general, DRM relies on the CDN to 2144 distribute encrypted content, with decryption keys distributed to 2145 users by some other means (e.g. directly from the CSP to the end 2146 user.) For this reason, DRM is considered out of scope for the CDNI 2147 WG [I-D.ietf-cdni-problem-statement] and does not introduce 2148 additional security issues for CDNI. 2150 9. Contributors 2152 The following individuals contributed to this document: 2154 o Francois le Faucheur 2156 o Aaron Falk 2158 o David Ferguson 2160 o John Hartman 2162 o Ben Niven-Jenkins 2164 10. Acknowledgements 2166 We thank Huw Jones for their helpful input to the draft. 2168 11. Informative References 2170 [I-D.bertrand-cdni-logging] 2171 Bertrand, G. and S. Emile, "CDNI Logging Interface", 2172 draft-bertrand-cdni-logging-00 (work in progress), 2173 February 2012. 2175 [I-D.brandenburg-cdni-has] 2176 Brandenburg, R., "Models for adaptive-streaming-aware CDN 2177 Interconnection", draft-brandenburg-cdni-has-00 (work in 2178 progress), February 2012. 2180 [I-D.caulfield-cdni-metadata-core] 2181 Leung, K. and M. Caulfield, "Content Distribution Network 2182 Interconnection (CDNI) Core Metadata", 2183 draft-caulfield-cdni-metadata-core-00 (work in progress), 2184 October 2011. 2186 [I-D.ietf-cdni-problem-statement] 2187 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 2188 Distribution Network Interconnection (CDNI) Problem 2189 Statement", draft-ietf-cdni-problem-statement-04 (work in 2190 progress), March 2012. 2192 [I-D.ietf-cdni-requirements] 2193 Leung, K. and Y. Lee, "Content Distribution Network 2194 Interconnection (CDNI) Requirements", 2195 draft-ietf-cdni-requirements-02 (work in progress), 2196 December 2011. 2198 [I-D.ietf-cdni-use-cases] 2199 Bertrand, G., Emile, S., Watson, G., Burbridge, T., 2200 Eardley, P., and K. Ma, "Use Cases for Content Delivery 2201 Network Interconnection", draft-ietf-cdni-use-cases-04 2202 (work in progress), March 2012. 2204 [I-D.lefaucheur-cdni-logging-delivery] 2205 Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI 2206 Logging Formats for HTTP and HTTP Adaptive Streaming 2207 Deliveries", draft-lefaucheur-cdni-logging-delivery-00 2208 (work in progress), February 2012. 2210 [I-D.ma-cdni-metadata] 2211 Ma, K., "Content Distribution Network Interconnection 2212 (CDNI) Metadata Interface", draft-ma-cdni-metadata-02 2213 (work in progress), April 2012. 2215 [I-D.murray-cdni-triggers] 2216 Murray, R. and B. Niven-Jenkins, "CDN Interconnect 2217 Triggers", draft-murray-cdni-triggers-00 (work in 2218 progress), February 2012. 2220 [I-D.previdi-cdni-footprint-advertisement] 2221 Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and 2222 L. Faucheur, "CDNI Footprint Advertisement", 2223 draft-previdi-cdni-footprint-advertisement-01 (work in 2224 progress), March 2012. 2226 [I-D.seedorf-alto-for-cdni] 2227 Seedorf, J., "ALTO for CDNi Request Routing", 2228 draft-seedorf-alto-for-cdni-00 (work in progress), 2229 October 2011. 2231 [I-D.vandergaast-edns-client-subnet] 2232 Contavalli, C., Gaast, W., Leach, S., and E. Lewis, 2233 "Client subnet in DNS requests", 2234 draft-vandergaast-edns-client-subnet-01 (work in 2235 progress), April 2012. 2237 [I-D.xiaoyan-cdni-request-routing-protocol] 2238 He, X., Dawkins, S., Li, J., and G. Chen, "Request Routing 2239 Protocol for CDN Interconnection", 2240 draft-xiaoyan-cdni-request-routing-protocol-00 (work in 2241 progress), October 2011. 2243 [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model 2244 for Content Internetworking (CDI)", RFC 3466, 2245 February 2003. 2247 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2248 Optimization (ALTO) Problem Statement", RFC 5693, 2249 October 2009. 2251 Authors' Addresses 2253 Larry Peterson (editor) 2254 Verivue, Inc. 2255 2 Technology Park Drive 2256 Westford, MA 2257 USA 2259 Phone: +1 978 303 8032 2260 Email: lpeterson@verivue.com 2262 Bruce Davie 2263 Nicira Networks, Inc. 2264 3460 W. Bayshore Rd. 2265 Palo Alto, CA 94303 2266 USA 2268 Email: bsd@nicira.com