One document matched: draft-ietf-cdni-redirection-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6707 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6707.xml">
<!ENTITY rfc7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY rfc7336 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7336.xml">
<!ENTITY rfc7337 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7337.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY rfc5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY rfc7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
]>
<?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-05" 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>Brassersplein 2</street>
<city>Delft</city>
<region/>
<code>2612CT</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 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.</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 that allows a upstream CDN to decide whether to
redirect particular user requests to that downstream CDN.</t>
<t>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.</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>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>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>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>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 downstream CDN or a
surrogate in a downstream CDN, etc.</t>
</section>
<section title="Interface function and operation overview">
<t>The CDNI Request Routing Redirection interface (RI) is one of the
main building blocks required in order to interconnect CDNs. The main
function of the Redirection interface 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 and 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 dCDN or another CDN) that will be using a
redirection protocol (DNS or HTTP) which may or may not be the same
as the original redirection protocol.</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 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.</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>CDNI solutions are required to support both of the request routing
mechanisms illustrated in section 2.1 of <xref target="RFC7336"/>,
namely Iterative Request Redirection and Recursive Request Redirection.
However, the Iterative Request Redirection method does not invoke any
interaction over the Redirection Interface between interconnected CDNs.
Therefore, the Redirection Interface is only relevant in the case of
Recursive Request Redirection and so this document will not discuss
Iterative Request Redirection further.</t>
<t>In the case of Recursive Request Redirection, in order to perform
redirection of a request received from a User Agent, the Upstream CDN
queries the Downstream CDN so that the Downstream CDN can select and
provide a Redirection Target. In cases where a uCDN has a choice of
dCDNs it is down 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 reject 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 Upstream CDN->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>Also, according to the CDNI generic and request routing interface
requirements, the CDNI solution shall support mechanisms to prevent and
detect RI request loops. To meet such requirements, this document
defines a loop prevention and detection mechanism as part of the
Redirection Interface.</t>
</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 downstream CDN in processing the requests.
The RI response encapsulates the attributes of the RT(s) that the
upstream CDN should return to the User Agent (if it decides to utilize
the Downstream CDN 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 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
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 attributes of |
| |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 request, either DNS request or HTTP
request, to CDN A. The Request Routing System of CDN A processes the
request and, through local policy, it recognizes that the request is
best served by another CDN, specifically CDN B (or that CDN B is 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 request and
assuming the request is well formed, etc. 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 upstream
CDN.</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 Downstream CDN, the Upstream
CDN ought to convey as much information as possible to the Downstream
CDN, 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 Downstream CDN 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 Downstream CDN 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
Downstream CDN may wish to return additional policy to the Upstream
CDN to help the Upstream CDN with future RI requests. For example the
Downstream CDN may wish to return a policy that expresses “this
response can be reused without requiring a 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>An indication of the cacheability of the response carried in
the HTTP response headers (to reduce the number of subsequent RI
requests the uCDN needs to make).</t>
<t>The scope of the response (if it is cacheable) carried within
the body of the HTTP 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"/> 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.</t>
<t>Requests and responses MUST NOT contain duplicate keys.</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. a RI request or response MUST NOT be
considered invalid on the basis that it contains unknown
keys).</t>
<t>Requests or responses containing duplicate keys or containing
keys that are not all lowercase are considered syntactically
invalid.</t>
</list></t>
<t>The following top level keys are defined along with whether they
are applicable to RI requests, RI responses or to both RI requests and
responses:</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 the CDN Provider IDs of previous CDNs
this RI request has passed through.</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 crudely 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 a RI request, a transit CDN appends its own CDN
Provider ID to the list in cdn-path so that downstream CDNs can detect
loops in the RI request chain. Transit CDNs MUST check the cdn-path
and MUST NOT cascade the RI request to downstream CDNs that are
already listed in cdn-path. 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>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 SHOULD use a MIME Media Type of
application/cdni.redirectionrequest+json.</t>
<t>RI responses SHOULD use a MIME Media Type of
application/cdni.redirectionresponse+json.</t>
</section>
<section title="DNS redirection">
<t>The following sections provide more 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 Upstream CDN.</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
Upstream CDN).</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 to a surrogate
and MUST include the dns-only property set to True on any cascaded
RI requests. Defaults to False.</c>
</texttable>
<t>A 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.redirectionrequest+json
Accept: application/cdni.redirectionresponse+json
{
"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) the RT (if the dCDN
is performing DNS based redirection directly to a surrogate);
or</t>
<t>The IP address(es) of (or the CNAME of) a RT which is a
Request Router (if the dCDN is performing HTTP based
redirection). 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.</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 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.redirectionresponse+json
{
"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
}
}
]]></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.redirectionresponse+json
{
"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 more detailed descriptions of the
information that should be passed in RI requests and responses for
HTTP redirection.</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 URL 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 URI 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.</c>
</texttable>
<t>A 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 DNS
query/request.</t>
<t>The http dictionary of a 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. In the case where the
User Agent request includes multiple HTTP header fields with the
same field-name, it is up to the uCDN to determine how to handle
this. One option would be to only send the contents of the first
occurence of that HTTP Header in the User Agent request. Another
would be to combine the different HTTP Headers into a single value
according to <xref target="RFC7230">Section 3.2.2 of</xref>.</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.redirectionrequest+json
Accept: application/cdni.redirectionresponse+json
{
"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 URL pointing to the selected RT (if the dCDN is performing
HTTP based redirection directly to a surrogate); or</t>
<t>A URL pointing to a RT which is a Request Router (if the dCDN
is not redirecting the User Agent directly to a surrogate).</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(cache-control)</c>
<c>String</c>
<c>No</c>
<c>The contents of the Cache-Control header to return to the
UA.</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>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 a RI response 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>The uCDN MAY decide to not return, override or alter some 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(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.redirectionresponse+json
{
"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",
"sc(cache-control)" : "public, max-age=30"
}
}
]]></artwork>
</figure>
</section>
</section>
<section title="Cacheability and scope of responses">
<t>RI responses may be cacheable and may be reused by the uCDN in
response to User Agent requests without the uCDN issuing another RI
request to the dCDN if the RI response is considered cacheable &
not stale according to the standard HTTP Cache-Control, etc
mechanisms.</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 the User Agent's c-ip is covered by the scope in the original
RI response).</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.redirectionresponse+json
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/>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Date: Mon, 06 Aug 2012 18:41:38 GMT
Content-Type: application/cdni.redirectionresponse+json
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: 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 a RI-level error specified in an RI
response message. 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 not being able 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 may 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 diagnostics of issues. The
resolution of such issues is outside the scope of this document and
this document therefore does not specify the 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>No</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>
<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>
</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.redirectionresponse+json
Cache-Control: private, no-cache
{
"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.redirectionresponse+json
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",
"sc(cache-control)" : "public, max-age=30"
},
"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 downstream CDN's Provider ID in the cdn-path. Transit CDNs MUST
check the cdn-path and not cascade the RI request to downstream CDNs
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
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 downstream CDN receives a RI request whose cdn-path already
contains that downstream CDN's Provider ID the downstream CDN SHOULD
send a RI response with an error code of 502.</t>
<t>If a downstream CDN receives a RI request where the number of CDN
Provider IDs in cdn-path is greater than max-hops, the downstream CDN
SHOULD send a 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 with 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 a 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>
<t>In order to prevent passive interception of RI messages the RI
communications channel should be suitably secured (e.g. use of TLS).</t>
<t>In order to reduce the risk of information leakage to unauthorized
parties, RI clients and servers SHOULD use suitable authentication prior
to trusting the contents of RI messages.</t>
</section>
<section anchor="iana_section" title="IANA Considerations">
<section title="Media type registrations">
<t/>
<section title="CDNI RI requests">
<t>The MIME media type for CDNI RI requests is
application/cdni.redirectionrequest+json.</t>
<t>Type Name: application</t>
<t>Subtype name: cdni.redirectionrequest+json</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: binary</t>
<t>Security Considerations: See [RFCthis], <xref
target="security"/></t>
<t>Interoperability Considerations: Described in [RFCthis]</t>
<t>Published Specification: [RFCthis]</t>
<t>Applications that use this media type: No known applications
currently use this media type.</t>
<t>Additional Information:</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File Extensions: N/A</t>
<t>Macintosh file type code(s): TEXT</t>
</list></t>
<t>Person & email address to contact for further information:
IESG <iesg@ietf.org></t>
<t>Intended Useage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: Ben Niven-Jenkins
<ben.niven-jenkins@alcatel-lucent.com></t>
<t>Change controller: IESG <iesg@ietf.org></t>
<t>Note: No "charset" parameter is defined for this registration
because a charset parameter is not defined for application/json
<xref target="RFC7159"/>.</t>
</section>
<section title="CDNI RI responses">
<t>The MIME media type for CDNI RI responses is
application/cdni.redirectionresponse+json.</t>
<t>Type Name: application</t>
<t>Subtype name: cdni.redirectionresponse+json</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: N/A</t>
<t>Encoding considerations: binary</t>
<t>Security Considerations: See [RFCthis], <xref
target="security"/></t>
<t>Interoperability Considerations: Described in [RFCthis]</t>
<t>Published Specification: [RFCthis]</t>
<t>Applications that use this media type: No known applications
currently use this media type.</t>
<t>Additional Information:</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File Extensions: N/A</t>
<t>Macintosh file type code(s): TEXT</t>
</list></t>
<t>Person & email address to contact for further information:
IESG <iesg@ietf.org></t>
<t>Intended Useage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: Ben Niven-Jenkins
<ben.niven-jenkins@alcatel-lucent.com></t>
<t>Change controller: IESG <iesg@ietf.org></t>
<t>Note: No "charset" parameter is defined for this registration
because a charset parameter is not defined for application/json
<xref target="RFC7159"/>.</t>
</section>
</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
and Scott Wainner for their valuable comments and input to this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3986;
&rfc4291;
&rfc5952;
&rfc7230;
&rfc7159;
</references>
<references title="Informative References">
&rfc6707;
&rfc7336;
&rfc7337;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:50:53 |