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