| < draft-ietf-cdni-framework-10.txt | draft-ietf-cdni-framework-14.txt > | |||
|---|---|---|---|---|
| Network Working Group L. Peterson | Network Working Group L. Peterson | |||
| Internet-Draft Akamai Technologies, Inc. | Internet-Draft Akamai Technologies, Inc. | |||
| Obsoletes: 3466 (if approved) B. Davie | Obsoletes: 3466 (if approved) B. Davie | |||
| Intended status: Informational VMware, Inc. | Intended status: Informational VMware, Inc. | |||
| Expires: September 4, 2014 R. van Brandenburg, Ed. | Expires: December 8, 2014 R. van Brandenburg, Ed. | |||
| TNO | TNO | |||
| March 3, 2014 | June 6, 2014 | |||
| Framework for CDN Interconnection | Framework for CDN Interconnection | |||
| draft-ietf-cdni-framework-10 | draft-ietf-cdni-framework-14 | |||
| Abstract | Abstract | |||
| This document presents a framework for Content Distribution Network | This document presents a framework for Content Distribution Network | |||
| Interconnection (CDNI). The purpose of the framework is to provide | Interconnection (CDNI). The purpose of the framework is to provide | |||
| an overall picture of the problem space of CDNI and to describe the | an overall picture of the problem space of CDNI and to describe the | |||
| relationships among the various components necessary to interconnect | relationships among the various components necessary to interconnect | |||
| CDNs. CDN Interconnection requires the specification of interfaces | CDNs. CDN Interconnection requires the specification of interfaces | |||
| and mechanisms to address issues such as request routing, | and mechanisms to address issues such as request routing, | |||
| distribution metadata exchange, and logging information exchange | distribution metadata exchange, and logging information exchange | |||
| across CDNs. The intent of this document is to outline what each | across CDNs. The intent of this document is to outline what each | |||
| interface needs to accomplish, and to describe how these interfaces | interface needs to accomplish, and to describe how these interfaces | |||
| and mechanisms fit together, while leaving their detailed | and mechanisms fit together, while leaving their detailed | |||
| specification to other documents. It obsoletes RFC 3466. | specification to other documents. This document, in combination with | |||
| RFC 6707, obsoletes RFC 3466. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 4, 2014. | This Internet-Draft will expire on December 8, 2014. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1.3. Structure Of This Document . . . . . . . . . . . . . . . 8 | 1.3. Structure Of This Document . . . . . . . . . . . . . . . 9 | |||
| 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 | 2. Building Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 8 | 2.1. Request Redirection . . . . . . . . . . . . . . . . . . . 9 | |||
| 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 8 | 2.1.1. DNS Redirection . . . . . . . . . . . . . . . . . . . 9 | |||
| 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 9 | 2.1.2. HTTP Redirection . . . . . . . . . . . . . . . . . . 11 | |||
| 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 10 | 3. Overview of CDNI Operation . . . . . . . . . . . . . . . . . 11 | |||
| 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 12 | 3.1. Preliminaries . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 13 | 3.2. Iterative HTTP Redirect Example . . . . . . . . . . . . . 14 | |||
| 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 18 | 3.3. Recursive HTTP Redirection Example . . . . . . . . . . . 19 | |||
| 3.4. Iterative DNS-based Redirection Example . . . . . . 22 | 3.4. Iterative DNS-based Redirection Example . . . . . . . . . 23 | |||
| 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 25 | 3.4.1. Notes on using DNSSEC . . . . . . . . . . . . . . . . 27 | |||
| 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 27 | 3.5. Dynamic Footprint Discovery Example . . . . . . . . . . . 28 | |||
| 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 28 | 3.6. Content Removal Example . . . . . . . . . . . . . . . . . 30 | |||
| 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 29 | 3.7. Pre-Positioned Content Acquisition Example . . . . . . . 31 | |||
| 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 31 | 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . 32 | |||
| 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 34 | ||||
| 3.10. Content and Metadata Acquisition with Multiple Upstream | 3.10. Content and Metadata Acquisition with Multiple Upstream | |||
| CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | CDNs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
| 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34 | 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 35 | 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 38 | |||
| 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 35 | 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . 38 | |||
| 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 36 | 4.3. Request Routing Interfaces . . . . . . . . . . . . . . . 39 | |||
| 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 37 | 4.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . 40 | |||
| 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 39 | 4.5. CDNI Control Interface . . . . . . . . . . . . . . . . . 42 | |||
| 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 39 | 4.6. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 42 | |||
| 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 40 | 4.7. HTTP Adaptive Streaming Concerns . . . . . . . . . . . . 43 | |||
| 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 42 | 4.8. URI Rewriting . . . . . . . . . . . . . . . . . . . . . . 44 | |||
| 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43 | 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 45 | |||
| 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 43 | 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
| 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44 | 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 47 | |||
| 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 45 | 5.3. CSP using CDNI Request Routing Interface . . . . . . . . 47 | |||
| 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46 | 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 48 | |||
| 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49 | 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 52 | |||
| 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 | |||
| 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52 | 9.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 54 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 | 9.2. Digital Rights Management . . . . . . . . . . . . . . . . 54 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| 11. Informative References . . . . . . . . . . . . . . . . . . . 52 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 | 12. Informative References . . . . . . . . . . . . . . . . . . . 55 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 | ||||
| 1. Introduction | 1. Introduction | |||
| This document provides an overview of the various components | This document provides an overview of the various components | |||
| necessary to interconnect CDNs, expanding on the problem statement | necessary to interconnect CDNs, expanding on the problem statement | |||
| and use cases introduced in [RFC6770] and [RFC6707]. It describes | and use cases introduced in [RFC6770] and [RFC6707]. It describes | |||
| the necessary interfaces and mechanisms in general terms and outlines | the necessary interfaces and mechanisms in general terms and outlines | |||
| how they fit together to form a complete system for CDN | how they fit together to form a complete system for CDN | |||
| Interconnection. Detailed specifications are left to other | Interconnection. Detailed specifications are left to other | |||
| documents. This document makes extensive use of message flow | documents. This document makes extensive use of message flow | |||
| skipping to change at page 3, line 34 ¶ | skipping to change at page 3, line 41 ¶ | |||
| [RFC3466] uses different terminology and models for "Content | [RFC3466] uses different terminology and models for "Content | |||
| Internetworking (CDI)". It is also less prescriptive in terms of | Internetworking (CDI)". It is also less prescriptive in terms of | |||
| interfaces. To avoid confusion, this document obsoletes [RFC3466]. | interfaces. To avoid confusion, this document obsoletes [RFC3466]. | |||
| 1.1. Terminology | 1.1. Terminology | |||
| This document uses the core terminology defined in [RFC6707]. It | This document uses the core terminology defined in [RFC6707]. It | |||
| also introduces the following terms: | also introduces the following terms: | |||
| CDN-Domain: a host name (FQDN) at the beginning of a URL, | CDN-Domain: a host name (FQDN) at the beginning of a URL (excluding | |||
| representing a set of content that is served by a given CDN. For | port and scheme), representing a set of content that is served by a | |||
| example, in the URL http://cdn.csp.example/...rest of url..., the CDN | given CDN. For example, in the URL http://cdn.csp.example/...rest of | |||
| domain is cdn.csp.example. A major role of CDN-Domain is to identify | url..., the CDN domain is cdn.csp.example. A major role of CDN- | |||
| a region (subset) of the URI space relative to which various CDN | Domain is to identify a region (subset) of the URI space relative to | |||
| Interconnection rules and policies are to apply. For example, a | which various CDN Interconnection rules and policies are to apply. | |||
| record of CDN Metadata might be defined for the set of resources | For example, a record of CDN Metadata might be defined for the set of | |||
| corresponding to some CDN-Domain. | resources corresponding to some CDN-Domain. | |||
| Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for | Distinguished CDN-Domain: a CDN-Domain that is allocated by a CDN for | |||
| the purposes of communication with a peer CDN, but which is not found | the purposes of communication with a peer CDN, but which is not found | |||
| in client requests. Such CDN-Domains may be used for inter-CDN | in client requests. Such CDN-Domains may be used for inter-CDN | |||
| acquisition, or as redirection targets, and enable a CDN to | acquisition, or as redirection targets, and enable a CDN to | |||
| distinguish a request from a peer CDN from an end-user request. | distinguish a request from a peer CDN from an end-user request. | |||
| Delivering CDN: the CDN that ultimately delivers a piece of content | Delivering CDN: the CDN that ultimately delivers a piece of content | |||
| to the end-user. The last in a potential sequence of downstream | to the end-user. The last in a potential sequence of downstream | |||
| CDNs. | CDNs. | |||
| Recursive CDNI Request Redirection: When an upstream CDN elects to | ||||
| redirect a request towards a downstream CDN, the upstream CDN can | ||||
| query the downstream CDN Request Routing system via the CDNI Request | ||||
| Routing Redirection Interface (or use information cached from earlier | ||||
| similar queries) to find out how the downstream CDN wants the request | ||||
| to be redirected, which allows the upstream CDN to factor in the | ||||
| downstream CDN response when redirecting the user agent. This | ||||
| approach is referred to as "Recursive" CDNI Request Redirection. | ||||
| Note that the downstream CDN may elect to have the request redirected | ||||
| directly to a Surrogate inside the downstream CDN, to the Request | ||||
| Routing System of the downstream CDN, to another CDN, or to whatever | ||||
| system is necessary to handle the redirected request appropriately. | ||||
| Iterative CDNI Request Redirection: When an upstream CDN elects to | Iterative CDNI Request Redirection: When an upstream CDN elects to | |||
| redirect a request towards a downstream CDN, the upstream CDN can | redirect a request towards a downstream CDN, the upstream CDN can | |||
| base its redirection purely on a local decision (and without | base its redirection purely on a local decision (and without | |||
| attempting to take into account how the downstream CDN may in turn | attempting to take into account how the downstream CDN may in turn | |||
| redirect the user agent). In that case, the upstream CDN redirects | redirect the user agent). In that case, the upstream CDN redirects | |||
| the request to the request routing system in the downstream CDN, | the request to the request routing system in the downstream CDN, | |||
| which in turn will decide how to redirect that request: this approach | which in turn will decide how to redirect that request: this approach | |||
| is referred to as "Iterative" CDNI Request Redirection. | is referred to as "Iterative" CDNI Request Redirection. | |||
| Recursive CDNI Request Redirection: When an upstream CDN elects to | ||||
| redirect a request towards a downstream CDN, the upstream CDN can | ||||
| query the downstream CDN Request Routing system via the CDNI Request | ||||
| Routing Redirection Interface (or use information cached from earlier | ||||
| similar queries) to find out how the downstream CDN wants the request | ||||
| to be redirected. This allows the upstream CDN to factor in the | ||||
| downstream CDN response when redirecting the user agent. This | ||||
| approach is referred to as "Recursive" CDNI Request Redirection. | ||||
| Note that the downstream CDN may elect to have the request redirected | ||||
| directly to a Surrogate inside the downstream CDN, or to any other | ||||
| element in the downstream CDN (or in another CDN) to handle the | ||||
| redirected request appropriately. | ||||
| Synchronous CDNI operations: operations between CDNs that happen | Synchronous CDNI operations: operations between CDNs that happen | |||
| during the process of servicing a user request, i.e. between the time | during the process of servicing a user request, i.e. between the time | |||
| that the user agent begins its attempt to obtain content and the time | that the user agent begins its attempt to obtain content and the time | |||
| at which that request is served. | at which that request is served. | |||
| Asynchronous CDNI operations: operations between CDNs that happen | Asynchronous CDNI operations: operations between CDNs that happen | |||
| independently of any given user request, such as advertisement of | independently of any given user request, such as advertisement of | |||
| footprint information or pre-positioning of content for later | footprint information or pre-positioning of content for later | |||
| delivery. | delivery. | |||
| Trigger Interface: a subset of the CDNI Control interface that | Trigger Interface: a subset of the CDNI Control interface that | |||
| includes operations to pre-position, revalidate, and purge both | includes operations to pre-position, revalidate, and purge both | |||
| metadata and content. These operations are typically called in | metadata and content. These operations are typically called in | |||
| response to some action (Trigger) by the CSP on the upstream CDN. | response to some action (Trigger) by the Content Service Provider | |||
| (CSP) on the upstream CDN. | ||||
| We also sometimes use uCDN and dCDN as shorthand for upstream CDN and | We also sometimes use uCDN and dCDN as shorthand for upstream CDN and | |||
| downstream CDN, respectively. | downstream CDN (see [RFC6707]), respectively. | |||
| At various points in this document, the concept of a CDN footprint is | ||||
| used. For a discussion on what constitutes a CDN footprint, the | ||||
| reader is referred to | ||||
| [I-D.ietf-cdni-footprint-capabilities-semantics]. | ||||
| 1.2. Reference Model | 1.2. Reference Model | |||
| This document uses the reference model in Figure 1, which expands the | This document uses the reference model in Figure 1, which expands the | |||
| reference model originally defined in [RFC6707]. (The difference is | reference model originally defined in [RFC6707]. (The difference is | |||
| that the expanded model splits the Request Routing Interface into its | that the expanded model splits the Request Routing Interface into its | |||
| two distinct parts: the Request Routing Redirection interface and the | two distinct parts: the Request Routing Redirection interface and the | |||
| Footprint and Capabilities Advertisement interface, as described | Footprint and Capabilities Advertisement interface, as described | |||
| below.) | below.) | |||
| -------- | -------- | |||
| skipping to change at page 7, line 22 ¶ | skipping to change at page 8, line 22 ¶ | |||
| * Offline exchanges, suitable for analytics and billing. | * Offline exchanges, suitable for analytics and billing. | |||
| The division between the sets of Trigger-based operations in the CDNI | The division between the sets of Trigger-based operations in the CDNI | |||
| Control interface and the CDNI Metadata interface is somewhat | Control interface and the CDNI Metadata interface is somewhat | |||
| arbitrary. For both cases, the information passed from the upstream | arbitrary. For both cases, the information passed from the upstream | |||
| CDN to the downstream CDN can broadly be viewed as metadata that | CDN to the downstream CDN can broadly be viewed as metadata that | |||
| describes how content is to be managed by the downstream CDN. For | describes how content is to be managed by the downstream CDN. For | |||
| example, the information conveyed by CI to pre-position, revalidate | example, the information conveyed by CI to pre-position, revalidate | |||
| or purge metadata is similar to the information conveyed by posting | or purge metadata is similar to the information conveyed by posting | |||
| updated metadata via the MI. Even the CI operation to purge content | updated metadata via the MI. Even the CI operation to purge content | |||
| could be viewed as an metadata update for that content: purge simply | could be viewed as a metadata update for that content: purge simply | |||
| says that the availability window for the named content ends now. | says that the availability window for the named content ends now. | |||
| The two interfaces share much in common, so minimally, there will | The two interfaces share much in common, so minimally, there will | |||
| need to be a consistent data model that spans both. | need to be a consistent data model that spans both. | |||
| The distinction we draw has to do with what the uCDN knows about the | The distinction we draw has to do with what the uCDN knows about the | |||
| successful application of the metadata by the dCDN. In the case of | successful application of the metadata by the dCDN. In the case of | |||
| the CI, the downstream CDN returning a successful status message | the CI, the downstream CDN returning a successful status message | |||
| guarantees that the operation has been successfully completed; e.g., | guarantees that the operation has been successfully completed; e.g., | |||
| the content has been purged or pre-positioned. This implies that the | the content has been purged or pre-positioned. This implies that the | |||
| downstream CDN accepts responsibility for having successfully | downstream CDN accepts responsibility for having successfully | |||
| skipping to change at page 8, line 34 ¶ | skipping to change at page 9, line 34 ¶ | |||
| 2. Building Blocks | 2. Building Blocks | |||
| 2.1. Request Redirection | 2.1. Request Redirection | |||
| At its core, CDN Interconnection requires the redirection of requests | At its core, CDN Interconnection requires the redirection of requests | |||
| from one CDN to another. For any given request that is received by | from one CDN to another. For any given request that is received by | |||
| an upstream CDN, it will either respond to the request directly, or | an upstream CDN, it will either respond to the request directly, or | |||
| somehow redirect the request to a downstream CDN. Two main | somehow redirect the request to a downstream CDN. Two main | |||
| mechanisms are available for redirecting a request to a downstream | mechanisms are available for redirecting a request to a downstream | |||
| CDN. The first leverages the DNS name resolution process and the | CDN. The first leverages the DNS name resolution process and the | |||
| second uses in-protocol redirection mechanisms such as the HTTP 302 | second uses application-layer redirection mechanisms such as the HTTP | |||
| or 307 redirection response. We discuss these below as background | 302 or RTSP 302 redirection responses. While there exists a large | |||
| before discussing some examples of their use in Section 3. | variety of application-layer protocols that include some form of | |||
| redirection mechanism, this document will use HTTP (and HTTPS) in its | ||||
| examples. Similar mechanisms can be applied to other application- | ||||
| layer protocols. What follows is a short discussion of both DNS- and | ||||
| HTTP-based redirection, before presenting some examples of their use | ||||
| in Section 3. | ||||
| 2.1.1. DNS Redirection | 2.1.1. DNS Redirection | |||
| DNS redirection is based on returning different IP addresses for the | DNS redirection is based on returning different IP addresses for the | |||
| same DNS name, for example, to balance server load or to account for | same DNS name, for example, to balance server load or to account for | |||
| the client's location in the network. A DNS server, sometimes called | the client's location in the network. A DNS server, sometimes called | |||
| the Local DNS (LDNS), resolves DNS names on behalf of an end-user. | the Local DNS (LDNS), resolves DNS names on behalf of an end-user. | |||
| The LDNS server in turn queries other DNS servers until it reaches | The LDNS server in turn queries other DNS servers until it reaches | |||
| the authoritative DNS server for the CDN-Domain. The network | the authoritative DNS server for the CDN-Domain. The network | |||
| operator typically provides the LDNS server, although the user is | operator typically provides the LDNS server, although the user is | |||
| skipping to change at page 9, line 36 ¶ | skipping to change at page 10, line 40 ¶ | |||
| In CNAME-based DNS redirection, the authoritative server returns a | In CNAME-based DNS redirection, the authoritative server returns a | |||
| CNAME response to the DNS request, telling the LDNS server to restart | CNAME response to the DNS request, telling the LDNS server to restart | |||
| the name lookup using a new name. A CNAME is essentially a symbolic | the name lookup using a new name. A CNAME is essentially a symbolic | |||
| link in the DNS namespace, and like a symbolic link, redirection is | link in the DNS namespace, and like a symbolic link, redirection is | |||
| transparent to the client; the LDNS server gets the CNAME response | transparent to the client; the LDNS server gets the CNAME response | |||
| and re-executes the lookup. Only when the name has been resolved to | and re-executes the lookup. Only when the name has been resolved to | |||
| an IP address does it return the result to the user. Note that DNAME | an IP address does it return the result to the user. Note that DNAME | |||
| would be preferable to CNAME if it becomes widely supported. | would be preferable to CNAME if it becomes widely supported. | |||
| One of the advantages of DNS redirection compared to HTTP redirection | ||||
| is that it can be cached, reducing load on the redirecting CDN's DNS | ||||
| server. However, this advantage can also be a drawback, especially | ||||
| when a given DNS resolver doesn't strictly adhere to the TTL, which | ||||
| is a known problem in some real world environments. In such cases, | ||||
| an end-user might end up at a dCDN without first having passed | ||||
| through the uCDN, which might be an undesirable scenario from a uCDN | ||||
| point of view. | ||||
| 2.1.2. HTTP Redirection | 2.1.2. HTTP Redirection | |||
| HTTP redirection makes use of the redirection response of the HTTP | HTTP redirection makes use of the redirection response of the HTTP | |||
| protocol (e.g.,"302" or "307"). This response contains a new URL | protocol (e.g.,"302" or "307"). This response contains a new URL | |||
| that the application should fetch instead of the original URL. By | that the application should fetch instead of the original URL. By | |||
| changing the URL appropriately, the server can cause the user to | changing the URL appropriately, the server can cause the user to | |||
| redirect to a different server. The advantages of HTTP redirection | redirect to a different server. The advantages of HTTP redirection | |||
| are that (1) the server can change the URL fetched by the client to | are that (1) the server can change the URL fetched by the client to | |||
| include, for example, both the DNS name of the particular server to | include, for example, both the DNS name of the particular server to | |||
| use, as well as the original HTTP server that was being accessed; (2) | use, as well as the original HTTP server that was being accessed; (2) | |||
| the client sends the HTTP request to the server, so that its IP | the client sends the HTTP request to the server, so that its IP | |||
| address is known and can be used in selecting the server; and (3) | address is known and can be used in selecting the server; and (3) | |||
| other attributes (e.g., content type, user agent type) are visible to | other attributes (e.g., content type, user agent type) are visible to | |||
| the redirection mechanism. | the redirection mechanism. | |||
| The disadvantages of HTTP redirection are (1) it is visible to the | Just as is the case for DNS redirection, there are some potential | |||
| application, so it requires application support and may affect the | disadvantages of using HTTP redirection. For example, it may affect | |||
| application behavior (e.g., web browsers will not send cookies if the | application behavior, e.g. web browsers will not send cookies if the | |||
| URL changes to a different domain); (2) HTTP is a heavyweight | URL changes to a different domain. In addition, although this might | |||
| protocol layered on TCP so it has relatively high overhead; and (3) | also be an advantage, results of HTTP redirection are not cached so | |||
| the results of HTTP redirection are not cached so that all | that all redirections must go through to the uCDN. | |||
| redirections must go through to the server. | ||||
| 3. Overview of CDNI Operation | 3. Overview of CDNI Operation | |||
| To provide a big picture overview of the various components of CDN | To provide a big picture overview of the various components of CDN | |||
| Interconnection, we walk through a "day in the life" of a content | Interconnection, we walk through a "day in the life" of a content | |||
| item that is made available via a pair of interconnected CDNs. This | item that is made available via a pair of interconnected CDNs. This | |||
| will serve to illustrate many of the functions that need to be | will serve to illustrate many of the functions that need to be | |||
| supported in a complete CDNI solution. We give examples using both | supported in a complete CDNI solution. We give examples using both | |||
| DNS-based and HTTP-based redirection. We begin with very simple | DNS-based and HTTP-based redirection. We begin with very simple | |||
| examples and then how additional capabilities, such as recursive | examples and then show how additional capabilities, such as recursive | |||
| request redirection and content removal, might be added. | request redirection and content removal, might be added. | |||
| Before walking through some specific examples, we present a high- | Before walking through the specific examples, we present a high-level | |||
| level view of the operations that may take place. This high-level | view of the operations that may take place. This high-level overview | |||
| overview is illustrated in Figure 2. Note that most operations will | is illustrated in Figure 2. Note that most operations will involve | |||
| involve only a subset of all the messages shown below, and that the | only a subset of all the messages shown below, and that the order and | |||
| order and number of operations may vary considerably, as more | number of operations may vary considerably, as the more detailed | |||
| detailed examples illustrate below. | examples illustrate. | |||
| The following shows Operator A as the upstream CDN (uCDN) and | The following shows Operator A as the upstream CDN (uCDN) and | |||
| Operator B as the downstream CDN (dCDN), where the former has a | Operator B as the downstream CDN (dCDN), where the former has a | |||
| relationship with a content provider and the latter being the CDN | relationship with a content provider and the latter being the CDN | |||
| selected by Operator A to deliver content to the end-user. The | selected by Operator A to deliver content to the end-user. The | |||
| interconnection relationship may be symmetric between these two CDN | interconnection relationship may be symmetric between these two CDN | |||
| operators, but each direction can be considered as operating | operators, but each direction can be considered as operating | |||
| independently of the other so for simplicity we show the interaction | independently of the other so for simplicity we show the interaction | |||
| in one direction only. | in one direction only. | |||
| skipping to change at page 11, line 17 ¶ | skipping to change at page 12, line 17 ¶ | |||
| | | | | | | | | |||
| | | [Async FCI Push] | (1) | | | [Async FCI Push] | (1) | |||
| | | | | | | | | |||
| | | [MI pre-positioning] | (2) | | | [MI pre-positioning] | (2) | |||
| | | | | | | | | |||
| | CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
| |-------------------------------------------------->| (3) | |-------------------------------------------------->| (3) | |||
| | | | | | | | | |||
| | | [Sync RI Pull] | (4) | | | [Sync RI Pull] | (4) | |||
| | | | | | | | | |||
| | RI REPLY | | | | CONTENT REQUEST REDIRECTION | | |||
| |<--------------------------------------------------| (5) | |<--------------------------------------------------| (5) | |||
| | | | | | | | | |||
| | | | | | | | | |||
| | CONTENT REQUEST | | | | CONTENT REQUEST | | | |||
| |------------------------>| | (6) | |------------------------>| | (6) | |||
| | | | | | | | | |||
| | | [Sync MI Pull] | (7) | | | [Sync MI Pull] | (7) | |||
| | | | | | | | | |||
| | | ACQUISITION REQUEST | | | | ACQUISITION REQUEST | | |||
| | X------------------------>| (8) | | X------------------------>| (8) | |||
| skipping to change at page 13, line 18 ¶ | skipping to change at page 14, line 18 ¶ | |||
| makes a request for URL | makes a request for URL | |||
| http://cdn.csp.example/...rest of url... | http://cdn.csp.example/...rest of url... | |||
| It may well be the case that cdn.csp.example is just a CNAME for some | It may well be the case that cdn.csp.example is just a CNAME for some | |||
| other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP | other CDN-Domain (such as csp.op-a.example). Nevertheless, the HTTP | |||
| request in the examples that follow is assumed to be for the example | request in the examples that follow is assumed to be for the example | |||
| URL above. | URL above. | |||
| Our goal is to enable content identified by the above URL to be | Our goal is to enable content identified by the above URL to be | |||
| served by the CDN of operator B. In the following sections we will | served by the CDN of operator B. In the following sections we will | |||
| walk through some scenarios in which content is served, as well as | walk through some scenarios in which content is served, as well as | |||
| other CDNI operations such as the removal of content from a | other CDNI operations such as the removal of content from a | |||
| downstream CDN. | downstream CDN. | |||
| 3.2. Iterative HTTP Redirect Example | 3.2. Iterative HTTP Redirect Example | |||
| In this section we walk through a simple, illustrative example using | In this section we walk through a simple, illustrative example using | |||
| HTTP redirection from uCDN to dCDN. The example also assumes the use | HTTP redirection from uCDN to dCDN. The example also assumes the use | |||
| of HTTP redirection inside uCDN and dCDN; however, this is | of HTTP redirection inside uCDN and dCDN; however, this is | |||
| independent of the choice of redirection approach across CDNs, so an | independent of the choice of redirection approach across CDNs, so an | |||
| skipping to change at page 14, line 14 ¶ | skipping to change at page 15, line 14 ¶ | |||
| region or a set of IP address prefixes. This information may again | region or a set of IP address prefixes. This information may again | |||
| be provided out of band or via a defined CDNI interface. | be provided out of band or via a defined CDNI interface. | |||
| We assume DNS is configured in the following way: | We assume DNS is configured in the following way: | |||
| o The content provider is configured to make operator A the | o The content provider is configured to make operator A the | |||
| authoritative DNS server for cdn.csp.example (or to return a CNAME | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
| for cdn.csp.example for which operator A is the authoritative DNS | for cdn.csp.example for which operator A is the authoritative DNS | |||
| server). | server). | |||
| o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for op-b-acq.op- | |||
| op-b-acq.op-a.example returns a request router in Operator A. | a.example returns a request router in Operator A. | |||
| o Operator B is configured so that a DNS request for | o Operator B is configured so that a DNS request for peer-a.op- | |||
| peer-a.op-b.example/cdn.csp.example returns a request router in | b.example/cdn.csp.example returns a request router in Operator B. | |||
| Operator B. | ||||
| Figure 3 illustrates how a client request for | Figure 3 illustrates how a client request for | |||
| http://cdn.csp.example/...rest of url... | http://cdn.csp.example/...rest of url... | |||
| is handled. | is handled. | |||
| End-User Operator B Operator A | End-User Operator B Operator A | |||
| |DNS cdn.csp.example | | | |DNS cdn.csp.example | | | |||
| |-------------------------------------------------->| | |-------------------------------------------------->| | |||
| skipping to change at page 16, line 7 ¶ | skipping to change at page 17, line 4 ¶ | |||
| recognizes that the end-user is best served by another CDN, | recognizes that the end-user is best served by another CDN, | |||
| specifically one provided by Operator B, and so it returns a 302 | specifically one provided by Operator B, and so it returns a 302 | |||
| redirect message for a new URL constructed by "stacking" | redirect message for a new URL constructed by "stacking" | |||
| Operator B's distinguished CDN-Domain (peer-a.op-b.example) on | Operator B's distinguished CDN-Domain (peer-a.op-b.example) on | |||
| the front of the original URL. (Note that more complex URL | the front of the original URL. (Note that more complex URL | |||
| manipulations are possible, such as replacing the initial CDN- | manipulations are possible, such as replacing the initial CDN- | |||
| Domain by some opaque handle.) | Domain by some opaque handle.) | |||
| 3. The end-user does a DNS lookup using Operator B's distinguished | 3. The end-user does a DNS lookup using Operator B's distinguished | |||
| CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the | CDN-Domain (peer-a.op-b.example). B's DNS resolver returns the | |||
| IP address of a request router for Operator B. Note that if | IP address of a request router for Operator B. Note that if | |||
| request routing within dCDN was performed using DNS instead of | request routing within dCDN was performed using DNS instead of | |||
| HTTP redirection, B's DNS resolver would also behave as the | HTTP redirection, B's DNS resolver would also behave as the | |||
| request router and directly return the IP address of a delivery | request router and directly return the IP address of a delivery | |||
| node. | node. | |||
| 4. The request router for Operator B processes the HTTP request and | 4. The request router for Operator B processes the HTTP request and | |||
| selects a suitable delivery node to serve the end-user request, | selects a suitable delivery node to serve the end-user request, | |||
| and returns a 302 redirect message for a new URL constructed by | and returns a 302 redirect message for a new URL constructed by | |||
| replacing the hostname with a subdomain of the Operator B's | replacing the hostname with a subdomain of the Operator B's | |||
| distinguished CDN-Domain that points to the selected delivery | distinguished CDN-Domain that points to the selected delivery | |||
| skipping to change at page 17, line 35 ¶ | skipping to change at page 18, line 35 ¶ | |||
| it is DNS or HTTP based). | it is DNS or HTTP based). | |||
| One disadvantage is that the end-user's browser is redirected to a | One disadvantage is that the end-user's browser is redirected to a | |||
| new URL that is not in the same domain of the original URL. This has | new URL that is not in the same domain of the original URL. This has | |||
| implications on a number of security or validation mechanisms | implications on a number of security or validation mechanisms | |||
| sometimes used on endpoints. For example, it is important that any | sometimes used on endpoints. For example, it is important that any | |||
| redirected URL be in the same domain (e.g., csp.example) if the | redirected URL be in the same domain (e.g., csp.example) if the | |||
| browser is expected to send any cookies associated with that domain. | browser is expected to send any cookies associated with that domain. | |||
| As another example, some video players enforce validation of a cross | As another example, some video players enforce validation of a cross | |||
| domain policy that needs to accommodate the domains involved in the | domain policy that needs to accommodate the domains involved in the | |||
| CDN redirection. These problems are generally soluble, but the | CDN redirection. These problems are generally solvable, but the | |||
| solutions complicate the example, so we do not discuss them further | solutions complicate the example, so we do not discuss them further | |||
| in this version of the draft. | in this document. | |||
| We note that this example begins to illustrate some of the interfaces | We note that this example begins to illustrate some of the interfaces | |||
| that may be required for CDNI, but does not require all of them. For | that may be required for CDNI, but does not require all of them. For | |||
| example, obtaining information from dCDN regarding the set of client | example, obtaining information from dCDN regarding the set of client | |||
| IP addresses or geographic regions it might be able to serve is an | IP addresses or geographic regions it might be able to serve is an | |||
| aspect of request routing (specifically of the CDNI Footprint & | aspect of request routing (specifically of the CDNI Footprint & | |||
| Capabilities Advertisement interface). Important configuration | Capabilities Advertisement interface). Important configuration | |||
| information such as the distinguished names used for redirection and | information such as the distinguished names used for redirection and | |||
| inter-CDN acquisition could also be conveyed via a CDNI interface | inter-CDN acquisition could also be conveyed via a CDNI interface | |||
| (e.g., perhaps the CDNI Control interface). The example also shows | (e.g., perhaps the CDNI Control interface). The example also shows | |||
| skipping to change at page 18, line 31 ¶ | skipping to change at page 19, line 31 ¶ | |||
| performs the rest of the redirection function by redirecting to a | performs the rest of the redirection function by redirecting to a | |||
| suitable surrogate. If request routing is performed in the dCDN | suitable surrogate. If request routing is performed in the dCDN | |||
| using HTTP redirection, this translates in the end-user experiencing | using HTTP redirection, this translates in the end-user experiencing | |||
| two successive HTTP redirections. By contrast, the alternative | two successive HTTP redirections. By contrast, the alternative | |||
| approach of "recursive" CDNI request redirection effectively | approach of "recursive" CDNI request redirection effectively | |||
| coalesces these two successive HTTP redirections into a single one, | coalesces these two successive HTTP redirections into a single one, | |||
| sending the end-user directly to the right delivery node in the dCDN. | sending the end-user directly to the right delivery node in the dCDN. | |||
| This "recursive" CDNI request routing approach is discussed in the | This "recursive" CDNI request routing approach is discussed in the | |||
| next section. | next section. | |||
| While the example above uses HTTP, the iterative HTTP redirection | ||||
| mechanism would work over HTTPS in a similar fashion. In order to | ||||
| make sure an end-user's HTTPS request is not downgraded to HTTP along | ||||
| the redirection path, it is necessary for every request router along | ||||
| the path from the initial uCDN Request Router to the final surrogate | ||||
| in the dCDN to respond to an incoming HTTPS request with an HTTP | ||||
| Redirect containing an HTTPS URL. It should be noted that using | ||||
| HTTPS will have the effect of increasing the total redirection | ||||
| process time and increasing the load on the request routers, | ||||
| especially when the redirection path includes many redirects and thus | ||||
| many TLS/SSL sessions. In such cases, a recursive HTTP redirection | ||||
| mechanism, as described in an example in the next section, might help | ||||
| to reduce some of these issues. | ||||
| 3.3. Recursive HTTP Redirection Example | 3.3. Recursive HTTP Redirection Example | |||
| The following example builds on the previous one to illustrate the | The following example builds on the previous one to illustrate the | |||
| use of the request routing interface (specifically the CDNI Request | use of the request routing interface (specifically the CDNI Request | |||
| Routing Redirection interface) to enable "recursive" CDNI request | Routing Redirection interface) to enable "recursive" CDNI request | |||
| routing. We build on the HTTP-based redirection approach because it | routing. We build on the HTTP-based redirection approach because it | |||
| illustrates the principles and benefits clearly, but it is equally | illustrates the principles and benefits clearly, but it is equally | |||
| possible to perform recursive redirection when DNS-based redirection | possible to perform recursive redirection when DNS-based redirection | |||
| is employed. | is employed. | |||
| In contrast to the prior example, the operators need not agree in | In contrast to the prior example, the operators need not agree in | |||
| advance on a CDN-Domain to serve as the target of redirections from | advance on a CDN-Domain to serve as the target of redirections from | |||
| uCDN to dCDN. We assume that the operators agree on some | uCDN to dCDN. We assume that the operators agree on some | |||
| distinguished CDN-Domain that will be used for inter-CDN acquisition | distinguished CDN-Domain that will be used for inter-CDN acquisition | |||
| of CSP's content by dCDN. In this example, we'll use | of CSP's content by dCDN. In this example, we'll use op-b-acq.op- | |||
| op-b-acq.op-a.example. | a.example. | |||
| We assume the operators also exchange information regarding which | We assume the operators also exchange information regarding which | |||
| requests dCDN is prepared to serve. For example, dCDN may be | requests dCDN is prepared to serve. For example, dCDN may be | |||
| prepared to serve requests from clients in a given geographical | prepared to serve requests from clients in a given geographical | |||
| region or a set of IP address prefixes. This information may again | region or a set of IP address prefixes. This information may again | |||
| be provided out of band or via a defined protocol. | be provided out of band or via a defined protocol. | |||
| We assume DNS is configured in the following way: | We assume DNS is configured in the following way: | |||
| o The content provider is configured to make operator A the | o The content provider is configured to make operator A the | |||
| authoritative DNS server for cdn.csp.example (or to return a CNAME | authoritative DNS server for cdn.csp.example (or to return a CNAME | |||
| for cdn.csp.example for which operator A is the authoritative DNS | for cdn.csp.example for which operator A is the authoritative DNS | |||
| server). | server). | |||
| o Operator A is configured so that a DNS request for | o Operator A is configured so that a DNS request for op-b-acq.op- | |||
| op-b-acq.op-a.example returns a request router in Operator A. | a.example returns a request router in Operator A. | |||
| o Operator B is configured so that a request for node1.op-b.example/ | o Operator B is configured so that a request for node1.op-b.example/ | |||
| cdn.csp.example returns the IP address of a delivery node. Note | cdn.csp.example returns the IP address of a delivery node. Note | |||
| that there might be a number of such delivery nodes. | that there might be a number of such delivery nodes. | |||
| Figure 3 illustrates how a client request for | Figure 3 illustrates how a client request for | |||
| http://cdn.csp.example/...rest of url... | http://cdn.csp.example/...rest of url... | |||
| is handled. | is handled. | |||
| skipping to change at page 21, line 24 ¶ | skipping to change at page 22, line 36 ¶ | |||
| avoid being tricked into serving as an open proxy). It then does | avoid being tricked into serving as an open proxy). It then does | |||
| a DNS request for the inter-CDN Acquisition "distinguished" CDN- | a DNS request for the inter-CDN Acquisition "distinguished" CDN- | |||
| Domain as agreed above (in this case, op-b-acq.op-a.example). | Domain as agreed above (in this case, op-b-acq.op-a.example). | |||
| 6. Operator A DNS resolver processes the DNS request and returns the | 6. Operator A DNS resolver processes the DNS request and returns the | |||
| IP address of a request router in operator A. | IP address of a request router in operator A. | |||
| 7. The request router for Operator A processes the HTTP request from | 7. The request router for Operator A processes the HTTP request from | |||
| Operator B delivery node. Operator A request router recognizes | Operator B delivery node. Operator A request router recognizes | |||
| that the request is from a peer CDN rather than an end-user | that the request is from a peer CDN rather than an end-user | |||
| because of the dedicated inter-CDN acquisition domain | because of the dedicated inter-CDN acquisition domain (op-b- | |||
| (op-b-acq.op-a.example). (Note that without this specially | acq.op-a.example). (Note that without this specially defined | |||
| defined inter-CDN acquisition domain, operator A would be at risk | inter-CDN acquisition domain, operator A would be at risk of | |||
| of redirecting the request back to operator B, resulting in an | redirecting the request back to operator B, resulting in an | |||
| infinite loop). The request router for Operator A selects a | infinite loop). The request router for Operator A selects a | |||
| suitable delivery node in uCDN to serve the inter-CDN acquisition | suitable delivery node in uCDN to serve the inter-CDN acquisition | |||
| request and returns a 302 redirect message for a new URL | request and returns a 302 redirect message for a new URL | |||
| constructed by replacing the hostname with a subdomain of the | constructed by replacing the hostname with a subdomain of the | |||
| Operator A's distinguished inter-CDN acquisition domain that | Operator A's distinguished inter-CDN acquisition domain that | |||
| points to the selected delivery node. | points to the selected delivery node. | |||
| 8. Operator A recognizes that the DNS request is from a peer CDN | 8. Operator A recognizes that the DNS request is from a peer CDN | |||
| rather than an end-user (due to the internal CDN-Domain) and so | rather than an end-user (due to the internal CDN-Domain) and so | |||
| returns the address of a delivery node. (Note that without this | returns the address of a delivery node. (Note that without this | |||
| skipping to change at page 22, line 37 ¶ | skipping to change at page 23, line 48 ¶ | |||
| redirection for request redirection from uCDN to dCDN (as well as for | redirection for request redirection from uCDN to dCDN (as well as for | |||
| request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- | request routing inside dCDN and uCDN). As noted in Section 2.1, DNS- | |||
| based redirection has certain advantages over HTTP-based redirection | based redirection has certain advantages over HTTP-based redirection | |||
| (notably, it is transparent to the end-user) as well as some | (notably, it is transparent to the end-user) as well as some | |||
| drawbacks (notably the client IP address is not visible to the | drawbacks (notably the client IP address is not visible to the | |||
| request router). | request router). | |||
| As before, Operator A has to learn the set of requests that dCDN is | As before, Operator A has to learn the set of requests that dCDN is | |||
| willing or able to serve (e.g. which client IP address prefixes or | willing or able to serve (e.g. which client IP address prefixes or | |||
| geographic regions are part of the dCDN footprint). We assume | geographic regions are part of the dCDN footprint). We assume | |||
| Operator has and makes known to operator A some unique identifier | Operator B has and makes known to Operator A some unique identifier | |||
| that can be used for the construction of a distinguished CDN-Domain, | that can be used for the construction of a distinguished CDN-Domain, | |||
| as shown in more detail below. (This identifier strictly needs only | as shown in more detail below. (This identifier strictly needs only | |||
| to be unique within the scope of Operator A, but a globally unique | to be unique within the scope of Operator A, but a globally unique | |||
| identifier, such as an AS number assigned to B, is one easy way to | identifier, such as an AS number assigned to B, is one easy way to | |||
| achieve that.) Also, Operator A obtains the NS records for Operator | achieve that.) Also, Operator A obtains the NS records for Operator | |||
| B's externally visible redirection servers. Also, as before, a | B's externally visible redirection servers. Also, as before, a | |||
| distinguished CDN-Domain, such as op-b-acq.op-a.example, must be | distinguished CDN-Domain, such as op-b-acq.op-a.example, must be | |||
| assigned for inter-CDN acquisition. | assigned for inter-CDN acquisition. | |||
| We assume DNS is configured in the following way: | We assume DNS is configured in the following way: | |||
| o The CSP is configured to make Operator A the authoritative DNS | o The CSP is configured to make Operator A the authoritative DNS | |||
| server for cdn.csp.example (or to return a CNAME for | server for cdn.csp.example (or to return a CNAME for | |||
| cdn.csp.example for which operator A is the authoritative DNS | cdn.csp.example for which operator A is the authoritative DNS | |||
| server). | server). | |||
| o When uCDN sees a request best served by dCDN, it returns CNAME and | o When uCDN sees a request best served by dCDN, it returns CNAME and | |||
| NS records for "b.cdn.csp.example", where "b" is the unique | NS records for "b.cdn.csp.example", where "b" is the unique | |||
| identifier assigned to Operator B. (It may, for example, be an AS | identifier assigned to Operator B. (It may, for example, be an AS | |||
| number assigned to Operator B.) | number assigned to Operator B.) | |||
| o dCDN is configured so that a request for "b.cdn.csp.example" | o dCDN is configured so that a request for "b.cdn.csp.example" | |||
| returns a delivery node in dCDN. | returns a delivery node in dCDN. | |||
| o uCDN is configured so that a request for "op-b-acq.op-a.example" | o uCDN is configured so that a request for "op-b-acq.op-a.example" | |||
| returns a delivery node in uCDN. | returns a delivery node in uCDN. | |||
| Figure 5 depicts the exchange of DNS and HTTP requests. The main | Figure 5 depicts the exchange of DNS and HTTP requests. The main | |||
| differences from Figure 3 are the lack of HTTP redirection and | differences from Figure 3 are the lack of HTTP redirection and | |||
| transparency to the end-user. | transparency to the end-user. | |||
| End-User Operator B Operator A | End-User Operator B Operator A | |||
| |DNS cdn.csp.example | | | |DNS cdn.csp.example | | | |||
| |-------------------------------------------------->| | |-------------------------------------------------->| | |||
| | | |(1) | | | |(1) | |||
| |CNAME b.cdn.csp.example | | | |CNAME b.cdn.csp.example | | | |||
| |NS records for b.cdn.csp.example | | ||||
| |<--------------------------------------------------| | |<--------------------------------------------------| | |||
| | | | | ||||
| |DNS b.cdn.csp.example | | | ||||
| |-------------------------------------------------->| | ||||
| | | |(2) | ||||
| |NS records for b.cdn.csp.example + | | ||||
| |Glue AAAA/A records for b.cdn.csp.example | | ||||
| |<--------------------------------------------------| | ||||
| | | | | ||||
| |DNS b.cdn.csp.example | | | |DNS b.cdn.csp.example | | | |||
| |------------------------>| | | |------------------------>| | | |||
| | |(2) | | | |(3) | | |||
| |IPaddr of B's Delivery Node | | |IPaddr of B's Delivery Node | | |||
| |<------------------------| | | |<------------------------| | | |||
| |HTTP cdn.csp.example | | | |HTTP cdn.csp.example | | | |||
| |------------------------>| | | |------------------------>| | | |||
| | |(3) | | | |(4) | | |||
| | |DNS op-b-acq.op-a.example| | | |DNS op-b-acq.op-a.example| | |||
| | |------------------------>| | | |------------------------>| | |||
| | | |(4) | | | |(5) | |||
| | |IPaddr of A's Delivery Node | | |IPaddr of A's Delivery Node | |||
| | |<------------------------| | | |<------------------------| | |||
| | |HTTP op-b-acq.op-a.example | | |HTTP op-b-acq.op-a.example | |||
| | |------------------------>| | | |------------------------>| | |||
| | | |(5) | | | |(6) | |||
| | |Data | | | |Data | | |||
| | |<------------------------| | | |<------------------------| | |||
| |Data | | | |Data | | | |||
| |<------------------------| | | |<------------------------| | | |||
| Figure 5: Message Flow for DNS-based Redirection | Figure 5: Message Flow for DNS-based Redirection | |||
| The steps illustrated in the figure are as follows: | The steps illustrated in the figure are as follows: | |||
| 1. Request Router for Operator A processes the DNS request for CDN- | 1. Request Router for Operator A processes the DNS request for CDN- | |||
| Domain cdn.csp.example and recognizes that the end-user is best | Domain cdn.csp.example and recognizes that the end-user is best | |||
| served by another CDN. (This may depend on the IP address of the | served by another CDN. (This may depend on the IP address of the | |||
| user's local DNS resolver, or other information discussed below.) | user's local DNS resolver, or other information discussed below.) | |||
| The Request Router returns a DNS CNAME response by "stacking" the | The Request Router returns a DNS CNAME response by "stacking" the | |||
| distinguished identifier for Operator B onto the original CDN- | distinguished identifier for Operator B onto the original CDN- | |||
| Domain (e.g., b.cdn.csp.example), plus an NS record that maps | Domain (e.g., b.cdn.csp.example). | |||
| b.cdn.csp.example to B's Request Router. | ||||
| 2. The end-user does a DNS lookup using the modified CDN-Domain | 2. The end-user sends a DNS query for the modified CDN-Domain (i.e. | |||
| (i.e., b.cdn.csp.example). This causes B's Request Router to | b.cdn.csp.example) to Operator A's DNS server. The Request | |||
| respond with a suitable delivery node. | Router for Operator A processes the DNS request and return a | |||
| delegation to b.cdn.csp.example by sending an NS record plus glue | ||||
| AAAA/A records pointing to Operator B's DNS server. (This extra | ||||
| step is necessary since typical DNS implementation won't follow | ||||
| an NS record when it is sent together with a CNAME record, | ||||
| thereby necessitating a two-step approach). | ||||
| 3. The end-user requests the content from B's delivery node. The | 3. The end-user sends a DNS query for the modified CDN-Domain (i.e., | |||
| b.cdn.csp.example) to Operator B's DNS server, using the NS and | ||||
| AAAA/A records received in step 2. This causes B's Request | ||||
| Router to respond with a suitable delivery node. | ||||
| 4. The end-user requests the content from B's delivery node. The | ||||
| requested URL contains the name cdn.csp.example. (Note that the | requested URL contains the name cdn.csp.example. (Note that the | |||
| returned CNAME does not affect the URL.) At this point the | returned CNAME does not affect the URL.) At this point the | |||
| delivery node has the correct IP address of the end-user and can | delivery node has the correct IP address of the end-user and can | |||
| do an HTTP 302 redirect if the redirections in steps 2 and 3 were | do an HTTP 302 redirect if the redirections in steps 2 and 3 were | |||
| incorrect. Otherwise B verifies that this CDN-Domain belongs to | incorrect. Otherwise B verifies that this CDN-Domain belongs to | |||
| a known peer (so as to avoid being tricked into serving as an | a known peer (so as to avoid being tricked into serving as an | |||
| open proxy). It then does a DNS request for an "internal" CDN- | open proxy). It then does a DNS request for an "internal" CDN- | |||
| Domain as agreed above (op-b-acq.op-a.example). | Domain as agreed above (op-b-acq.op-a.example). | |||
| 4. Operator A recognizes that the DNS request is from a peer CDN | 5. Operator A recognizes that the DNS request is from a peer CDN | |||
| rather than an end-user (due to the internal CDN-Domain) and so | rather than an end-user (due to the internal CDN-Domain) and so | |||
| returns the address of a delivery node in uCDN. | returns the address of a delivery node in uCDN. | |||
| 5. Operator A serves content to dCDN. Although not shown, it is at | 6. Operator A serves content to dCDN. Although not shown, it is at | |||
| this point that Operator A processes the rest of the URL: it | this point that Operator A processes the rest of the URL: it | |||
| extracts information identifying the origin server, validates | extracts information identifying the origin server, validates | |||
| that this server has been registered, and determines the content | that this server has been registered, and determines the content | |||
| provider that owns the origin server. | provider that owns the origin server. | |||
| The advantages of this approach are that it is more transparent to | The advantages of this approach are that it is more transparent to | |||
| the end-user and requires fewer round trips than HTTP-based | the end-user and requires fewer round trips than HTTP-based | |||
| redirection (in its worst case, i.e., when none of the needed DNS | redirection (in its worst case, i.e., when none of the needed DNS | |||
| information is cached). A potential problem is that the upstream CDN | information is cached). A potential problem is that the upstream CDN | |||
| depends on being able to learn the correct downstream CDN that serves | depends on being able to learn the correct downstream CDN that serves | |||
| skipping to change at page 25, line 8 ¶ | skipping to change at page 27, line 9 ¶ | |||
| user uses a global DNS service--then the upstream CDN cannot | user uses a global DNS service--then the upstream CDN cannot | |||
| determine the appropriate downstream CDN to serve the end-user. In | determine the appropriate downstream CDN to serve the end-user. In | |||
| this case, and assuming the uCDN is capable of detecting that | this case, and assuming the uCDN is capable of detecting that | |||
| situation, one option is for the upstream CDN to treat the end-user | situation, one option is for the upstream CDN to treat the end-user | |||
| as it would any user not connected to a peer CDN. Another option is | as it would any user not connected to a peer CDN. Another option is | |||
| for the upstream CDN to "fall back" to a pure HTTP-based redirection | for the upstream CDN to "fall back" to a pure HTTP-based redirection | |||
| strategy in this case (i.e., use the first method). Note that this | strategy in this case (i.e., use the first method). Note that this | |||
| problem affects existing CDNs that rely on DNS to determine where to | problem affects existing CDNs that rely on DNS to determine where to | |||
| redirect client requests, but the consequences are arguably less | redirect client requests, but the consequences are arguably less | |||
| serious for CDNI since the LDNS is likely in the same network as the | serious for CDNI since the LDNS is likely in the same network as the | |||
| dCDN serves. One approach to ensuring that the client's IP address | dCDN serves. | |||
| prefix is correctly determined in such situations is described in | ||||
| [I-D.vandergaast-edns-client-subnet]. | ||||
| As with the prior example, this example partially illustrates the | As with the prior example, this example partially illustrates the | |||
| various interfaces involved in CDNI. Operator A could learn | various interfaces involved in CDNI. Operator A could learn | |||
| dynamically from Operator B the set of prefixes or regions that B is | dynamically from Operator B the set of prefixes or regions that B is | |||
| willing and able to serve via the CDNI Footprint & Capabilities | willing and able to serve via the CDNI Footprint & Capabilities | |||
| Advertisement interface. The distinguished name used for acquisition | Advertisement interface. The distinguished name used for acquisition | |||
| and the identifier for Operator B that is prepended to the CDN-Domain | and the identifier for Operator B that is prepended to the CDN-Domain | |||
| on redirection are examples of information elements that might also | on redirection are examples of information elements that might also | |||
| be conveyed by CDNI interfaces (or, alternatively, statically | be conveyed by CDNI interfaces (or, alternatively, statically | |||
| configured). As before, minimal metadata sufficient to obtain the | configured). As before, minimal metadata sufficient to obtain the | |||
| content is carried "in-band" as part of the redirection process, and | content is carried "in-band" as part of the redirection process, and | |||
| standard HTTP is used for inter-CDN acquisition. There is no | standard HTTP is used for inter-CDN acquisition. There is no | |||
| explicit CDNI Logging interface discussed in this example. | explicit CDNI Logging interface discussed in this example. | |||
| 3.4.1. Notes on using DNSSEC | ||||
| Although it is possible to use DNSSEC in combination with the | ||||
| Iterative DNS-based Redirection mechanism explained above, it is | ||||
| important to note that the uCDN might have to sign records on the | ||||
| fly, since the CNAME returned, and thus the signature provided, can | ||||
| potentially be different for each incoming query. Although there is | ||||
| nothing preventing a uCDN from performing such on-the-fly signing, | ||||
| this might be computationally expensive. In the case where the | ||||
| number of dCDNs, and thus the number of different CNAMEs to return, | ||||
| is relatively stable, an alternative solution would be for the uCDN | ||||
| to pre-generate signatures for all possible CNAMEs. For each | ||||
| incoming query the uCDN would then determine the appropriate CNAME | ||||
| and return it together with the associated pre-generated signature. | ||||
| Note: In the latter case maintaining the serial and signature of SOA | ||||
| might be an issue since technically it should change every time a | ||||
| different CNAME is used. However, since in practice direct SOA | ||||
| queries are relatively rare, a uCDN could defer incrementing the | ||||
| serial and resigning the SOA until it is queried and then do it on- | ||||
| the-fly. | ||||
| Note also that the NS record and the glue AAAA/A records used in step | ||||
| 2 in the previous section should generally be identical to those of | ||||
| their authoritative zone managed by Operator B. Even if they differ, | ||||
| this will not make the DNS resolution process fail, but the client | ||||
| DNS server will prefer the authoritative data in its cache and use it | ||||
| for subsequent queries. Such inconsistency is a general operational | ||||
| issue of DNS, but it may be more important for this architecture | ||||
| because the uCDN (operator A) would rely on the consistency to make | ||||
| the resulting redirection work as intended. In general, it is the | ||||
| administrator's responsibility to make them consistent. | ||||
| 3.5. Dynamic Footprint Discovery Example | 3.5. Dynamic Footprint Discovery Example | |||
| There could be situations where being able to dynamically discover | There could be situations where being able to dynamically discover | |||
| the set of requests that a given dCDN is willing and able to serve is | the set of requests that a given dCDN is willing and able to serve is | |||
| beneficial. For example, a CDN might at one time be able to serve a | beneficial. For example, a CDN might at one time be able to serve a | |||
| certain set of client IP prefixes, but that set might change over | certain set of client IP prefixes, but that set might change over | |||
| time due to changes in the topology and routing policies of the IP | time due to changes in the topology and routing policies of the IP | |||
| network. The following example illustrates this capability. We have | network. The following example illustrates this capability. We have | |||
| chosen the example of DNS-based redirection, but HTTP-based | chosen the example of DNS-based redirection, but HTTP-based | |||
| redirection could equally well use this approach. | redirection could equally well use this approach. | |||
| skipping to change at page 26, line 42 ¶ | skipping to change at page 29, line 42 ¶ | |||
| | |------------------------>| | | |------------------------>| | |||
| | | |(5) | | | |(5) | |||
| | |Data | | | |Data | | |||
| | |<------------------------| | | |<------------------------| | |||
| |Data | | | |Data | | | |||
| |<------------------------| | | |<------------------------| | | |||
| Figure 6: Message Flow for Dynamic Footprint Discovery | Figure 6: Message Flow for Dynamic Footprint Discovery | |||
| This example differs from the one in Figure 5 only in the addition of | This example differs from the one in Figure 5 only in the addition of | |||
| a FCI request (step 2) and corresponding response (step 3). The RI | a RI request (step 2) and corresponding response (step 3). The RI | |||
| REQ could be a message such as "Can you serve clients from this IP | REQ could be a message such as "Can you serve clients from this IP | |||
| Prefix?" or it could be "Provide the list of client IP prefixes you | Prefix?" or it could be "Provide the list of client IP prefixes you | |||
| can currently serve". In either case the response might be cached by | can currently serve". In either case the response might be cached by | |||
| operator A to avoid repeatedly asking the same question. | operator A to avoid repeatedly asking the same question. | |||
| Alternatively, or in addition, Operator B may spontaneously advertise | Alternatively, or in addition, Operator B may spontaneously advertise | |||
| to Operator A information (or changes) on the set of requests it is | to Operator A information (or changes) on the set of requests it is | |||
| willing and able to serve on behalf of operator A; in that case, | willing and able to serve on behalf of operator A; in that case, | |||
| Operator B may spontaneously issue RR/RI REPLY messages that are not | Operator B may spontaneously issue RR/RI REPLY messages that are not | |||
| in direct response to a corresponding RR/RI REQ message. (Note that | in direct response to a corresponding RR/RI REQ message. (Note that | |||
| the issues of determining the client's subnet from DNS requests, as | the issues of determining the client's subnet from DNS requests, as | |||
| skipping to change at page 27, line 24 ¶ | skipping to change at page 30, line 24 ¶ | |||
| 3.6. Content Removal Example | 3.6. Content Removal Example | |||
| The following example illustrates how the CDNI Control interface may | The following example illustrates how the CDNI Control interface may | |||
| be used to achieve pre-positioning of an item of content in the dCDN. | be used to achieve pre-positioning of an item of content in the dCDN. | |||
| In this example, user requests for a particular content, and | In this example, user requests for a particular content, and | |||
| corresponding redirection of such requests from Operator A to | corresponding redirection of such requests from Operator A to | |||
| Operator B CDN, may (or may not) have taken place earlier. Then, at | Operator B CDN, may (or may not) have taken place earlier. Then, at | |||
| some point in time, the uCDN (for example, in response to a | some point in time, the uCDN (for example, in response to a | |||
| corresponding Trigger from the Content Provider) uses the CI to | corresponding Trigger from the Content Provider) uses the CI to | |||
| request that content identified by a particular URL be removed from | request that content identified by a particular URL be removed from | |||
| dCDN. The following diagram illustrates the operation. | dCDN. The following diagram illustrates the operation. It should be | |||
| noted that a uCDN will typically not know whether a dCDN has cached a | ||||
| given content item, however, it may send the content removal request | ||||
| to make sure no cached versions remain to satisfy any contractual | ||||
| obligations it may have. | ||||
| End-User Operator B Operator A | End-User Operator B Operator A | |||
| | |CI purge cdn.csp.example/... | | |CI purge cdn.csp.example/... | |||
| | |<------------------------| | | |<------------------------| | |||
| | | | | | | | | |||
| | |CI OK | | | |CI OK | | |||
| | |------------------------>| | | |------------------------>| | |||
| | | | | | | | | |||
| Figure 7: Message Flow for Content Removal | Figure 7: Message Flow for Content Removal | |||
| skipping to change at page 31, line 12 ¶ | skipping to change at page 34, line 12 ¶ | |||
| 4. Operator A replies with the requested metadata. This document | 4. Operator A replies with the requested metadata. This document | |||
| does not constrain how the CDNI metadata information is actually | does not constrain how the CDNI metadata information is actually | |||
| represented. For the purposes of this example, we assume that | represented. For the purposes of this example, we assume that | |||
| Operator A provides CDNI metadata to Operator B indicating that: | Operator A provides CDNI metadata to Operator B indicating that: | |||
| * this CDNI Metadata is applicable to any content referenced by | * this CDNI Metadata is applicable to any content referenced by | |||
| some CDN-Domain. | some CDN-Domain. | |||
| * this CDNI metadata consists of a distribution policy | * this CDNI metadata consists of a distribution policy | |||
| requiring enforcement by the delivery node of a specific per- | requiring enforcement by the delivery node of a specific per- | |||
| request authorization mechanism (e.g. URI signature or token | request authorization mechanism (e.g. URI signature or token | |||
| validation). | validation). | |||
| 5. A Content Request occurs as usual. | 5. A Content Request occurs as usual. | |||
| 6. A CDNI Request Routing Redirection request (RI REQ) is issued by | 6. A CDNI Request Routing Redirection request (RI REQ) is issued by | |||
| operator A CDN, as discussed in Section 3.3. Operator B's | operator A CDN, as discussed in Section 3.3. Operator B's | |||
| request router can access the CDNI Metadata that are relevant to | request router can access the CDNI Metadata that are relevant to | |||
| the requested content and that have been pre-positioned as per | the requested content and that have been pre-positioned as per | |||
| Steps 1-4, which may or may not affect the response. | Steps 1-4, which may or may not affect the response. | |||
| skipping to change at page 35, line 8 ¶ | skipping to change at page 38, line 8 ¶ | |||
| One interface that is not shown in Figure 1 is the interface between | One interface that is not shown in Figure 1 is the interface between | |||
| the user and the CSP. While for the purposes of CDNI that interface | the user and the CSP. While for the purposes of CDNI that interface | |||
| is out of scope, it is worth noting that it does exist and can | is out of scope, it is worth noting that it does exist and can | |||
| provide useful functions, such as end-to-end performance monitoring | provide useful functions, such as end-to-end performance monitoring | |||
| and some forms of authentication and authorization. | and some forms of authentication and authorization. | |||
| There is also an important interface between the user and the Request | There is also an important interface between the user and the Request | |||
| Routing function of both uCDN and dCDN (shown as the "Request" | Routing function of both uCDN and dCDN (shown as the "Request" | |||
| Interface in Figure 1). As we saw in some of the preceding examples, | Interface in Figure 1). As we saw in some of the preceding examples, | |||
| that interface can be used as a way of passing information a subset | that interface can be used as a way of passing metadata, such as the | |||
| of metadata such as the minimum information that is required for dCDN | minimum information that is required for dCDN to obtain the content | |||
| to obtain the content from uCDN. | from uCDN. | |||
| In this section we will provide an overview of the functions | In this section we will provide an overview of the functions | |||
| performed by each of the CDNI interfaces and discuss how they fit | performed by each of the CDNI interfaces and discuss how they fit | |||
| into the overall solution. We also examine some of the design | into the overall solution. We also examine some of the design | |||
| tradeoffs, and explore several cross-interface concerns. We begin | tradeoffs, and explore several cross-interface concerns. We begin | |||
| with an examination of one such tradeoff that affects all the | with an examination of one such tradeoff that affects all the | |||
| interfaces - the use of in-band or out-of-band communication. | interfaces - the use of in-band or out-of-band communication. | |||
| 4.1. In-Band versus Out-of-Band Interfaces | 4.1. In-Band versus Out-of-Band Interfaces | |||
| skipping to change at page 38, line 14 ¶ | skipping to change at page 41, line 14 ¶ | |||
| o Bytes Sent - the number of bytes in the body sent to the client | o Bytes Sent - the number of bytes in the body sent to the client | |||
| o Request ID - a unique identifier for this transfer | o Request ID - a unique identifier for this transfer | |||
| o User agent - the user agent, if supplied | o User agent - the user agent, if supplied | |||
| o Duration - the duration of the transfer in milliseconds | o Duration - the duration of the transfer in milliseconds | |||
| o Cached Bytes - the number of body bytes served from the cache | o Cached Bytes - the number of body bytes served from the cache | |||
| o Referrer - the referrer string from the client, if supplied | o Referer - the referrer string from the client, if supplied | |||
| Of these, only the Domain field is indirect in the downstream CDN--it | Of these, only the Domain field is indirect in the downstream CDN--it | |||
| is set to the CDN-Domain used by the upstream CDN rather than the | is set to the CDN-Domain used by the upstream CDN rather than the | |||
| actual origin server. This field could then used to filter traffic | actual origin server. This field could then used to filter traffic | |||
| log entries so only those entries matching the upstream CDN are | log entries so only those entries matching the upstream CDN are | |||
| reported to the corresponding operator. Further discussion of the LI | reported to the corresponding operator. Further discussion of the LI | |||
| can be found in [I-D.ietf-cdni-logging]. | can be found in [I-D.ietf-cdni-logging]. | |||
| One open question is who does the filtering. One option is that the | One open question is who does the filtering. One option is that the | |||
| downstream CDN filters its own logs, and passes the relevant records | downstream CDN filters its own logs, and passes the relevant records | |||
| skipping to change at page 40, line 12 ¶ | skipping to change at page 43, line 12 ¶ | |||
| time window or inability to make use of a downstream CDN that covers | time window or inability to make use of a downstream CDN that covers | |||
| a broader footprint than the geo-blocking restrictions. | a broader footprint than the geo-blocking restrictions. | |||
| Similarly, some forms of access control may also be performed on a | Similarly, some forms of access control may also be performed on a | |||
| per-request basis using HTTP directives. For example, being able to | per-request basis using HTTP directives. For example, being able to | |||
| respond to a conditional GET request gives the upstream CDN an | respond to a conditional GET request gives the upstream CDN an | |||
| opportunity to influence how the downstream CDN delivers its content. | opportunity to influence how the downstream CDN delivers its content. | |||
| Minimally, the upstream CDN can invalidate (purge) content previously | Minimally, the upstream CDN can invalidate (purge) content previously | |||
| cached by the downstream CDN. | cached by the downstream CDN. | |||
| Fine-grain control over how the downstream CDN delivers content on | ||||
| behalf of the upstream CDN is also possible. For example, by | ||||
| including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded] | ||||
| with the conditional GET request, the downstream CDN can report the | ||||
| end-user's IP address to the upstream CDN, giving it an opportunity | ||||
| to control whether the downstream CDN should serve the content to | ||||
| this particular end-user. The upstream CDN would communicate its | ||||
| directive through its response to the conditional GET. The | ||||
| downstream CDN can cache information for a period of time specified | ||||
| by the upstream CDN, thereby reducing control overhead, but then | ||||
| preventing per-request control during the corresponding caching | ||||
| period. | ||||
| All of these in-band techniques serve to illustrate that uCDNs have | All of these in-band techniques serve to illustrate that uCDNs have | |||
| the option of enforcing some of their access control policies | the option of enforcing some of their access control policies | |||
| themselves (at the expense of increased inter-CDN signaling load), | themselves (at the expense of increased inter-CDN signaling load), | |||
| rather than delegating enforcement to dCDNs using the MI. As a | rather than delegating enforcement to dCDNs using the MI. As a | |||
| consequence, the MI could provide a means for the uCDN to express its | consequence, the MI could provide a means for the uCDN to express its | |||
| desire to retain enforcement for itself. For example, this might be | desire to retain enforcement for itself. For example, this might be | |||
| done by including a "check with me" flag in the metadata associated | done by including a "check with me" flag in the metadata associated | |||
| with certain content. The realization of such in-band techniques | with certain content. The realization of such in-band techniques | |||
| over the various inter-CDN acquisition protocols (e.g., HTTP) | over the various inter-CDN acquisition protocols (e.g., HTTP) | |||
| requires further investigation and may require small extensions or | requires further investigation and may require small extensions or | |||
| skipping to change at page 42, line 13 ¶ | skipping to change at page 44, line 48 ¶ | |||
| alternatively, they may remain distinct. | alternatively, they may remain distinct. | |||
| 4.8. URI Rewriting | 4.8. URI Rewriting | |||
| When using HTTP redirection, content URIs may be rewritten when | When using HTTP redirection, content URIs may be rewritten when | |||
| redirection takes place within an uCDN, from an uCDN to a dCDN, and | redirection takes place within an uCDN, from an uCDN to a dCDN, and | |||
| within the dCDN. In the case of cascaded CDNs, content URIs may be | within the dCDN. In the case of cascaded CDNs, content URIs may be | |||
| rewritten at every CDN hop (e.g., between the uCDN and the dCDN | rewritten at every CDN hop (e.g., between the uCDN and the dCDN | |||
| acting as the transit CDN, and between the transit CDN and the dCDN | acting as the transit CDN, and between the transit CDN and the dCDN | |||
| serving the request. The content URI used between any uCDN/dCDN pair | serving the request. The content URI used between any uCDN/dCDN pair | |||
| becomes a common handle that can be referred without ambiguity by | becomes a common handle that can be referred to without ambiguity by | |||
| both CDNs in all their inter-CDN communications. This handle allows | both CDNs in all their inter-CDN communications. This handle allows | |||
| the uCDN and dCDN to correlate information exchanged using other CDNI | the uCDN and dCDN to correlate information exchanged using other CDNI | |||
| interfaces in both the downstream direction (e.g., when using the MI) | interfaces in both the downstream direction (e.g., when using the MI) | |||
| and the upstream direction (e.g., when using the LI). | and the upstream direction (e.g., when using the LI). | |||
| Consider the simple case of a single uCDN/dCDN pair using HTTP | Consider the simple case of a single uCDN/dCDN pair using HTTP | |||
| redirection. We introduce the following terminology for content URIs | redirection. We introduce the following terminology for content URIs | |||
| to simplify the discussion: | to simplify the discussion: | |||
| "u-URI" represents a content URI in a request presented to the | "u-URI" represents a content URI in a request presented to the | |||
| skipping to change at page 42, line 39 ¶ | skipping to change at page 45, line 27 ¶ | |||
| "d-URI" represents a content URI in a request made within the | "d-URI" represents a content URI in a request made within the | |||
| delegate dCDN. | delegate dCDN. | |||
| In our simple pair-wise example, the "ud-URI" effectively becomes the | In our simple pair-wise example, the "ud-URI" effectively becomes the | |||
| handle that the uCDN/dCDN pair use to correlate all CDNI information. | handle that the uCDN/dCDN pair use to correlate all CDNI information. | |||
| In particular, for a given pair of CDNs executing the HTTP | In particular, for a given pair of CDNs executing the HTTP | |||
| redirection, the uCDN needs to map the u-URI to the ud-URI handle for | redirection, the uCDN needs to map the u-URI to the ud-URI handle for | |||
| all MI message exchanges, while the dCDN needs to map the d-URI to | all MI message exchanges, while the dCDN needs to map the d-URI to | |||
| the ud-URI handle for all LI message exchanges. | the ud-URI handle for all LI message exchanges. | |||
| In the case of a cascaded CDNs, the transit CDN will rewrite the | In the case of cascaded CDNs, the transit CDN will rewrite the | |||
| content URI when redirecting to the dCDN, thereby establishing a new | content URI when redirecting to the dCDN, thereby establishing a new | |||
| handle between the transit CDN and the dCDN, that is different from | handle between the transit CDN and the dCDN, that is different from | |||
| the handle between the uCDN and transit CDN. It is the | the handle between the uCDN and transit CDN. It is the | |||
| responsibility of the transit CDN to manage its mapping across | responsibility of the transit CDN to manage its mapping across | |||
| handles so the right handle for all pairs of CDNs is always used in | handles so the right handle for all pairs of CDNs is always used in | |||
| its CDNI communication. | its CDNI communication. | |||
| In summary, all CDNI interfaces between a given pair of CDNs need to | In summary, all CDNI interfaces between a given pair of CDNs need to | |||
| always use the "ud-URI" handle for that specific CDN pair as their | always use the "ud-URI" handle for that specific CDN pair as their | |||
| content URI reference. | content URI reference. | |||
| skipping to change at page 45, line 52 ¶ | skipping to change at page 48, line 10 ¶ | |||
| candidate CDN providers; In this case the content provider may be | candidate CDN providers; In this case the content provider may be | |||
| modeled as the combination of a CSP and of a special, restricted case | modeled as the combination of a CSP and of a special, restricted case | |||
| of a CDN. In that case, as illustrated in Figure 13, the CDNI | of a CDN. In that case, as illustrated in Figure 13, the CDNI | |||
| Request Routing interfaces can be used between the restricted CDN | Request Routing interfaces can be used between the restricted CDN | |||
| operated by the content provider Organization and the CDN operated by | operated by the content provider Organization and the CDN operated by | |||
| the full CDN organization acting as a dCDN in the request routing | the full CDN organization acting as a dCDN in the request routing | |||
| control plane. Interfaces outside the scope of the CDNI work can be | control plane. Interfaces outside the scope of the CDNI work can be | |||
| used between the CSP functional entities of the content provider | used between the CSP functional entities of the content provider | |||
| organization and the CDN operated by the full CDN organization acting | organization and the CDN operated by the full CDN organization acting | |||
| as a uCDN) in the CDNI control planes other than the request routing | as a uCDN) in the CDNI control planes other than the request routing | |||
| plane (i.e. Control, Distribution, Logging). | plane (i.e. Control, Distribution, Logging). | |||
| ##################################### ################## | ##################################### ################## | |||
| # # # # | # # # # | |||
| # Organization A # # Organization B # | # Organization A # # Organization B # | |||
| # # # # | # # # # | |||
| # -------- ------------- # # ----------- # | # -------- ------------- # # ----------- # | |||
| # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # | # / CSP \ / uCDN(RR) \ # # / dCDN(RR) \ # | |||
| # | | | +----+ | # # | +----+ | # | # | | | +----+ | # # | +----+ | # | |||
| # | |*****| | RR |==========CDNI=====>| RR | | # | # | |*****| | RR |==========CDNI=====>| RR | | # | |||
| # | | | +----+ | # RR # | +----+ | # | # | | | +----+ | # RR # | +----+ | # | |||
| skipping to change at page 47, line 24 ¶ | skipping to change at page 49, line 32 ¶ | |||
| Figure 14, we observe that in this example: | Figure 14, we observe that in this example: | |||
| o each CDN supports a direct CDNI Control interface to every other | o each CDN supports a direct CDNI Control interface to every other | |||
| CDN | CDN | |||
| o each CDN supports a direct CDNI Metadata interface to every other | o each CDN supports a direct CDNI Metadata interface to every other | |||
| CDN | CDN | |||
| o each CDN supports a CDNI Logging interface with the CDN Exchange | o each CDN supports a CDNI Logging interface with the CDN Exchange | |||
| o each CDN supports both a CDNI Request Routing interfaces with the | o each CDN supports both a CDNI Request Routing interface with the | |||
| CDN Exchange (for aggregation and redistribution of dynamic CDN | CDN Exchange (for aggregation and redistribution of dynamic CDN | |||
| footprint discovery information) and a direct RI to every other | footprint discovery information) and a direct RI to every other | |||
| CDN (for actual request redirection). | CDN (for actual request redirection). | |||
| ---------- --------- | ---------- --------- | |||
| / CDN A \ / CDN B \ | / CDN A \ / CDN B \ | |||
| | +----+ | | +----+ | | | +----+ | | +----+ | | |||
| //========>| C |<==============CDNI============>| C |<==========\\ | //========>| C |<==============CDNI============>| C |<==========\\ | |||
| || | +----+ | C | +----+ | || | || | +----+ | C | +----+ | || | |||
| || | +----+ | | +----+ | || | || | +----+ | | +----+ | || | |||
| skipping to change at page 48, line 52 ¶ | skipping to change at page 50, line 52 ¶ | |||
| -------------- | -------------- | |||
| <=CDNI RR=> CDNI Request Routing Interface | <=CDNI RR=> CDNI Request Routing Interface | |||
| <=CDNI M==> CDNI Metadata Interface | <=CDNI M==> CDNI Metadata Interface | |||
| <=CDNI C==> CDNI Control Interface | <=CDNI C==> CDNI Control Interface | |||
| <=CDNI L==> CDNI Logging Interface | <=CDNI L==> CDNI Logging Interface | |||
| Figure 14: CDNI Deployment Model: CDN Exchange | Figure 14: CDNI Deployment Model: CDN Exchange | |||
| Note that a CDN exchange may alternatively support a different set of | Note that a CDN exchange may alternatively support a different set of | |||
| functionality (e.g. Logging only, or Logging and full request | functionality (e.g. Logging only, or Logging and full request | |||
| routing, or all the functionality of a CDN including content | routing, or all the functionality of a CDN including content | |||
| distribution). All these options are expected to be allowed by the | distribution). All these options are expected to be allowed by the | |||
| IETF CDNI specifications. | IETF CDNI specifications. | |||
| 6. Trust Model | 6. Trust Model | |||
| There are a number of trust issues that need to be addressed by a | There are a number of trust issues that need to be addressed by a | |||
| CDNI solution. Many of them are in fact similar or identical to | CDNI solution. Many of them are in fact similar or identical to | |||
| those in a simple CDN without interconnection. In a standard CDN | those in a simple CDN without interconnection. In a standard CDN | |||
| environment (without CDNI), the CSP places a degree of trust in a | environment (without CDNI), the CSP places a degree of trust in a | |||
| skipping to change at page 49, line 45 ¶ | skipping to change at page 51, line 45 ¶ | |||
| the CDN has performed adequately. A CSP may use techniques such as | the CDN has performed adequately. A CSP may use techniques such as | |||
| client-based metering to verify that accounting information provided | client-based metering to verify that accounting information provided | |||
| by the CDN is reliable. HTTP conditional requests may be used to | by the CDN is reliable. HTTP conditional requests may be used to | |||
| provide the CSP with some checks on CDN operation. In other words, | provide the CSP with some checks on CDN operation. In other words, | |||
| while a CSP may trust a CDN to perform some functions in the short | while a CSP may trust a CDN to perform some functions in the short | |||
| term, the CSP is able in most cases to verify whether these actions | term, the CSP is able in most cases to verify whether these actions | |||
| have been performed correctly and to take action (such as moving the | have been performed correctly and to take action (such as moving the | |||
| content to a different CDN) if the CDN does not live up to | content to a different CDN) if the CDN does not live up to | |||
| expectations. | expectations. | |||
| The main trust issue raised by CDNI is that it introduces transitive | One of the trust issues raised by CDNI is transitive trust. A CDN | |||
| trust. A CDN that has a direct relationship with a CSP can now | that has a direct relationship with a CSP can now "outsource" the | |||
| "outsource" the delivery of content to another (downstream) CDN. | delivery of content to another (downstream) CDN. That CDN may in | |||
| That CDN may in term outsource delivery to yet another downstream | term outsource delivery to yet another downstream CDN, and so on. | |||
| CDN, and so on. | ||||
| The top level CDN in such a chain of delegation is responsible for | The top level CDN in such a chain of delegation is responsible for | |||
| ensuring that the requirements of the CSP are met. Failure to do so | ensuring that the requirements of the CSP are met. Failure to do so | |||
| is presumably just as serious as in the traditional single CDN case. | is presumably just as serious as in the traditional single CDN case. | |||
| Hence, an upstream CDN is essentially trusting a downstream CDN to | Hence, an upstream CDN is essentially trusting a downstream CDN to | |||
| perform functions on its behalf in just the same way as a CSP trusts | perform functions on its behalf in just the same way as a CSP trusts | |||
| a single CDN. Monitoring and reporting can similarly be used to | a single CDN. Monitoring and reporting can similarly be used to | |||
| verify that the downstream CDN has performed appropriately. However, | verify that the downstream CDN has performed appropriately. However, | |||
| the introduction of multiple CDNs in the path between CSP and end | the introduction of multiple CDNs in the path between CSP and end | |||
| user complicates the picture. For example, third party monitoring of | user complicates the picture. For example, third party monitoring of | |||
| skipping to change at page 50, line 41 ¶ | skipping to change at page 52, line 38 ¶ | |||
| We expect that the detailed designs for the specific interfaces for | We expect that the detailed designs for the specific interfaces for | |||
| CDNI will need to take the transitive trust issues into account. For | CDNI will need to take the transitive trust issues into account. For | |||
| example, explicit confirmation that some action (such as content | example, explicit confirmation that some action (such as content | |||
| removal) has taken place in a downstream CDN may help to mitigate | removal) has taken place in a downstream CDN may help to mitigate | |||
| some issues of transitive trust. | some issues of transitive trust. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This memo includes no request to IANA. | This memo includes no request to IANA. | |||
| 8. Security Considerations | 8. Privacy Considerations | |||
| While there is a variety of security issues introduced by a single | In general, a CDN has the opportunity to collect detailed information | |||
| about the behavior of end-users e.g. by logging which files are being | ||||
| downloaded. While the concept of interconnected CDNs as described in | ||||
| this document doesn't necessarily allow any given CDN to gather more | ||||
| information on any specific user, it potentially facilitates sharing | ||||
| of this data by a CDN with more parties. As an example, the purpose | ||||
| of the CDNI Logging Interface is to allow a dCDN to share some of its | ||||
| log records with a uCDN, both for billing purposes as well as for | ||||
| sharing traffic statistics with the Content Provider on which behalf | ||||
| the content was delivered. The fact that the CDNI Interfaces provide | ||||
| mechanisms for sharing such potentially sensitive user data, shows | ||||
| that it is necessary to include in these interface appropriate | ||||
| privacy and confidentiality mechanisms. The definition of such | ||||
| mechanisms is dealt with in the respective CDN interface documents. | ||||
| 9. Security Considerations | ||||
| While there are a variety of security issues introduced by a single | ||||
| CDN, we are concerned here specifically with the additional issues | CDN, we are concerned here specifically with the additional issues | |||
| that arise when CDNs are interconnected. For example, when a single | that arise when CDNs are interconnected. For example, when a single | |||
| CDN has the ability to distribute content on behalf of a CSP, there | CDN has the ability to distribute content on behalf of a CSP, there | |||
| may be concerns that such content could be distributed to parties who | may be concerns that such content could be distributed to parties who | |||
| are not authorized to receive it, and there are mechanisms to deal | are not authorized to receive it, and there are mechanisms to deal | |||
| with such concerns. Our focus in this section is on how CDN | with such concerns. Our focus in this section is on how CDN | |||
| interconnection introduces new security issues not found in the | interconnection introduces new security issues not found in the | |||
| single CDN case. | single CDN case. For a more detailed analysis of the security | |||
| requirements of CDNI, see section 9 of [I-D.ietf-cdni-requirements]. | ||||
| Many of the security issues that arise in CDNI are related to the | Many of the security issues that arise in CDNI are related to the | |||
| transitivity of trust (or lack thereof) described in Section 6. As | transitivity of trust (or lack thereof) described in Section 6. As | |||
| noted above, the design of the various interfaces for CDNI must take | noted above, the design of the various interfaces for CDNI must take | |||
| account of the additional risks posed by the fact that a CDN with | account of the additional risks posed by the fact that a CDN with | |||
| whom a CSP has no direct relationship is now potentially distributing | whom a CSP has no direct relationship is now potentially distributing | |||
| content for that CSP. The mechanisms used to mitigate these risks | content for that CSP. The mechanisms used to mitigate these risks | |||
| may be similar to those used in the single CDN case, but their | may be similar to those used in the single CDN case, but their | |||
| suitability in this more complex environment must be validated. | suitability in this more complex environment must be validated. | |||
| Another concern that arises in any CDN is that information about the | ||||
| behavior of users (what content they access, how much content they | ||||
| consume, etc.) may be gathered by the CDN. This risk certainly | ||||
| exists in inter-connected CDNs, but it should be possible to apply | ||||
| the same techniques to mitigate it as in the single CDN case. | ||||
| CDNs today offer a variety of means to control access to content, | CDNs today offer a variety of means to control access to content, | |||
| such as time-of-day restrictions, geo-blocking, and URI signing. | such as time-of-day restrictions, geo-blocking, and URI signing. | |||
| These mechanisms must continue to function in CDNI environments, and | These mechanisms must continue to function in CDNI environments, and | |||
| this consideration is likely to affect the design of certain CDNI | this consideration is likely to affect the design of certain CDNI | |||
| interfaces (e.g. metadata, request routing.) | interfaces (e.g. metadata, request routing). For more information on | |||
| URI signing in CDNI, see [I-D.leung-cdni-uri-signing]. | ||||
| Just as with a single CDN, each peer CDN must ensure that it is not | Just as with a single CDN, each peer CDN must ensure that it is not | |||
| used as an "open proxy" to deliver content on behalf of a malicious | used as an "open proxy" to deliver content on behalf of a malicious | |||
| CSP. Whereas a single CDN typically addresses this problem by having | CSP. Whereas a single CDN typically addresses this problem by having | |||
| CSPs explicitly register content (or origin servers) that is to be | CSPs explicitly register content (or origin servers) that are to be | |||
| served, simply propagating this information to peer downstream CDNs | served, simply propagating this information to peer downstream CDNs | |||
| may be problematic because it reveals more information than the | may be problematic because it reveals more information than the | |||
| upstream CDN is willing to specify. (To this end, the content | upstream CDN is willing to specify. (To this end, the content | |||
| acquisition step in the earlier examples force the dCDN to retrieve | acquisition step in the earlier examples force the dCDN to retrieve | |||
| content from the uCDN rather than go directly to the origin server.) | content from the uCDN rather than go directly to the origin server.) | |||
| There are several approaches to this problem. One is for the uCDN to | There are several approaches to this problem. One is for the uCDN to | |||
| encoded a signed token generated from a shared secret in each URL | encode a signed token generated from a shared secret in each URL | |||
| routed to a dCDN, and for the dCDN to validate the request based on | routed to a dCDN, and for the dCDN to validate the request based on | |||
| this token. Another one is to have each upstream CDN advertise the | this token. Another one is to have each upstream CDN advertise the | |||
| set of CDN-Domains they serve, where the downstream CDN checks each | set of CDN-Domains they serve, where the downstream CDN checks each | |||
| request against this set before caching and delivering the associated | request against this set before caching and delivering the associated | |||
| object. Although straightforward, this approach requires operators | object. Although straightforward, this approach requires operators | |||
| to reveal additional information, which may or may not be an issue. | to reveal additional information, which may or may not be an issue. | |||
| 8.1. Security of CDNI Interfaces | 9.1. Security of CDNI Interfaces | |||
| It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces | It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces | |||
| must be able to operate securely over insecure IP networks. Since it | must be able to operate securely over insecure IP networks. Since it | |||
| is expected that the CDNI interfaces will be implemented using | is expected that the CDNI interfaces will be implemented using | |||
| existing application protocols such as HTTP or XMPP, we also expect | existing application protocols such as HTTP or XMPP, we also expect | |||
| that the security mechanisms available to those protocols may be used | that the security mechanisms available to those protocols may be used | |||
| by the CDNI interfaces. Details of how these interfaces are secured | by the CDNI interfaces. Details of how these interfaces are secured | |||
| will be specified in the relevant interface documents. | will be specified in the relevant interface documents. | |||
| 8.2. Digital Rights Management | 9.2. Digital Rights Management | |||
| Issues of digital rights management (DRM, also sometimes called | Issues of digital rights management (DRM, also sometimes called | |||
| digital restrictions management) is often employed for content | digital restrictions management) is often employed for content | |||
| distributed via CDNs. In general, DRM relies on the CDN to | distributed via CDNs. In general, DRM relies on the CDN to | |||
| distribute encrypted content, with decryption keys distributed to | distribute encrypted content, with decryption keys distributed to | |||
| users by some other means (e.g. directly from the CSP to the end | users by some other means (e.g. directly from the CSP to the end | |||
| user.) For this reason, DRM is considered out of scope [RFC6707] and | user.) For this reason, DRM is considered out of scope [RFC6707] and | |||
| does not introduce additional security issues for CDNI. | does not introduce additional security issues for CDNI. | |||
| 9. Contributors | 10. Contributors | |||
| The following individuals contributed to this document: | The following individuals contributed to this document: | |||
| o Ray van Brandenburg | ||||
| o Matt Caulfield | o Matt Caulfield | |||
| o Francois le Faucheur | o Francois le Faucheur | |||
| o Aaron Falk | o Aaron Falk | |||
| o David Ferguson | o David Ferguson | |||
| o John Hartman | o John Hartman | |||
| o Ben Niven-Jenkins | o Ben Niven-Jenkins | |||
| o Kent Leung | o Kent Leung | |||
| 10. Acknowledgements | 11. Acknowledgements | |||
| We thank Huw Jones for helpful input to the draft. | ||||
| 11. Informative References | The authors would like to thank Huw Jones and Jinmei Tatuya for their | |||
| helpful input to this document. In addition, the authors would like | ||||
| to thank Stephen Farrell, Ted Lemon and Alissa Cooper for their | ||||
| reviews, which have helped to improve this document. | ||||
| [I-D.ietf-appsawg-http-forwarded] | 12. Informative References | |||
| Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", | ||||
| draft-ietf-appsawg-http-forwarded-10 (work in progress), | ||||
| October 2012. | ||||
| [I-D.ietf-cdni-control-triggers] | [I-D.ietf-cdni-control-triggers] | |||
| Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | |||
| Triggers", draft-ietf-cdni-control-triggers-02 (work in | Triggers", draft-ietf-cdni-control-triggers-02 (work in | |||
| progress), December 2013. | progress), December 2013. | |||
| [I-D.ietf-cdni-footprint-capabilities-semantics] | [I-D.ietf-cdni-footprint-capabilities-semantics] | |||
| Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., | Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., | |||
| and K. Ma, "CDNI Request Routing: Footprint and | and K. Ma, "CDNI Request Routing: Footprint and | |||
| Capabilities Semantics", draft-ietf-cdni-footprint- | Capabilities Semantics", draft-ietf-cdni-footprint- | |||
| capabilities-semantics-02 (work in progress), February | capabilities-semantics-02 (work in progress), February | |||
| 2014. | 2014. | |||
| [I-D.ietf-cdni-logging] | [I-D.ietf-cdni-logging] | |||
| Faucheur, F., Bertrand, G., Oprescu, I., and R. | Faucheur, F., Bertrand, G., Oprescu, I., and R. | |||
| Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- | Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- | |||
| logging-09 (work in progress), February 2014. | logging-11 (work in progress), March 2014. | |||
| [I-D.ietf-cdni-metadata] | [I-D.ietf-cdni-metadata] | |||
| Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., | Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., | |||
| Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- | Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- | |||
| ietf-cdni-metadata-06 (work in progress), February 2014. | ietf-cdni-metadata-06 (work in progress), February 2014. | |||
| [I-D.ietf-cdni-redirection] | [I-D.ietf-cdni-redirection] | |||
| Danhua, W., Niven-Jenkins, B., He, X., Chen, G., and W. | Niven-Jenkins, B. and R. Brandenburg, "Request Routing | |||
| Ni, "Request Routing Redirection Interface for CDN | Redirection Interface for CDN Interconnection", draft- | |||
| Interconnection", draft-ietf-cdni-redirection-01 (work in | ietf-cdni-redirection-02 (work in progress), April 2014. | |||
| progress), October 2013. | ||||
| [I-D.ietf-cdni-requirements] | [I-D.ietf-cdni-requirements] | |||
| Leung, K. and Y. Lee, "Content Distribution Network | Leung, K. and Y. Lee, "Content Distribution Network | |||
| Interconnection (CDNI) Requirements", draft-ietf-cdni- | Interconnection (CDNI) Requirements", draft-ietf-cdni- | |||
| requirements-17 (work in progress), January 2014. | requirements-17 (work in progress), January 2014. | |||
| [I-D.vandergaast-edns-client-subnet] | [I-D.leung-cdni-uri-signing] | |||
| Contavalli, C., Gaast, W., Leach, S., and E. Lewis, | Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and | |||
| "Client Subnet in DNS Requests", draft-vandergaast-edns- | S. Leibrand, "URI Signing for CDN Interconnection (CDNI)", | |||
| client-subnet-02 (work in progress), July 2013. | draft-leung-cdni-uri-signing-05 (work in progress), March | |||
| 2014. | ||||
| [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model | [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model | |||
| for Content Internetworking (CDI)", RFC 3466, February | for Content Internetworking (CDI)", RFC 3466, February | |||
| 2003. | 2003. | |||
| [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content | [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content | |||
| Distribution Network Interconnection (CDNI) Problem | Distribution Network Interconnection (CDNI) Problem | |||
| Statement", RFC 6707, September 2012. | Statement", RFC 6707, September 2012. | |||
| [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, | [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, | |||
| End of changes. 73 change blocks. | ||||
| 186 lines changed or deleted | 266 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||