Network Working Group Danhua. Wang, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track Xiaoyan. He Expires: December 21, 2012 Spencer. Dawkins Huawei Chen. Ge China Telecom Wei. Ni Yunfei. Zhang China Mobile July 16, 2012 Routing Request Redirection for CDN Interconnection draft-he-cdni-routing-request-redirection-02 Abstract The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a dCDN that allows a uCDN to decide whether to redirect particular user requests to that dCDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires December 21, 2012 [Page 1] Internet-Draft Routing Request Redirection June 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Interface function and operation overview . . . . . . . . . . 4 3.1. Discussion on protocol type for CDNI RRI . . . . . . . . . 5 4. Data passed in CDNI request routing requests & responses . . . 7 4.1. Data passed in CDNI request routing requests . . . . . . 7 4.2. Data passed in CDNI request routing responses . . . . . . 8 5. HTTP based RESTful interface for CDNI Request Routing . . . . 9 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 11 6.1. Recursive Request Routing . . . . . . . . . . . . . . . . 11 6.1.1. DNS based Request Routing Protocol . . . . . . . . . . 11 6.1.2. HTTP based Request Routing Protocol . . . . . . . . . 12 6.2. Iterative Request Routing . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wang, et al. Expires December 21, 2012 [Page 2] Internet-Draft Routing Request Redirection June 2012 1. Introduction A Content Delivery Network (CDN) is a system built on an existing IP network which is used for large scale content delivery, via prefetching or dynamically caching contents on its distributed surrogates (caching servers) that are typically deployed close to the end users so that a CDN can improve access to the content it caches, for example, by reducing access latency and improvingan end user's experience. In recent years the volume of video and multimedia content delivered over the internet is rapidly increasing. To accommodating this increase, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. Another emerging requirement is CDN Interconnection (CDNI). Several real world use cases are described in [I-D.draft-cdni-use- cases] which prove the necessity for CDN interconnection. The most frequently mentioned use case is leveraging the collective CDN footprint of interconnected standalone CDNs to achieve the goal of delivering content to additional distributed end users regardless of their location. [I-D.draft-cdni-problem- statement] describes the problem area, where CDNs are interconnected as described in [I-D.draft-cdni-use-cases] based on the requirements described in [I-D.draft-cdni-requirements], and using the technology framework described in [I-D.davie-cdni- framework]. The purpose of this document is to define the interface for synchronous redirection operation of the request routing interface, which is one of the main building blocks of the CDN interconnection architecture described in [I-D.draft-cdni- requirements]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. This document reuses the terminology defined in [I-D.draft-cdni- problem-statement]. The term "Distinguished CDN Domain" defined in [I-D.davie- cdni-framework] is also reused in this document. The following additional terms are introduced by this document: DNS Redirection: The act of using DNS name resolution for the request Wang, et al. Expires December 21, 2012 [Page 3] Internet-Draft Routing Request Redirection June 2012 routing process of a CDN. In DNS Redirection, the DNS resolver of the CDN makes the routing decision based on a local policy and returns the result as the response of a DNS query request to redirect a user agent to a new target. In CDNI, the result may point to a surrogate of the CDN, a request router in a downstream CDN or a surrogate in a downstream CDN, etc. HTTP Redirection: The act of using an HTTP redirection response to redirect a user agent to a new target. The new target is the result of the routing decision of a CDN at the time it receives a content request via HTTP. In CDNI, the result may point to a surrogate of the CDN, a request router in a downstream CDN or a surrogate in a downstream CDN etc. 3. Interface function and operation overview Editor's note: How an upsteam CDN decides which downstream CDN(s) to query is outside the scope of this document. The CDNI Request Routing interface is one of the main building blocks required in order to interconnect CDNs. The main function of the Request Routing interface is to allow the Request Routing systems in interconnected CDNs to communicate to facilitate the redirection of User Agent requests between interconnected CDNs. The detailed requirements for the CDNI Request Routing interface and their relative priorities of those requirements are described in section 5 of [I-D.draft-cdni-requirements]. The CDNI Request Routing interface operates between a pair of interconnected CDNs. To enable communication over the CDNI Request Routing Interface, the two interconnected CDNs need to know the end point (URI) in the other CDN to query. For example, an Upstream CDN needs to know the URI (end point) in a Downstream CDN to send its CDNI Request Routing queries to. The CDNI Request Routing URI may be statically pre-configured, dynamically discovered via the CDNI control interface, or discovered via other means. However, such discovery mechanisms are not specified in this document, as they are considered out of the scope of the CDNI Request Routing Protocol. The CDNI Request Routing interface must support both of the request routing mechanisms illustrated in section 3.2 and 3.4 of [I-D.davie- cdni-framework], namely Interative Request Routing and Recursive Request Routing. The Iterative Request Routing method does not invoke any interaction over the request routing interface across Wang, et al. Expires December 21, 2012 [Page 4] Internet-Draft Routing Request Redirection June 2012 interconnected CDNs. This document hence will not discuss Iterative Request Routing further. In the case of Recursive Request Routing, an Upstream CDN forwards a routing request from a user agent to a Downstream CDN for surrogate selection. The initial candidate protocols for these interactions are DNS and HTTP. Moreover, the inside routing mechanisms used between the CDN and the user agent (DNS and HTTP Redirection) of the two interconnected CDNs should also be taken into account as they may affect the type of query request the Upstream CDN send to a Downstream CDN and the information the Downstream CDN return in its query response. 3.1. Discussion on protocol type for CDNI RRI The request routing process has several variants depending on the factors including: Which routing mechanism is adopted by an Upstream CDN inside, DNS Redirection or HTTP Redirection. Which protocol is adopted for the CDNI Request Routing Interface. Which routing mechanism is adopted by a Downstream CDN inside, DNS Redirection or HTTP Redirection. All possible combinations and their validity are shown in Table 1. Wang, et al. Expires December 21, 2012 [Page 5] Internet-Draft Routing Request Redirection June 2012 +-------+---------+----------+------------ +-----------------------+ |CaseNO.| uCDN | RRI | dCDN | Note | | | Received| Interface| Response | | | | Request| | | | +-------+---------+----------+------------ +-----------------------+ | 1 | DNS | DNS based| DNS with IP | dCDN works in HTTP | | | | |address of RR| Redirection mode, | | | | | |illustrated in section | | | | | |3.1.1.1. | +-------+---------+----------+------------ +-----------------------+ | 2 | DNS | DNS based| DNS with | dCDN works in DNS | | | | | hostname of | Redirection mode, | | | | | RR | illustrated in section| | | | | |3.1.1.2. | +-------+---------+----------+------------ +-----------------------+ | 3 | DNS |HTTP based| Invalid case|Protocol conversion | | | | | |occurs in uCDN, | | | | | | invalid case. | +-------+---------+----------+------------ +-----------------------+ | 4 | HTTP |HTTP based| HTTP 302 | dCDN works in HTTP | | | | | Redirection | Redirection mode, | | | | | |illustrated in section | | | | | |3.1.2. | +-------+---------+----------+------------ +-----------------------+ | 5 | HTTP |HTTP based| DNS | dCDN works in DNS | | | | | Redirection | Redirection mode, | | | | | | invalid case. | +-------+---------+----------+------------ +-----------------------+ | 6 | HTTP |DNS based| Invalid case| Protocol conversion | | | | | | occurs, invalid case. | +-------+---------+----------+------------ +-----------------------+ Table 1: Recursive Routing Cases The rules to filter the cases and determine the validity of them are discussed below. The Upstream CDN must not perform protocol conversion (A DNS query to an HTTP request or vice versa). To assist the routing decision of a Downstream CDN, the Upstream CDN shall convey as much information as possible to the Downstream CDN, e.g. URI of the requested content, the client's location information. In the case of HTTP to DNS conversion, a DNS request cannot convey all the information an HTTP request contains. In the case of DNS to HTTP conversion, a full HTTP URL cannot be constructed through a simple domain name contained by a DNS query request. Hence it is concluded that the protocol type used in the CDNI Request Routing Interface will be consistent with the one the Upstream CDN received from the user agent. Case3, Case6 are invalid according to this rule. Wang, et al. Expires December 21, 2012 [Page 6] Internet-Draft Routing Request Redirection June 2012 The Downstream CDN can determine according to its local policy a DNS Redirection or an HTTP Redirection to be adopted. When receiving a DNS query request over the CDNI Request Routing Interface. If DNS Redirection is selected, as the location information has been changed to the Upstream CDN's when it proxies the DNS query request, the Downstream CDN cannot get the user agent's location information from the query request. The Downstream CDN sends a response with a CNAME of the hostname of the Request Router, so that the user agent issues another DNS query request which will convey its location information as shown in case2. If HTTP Redirection is selected, the Downstream CDN sends a response with the IP address of its Request Router, so that it can receive a subsequent content request based on HTTP containing the client's location information, to allow selection of an appropriate surrogate as shown in case1. Based on filter rules above, Case 1, 2, and 4 are valid cases for CDNI. The following section describes these cases in detail. 4. Data passed in CDNI request routing requests & responses As to the data that have to be passed between the CDNI request routing requests and responses, we believe that besides End User's request/response, certain CDNI metadata or policies might also be required. For example, in the CDNI request routing requests, appropriate CDNI Metadata could be introduced to aid the downstream CDN in making its decision. In the response, some policies might be included and returned to the End User to indicate how the responses could be reused, e.g., "the same response can be used without asking me again provided the End User is in this IP Address range", etc. As follows, detailed description of data that should be passed in the CDNI request routing requests and responses will be given respectively, considering under both DNS redirection and HTTP redirection mechanisms. 4.1. Data passed in CDNI request routing requests The data passed in CDNI request routing requests splits into two basic categories, an encapsulation of the User Agent's request to the upstream CDN; and properties/parameters that the uCDN can use to control the dCDN's response or that can help the dCDN make its decision. Data passed in CDNI request routing requests are enumerated in Table 1, including both DNS request and HTTP request. Wang, et al. Expires December 21, 2012 [Page 7] Internet-Draft Routing Request Redirection June 2012 Table1. Data Passed in CDNI Request Routing Requests +------------------+-------------------------------+-------------------------+ | | DNS Request | HTTP Request | +------------------+-------------------------------+-------------------------+ | | DNS Client IP address | Client IP address | |An encapsulation +-------------------------------+-------------------------+ |of the User | Type of query | Requested URL | |Agent's request +-------------------------------+-------------------------+ | |Real Client IP address(if know)| | | +-------------------------------+-------------------------+ | |URI of requested content | | +------------------+-------------------------------+-------------------------+ |Properties that |A link to the associated | A link to the associated| |uCDN can use |CDNI Metadata | CDNI Metadata | |to control the +-------------------------------+-------------------------+ |dCDN's response | | Whether to return | | | | hostnames or IP address | | | | in the redirection URL | +------------------+-------------------------------+-------------------------+ Note: As we presented before, the downstream CDN needs to obtain the appropriate CDNI Metadata to know how to process the CDNI Request Routing requests. We do not include actual CDNI Metadata in the CDNI Request Routing requests, only a link to the CDNI Metadata is included, shown in Table 1. 4.2. Data passed in CDNI request routing responses There are also two basic categories of data passed in CDNI request routing responses, an encapsulation of the DNS response or HTTP response to return to the End User; parameters /policies that indicate the properties of the response, such as, whether it is cacheable, the scope of the response, etc. Data passed in CDNI request routing responses are enumerated in Table 2, including both DNS response and HTTP response. Wang, et al. Expires December 21, 2012 [Page 8] Internet-Draft Routing Request Redirection June 2012 Table2. Data Passed in CDNI Request Routing Responses +-------------------+--------------------+---------------------+ | | DNS Response | HTTP Response | +-------------------+--------------------+---------------------+ |An encapsulation | | | |of CDNI/HTTP |CNAME of the dCDN's |IP address or | |response to the |Request Router |hostname of request | |End User | |router | +-------------------+--------------------+---------------------+ | |Parameter that indicate whether | | |the response is cacheable | | +------------------------------------------+ |Parameters/policies|Parameter that indicate how long to reduce| |that indicate the |the number of subsequent CDNI request | |properties of the |routing requests the uCDN needs to make | |response +------------------------------------------+ | |Parameter that indicate the scope of the | | |response (if it is cacheable), e.g., does | | |it apply to a wider range of client IP | | |addresses or URIs than one in the request | +-------------------+------------------------------------------+ 5. HTTP based RESTful interface for CDNI Request Routing This document defines a simple HTTP based RESTful interface for CDNI Request Routing, where End User's requests are encapsulated along with links to appropriate CDNI Metadata resources (records) and any other data that can aid the downstream CDN in processing the requests. The response encapsulates the response that the upstream CDN should return to the End User (if it decides to utilize the Downstream CDN for delivery) along with the policy for how the response could be reused (through standard HTTP Cache-Control headers). The same RESTful interface is used for both DNS and HTTP redirection of User Agent's requests, although the contents of the CDNI Request Routing Interface requests/responses contain data specific to either DNS or HTTP redirection. This approach has been chosen because it enables CDN operators to only have to deploy a single (RESTful) interface for request routing between their CDNs, regardless of the User Agent redirection method. In this way, from an operational point of view there is only one interface to monitor, manage, or develop troubleshooting tools for. In addition, having a single CDNI Request Routing interface where the User Agent's DNS or HTTP request are encapsulated along with the Wang, et al. Expires December 21, 2012 [Page 9] Internet-Draft Routing Request Redirection June 2012 other data required for the downstream CDN to make a request routing decision, avoids having to try and encapsulate or proxy DNS/HTTP/ RTMP/etc requests and find ways to somehow embed the additional CDNI Request Routing properties/data within those End User DNS/HTTP/RTMP/ etc requests. Finally, the interface is easily extendable to support other User Agent request redirection methods (e.g. RTMP 302 redirection). The general call flow between Request Routers in a pair of interconnected CDNs is as follows: User Agent CDN B RR CDN A RR |UA Request (DNS or HTTP) | | |-------------------------------------------------->| | | | | |HTTP POST to CDN B's CDNI| | |RRI URI encapsulating UA | (1) | |request etc. | | |<------------------------| | | | | |200(?) Response with body| | |containing encapsulation | (2) | |of protocol specific | | |response to return to UA | | |------------------------>| | | | | Protocol specific response (redirection)| (3) |<--------------------------------------------------| | | | 1. The User Agent sends its request, either CDN request or HTTP request etc., to CDN A. A Request Routing System of CDN A processes the request, and it recognizes that the request is best served by another CDN, specifically CDN B. 2. A Request Routing System of CDN A sends an HTTP POST to CDN B's CDNI Request Routing Interface URI encapsulating User Agent's request, as well as a link to the associated CDNI metadata, etc., which may help CDN B make its decision when processing the request. 3. A Request Routing System of CDN B processes the request and replies an HTTP "200" Response with body containing encapsulation of protocol specific response (e.g., for DNS, CNAME of the dCDN's Request Router, and for HTTP, IP address or hostname of dCDN's Request Router) as well as parameters that indicate the properties of the response (e.g., parameter that indicate whether the response is cacheable) to return to the User Agent. Wang, et al. Expires December 21, 2012 [Page 10] Internet-Draft Routing Request Redirection June 2012 4. A Request Routing System of CDN B sends the protocol specific response to the User Agent, and then the User Agent's request will be redirect to the CDN B. 6. Protocol Specification This section only specifies a brief introduction of different fields to be exchanged in Request Routing requests/responses, and the specific encoding for them will be presented in our future work. 6.1. Recursive Request Routing 6.1.1. DNS based Request Routing Protocol 6.1.1.1. Upstream CDN Behavior Upon receiving a DNS query request from a User Agent, the Request Routing System of the Upstream CDN SHALL first determine an inside routing mechanism according to local policy. If it is aware that the End User is best served by another CDN, the Upstream CDN SHALL select a Downstream CDN and forward the End User's request along with a link to the associated CDNI Metadata to the Downstream CDN, while the End User's request includes DNS Client IP address, type of query, real Client IP address (if know), and URI of requested content. Upon receiving a response from the Downstream CDN, the Request Routing System of the Upstream CDN shall forward it back to the User Agent. 6.1.1.2. Downstream CDN Behavior Upon receiving a DNS query request, the Downstream CDN SHALL extracts End User's request information (e.g., the content provider's domain name) as well as associated CDNI Metadata to help it process the request. It then SHALL determine an inside routing mechanism according to local routing policy. Editor's note: The local routing policy may take into account the CP's policy if existed identified by the CP's domain name. In case of DNS Redirection, it SHALL select a Request Router and return a response containing CNAME of the Downstream CDN's Request Router, as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable, parameter that indicate how long to reduce the number of subsequent CDNI Request Routing requests the Upstream CDN needs to make, and parameter that indicate the scope of the response Wang, et al. Expires December 21, 2012 [Page 11] Internet-Draft Routing Request Redirection June 2012 (if it is cacheable). In the case of HTTP Redirection, it SHALL select a Request Router and return IP address or hostname of Request Router, as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable, parameter that indicate how long to reduce the number of subsequent CDNI Request Routing Requests the Upstream CDN needs to make, and parameter that indicate the scope of the response (if it is cacheable). 6.1.2. HTTP based Request Routing Protocol 6.1.2.1. Upstream CDN Behavior Upon receiving an HTTP Request from a User Agent for specific content, based on the local routing policy, if it is determined that the user is best served by another CDN, the Request Router of the Upstream CDN SHALL select a Downstream CDN for the End User, encapsulate the User Agent's request (Client IP address, request URL) with properties that Upstream CDN can use to control the dCDN's response (a link to the associated CDNI Metadata, whether to return hostnames or IP address in the redirection URL), and then forward the request to the selected Downstream CDN. After receiving an HTTP "200" response from the Downstream CDN, the Upstream CDN SHALL forward it back to the User Agent. 6.1.2.2. Downstream CDN Behavior Upon receiving an HTTP Request, the Downstream CDN SHALL select a delivery node for the User Agent based on the local routing policy. It SHALL then return IP address or hostname of selected delivery node, as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable, parameter that indicate how long to reduce the number of subsequent CDNI Request Routing Requests the Upstream CDN needs to make, and parameter that indicate the scope of the response (if it is cacheable). 6.2. Iterative Request Routing Editor's note: Whether any content relative to Iterative Request Routing should be added here is to be determined by the CDNI working group. Wang, et al. Expires December 21, 2012 [Page 12] Internet-Draft Routing Request Redirection June 2012 7. Security Considerations In HTTP based Recursive Request Routing, the end user's web browsers will not send cookies if the content request is redirected to a URL in a different domain rather than the original CP's domain, e.g. the Downstream CDN's domain. If the browser is expected to send any cookies associated with the original CP's domain, this will cause problem that the CP's policy is not enforced by the CDN. The section 5.2 of draft [I-D.draft-peterson-cdni-strawman] has discussed a similar question and given a solution. 8. IANA Considerations This document makes no request of IANA. 9. References 9.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", January 2005. 9.2. Informative Reference [draft-cdni-use-cases] Bertrand, G., Emile, S., Watson, G., Burbridge, T., Eardley, P., and K. Ma, "Use Cases for Content Delivery Network Interconnection", Sep. 2011. [draft-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", Sep. 2011. [draft-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Sep. 2011. Wang, et al. Expires December 21, 2012 [Page 13] Internet-Draft Routing Request Redirection June 2012 [draft-peterson-cdni-strawman] Peterson, L. and J. Hartman, "A Simple Approach to CDN Interconnection", May 2011. [davie-cdni-framework] Davie, B. and L. Peterson, "A Simple Approach to CDN Interconnection", July 2011. Authors' Addresses Wang Danhua (editor) Huawei Technologies No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-56624734 Fax: +86-25-56624702 Email: wangdanhua@huawei.com He Xiaoyan Huawei B2, Huawei Industrial Base 518129 P.R.China Email: hexiaoyan@huawei.com Spencer Dawkins Huawei Email: spencer.dawkins@wondermaster.com Ge Chen China Telecom 109 West Zhongshan Ave,Tianhe District Guangzhou P.R. China Email: cheng@gsta.com Wang, et al. Expires December 21, 2012 [Page 14] Internet-Draft Routing Request Redirection June 2012 Ni Wei China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 P.R. China Email: niwei@chinamobile.com Zhang Yunfei China Mobile Email: zhangyunfei@chinamobile.com Wang, et al. Expires December 21, 2012 [Page 15]