Routing Request Redirection for CDN Interconnection
draft-he-cdni-routing-request-redirection-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Wang Danhua , Xiaoyan He , Spencer Dawkins , Ge Chen , Wei Ni , Yunfei Zhang , Ben Niven-Jenkins | ||
| Last updated | 2012-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-he-cdni-routing-request-redirection-03
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]