One document matched: draft-ietf-cdni-redirection-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-cdni-redirection-12" ipr="trust200902">
<front>
<title abbrev="Request Routing Redirection">Request Routing Redirection
Interface for CDN Interconnection</title>
<author fullname="Ben Niven-Jenkins" initials="B." role="editor"
surname="Niven-Jenkins">
<organization>Velocix (Alcatel-Lucent)</organization>
<address>
<postal>
<street>3 Ely Road</street>
<city>Milton</city>
<region>Cambridge</region>
<code>CB24 6DD</code>
<country>UK</country>
</postal>
<email>ben.niven-jenkins@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Ray van Brandenburg" initials="R." role="editor"
surname="van Brandenburg">
<organization>TNO</organization>
<address>
<postal>
<street>Anna van Buerenplein 1</street>
<city>The Hague</city>
<region/>
<code>2595DA</code>
<country>the Netherlands</country>
</postal>
<phone>+31-88-866-7000</phone>
<facsimile/>
<email>ray.vanbrandenburg@tno.nl</email>
<uri/>
</address>
</author>
<date day="" month="" year=""/>
<abstract>
<t>The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream Content
Delivery Network (CDN) that allows an 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>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). <xref target="RFC6707"/> describes the problem area of
interconnecting CDNs.</t>
<t>The CDNI Request Routing interface outlined in <xref
target="RFC7336"/> comprises of:</t>
<t><list style="numbers">
<t>The asynchronous advertisement of footprint and capabilities by a
downstream CDN (dCDN) that allows an upstream CDN (uCDN) to decide
whether to redirect particular user requests to that dCDN.</t>
<t>The synchronous operation of a uCDN requesting whether a dCDN is
prepared to accept a user request and of a dCDN responding with how
to actually redirect the user request.</t>
</list></t>
<t>This document describes an interface for the latter part, i.e. the
CDNI Request Routing Redirection interface (RI).</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"/>.</t>
<t>This document reuses the terminology defined in <xref
target="RFC6707"/>.</t>
<t>The following additional terms are introduced by this document:</t>
<t><list style="hanging">
<t hangText="Application Level Redirection:">The act of using an
application specific redirection mechanism for the request routing
process of a CDN. The Redirection Target (RT) is the result of the
routing decision of a CDN at the time it receives a content request
via an application specific protocol response. Examples of an
application level redirection are HTTP 302 Redirection and RTMP 302
Redirection.</t>
<t hangText="DNS Redirection:">The act of using DNS name resolution
for the request routing process of a CDN. In DNS Redirection, the
DNS name server of the CDN makes the routing decision based on a
local policy and selects one or more Redirection Targets (RTs) and
redirects the user agent to the RT(s) by returning the details of
the RT(s) in response to the DNS query request from the user agent's
DNS resolver.</t>
<t hangText="HTTP Redirection:">The act of using an HTTP redirection
response for the request routing process of a CDN. The Redirection
Target (RT) is the result of the routing decision of a CDN at the
time it receives a content request via HTTP. HTTP Redirection is a
particular case of Application Level Redirection.</t>
<t hangText="Redirection Target (RT):">A Redirection Target is the
endpoint to which the user agent is redirected. In CDNI, a RT may
point to a number of different components, some examples include a
surrogate in the same CDN as the request router, a request router in
a dCDN or a surrogate in a dCDN, etc.</t>
</list></t>
</section>
<section title="Interface function and operation overview">
<t>The main function of the CDNI Redirection interface (RI) is to allow
the request routing systems in interconnected CDNs to communicate to
facilitate the redirection of User Agent requests between interconnected
CDNs.</t>
<t>The detailed requirements for the Redirection Interface and their
relative priorities are described in section 5 of <xref
target="RFC7337"/>.</t>
<t>The User Agent will make a request to a request router in the uCDN
using one of either DNS or HTTP. The RI is used between the uCDN and one
or more dCDNs. The dCDN's RI response may contain a Redirection Target
with a type that is compatible with the protocol used between User Agent
and uCDN request router. The dCDN has control over the Redirection
Target it provides. Depending on the returned Redirection Target, the
User Agent's request may be redirected to:</t>
<t><list style="symbols">
<t>The final Surrogate, which may be in the dCDN that returned the
RI response to the uCDN, or another CDN (if the dCDN delegates the
delivery to another CDN).</t>
<t>A request router (in the dCDN or another CDN), which may use a
different redirection protocol (DNS or HTTP) than the one included
in the RI request.</t>
</list></t>
<t>The Redirection interface operates between the request routing
systems of a pair of interconnected CDNs. To enable communication over
the Redirection Interface, the uCDN needs to know the URI (end point) in
the dCDN to send CDNI request routing queries.</t>
<t>The 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
Redirection Interface specification.</t>
<t>The Redirection Interface is only relevant in the case of Recursive
Request Redirection, as Iterative Request Redirection does not invoke
any interaction over the Redirection Interface between interconnected
CDNs. Therefore the scope of this document is limited to Recursive
Request Redirection.</t>
<t>In the case of Recursive Request Redirection, in order to perform
redirection of a request received from a User Agent, the uCDN queries
the dCDN so that the dCDN can select and provide a Redirection Target.
In cases where a uCDN has a choice of dCDNs it is up to the uCDN to
decide (for example via configured policies) which dCDN(s) to query and
in which order to query them. A number of strategies are possible
including selecting a preferred dCDN based on local policy, possibly
falling back to querying an alternative dCDN(s) if the first dCDN does
not return a Redirection Target or otherwise rejects the uCDN's RI
request. A more complex strategy could be to query multiple dCDNs in
parallel before selecting one and using the Redirection Target provided
by that dCDN.</t>
<t>The uCDN->User Agent redirection protocols addressed in this draft
are: DNS redirection and HTTP redirection. Other types of application
level redirection will not be discussed further in this document.
However, the Redirection Interface is designed to be extensible and
could be extended to support additional application level redirection
protocols.</t>
<t>This document also defines an RI loop prevention and detection
mechanism as part of the Redirection Interface.</t>
<section title="Redirection of encrypted traffic">
<t>
The Redirection Interface defined in this document might be used to redirect a request where the User Agent will subsequently attempt to establish a TLS session with the Redirection Target. In such a case, any surrogate or request router to which the User Agent is redirected needs to be able to successfully complete the TLS handshake and to perform encryption of the TLS channel. Mechanisms to distribute the required information and/or configuration, such as private keys, to surrogates and request routers in dCDNs are outside the scope of this document.
</t>
</section>
</section>
<section title="HTTP based interface for the Redirection Interface">
<t>This document defines a simple interface for the Redirection
Interface based on HTTP 1.1 <xref target="RFC7230"/>, where the
attributes of a User Agent's requests are encapsulated along with any
other data that can aid the dCDN in processing the requests. The RI
response encapsulates the attributes of the RT(s) that the uCDN should
return to the User Agent (if it decides to utilize the dCDN for
delivery) along with the policy for how the response can be reused. The
examples of RI requests and responses below do not contain a complete
set of HTTP headers for brevity; only the pertinent HTTP headers are
shown.</t>
<t>The same HTTP interface is used for both DNS and HTTP redirection of
User Agent requests, although the contents of the RI requests/responses
contain data specific to either DNS or HTTP redirection.</t>
<t>This approach has been chosen because it enables CDN operators to
only have to deploy a single interface for the RI 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.</t>
<t>In addition, having a single RI where the attributes of the User
Agent's DNS or HTTP request are encapsulated along with the other data
required for the dCDN 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 Redirection
interface properties/data within those End User DNS/HTTP/RTMP/etc
requests.</t>
<t>Finally, the RI is easily extendable to support other User Agent
request redirection methods (e.g. RTMP 302 redirection).</t>
<t>The generic Recursive Request Redirection message flow between
Request Routing systems in a pair of interconnected CDNs is as
follows:</t>
<t/>
<figure anchor="generic-message-flow"
title="Generic Recursive Request Redirection message flow">
<artwork><![CDATA[User Agent CDN B RR CDN A RR
|UA Request (DNS or HTTP) | |
|-------------------------------------------------->| (1)
| | |
| |HTTP POST to CDN B's RI |
| |URI encapsulating UA |
| |request attributes |
| |<------------------------| (2)
| | |
| |HTTP Response with body |
| |containing RT attributes |
| |of the protocol specific |
| |response to return to UA |
| |------------------------>| (3)
| | |
| Protocol specific response (redirection)|
|<--------------------------------------------------| (4)
| | |]]></artwork>
</figure>
<t/>
<t><list style="numbers">
<t>The User Agent sends its (DNS or HTTP) request to CDN A. The
Request Routing System of CDN A processes the request and, through
local policy, recognizes that the request is best served by another
CDN, specifically CDN B (or that CDN B may be one of a number of
candidate dCDNs it could use).</t>
<t>The Request Routing System of CDN A sends an HTTP POST to CDN B's
RI URI containing the attributes of the User Agent's request.</t>
<t>The Request Routing System of CDN B processes the RI request and
assuming the request is well formed, responds with an HTTP "200"
response with a message body containing the RT(s) to return to the
User Agent as well as parameters that indicate the properties of the
response (cacheability and scope).</t>
<t>The Request Routing System of CDN A sends a protocol specific
response (containing the returned attributes) to the User Agent, so
that the User Agent's request will be redirected to the RT(s)
returned by CDN B.</t>
</list></t>
<section title="Information passed in RI requests & responses">
<t>The information passed in RI requests splits into two basic
categories:</t>
<t><list style="numbers">
<t>The attributes of the User Agent's request to the uCDN.</t>
<t>Properties/parameters that the uCDN can use to control the
dCDN’s response or that can help the dCDN make its
decision.</t>
</list></t>
<t>To assist the routing decision of a dCDN, the uCDN SHOULD convey as
much information as possible to the dCDN, for example the URI of the
requested content and the User Agent's IP address or subnet, when
those are known by the uCDN Request Routing system.</t>
<t>In order for the dCDN to determine whether it is capable of
delivering any requested content, it requires CDNI metadata related to
the content the User Agent is requesting. That metadata will describe
the content and any policies associated with it. It is expected that
the RI request contains sufficient information for the Request Router
in the dCDN to be able to retrieve the required CDNI Metadata via the
CDNI Metadata interface.</t>
<t>The information passed in RI responses splits into two basic
categories:</t>
<t><list style="numbers">
<t>The attributes of the RT to return to the User Agent in the DNS
response or HTTP response.</t>
<t>Parameters/policies that indicate the properties of the
response, such as, whether it is cacheable, the scope of the
response, etc.</t>
</list></t>
<t>In addition to details of how to redirect the User Agent, the dCDN
may wish to return additional policy information to the uCDN to it
with future RI requests. For example the dCDN may wish to return a
policy that expresses “this response can be reused without
requiring an RI request for 60 seconds provided the User Agent's IP
address is in the range 198.51.100.0 - 198.51.100.255”.</t>
<t>These additional policies split into two basic categories:</t>
<t><list style="symbols">
<t>Cacheability information signaled via the HTTP response headers
of the RI response (to reduce the number of subsequent RI requests
the uCDN needs to make).</t>
<t>The scope of the response (if it is cacheable) signaled the
HTTP response body of the RI response. For example whether the
response applies to a wider range of IP addresses than what was
included in the RI request.</t>
</list></t>
<t>The cacheability of the response is indicated using the standard
HTTP Cache-Control mechanisms.</t>
</section>
<section title="JSON encoding of RI requests & responses">
<t>The body of RI requests and responses is a JSON object <xref
target="RFC7159"/> that MUST conform to <xref target="RFC7493"/>
containing a dictionary of key:value pairs.</t>
<t>The following additional rules apply to all keys in RI requests and
responses (whether in the top level object or in sub-objects):</t>
<t><list style="symbols">
<t>Keys MUST always be encoded in lowercase. Requests or responses
containing keys that are not all lowercase MUST be considered
syntactically invalid.</t>
<t>Unknown keys MUST be ignored but the request or response MUST
NOT be considered invalid unless the syntax of the request or
response is invalid (i.e. an RI request or response MUST NOT be
considered invalid on the basis that it contains unknown
keys).</t>
</list></t>
<t>The following top level keys are defined along with whether they
are applicable to RI requests, RI responses or both:</t>
<texttable title="Top-Level keys in RI requests/responses">
<ttcol>Key</ttcol>
<ttcol>Request/Response</ttcol>
<ttcol>Description</ttcol>
<c>dns</c>
<c>Both</c>
<c>The attributes of the UA's DNS request or the attributes of the
RT(s) to return in a DNS response.</c>
<c>http</c>
<c>Both</c>
<c>The attributes of the UA's HTTP request or the attributes of the
RT to return in a HTTP response.</c>
<c>scope</c>
<c>Response</c>
<c>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 RI request.</c>
<c>error</c>
<c>Response</c>
<c>Additional details if the response is an error response.</c>
<c>cdn-path</c>
<c>Both</c>
<c>A List of Strings. Contains a list of the CDN Provider IDs of
previous CDNs that have participated in the request routing for the
associated User Agent request. On RI requests it contains the list
of previous CDNs that this RI request has passed through. On RI
responses it contains the list of CDNs that were involved in
obtaining the final redirection included in the RI response.</c>
<c>max-hops</c>
<c>Request</c>
<c>Integer specifying the maximum number of hops (CDN Provider IDs)
this request is allowed to be propagated along. This allows the uCDN
to coarsely constrain the latency of the request routing chain.</c>
</texttable>
<t>A single request or response MUST contain only one of the dns or
http keys. Requests MUST contain a cdn-path key and responses MAY
contain a cdn-path key. If the max-hops key is not present then there
is no limit on the number of CDN hops that the RI request can be
propagated along. If the first uCDN does not wish the RI request to be
propagated beyond the dCDN it is making the request to, then the uCDN
MUST set max-hops to 1.</t>
<t>When cascading an RI request, a transit CDN MUST append its own CDN
Provider ID to the list in cdn-path so that dCDNs can detect loops in
the RI request chain. Transit CDNs MUST check the cdn-path and MUST
NOT cascade the RI request to dCDNs that are already listed in
cdn-path. Transit CDNs MUST NOT modify the cdn-path when cascading an
RI request, except to append its own CDN Provider ID.</t>
<t>The cdn-path MAY be reflected back in RI responses, although doing
so could expose information to the uCDN that a dCDN may not wish to
expose (for example, the existence of business relationships between a
dCDN and other CDNs).</t>
<t>If the cdn-path is reflected back in the RI response it MUST
contain the value of cdn-path received in the associated RI request
with the final dCDN's CDN Provider ID appended. Transit CDNs MAY
remove the cdn-path from RI responses but MUST NOT modify the cdn-path
in other ways.</t>
<t>The presence of an error key within a response that also contains
either a dns or http key does not automatically indicate that the RI
request was unsuccessful as the error key MAY be used for
communicating additional (e.g. debugging) information. When a response
contains an error key as well as either a dns or http key, the
error-code SHOULD be 1xx (e.g. 100). See <xref target="error"/> for
more details of encoding error information in RI responses.</t>
<t>Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of <xref
target="RFC3986"/> and MUST support all IPv6 address formats specified
in <xref target="RFC4291"/>. Server implementations SHOULD use IPv6
address formats specified in <xref target="RFC5952"/>.</t>
</section>
<section title="MIME Media Types used by the RI interface">
<t>RI requests MUST use a MIME Media Type of application/cdni as specified in <xref target="I-D.ietf-cdni-media-type"/>, with the Payload Type (ptype) parameter set to 'redirection-request'.</t>
<t>RI requests MUST use a MIME Media Type of application/cdni as specified in <xref target="I-D.ietf-cdni-media-type"/>, with the Payload Type (ptype) parameter set to 'redirection-response'.</t>
</section>
<section title="DNS redirection">
<t>The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for DNS
redirection.</t>
<section title="DNS Redirection requests">
<t>For DNS based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:</t>
<t><list style="symbols">
<t>The IP address of the DNS resolver that made the DNS request
to the uCDN.</t>
<t>The type of DNS query made (usually either A or AAAA).</t>
<t>The class of DNS query made (usually IN).</t>
<t>The fully qualified domain name for which DNS redirection is
being requested.</t>
<t>The IP address or prefix of the User Agent (if known to the
uCDN).</t>
</list></t>
<t>The information above is encoded as a set of key:value pairs
within the dns dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>resolver-ip</c>
<c>String</c>
<c>Yes</c>
<c>The IP address of the UA's DNS resolver.</c>
<c>qtype</c>
<c>String</c>
<c>Yes</c>
<c>The type of DNS query made by the UA's DNS resolvers in
uppercase (A, AAAA, etc.).</c>
<c>qclass</c>
<c>String</c>
<c>Yes</c>
<c>The class of DNS query made in uppercase (IN, etc.).</c>
<c>qname</c>
<c>String</c>
<c>Yes</c>
<c>The fully qualified domain name being queried.</c>
<c>c-subnet</c>
<c>String</c>
<c>No</c>
<c>The IP address (or prefix) of the UA in CIDR format.</c>
<c>dns-only</c>
<c>Boolean</c>
<c>No</c>
<c>If True then dCDN MUST only use DNS redirection and MUST
include RTs to one or more surrogates in its RI response. CDNs
MUST include the dns-only property set to True on any cascaded RI
requests. Defaults to False.</c>
</texttable>
<t>An RI request for DNS-based redirection MUST include a dns
dictionary. This dns dictionary MUST contain the following keys:
resolver-ip, qtype, qclass, qname and the value of each MUST be the
value of the appropriate part of the User Agent's DNS
query/request.</t>
<t>An example RI request (uCDN->dCDN) for DNS based
redirection:</t>
<t/>
<figure>
<artwork><![CDATA[POST /dcdn/ri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"dns" : {
"resolver-ip" : "192.0.2.1",
"c-subnet" : "198.51.100.0/24",
"qtype" : "A",
"qclass" : "IN",
"qname" : "www.example.com"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
]]></artwork>
</figure>
</section>
<section anchor="dns-redirection-response"
title="DNS Redirection responses">
<t>For a successful DNS based redirection, the dCDN needs to return
one of the following to the uCDN in the RI response:</t>
<t><list style="symbols">
<t>The IP address(es) of (or the CNAME of) RTs that are dCDN
surrogates (if the dCDN is performing DNS based redirection
directly to a surrogate); or</t>
<t>The IP address(es) of (or the CNAME of) RTs that are Request
Routers (if the dCDN will perform request redirection itself). A
dCDN MUST NOT return a RT which is a Request Router if the
dns-only key is set to True in the RI request.</t>
</list></t>
<t>The information above is encoded as a set of key:value pairs
within the dns dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>rcode</c>
<c>Integer</c>
<c>Yes</c>
<c>DNS response code (see <xref target="RFC6895"/>).</c>
<c>name</c>
<c>String</c>
<c>Yes</c>
<c>The fully qualified domain name the response relates to.</c>
<c>a</c>
<c>List of String</c>
<c>No</c>
<c>Set of IPv4 Addresses of RT(s).</c>
<c>aaaa</c>
<c>List of String</c>
<c>No</c>
<c>Set of IPv6 Addresses of RT(s).</c>
<c>cname</c>
<c>List of String</c>
<c>No</c>
<c>Set of fully qualified domain names of RT(s).</c>
<c>ttl</c>
<c>Integer</c>
<c>No</c>
<c>TTL in seconds of DNS response. Default is 0.</c>
</texttable>
<t>A successful RI response for DNS-based redirection MUST include a
dns dictionary and MAY include an error dictionary (see <xref
target="error"/>). An unsuccessful RI response for DNS-based
redirection MUST include an error dictionary. If a dns dictionary is
included in the RI response, it MUST include at least one of the
following keys: a, aaaa, cname. The dns dictionary MAY include both
'a' and 'aaaa' keys. If the dns dictionary contains a cname key it
MUST NOT contain either an a or aaaa key.</t>
<t>An example of a successful RI response (dCDN->uCDN) for DNS
based redirection with both a and aaaa keys is listed below :</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
]]></artwork>
</figure>
<t/>
<t>A further example of a successful RI response (dCDN->uCDN) for
DNS based redirection is listed below, in this case with a cname key
containing the FQDN of the RT.</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"cname" : ["rr1.dcdn.example"],
"ttl" : 20
}
}]]></artwork>
</figure>
<t/>
</section>
</section>
<section title="HTTP Redirection">
<t>The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for
HTTP redirection.</t>
<t>The dictionary keys used in HTTP Redirection requests and responses
use the following conventions for their prefixes:</t>
<t><list style="symbols">
<t>c- is prefixed to keys for information related to the Client
(User Agent).</t>
<t>cs- is prefixed to keys for information passed by the Client
(User Agent) to the Server (uCDN).</t>
<t>sc- is prefixed to keys for information to be passed by the
Server (uCDN) to the Client (User Agent).</t>
</list></t>
<section title="HTTP Redirection requests">
<t>For HTTP-based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:</t>
<t><list style="symbols">
<t>The IP address of the User Agent.</t>
<t>The URI requested by the User Agent.</t>
<t>The HTTP method requested by the User Agent</t>
<t>The HTTP version number requested by the User Agent.</t>
</list></t>
<t>The uCDN may also decide to pass the presence and value of
particular HTTP headers included in the User Agent request to the
dCDN.</t>
<t>The information above is encoded as a set of key:value pairs
within the http dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>c-ip</c>
<c>String</c>
<c>Yes</c>
<c>The IP address of the UA.</c>
<c>cs-uri</c>
<c>String</c>
<c>Yes</c>
<c>The Effective Request URI <xref target="RFC7230"/> requested by
the UA.</c>
<c>cs-method</c>
<c>String</c>
<c>Yes</c>
<c>The method part of the request-line as defined in <xref
target="RFC7230">Section 3.1.1 of</xref>.</c>
<c>cs-version</c>
<c>String</c>
<c>Yes</c>
<c>The HTTP-version part of the request-line as defined in <xref
target="RFC7230">Section 3.1.1 of</xref>.</c>
<c>cs-(<headername>)</c>
<c>String</c>
<c>No</c>
<c>The field-value of the HTTP header field named
<HeaderName> as a string, for example cs-(cookie) would
contain the value of the HTTP Cookie header from the UA
request.</c>
</texttable>
<t>An RI request for HTTP-based redirection MUST include an http
dictionary. This http dictionary MUST contain the following keys:
c-ip, cs-method, cs-version and cs-uri and the value of each MUST be
the value of the appropriate part of the User Agent's HTTP
request.</t>
<t>The http dictionary of an RI request MUST contain a maximum of
one cs-(<headername>) key for each unique header field-name
(HTTP header field). <headername> MUST be identical to the
equivalent HTTP header field-name encoded in all lowercase.</t>
<t>In the case where the User Agent request includes multiple HTTP
header fields with the same field-name, it is RECOMMENDED that the
uCDN combines these different HTTP headers into a single value
according to <xref target="RFC7230">Section 3.2.2 of</xref>.
However, because of the plurality of already defined HTTP header
fields, and inconsistency of some of these header fields concerning
the combination mechanism defined in RFC 7230, the uCDN MAY have to
deviate from using the combination mechanism where appropriate. For
example, it MAY only send the contents of the first occurrence of
the HTTP Headers instead.</t>
<t>An example RI request (uCDN->dCDN) for HTTP based
redirection:</t>
<t/>
<figure>
<artwork><![CDATA[POST /dcdn/rrri HTTP/1.1
Host: rr1.dcdn.example.net
Content-Type: application/cdni; ptype=redirection-request
Accept: application/cdni; ptype=redirection-response
{
"http": {
"c-ip": "198.51.100.1",
"cs-uri": "http://www.example.com",
"cs-version": "HTTP/1.1",
"cs-method": "GET"
},
"cdn-path": ["AS64496:0"],
"max-hops": 3
}
]]></artwork>
</figure>
</section>
<section anchor="http-redirection-response"
title="HTTP Redirection responses">
<t/>
<t>For a successful HTTP based redirection, the dCDN needs to return
one of the following to the uCDN in the RI response:<list
style="symbols">
<t>A URI pointing to an RT that is the selected dCDN
surrogate(s) (if the dCDN is performing HTTP based redirection
directly to a surrogate); or</t>
<t>A URI pointing to an RT that is a Request Router (if the dCDN
will perform request redirection itself).</t>
</list></t>
<t/>
<t>The information above is encoded as a set of key:value pairs
within the http dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>sc-status</c>
<c>Integer</c>
<c>Yes</c>
<c>The status-code part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA
(usually set to 302).</c>
<c>sc-version</c>
<c>String</c>
<c>Yes</c>
<c>The HTTP-version part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA.</c>
<c>sc-reason</c>
<c>String</c>
<c>Yes</c>
<c>The reason-phrase part of the status-line as defined in <xref
target="RFC7230">Section 3.1.2 of</xref> to return to the UA.</c>
<c>cs-uri</c>
<c>String</c>
<c>Yes</c>
<c>The URI requested by the UA/client.</c>
<c>sc-(location)</c>
<c>String</c>
<c>Yes</c>
<c>The contents of the Location header to return to the UA (i.e. a
URI pointing to the RT(s)).</c>
<c>sc-(<headername>)</c>
<c>String</c>
<c>No</c>
<c>The field-value of the HTTP header field named
<HeaderName> to return to the UA. For example, sc-(expires)
would contain the value of the HTTP Expires header.</c>
</texttable>
<t>Note: The sc-(location) key in the table above is an example of
sc-(<headername>) that has been called out separately as its
presence is mandatory in RI responses.</t>
<t>A successful RI response for HTTP-based redirection MUST include
an http dictionary and MAY include an error dictionary (see <xref
target="error"/>). An unsuccessful RI response for HTTP-based
redirection MUST include an error dictionary. If an http dictionary
is included in the RI response, it MUST include at least the
following keys: sc-status, sc-version, sc-reason, cs-uri,
sc-(location).</t>
<t>The http dictionary of an RI response MUST contain a maximum of
one sc-(<headername>) key for each unique header field-name
(HTTP header field). <headername> MUST be identical to the
equivalent HTTP header field-name encoded in all lowercase.</t>
<t>The uCDN MAY decide to not return, override or alter any or all
of the HTTP headers defined by sc-(<headername>) keys before
sending the HTTP response to the UA. It should be noted that in some
cases, sending the HTTP Headers indicated by the dCDN transparently
on to the UA might result in, for the uCDN, undesired behaviour. As
an example, the dCDN might include sc-(cache-control),
sc-(last-modified) and sc-(expires) keys in the http dictionary,
through which the dCDN may try to influence the cacheability of the
response by the UA. If the uCDN would pass these HTTP headers on to
the UA, this could mean that further requests from the uCDN would go
directly to the dCDN, bypassing the uCDN and any logging it may
perform on incoming requests. The uCDN is therefore recommended to
carefully consider which HTTP headers to pass on, and which to
either override or not pass on at all.</t>
<t>An example of a successful RI response (dCDN->uCDN) for HTTP
based redirection:</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
}
}
]]></artwork>
</figure>
</section>
</section>
<section title="Cacheability and scope of responses">
<t>RI responses may be cacheable. As long as a cached RI response is
not stale according to standard HTTP Cache-Control or other applicable
mechanisms, it may be reused by the uCDN in response to User Agent
requests without sending another RI request to the dCDN.</t>
<t>An RI response MUST NOT be reused unless the request from the User
Agent would generate an identical RI request to the dCDN as the one
that resulted in the cached RI response (except for the c-ip field
provided that the User Agent's c-ip is covered by the scope in the
original RI response, as elaborated upon below).</t>
<t>Additionally, although RI requests only encode a single User Agent
request to be redirected there may be cases where a dCDN wishes to
indicate to the uCDN that the RI response can be reused for other User
Agent requests without the uCDN having to make another request via the
RI. For example a dCDN may know that it will always select the same
Surrogates for a given set of User Agent IP addresses and in order to
reduce request volume across the RI or to remove the additional
latency associated with an RI request, the dCDN may wish to indicate
that set of User Agent IP addresses to the uCDN in the initial RI
response. This is achieved by including an optional scope dictionary
in the RI response.</t>
<t>Scope is encoded as a set of key:value pairs within the scope
dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>iprange</c>
<c>List of String</c>
<c>No</c>
<c>A List of IP subnets in CIDR notation that this RI response can
be reused for, provided the RI response is still considered
fresh.</c>
</texttable>
<t>If a uCDN has multiple cached responses with overlapping scopes and
a UA request comes in for which the User Agent's IP matches with the
IP subnets in multiple of these cached responses, the uCDN SHOULD use
the most recent cached response when determining the approriate RI
response to use.</t>
<t>The following is an example of a DNS redirection response from
<xref target="dns-redirection-response"/> that is cacheable by the
uCDN for 30 seconds and can be returned to any User Agent with an IPv4
address in 198.51.100.0/24.</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=30
{
"dns" : {
"rcode" : 0,
"name" : "www.example.com",
"a" : ["203.0.113.200", "203.0.113.201"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
]]></artwork>
</figure>
<t/>
<t>Example of HTTP redirection response from <xref
target="http-redirection-response"/> that is cacheable by the uCDN for
60 seconds and can be returned to any User Agent with an IPv4 address
in 198.51.100.0/24.</t>
<t>Note: The response to the UA is only valid for 30 seconds, whereas
the uCDN can cache the RI response for 60 seconds.</t>
<t/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: public, max-age=60
{
"http": {
"sc-status": 302,
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
"sc-(cache-control)" : "public, max-age=30"
}
"scope" : {
"iprange" : ["198.51.100.0/24"]
}
}
]]></artwork>
</figure>
<t/>
</section>
<section anchor="error" title="Error responses">
<t>From a uCDN perspective, there are two types of errors that can be
the result of the transmission of an RI request to a dCDN:</t>
<t><list style="numbers">
<t>An HTTP protocol error signaled via an HTTP status code,
indicating a problem with the reception or parsing of the RI
request or the generation of the RI response by the dCDN, and</t>
<t>An RI-level error specified in an RI response message</t>
</list></t>
<t>This section deals with the latter type. The former type is outside
the scope of this document.</t>
<t>There are numerous reasons for a dCDN to be unable to return an
affirmative RI response to a uCDN. Reasons may include both dCDN
internal issues such as capacity problems, as well as reasons outside
the influence of the dCDN, such as a malformed RI request. To aid with
diagnosing the cause of errors, RI responses SHOULD include an error
dictionary to provide additional information to the uCDN as to the
reason/cause of the error. The intention behind the error dictionary
is to aid with either manual or automatic diagnosis of issues. The
resolution of such issues is outside the scope of this document; this
document does not specify any consequent actions a uCDN should take
upon receiving a particular error code.</t>
<t>Error information (if present) is encoded as a set of key:value
pairs within a JSON-encoded error dictionary as follows:</t>
<texttable>
<ttcol>Key</ttcol>
<ttcol>Value</ttcol>
<ttcol>Mandatory</ttcol>
<ttcol>Description</ttcol>
<c>error-code</c>
<c>Integer</c>
<c>Yes</c>
<c>A three-digit numeric code defined by the server to indicate the
error(s) that occurred.</c>
<c>reason</c>
<c>String</c>
<c>No</c>
<c>A string providing further information related to the error.</c>
</texttable>
<t>The first digit of the error-code defines the class of error. There
are 5 classes of error distinguished by the first digit of the
error-code:</t>
<t><list style="empty">
<t>1xx: Informational (no error): The response should not be
considered an error by the uCDN, which may proceed by redirecting
the UA according to the values in the RI response. The error code
and accompanying description may be used for informational
purposes, e.g. for logging.</t>
<t>2xx: Reserved.</t>
<t>3xx: Reserved.</t>
<t>4xx: uCDN error: The dCDN can not or will not process the
request due to something that is perceived to be a uCDN error, for
example the RI request could not be parsed succesfully by the
dCDN. The last two-digits may be used to more specifically
indicate the source of the problem.</t>
<t>5xx: dCDN error: Indicates that the dCDN is aware that it has
erred or is incapable of satisfying the RI request for some
reason, for example the dCDN was able to parse the RI request but
encountered an error for some reason. Examples include the dCDN
not being able to retrieve the associated metadata or the dCDN
being out of capacity.</t>
</list></t>
<t>The following error codes are defined and maintained by IANA (see
<xref target="iana_section"/>):</t>
<t>Error codes with a "Reason" of "<reason>" do not have a
defined value for their 'reason'-key. Depending on the error-code
semantics, the value of this field may be determined dynamically.</t>
<texttable anchor="error_codes">
<ttcol>Code</ttcol>
<ttcol>Reason</ttcol>
<ttcol>Description</ttcol>
<c>100</c>
<c><reason> (see Description)</c>
<c>Generic informational error-code meant for carrying a
human-readable string</c>
<c>400</c>
<c><reason> (see Description)</c>
<c>Generic error-code for uCDN errors where the dCDN can not or will
not process the request due to something that is perceived to be a
uCDN error. The reason field may be used to provide more details
about the source of the error.</c>
<c>500</c>
<c><reason> (see Description)</c>
<c>Generic error-code for dCDN errors where the dCDN is aware that
it has erred or is incapable of satisfying the RI request for some
reason. The reason field may be used to provide more details about
the source of the error.</c>
<c>501</c>
<c>Unable to retrieve metadata</c>
<c>The dCDN is unable to retrieve the metadata associated with the
content requested by the UA. This may indicate a configuration error
or the content requested by the UA not existing.</c>
<c>502</c>
<c>Loop detected</c>
<c>The dCDN detected a redirection loop (see <xref
target="loop_detection"/>).</c>
<c>503</c>
<c>Maximum hops exceeded</c>
<c>The dCDN detected the maximum number of redirection hops
exceeding max-hops (see <xref target="loop_detection"/>).</c>
<c>504</c>
<c>Out of capacity</c>
<c>The dCDN does not currently have sufficient capacity to handle
the UA request.</c>
<c>505</c>
<c>Delivery protocol not supported</c>
<c>The dCDN does not support the (set of) delivery protocols
indicated in the CDNI Metadata of the content requested content by
the UA.</c>
<c>506</c>
<c>Redirection protocol not supported</c>
<c>The dCDN does not support the requested redirection protocol.
This error-code is also used when the RI request has the dns-only
flag set to True and the dCDN is not support or is not prepared to
return a RT of a surrogate directly.</c>
</texttable>
<t>The following is an example of an unsuccessful RI response
(dCDN->uCDN) for a DNS based User Agent request:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 500 Internal Server Error
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"error" : {
"error-code" : 504,
"description" : "Out of capacity"
}
}
]]></artwork>
</figure>
<t/>
<t>The following is an example of a successful RI response
(dCDN->uCDN) for a HTTP based User Agent request containing an
error dictionary for informational purposes:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni; ptype=redirection-response
Cache-Control: private, no-cache
{
"http": {
"sc-status": 302,
"sc-version": "HTTP/1.1",
"sc-reason": "Found",
"cs-uri": "http://www.example.com"
"sc-(location)":
"http://sur1.dcdn.example/ucdn/example.com",
},
"error" : {
"error-code" : 100,
"description" :
"This is a human-readable message meant for debugging purposes"
}
}
]]></artwork>
</figure>
</section>
<section anchor="loop_detection" title="Loop detection & prevention">
<t>In order to prevent and detect RI request loops, each CDN MUST
insert its CDN Provider ID into the cdn-path key of every RI request
it originates or cascades. When receiving RI requests a dCDN MUST
check the cdn-path and reject any RI requests which already contain
the dCDN's Provider ID in the cdn-path. Transit CDNs MUST check the
cdn-path and not cascade the RI request to dCDNs that are already
listed in cdn-path. Transit CDNs MUST NOT propagate to any downstream
CDNs if the number of CDN Provider IDs in cdn-path (before adding its
own Provider ID) is equal to or greater than max-hops.</t>
<t>The CDN Provider ID uniquely identifies each CDN provider during
the course of request routing redirection. It consists of the
characters AS followed by the CDN Provider's AS number, then a colon
(':') and an additional qualifier that is used to guarantee uniqueness
in case a particular AS has multiple independent CDNs deployed. For
example "AS64496:0".</t>
<t>If a dCDN receives an RI request whose cdn-path already contains
that dCDN's Provider ID the dCDN SHOULD send an RI response with an
error code of 502.</t>
<t>If a dCDN receives an RI request where the number of CDN Provider
IDs in cdn-path is greater than max-hops, the dCDN SHOULD send an RI
response with an error code of 503.</t>
<t>It should be noted that the loop detection & prevention
mechanisms described above only cover preventing and detecting loops
within the RI itself. As well as loops within the RI itself, there is
also the possibility of loops in the data plane, for example if the IP
address(es) or URI(s) returned in RI responses do not resolve directly
to a surrogate in the final dCDN there is the possibility that a User
Agent may be continuosly redirected through a loop of CDNs. The
specification of solutions to address data plane request redirection
loops between CDNs is outside of the scope of this document.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>Information passed over the RI could be considered personal or
sensitive, for example RI requests contain parts of a User Agent's
original request and RI responses reveal information about the dCDN's
policy for which surrogates should serve which content/user
locations.</t>
<t>The RI interface also provides a mechanism whereby a uCDN could probe
a dCDN and infer the dCDN's edge topology by making repeated RI requests
for different content and/or UA IP addresses and correlating the
responses from the dCDN. Additionally the ability for a dCDN to indicate
that an RI response applies more widely than the original request (via
the scope dictionary) may significantly reduce the number of RI requests
required to probe and infer the dCDN's edge topology.</t>
<t>The same information could be obtained in the absence of the RI
interface, but it could be more difficult to gather as it would require
a distributed set of machines with a range of different IP addresses
each making requests directly to the dCDN. However, the RI facilitates
easier collection of such information as it enables a single client to
query the dCDN for a redirection/surrogate selection on behalf of any UA
IP address.</t>
<section anchor="authentication" title="Authentication, Authorization, Confidentiality, Integrity
Protection">
<t>An implementation of the CDNI Redirection interface MUST support TLS transport as per <xref target="RFC2818"/> and <xref target="RFC7230"/>. The use of TLS for transport of the CDNI Redirection interface messages allows:</t>
<t><list style="symbols">
<t>The dCDN and uCDN to authenticate each other</t>
</list></t>
<t>and, once they have mutually authenticated each other, it allows:</t>
<t><list style="symbols">
<t>the dCDN and uCDN to authorize each other (to ensure they are transmitting/receiving CDNI Redirection messages to/from an authorized CDN)</t>
<t>CDNI Redirection interface messages to be transmitted with
confidentiality.</t>
<t>The integrity of the CDNI Redirection interface messages to be
protected during the exchange.</t>
</list>
</t>
<t>In an environment where any such protection is required,
mutually authenticated encrypted transport MUST be used to ensure
confidentiality of the redirection information. To that end, TLS MUST be used (including authentication of the remote end) by the server-side (dCDN) and the client-side (uCDN) of the CDNI Redirection interface.</t>
<t>When TLS is used, the general TLS usage guidance in <xref target="RFC7525"/> MUST be followed.</t>
</section>
<section anchor="privacy" title="Privacy">
<t>Information passed over the RI could be considered personal or sensitive. In particular, parts of a User Agent's
original request, most notably the UA's IP address and requested URI, are transmitted over the RI to the dCDN. The use of mutually authenticated TLS, as described in the previous section, prevents any other party than the authorized dCDN from gaining access to this information.</t>
<t>Regardless of whether the uCDN and dCDN use the RI, a successfull redirect from a uCDN to a dCDN will make that dCDN aware of the UA's IP address. As such, the fact that this information is transmitted across the RI does not allow the dCDN to learn new information. On the other hand, if a uCDN uses the RI to check with multiple candidate dCDNs, those candidates that do not end up getting redirected to, do obtain information regarding End User IP addresses and requested URIs that they wouldn't had the RI not been used.</t>
<t>While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address, it is important to note that this will reduce the effectivess of the RI in certain cases. As an example, when the UA is behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary. Another potential issue when using IP anonymization is that it is no longer possible to correlate a RI Request with a subsequent UA request.</t>
</section>
</section>
<section anchor="iana_section" title="IANA Considerations">
<section title="CDNI Payload Type Parameter registrations">
<t>The IANA is requested to register the following two new Payload Types in the CDNI Payload Type Parameter registry for use with the application/cdni MIME media type.</t>
<texttable>
<ttcol>Payload Type</ttcol>
<ttcol>Specification</ttcol>
<c>redirection-request</c>
<c>[RFCthis]</c>
<c>redirection-response</c>
<c>[RFCthis]</c>
</texttable>
</section>
<section title="RI Error response registry">
<t>This document establishes a new IANA registry for CDNI RI Error
response codes.</t>
<t>An expert reviewer is advised to examine new registrations for
possible duplication with existing error codes and to ensure that the
new code is in accordance with the error classes defined in section
<xref target="error"/> of this document.</t>
<t>New registrations are required to provide the following
information:</t>
<t><list style="empty">
<t>Code: A three-digit numeric error-code, in accordance with the
error classes defined in section <xref target="error"/> of this
document.</t>
<t>Reason: A string that provides further information related to
the error that will be included in the JSON error dictionary with
the 'reason'-key. Depending on the error-code semantics, the value
of this field may be determined dynamically. In that case, the
registration should set this value to '<reason>' and define
its semantics in the description field.</t>
<t>Description: A brief description of the error code
semantics.</t>
<t>Specification: An optional reference to a specification that
defines in the error code in more detail.</t>
</list></t>
<t>The entries in <xref target="error_codes"/> are registered by this
document.</t>
</section>
</section>
<section title="Contributors">
<t>[RFC Editor Note: Please move the contents of this section to the
Authors' Addresses section prior to publication as an RFC.]</t>
<t>The following persons have participated as co-authors to this
document:</t>
<t><list style="empty">
<t>Wang Danhua, Huawei, Email: wangdanhua@huawei.com</t>
<t>He Xiaoyan, Huawi, Email: hexiaoyan@huawei.com</t>
<t>Ge Chen, China Telecom, Email: cheng@gsta.com</t>
<t>Ni Wei, China Mobile, Email: niwei@chinamobile.com</t>
<t>Yunfei Zhang, Email:hishigh@gmail.com</t>
<t>Spencer Dawkins, Huawei, Email: spencer@wonderhamster.org</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Taesang Choi, Francois le Faucheur,
Matt Miller and Scott Wainner for their valuable comments and input to
this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.5952'?>
<?rfc include='reference.RFC.7230'?>
<?rfc include='reference.RFC.7159'?>
<?rfc include='reference.RFC.6895'?>
<?rfc include='reference.RFC.7493'?>
<?rfc include='reference.RFC.7525'?>
<?rfc include='reference.I-D.ietf-cdni-media-type'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6707'?>
<?rfc include='reference.RFC.7336'?>
<?rfc include='reference.RFC.7337'?>
<?rfc include='reference.RFC.2818'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:51:02 |