Network Working Group Danhua. Wang, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track Xiaoyan. He Expires: April 25, 2013 Spencer. Dawkins Huawei Chen. Ge China Telecom Wei. Ni Yunfei. Zhang China Mobile B. Niven-Jenkins Velocix (Alcatel-Lucent) October 22, 2012 Routing Request Redirection for CDN Interconnection draft-he-cdni-routing-request-redirection-03 Abstract The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; 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, i.e. the CDNI Request Routing Redirection interface. 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 April 25, 2013. Copyright Notice Wang, et al. Expires April 25, 2013 [Page 1] Internet-Draft Routing Request Redirection October 2012 Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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 RRRI . . . . . . . . 5 4. Data passed in CDNI request routing redirection requests & responses . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Data passed in CDNI RRRI requests & response for DNS redirection . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Data passed in CDNI RRRI request & responses for HTTP redirection . . . . . . . . . . . . . . . . . . . . . . . 8 5. HTTP based RESTful interface for CDNI Request Routing Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 11 6.1. Recursive Request Routing . . . . . . . . . . . . . . . . 11 6.1.1. Downstream CDN Behavior for DNS based User Agent requests . . . . . . . . . . . . . . . . . . . . . . . 11 6.1.2. Downstream CDN Behavior for HTTP based User Agent requests . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.3. Example CDNI RRRI Requests/Responses . . . . . . . . . 12 6.2. Iterative Request Routing . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Wang, et al. Expires April 25, 2013 [Page 2] Internet-Draft Routing Request Redirection October 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 content 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 improving the end user experience. In recent years the volume of video and multimedia content delivered over the internet is rapidly increasing. To accommodate 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.ietf-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.ietf-cdni-problem-statement] describes the problem area, where CDNs are interconnected as described in [I-D.ietf-cdni-use-cases] based on the requirements described in [I-D.ietf-cdni-requirements], and using the technology framework described in [I-D.ietf-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.ietf-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 [RFC2119]. This document reuses the terminology defined in [I-D.ietf-cdni-problem-statement]. The term "Distinguished CDN Domain" defined in [I-D.ietf-cdni-framework] is also reused in this document. The following additional terms are introduced by this document: Wang, et al. Expires April 25, 2013 [Page 3] Internet-Draft Routing Request Redirection October 2012 DNS Redirection: The act of using DNS name resolution for the request 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 a local policy within the upstream CDN and is outside the scope of this document.]] The CDNI Request Routing Redirection interface (CDNI RRRI) 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 Redirection interface and their relative priorities of those requirements are described in section 5 of [I-D.ietf-cdni-requirements]. The CDNI Request Routing Redirection interface operates between a pair of interconnected CDNs. To enable communication over the CDNI Request Routing Redirection 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 Redirection interface 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 Redirection interface specification. CDNI solutions must support both of the request routing mechanisms Wang, et al. Expires April 25, 2013 [Page 4] Internet-Draft Routing Request Redirection October 2012 illustrated in section 2.1 of [I-D.ietf-cdni-framework], namely Iterative Request Routing and Recursive Request Routing. However, the Iterative Request Routing method does not invoke any interaction over the request routing redirection interface across interconnected CDNs. Therefore, the Request Routing Redirection interface is only relevant in the case of Recursive Request Routing and so this document will not discuss Iterative Request Routing further. In the case of Recursive Request Routing, an Upstream CDN forwards a CDNI request routing request from a user agent to a Downstream CDN for surrogate selection. The initial Upstream CDN->User Agent redirection protocols addressed in this draft are: DNS redirection and HTTP redirection. Moreover, the internal 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 CDNs return in its query response. 3.1. Discussion on protocol type for CDNI RRRI The request routing process between an Upstream CDN and a Downstream CDN has several variants depending on the following factors: o Which request routing mechanism is being used by an Upstream CDN to redirect the User Agent: DNS Redirection or HTTP Redirection. o Which request routing mechanism is being used by a Downstream CDN to redirect the User Agent: DNS Redirection or HTTP Redirection. The possible combinations are shown in Table 1. +------+----------+------------------+------------------------------+ | Case | uCDN | dCDN Response | Notes | | | Received | | | | | Request | | | +------+----------+------------------+------------------------------+ | 1 | DNS | DNS with IP | dCDN uses DNS redirection | | | | address/hostname | (via the CDNI RRRI | | | | of Surrogate | interface) to redirect the | | | | | UA to one or more surrogates | | | | | in the dCDN. | +------+----------+------------------+------------------------------+ Wang, et al. Expires April 25, 2013 [Page 5] Internet-Draft Routing Request Redirection October 2012 +------+----------+------------------+------------------------------+ | 2 | DNS | DNS with IP | dCDN uses DNS redirection | | | | address/hostname | (via the RRRI interface) to | | | | of RR | redirect the UA to a RR in | | | | | the dCDN which then performs | | | | | a HTTP redirection to | | | | | redirect the UA to a | | | | | surrogate in the dCDN. | +------+----------+------------------+------------------------------+ | 3 | HTTP | HTTP 302 | dCDN uses HTTP redirection | | | | redirection | mode to redirect the UA to | | | | | either (a) a RR in the dCDN, | | | | | or (b) a surrogate in the | | | | | dCDN. | +------+----------+------------------+------------------------------+ Table 1. Recursive Routing Cases 4. Data passed in CDNI request routing redirection requests & responses 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 addition to details of the User Agent's request to the Upstream CDN, the Downstream CDN requires the appropriate CDNI metadata or policies related to the content the User Agent is requesting in order for the Downstream CDN to determine whether it is capable of delivering any requested content in the manner specified by the CDNI Metadata associated with that content. For example, the Downstream CDN needs to verify that the delivery protocol that will be used is a delivery protocol that the Downstream CDN supports. Similarly, in addition to details of how to redirect the User Agent, the Downstream CDN may wish to return additional policy to the Upstream CDN to help the Upstream CDN with future CDNI RRRI requests. For example the Downstream CDN may wish to return a policy that expresses "this response can be reused without requiring a RRRI request for 60 seconds provided the User Agent's IP address is in the range 192.0.2.0 - 192.0.2.255". The information passed in CDNI request routing redirection requests splits into two basic categories: Wang, et al. Expires April 25, 2013 [Page 6] Internet-Draft Routing Request Redirection October 2012 1. An encapsulation of the User Agent's request to the upstream CDN. 2. Properties/parameters that the uCDN can use to control the dCDN's response or that can help the dCDN make its decision. The information passed in CDNI request routing redirection response splits into two basic categories: 1. An encapsulation of the DNS response or HTTP response to return to the End User. 2. parameters /policies that indicate the properties of the response, such as, whether it is cacheable, the scope of the response, etc. The following sections provide more detailed descriptions of the information that should be passed in CDNI request routing redirection interface requests and responses for both DNS redirection and HTTP redirection mechanisms. 4.1. Data passed in CDNI RRRI requests & response for DNS redirection [[Editor's Note: Align the terminology in this section with standards DNS terminology.]] For DNS based redirection the uCDN needs to pass the following information to the dCDN in the CDNI RRRI request: o The IP address of the DNS resolver that made the DNS request to the Upstream CDN. o The type of DNS query made (A, AAAA, etc.). o The host/domain for which DNS redirection is being requested. o The IP address of the User Agent (if known to the Upstream CDN, e.g. through edns-client-subnet). For DNS redirection, the uCDN also needs to provide in the CDNI RRRI request the a link to the associated CDNI Metadata for the host/ domain being requested. The information passed in CDNI request routing redirection requests are enumerated in the sections below, which covers both DNS redirection and HTTP redirection. For DNS based redirection the dCDN needs to return one of the following to the uCDN in the CDNI RRRI response: Wang, et al. Expires April 25, 2013 [Page 7] Internet-Draft Routing Request Redirection October 2012 o The IP address of the selected Surrogate in the dCDN (if the dCDN is performing DNS based redirection); or o The IP address of a Request Router in the dCDN (if the dCDN is performing HTTP based redirection). In addition, the dCDN could also include the following information in its response: o An indication of the cacheability of the response (to reduce the number of subsequent CDNI RRI requests the uCDN needs to make). o The scope of the response (if it is cacheable). For example whether the response applies to a wider range of IP addresses than what was included in the CDNI RRRI request. 4.2. Data passed in CDNI RRRI request & responses for HTTP redirection For HTTP based redirection the uCDN needs to pass the following information to the dCDN in the CDNI RRRI request: o The IP address of the User Agent. o The URL requested by the User Agent. For HTTP redirection, the uCDN also needs to provide in the CDNI RRRI request the a link to the associated CDNI Metadata for the host/ domain being requested and whether the uCDN would like the dCDN to return the IP address or the hostname of the surrogate in the returned redirection URL. [[Editor's note: An alternative would be to have the RRRI response always contain both hostnames & IP addresses and just let the uCDN pick which one it want to return to the User Agent]] For HTTP based redirection the dCDN needs to return one of the following to the uCDN in the CDNI RRRI response: o A URL pointing to the selected Surrogate in the dCDN (if the dCDN is redirecting the User Agent directly to a surrogate); or o A URL pointing to a Request Router in the dCDN (if the dCDN is not redirecting the User Agent directly to a surrogate). In addition, the dCDN could also include the following information in its response: Wang, et al. Expires April 25, 2013 [Page 8] Internet-Draft Routing Request Redirection October 2012 o An indication of the cacheability of the response (to reduce the number of subsequent CDNI RRI requests the uCDN needs to make). o The scope of the response (if it is cacheable). For example whether the response applies to a wider range of IP addresses than what was included in the CDNI RRRI request. 5. HTTP based RESTful interface for CDNI Request Routing Redirection This document defines a simple HTTP based RESTful interface for the CDNI Request Routing Redirection interface, 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 RRI 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 RRRI 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, develop troubleshooting tools for, etc. In addition, having a single CDNI Request Routing interface where the User Agent's DNS or HTTP request are encapsulated along with the 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: Wang, et al. Expires April 25, 2013 [Page 9] Internet-Draft Routing Request Redirection October 2012 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. | | |<------------------------| | | | | |HTTP 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 DNS request or HTTP request etc., to CDN A. The Request Routing System of CDN A processes the request, and it recognizes that the request is best served by another CDN, specifically CDN B (or that CDN B is one of a number of candiodate dCDNs it could use). 2. The Request Routing System of CDN A sends an HTTP POST to CDN B's CDNI Request Routing Interface URI encapsulating the 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. The Request Routing System of CDN B processes the request and assuming the request is well formed, etc. responds with an HTTP "200" response with a mesage body containing an encapsulation of the protocol specific response to return to the User Agent (e.g., for HTTP redirection the URI that CDN A needs to return in a 302 response to the User Agent) as well as parameters that indicate the properties of the response (e.g., parameter that indicates if the response applies to a wider range of IP addresses than the single IP address being used by the User Agent). 4. The Request Routing System of CDN B sends the protocol specific response to the User Agent, and then the User Agent's request will be redirected to the CDN B. Wang, et al. Expires April 25, 2013 [Page 10] Internet-Draft Routing Request Redirection October 2012 6. Protocol Specification This section only specifies a brief introduction of different fields to be exchanged in CDNI Request Routing Redirection requests/ responses, and the specific encoding for them will be presented in a future revision. [[Editor's note: This section needs some re-work, which we should do as part of documenting the specific protocol details.]] 6.1. Recursive Request Routing Upon receiving a DNS query request from a User Agent, the Request Routing System of the Upstream CDN firsts determines how it should redirect the request using local policy. If it is aware that the End User is best served by another CDN, the Upstream CDN may make a CDNI RRRI request (that encapsulates the User Agent's request) to that Downstream CDN. Upon receiving a response from the Downstream CDN, if the Request Routing System of the Upstream CDN decides to use that Downstream CDN, the Upstream CDN redirects the User Agent to the downstream CDN using the information in the CDNI RRRI response. 6.1.1. Downstream CDN Behavior for DNS based User Agent requests Upon receiving a CDNI RRRI request, the Downstream CDN 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 determines how it should redirect the request using local policy. If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting directly to a surrogate in the Downstream CDN: the Downstream CDN selects one or more surrogates and returns a CDNI RRRI response containing the IP addresses of the selected surrogate(s), as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable and for how long, parameter that indicate the scope of the response (if it is cacheable), etc. If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting to a Request Router in the dCDN: the Downstream CDN returns a CDNI RRRI response containing a CNAME of the Downstream CDN's Request Router(s), as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable and for how long, parameter that indicate the scope of the response (if it is cacheable), etc. Wang, et al. Expires April 25, 2013 [Page 11] Internet-Draft Routing Request Redirection October 2012 If the dCDN decides to use HTTP Redirection, where the original User Agent request was via DNS: the Downstream CDN returns a CDNI RRRI response containing the IP address of the Downstream CDN's Request Router(s), as well as parameters/policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable and for how long, parameter that indicate the scope of the response (if it is cacheable), etc. 6.1.2. Downstream CDN Behavior for HTTP based User Agent requests Upon receiving a CDNI RRRI request, the Downstream CDN 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 determines how it should redirect the request using local policy. The Downstream CDN selects one or more surrogates and returns a CDNI RRRI response containing a URL including the hostname and/or IP addresses of the selected surrogate(s), as well a path component that will return the resource originally request by the End User's User Agent. The CDNI RRRI response should also include parameters/ policies that indicate the properties of the response, such as, parameter that indicate whether the response is cacheable and for how long, parameter that indicate the scope of the response (if it is cacheable), etc. 6.1.3. Example CDNI RRRI Requests/Responses [[Editors' Note: Explanation of the format of the CDNI RRRI requests/ responses is given as comments marked '#'. Need to extract & place in their own section which specifies the structure of CDNI RRRI requests/responses]] CDN RRRI Request (uCDN->dCDN) for DNS based End User User Agent requests: Wang, et al. Expires April 25, 2013 [Page 12] Internet-Draft Routing Request Redirection October 2012 POST /dcdn/rrri HTTP/1.1 Host: rr1.dcdn.example.net Accept: application/vnd.cdni.rrri.response+json { "dns" : { # Contains a representation of # the DNS query "resolverip" : "192.0.2.1", # IP address of DNS resolver "clientsubnet" : "198.51.100.1/24", # IP subnet of the UA/client # if known e.g. draft- # vandergaast-edns-client-subnet "qtype" : "A", # DNS request type (one of A, # AAAA, CNAME) "qclass" : "IN", # class of query "qname" : "www.example.com" # domain name being queried } "metadata" : # Link to associated CDNI "http://md.ucdn.example/www.example.com/" # Metadata } CDNI RRRI successful Response (dCDN->uCDN) for DNS based End User User Agent requests: [Currently shows both A/AAAA & CNAME in single response, need to split to show the different use cases of redirecting directly to a dCDN surrogate versus redirecting to a dCDN Request Router] Wang, et al. Expires April 25, 2013 [Page 13] Internet-Draft Routing Request Redirection October 2012 HTTP/1.1 200 OK Date: Mon, 06 Aug 2012 18:41:38 GMT Content-Type: application/vnd.cdni.rrri.response+json Cache-Control: public, max-age=600 { "dns" : { # Contains a representation of # the DNS response to return to # the UA "rcode" : 0, # DNS response code "name" : "www.example.com", # Domain name response relates to # Response must contain at least # one of a, aaaa, cname "a" : ["192.0.2.200", # Set of IPv4 Addresses of dCDN "192.0.2.201"], # Surrogates or dCDN RRs "aaaa" : ["2001:DB8::C8", # Set of IPv6 Addresses of dCDN "2001:DB8::C9"], # or dCDN RRs "cname" : ["rr1.dcdn.example.net", # Set of domain names of dCDN "rr2.dcdn.example.net"], # Surrogates or dCDN RRs "ttl" : 60, # TTL to return in DNS response } "scope" : { # Scope of response "iprange" : "198.51.100.1/16" # Applies to a wider resolver/ } # client subnet } CDN RRRI Request (uCDN->dCDN) for HTTP based End User User Agent requests: POST/dcdn/rrri HTTP/1.1 Host: rr1.dcdn.example.net Accept: application/vnd.cdni.rrri.response+json { "http": { # Contains a representation of # the HTTP query "clientsubnet": "198.51.100.1/24", # IP subnet of the UA/client "url": http://www.example.com, # URL requested by the UA } "metadata" : # Link to associated CDNI "http://md.ucdn.example/www.example.com/" # Metadata } CDNI RRRI successful Response (dCDN->uCDN) for HTTP based End User User Agent requests: Wang, et al. Expires April 25, 2013 [Page 14] Internet-Draft Routing Request Redirection October 2012 HTTP RRRI successful Response (dCDN->uCDN): HTTP/1.1 200 OK Date: Mon, 06 Aug 2012 18:41:38 GMT Content-Type: application/vnd.cdni.rrri.response+json Cache-Control: public, max-age=600 { "http": { # Contains a representation of # the HTTP response to return to # the UA "rcode": 200, # HTTP response code "url": http://www.example.com, # URL response relates to "surrogates": # Set of URL pointing to the # selected dCDN Surrogates # or dCDN RR ["http://sur1.dcdn.example.net/ucdn/example.com", "http://sur2.dcdn.example.net/ucdn/example.com"] "ttl" : 60, # TTL to return in DNS response, } "scope" : { # Scope of response "iprange" : "198.51.100.0/16" # Applies to a wider range of UA } # IP addresses } CDNI RRRI error response examples. CDNI RRRI error response (dCDN->uCDN) for DNS based End User User Agent requests: HTTP/1.1 500 Server Error Date: Mon, 06 Aug 2012 18:41:38 GMT Content-Type: application/vnd.cdni.rrri.error+json Cache-Control: private, no-cache { "dns" : { "rcode" : 4 # DNS response code (e.g doesn't support AAAA) "name" : "www.example.com", # domain name response relates to }, "error" : { "code" : TBD, # Give each error type its own # numeric code "description" : # Give more informative "IPv6/AAAA queries are not supported" # description than just protocol } # specific error codes } Wang, et al. Expires April 25, 2013 [Page 15] Internet-Draft Routing Request Redirection October 2012 CDNI RRRI error response (dCDN->uCDN) for HTTP based End User User Agent requests: HTTP/1.1 500 Server Error Date: Mon, 06 Aug 2012 18:41:38 GMT Content-Type: application/vnd.cdni.rrri.error+json Cache-Control: private, no-cache { "http": { "rcode": 400, # HTTP response code "url": http://www.example.com, # URL response relates to } "error" : { "code" : TBD, # Give each error type its own # numeric code "description" : TBD # Give more informative # description than just protocol } # specific error codes } TBD: Work out more explanation & examples of errors that shouldn't be propagated to the EU User Agent. 6.2. Iterative Request Routing [[Editor's note: Currently Iterative Request Routing is out of scope for this document as it does not require use of the CDNI RRRI. This section is just included to show that the authors' have not overlooked Iterative Request Routing.]] 7. Security Considerations [[Editor's note: Not sure if this current text is really security considerations or whether it is better placed elsewhere in the document.]] 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.peterson-cdni-strawman] has discussed a similar question and given a solution. Wang, et al. Expires April 25, 2013 [Page 16] Internet-Draft Routing Request Redirection October 2012 8. IANA Considerations This document makes no request of IANA. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-08 (work in progress), June 2012. [I-D.ietf-cdni-use-cases] Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-09 (work in progress), July 2012. [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for CDN Interconnection", draft-ietf-cdni-framework-01 (work in progress), July 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-03 (work in progress), June 2012. [I-D.peterson-cdni-strawman] Peterson, L. and J. Hartman, "A Simple Approach to CDN Interconnection", draft-peterson-cdni-strawman-01 (work in progress), May 2011. Wang, et al. Expires April 25, 2013 [Page 17] Internet-Draft Routing Request Redirection October 2012 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 Ni Wei China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 P.R. China Email: niwei@chinamobile.com Wang, et al. Expires April 25, 2013 [Page 18] Internet-Draft Routing Request Redirection October 2012 Zhang Yunfei China Mobile Email: zhangyunfei@chinamobile.com Ben Niven-Jenkins Velocix (Alcatel-Lucent) 3 Ely Road Milton, Cambridge CB24 6DD UK Email: ben@velocix.com Wang, et al. Expires April 25, 2013 [Page 19]