Request Routing Redirection Interface for CDN Interconnection
draft-ietf-cdni-redirection-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7975.
|
|
|---|---|---|---|
| Authors | Ben Niven-Jenkins , Ray van Brandenburg | ||
| Last updated | 2014-12-12 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Daryl Malas | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Daryl Malas" <d.malas@cablelabs.com> |
draft-ietf-cdni-redirection-06
Network Working Group B. Niven-Jenkins, Ed.
Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Standards Track R. van Brandenburg, Ed.
Expires: June 13, 2015 TNO
December 10, 2014
Request Routing Redirection Interface for CDN Interconnection
draft-ietf-cdni-redirection-06
Abstract
The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 1]
Internet-Draft Request Routing Redirection December 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Interface function and operation overview . . . . . . . . . . 4
4. HTTP based interface for the Redirection Interface . . . . . 5
4.1. Information passed in RI requests & responses . . . . . . 7
4.2. JSON encoding of RI requests & responses . . . . . . . . 8
4.3. MIME Media Types used by the RI interface . . . . . . . . 10
4.4. DNS redirection . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. DNS Redirection requests . . . . . . . . . . . . . . 11
4.4.2. DNS Redirection responses . . . . . . . . . . . . . . 12
4.5. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 14
4.5.1. HTTP Redirection requests . . . . . . . . . . . . . . 14
4.5.2. HTTP Redirection responses . . . . . . . . . . . . . 16
4.6. Cacheability and scope of responses . . . . . . . . . . . 18
4.7. Error responses . . . . . . . . . . . . . . . . . . . . . 20
4.8. Loop detection & prevention . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. Media type registrations . . . . . . . . . . . . . . . . 26
6.1.1. CDNI RI requests . . . . . . . . . . . . . . . . . . 26
6.1.2. CDNI RI responses . . . . . . . . . . . . . . . . . . 27
6.2. RI Error response registry . . . . . . . . . . . . . . . 28
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
A Content Delivery Network (CDN) is a system built on an existing IP
network which is used for large scale content delivery, via
prefetching or dynamically caching content on its distributed
surrogates (caching servers). [RFC6707] describes the problem area
of interconnecting CDNs.
The CDNI Request Routing interface outlined in [RFC7336] comprises
of:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 2]
Internet-Draft Request Routing Redirection December 2014
1. 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.
2. 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.
This document describes an interface for the latter part, i.e. the
CDNI Request Routing Redirection interface (RI).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document reuses the terminology defined in [RFC6707].
The following additional terms are introduced by this document:
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.
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.
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.
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 3]
Internet-Draft Request Routing Redirection December 2014
3. Interface function and operation overview
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.
The detailed requirements for the Redirection Interface and their
relative priorities are described in section 5 of [RFC7337].
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:
o 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).
o 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.
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.
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.
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.
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
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 4]
Internet-Draft Request Routing Redirection December 2014
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.
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.
This document also defines an RI loop prevention and detection
mechanism as part of the Redirection Interface.
4. HTTP based interface for the Redirection Interface
This document defines a simple interface for the Redirection
Interface based on HTTP 1.1 [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.
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.
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.
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 5]
Internet-Draft Request Routing Redirection December 2014
Finally, the RI is easily extendable to support other User Agent
request redirection methods (e.g. RTMP 302 redirection).
The generic Recursive Request Redirection message flow between
Request Routing systems in a pair of interconnected CDNs is as
follows:
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)
| | |
Figure 1: Generic Recursive Request Redirection message flow
1. 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).
2. 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.
3. 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).
4. 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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 6]
Internet-Draft Request Routing Redirection December 2014
4.1. Information passed in RI requests & responses
The information passed in RI requests splits into two basic
categories:
1. The attributes of the User Agent's request to the uCDN.
2. Properties/parameters that the uCDN can use to control the dCDN's
response or that can help the dCDN make its decision.
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.
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.
The information passed in RI responses splits into two basic
categories:
1. The attributes of the RT to return to the User Agent in the DNS
response or HTTP response.
2. Parameters/policies that indicate the properties of the response,
such as, whether it is cacheable, the scope of the response, etc.
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".
These additional policies split into two basic categories:
o 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).
o The scope of the response (if it is cacheable) signaled the HTTP
response body of the RI response. For example whether the
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 7]
Internet-Draft Request Routing Redirection December 2014
response applies to a wider range of IP addresses than what was
included in the RI request.
The cacheability of the response is indicated using the standard HTTP
Cache-Control mechanisms.
4.2. JSON encoding of RI requests & responses
The body of RI requests and responses is a JSON object [RFC7159]
containing a dictionary of key:value pairs.
The following additional rules apply to all keys in RI requests and
responses (whether in the top level object or in sub-objects):
o Keys MUST always be encoded in lowercase.
o Requests and responses MUST NOT contain duplicate keys.
o 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).
o Requests or responses containing duplicate keys or containing keys
that are not all lowercase MUST be considered syntactically
invalid.
The following top level keys are defined along with whether they are
applicable to RI requests, RI responses or both:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 8]
Internet-Draft Request Routing Redirection December 2014
+----------+------------------+-------------------------------------+
| Key | Request/Response | Description |
+----------+------------------+-------------------------------------+
| dns | Both | The attributes of the UA's DNS |
| | | request or the attributes of the |
| | | RT(s) to return in a DNS response. |
| http | Both | The attributes of the UA's HTTP |
| | | request or the attributes of the RT |
| | | to return in a HTTP response. |
| scope | Response | 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. |
| error | Response | Additional details if the response |
| | | is an error response. |
| cdn-path | Both | 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. |
| max-hops | Request | 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. |
+----------+------------------+-------------------------------------+
Top-Level keys in RI requests/responses
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 9]
Internet-Draft Request Routing Redirection December 2014
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.
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).
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.
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 Section 4.7 for more
details of encoding error information in RI responses.
Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and
MUST support all IPv6 address formats specified in [RFC4291]. Server
implementations SHOULD use IPv6 address formats specified in
[RFC5952].
4.3. MIME Media Types used by the RI interface
RI requests MUST use a MIME Media Type of application/
cdni.redirectionrequest+json.
RI responses MUST use a MIME Media Type of application/
cdni.redirectionresponse+json.
4.4. DNS redirection
The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for
DNS redirection.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 10]
Internet-Draft Request Routing Redirection December 2014
4.4.1. DNS Redirection requests
For DNS based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:
o The IP address of the DNS resolver that made the DNS request to
the uCDN.
o The type of DNS query made (usually either A or AAAA).
o The class of DNS query made (usually IN).
o The fully qualified domain name for which DNS redirection is being
requested.
o The IP address or prefix of the User Agent (if known to the uCDN).
The information above is encoded as a set of key:value pairs within
the dns dictionary as follows:
+-------------+---------+-----------+-------------------------------+
| Key | Value | Mandatory | Description |
+-------------+---------+-----------+-------------------------------+
| resolver-ip | String | Yes | The IP address of the UA's |
| | | | DNS resolver. |
| qtype | String | Yes | The type of DNS query made by |
| | | | the UA's DNS resolvers in |
| | | | uppercase (A, AAAA, etc.). |
| qclass | String | Yes | The class of DNS query made |
| | | | in uppercase (IN, etc.). |
| qname | String | Yes | The fully qualified domain |
| | | | name being queried. |
| c-subnet | String | No | The IP address (or prefix) of |
| | | | the UA in CIDR format. |
| dns-only | Boolean | No | 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. |
+-------------+---------+-----------+-------------------------------+
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 11]
Internet-Draft Request Routing Redirection December 2014
An example RI request (uCDN->dCDN) for DNS based redirection:
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
}
4.4.2. DNS Redirection responses
For a successful DNS based redirection, the dCDN needs to return one
of the following to the uCDN in the RI response:
o 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
o 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.
The information above is encoded as a set of key:value pairs within
the dns dictionary as follows:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 12]
Internet-Draft Request Routing Redirection December 2014
+-------+-----------+-----------+-----------------------------------+
| Key | Value | Mandatory | Description |
+-------+-----------+-----------+-----------------------------------+
| rcode | Integer | Yes | DNS response code (see |
| | | | [RFC6895]). |
| name | String | Yes | The fully qualified domain name |
| | | | the response relates to. |
| a | List of | No | Set of IPv4 Addresses of RT(s). |
| | String | | |
| aaaa | List of | No | Set of IPv6 Addresses of RT(s). |
| | String | | |
| cname | List of | No | Set of fully qualified domain |
| | String | | names of RT(s). |
| ttl | Integer | No | TTL in seconds of DNS response. |
| | | | Default is 0. |
+-------+-----------+-----------+-----------------------------------+
A successful RI response for DNS-based redirection MUST include a dns
dictionary and MAY include an error dictionary (see Section 4.7). 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.
An example of a successful RI response (dCDN->uCDN) for DNS based
redirection with both a and aaaa keys is listed below :
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", "203.0.113.202"],
"aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
"ttl" : 60
}
}
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 13]
Internet-Draft Request Routing Redirection December 2014
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
}
}
4.5. HTTP Redirection
The following sections provide detailed descriptions of the
information that should be passed in RI requests and responses for
HTTP redirection.
The dictionary keys used in HTTP Redirection requests and responses
use the following conventions for their prefixes:
o c- is prefixed to keys for information related to the Client (User
Agent).
o cs- is prefixed to keys for information passed by the Client (User
Agent) to the Server (uCDN).
o sc- is prefixed to keys for information to be passed by the Server
(uCDN) to the Client (User Agent).
4.5.1. HTTP Redirection requests
For HTTP-based redirection the uCDN needs to pass the following
information to the dCDN in the RI request:
o The IP address of the User Agent.
o The URI requested by the User Agent.
o The HTTP method requested by the User Agent
o The HTTP version number requested by the User Agent.
The uCDN may also decide to pass the presence and value of particular
HTTP headers included in the User Agent request to the dCDN.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 14]
Internet-Draft Request Routing Redirection December 2014
The information above is encoded as a set of key:value pairs within
the http dictionary as follows:
+------------------+--------+-----------+---------------------------+
| Key | Value | Mandatory | Description |
+------------------+--------+-----------+---------------------------+
| c-ip | String | Yes | The IP address of the UA. |
| cs-uri | String | Yes | The Effective Request URI |
| | | | [RFC7230] requested by |
| | | | the UA. |
| cs-method | String | Yes | The method part of the |
| | | | request-line as defined |
| | | | in Section 3.1.1 of |
| | | | [RFC7230]. |
| cs-version | String | Yes | The HTTP-version part of |
| | | | the request-line as |
| | | | defined in Section 3.1.1 |
| | | | of [RFC7230]. |
| cs(<headername>) | String | No | 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. |
+------------------+--------+-----------+---------------------------+
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.
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.
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 Section 3.2.2 of [RFC7230]. 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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 15]
Internet-Draft Request Routing Redirection December 2014
An example RI request (uCDN->dCDN) for HTTP based redirection:
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
}
4.5.2. HTTP Redirection responses
For a successful HTTP based redirection, the dCDN needs to return one
of the following to the uCDN in the RI response:
o 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
o A URI pointing to an RT that is a Request Router (if the dCDN will
perform request redirection itself).
The information above is encoded as a set of key:value pairs within
the http dictionary as follows:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 16]
Internet-Draft Request Routing Redirection December 2014
+-------------------+---------+-----------+-------------------------+
| Key | Value | Mandatory | Description |
+-------------------+---------+-----------+-------------------------+
| sc-status | Integer | Yes | The status-code part of |
| | | | the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA |
| | | | (usually set to 302). |
| sc-version | String | Yes | The HTTP-version part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| sc-reason | String | Yes | The reason-phrase part |
| | | | of the status-line as |
| | | | defined in Section |
| | | | 3.1.2 of [RFC7230] to |
| | | | return to the UA. |
| cs-uri | String | Yes | The URI requested by |
| | | | the UA/client. |
| sc(location) | String | Yes | The contents of the |
| | | | Location header to |
| | | | return to the UA (i.e. |
| | | | a URI pointing to the |
| | | | RT(s)). |
| sc(cache-control) | String | No | The contents of the |
| | | | Cache-Control header to |
| | | | return to the UA. |
| sc(<headername>) | String | No | 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. |
+-------------------+---------+-----------+-------------------------+
A successful RI response for HTTP-based redirection MUST include an
http dictionary and MAY include an error dictionary (see
Section 4.7). 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).
The http dictionary of an RI response MUST contain a maximum of one
sc(<headername>) key for each unique header field-name (HTTP header
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 17]
Internet-Draft Request Routing Redirection December 2014
field). <headername> MUST be identical to the equivalent HTTP header
field-name encoded in all lowercase.
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(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.
An example of a successful RI response (dCDN->uCDN) for HTTP based
redirection:
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"
}
}
4.6. Cacheability and scope of responses
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.
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
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 18]
Internet-Draft Request Routing Redirection December 2014
provided that the User Agent's c-ip is covered by the scope in the
original RI response, as elaborated upon below).
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.
Scope is encoded as a set of key:value pairs within the scope
dictionary as follows:
+---------+--------+-----------+------------------------------------+
| Key | Value | Mandatory | Description |
+---------+--------+-----------+------------------------------------+
| iprange | List | No | A List of IP subnets in CIDR |
| | of | | notation that this RI response can |
| | String | | be reused for, provided the RI |
| | | | response is still considered |
| | | | fresh. |
+---------+--------+-----------+------------------------------------+
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.
The following is an example of a DNS redirection response from
Section 4.4.2 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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 19]
Internet-Draft Request Routing Redirection December 2014
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"]
}
}
Example of HTTP redirection response from Section 4.5.2 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.
Note: The response to the UA is only valid for 30 seconds, whereas
the uCDN can cache the RI response for 60 seconds.
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"]
}
}
4.7. Error responses
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:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 20]
Internet-Draft Request Routing Redirection December 2014
1. 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
2. An 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.
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.
Error information (if present) is encoded as a set of key:value pairs
within a JSON-encoded error dictionary as follows:
+------------+---------+-----------+--------------------------------+
| Key | Value | Mandatory | Description |
+------------+---------+-----------+--------------------------------+
| error-code | Integer | No | A three-digit numeric code |
| | | | defined by the server to |
| | | | indicate the error(s) that |
| | | | occurred. |
| reason | String | No | A string providing further |
| | | | information related to the |
| | | | error. |
+------------+---------+-----------+--------------------------------+
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:
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.
2xx: Reserved.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 21]
Internet-Draft Request Routing Redirection December 2014
3xx: Reserved.
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.
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.
The following error codes are defined and maintained by IANA (see
Section 6):
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.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 22]
Internet-Draft Request Routing Redirection December 2014
+------+--------------+---------------------------------------------+
| Code | Reason | Description |
+------+--------------+---------------------------------------------+
| 100 | <reason> | Generic informational error-code meant for |
| | (see | carrying a human-readable string |
| | Description) | |
| 400 | <reason> | Generic error-code for uCDN errors where |
| | (see | the dCDN can not or will not process the |
| | Description) | 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. |
| 500 | <reason> | Generic error-code for dCDN errors where |
| | (see | the dCDN is aware that it has erred or is |
| | Description) | 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. |
| 501 | Unable to | The dCDN is unable to retrieve the metadata |
| | retrieve | associated with the content requested by |
| | metadata | the UA. This may indicate a configuration |
| | | error or the content requested by the UA |
| | | not existing. |
| 502 | Loop | The dCDN detected a redirection loop (see |
| | detected | Section 4.8). |
| 503 | Maximum hops | The dCDN detected the maximum number of |
| | exceeded | redirection hops exceeding max-hops (see |
| | | Section 4.8). |
| 504 | Out of | The dCDN does not currently have sufficient |
| | capacity | capacity to handle the UA request. |
| 505 | Delivery | The dCDN does not support the (set of) |
| | protocol not | delivery protocols indicated in the CDNI |
| | supported | Metadata of the content requested content |
| | | by the UA. |
| 506 | Redirection | The dCDN does not support the requested |
| | protocol not | redirection protocol. This error-code is |
| | supported | 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. |
+------+--------------+---------------------------------------------+
Table 1
The following is an example of an unsuccessful RI response
(dCDN->uCDN) for a DNS based User Agent request:
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 23]
Internet-Draft Request Routing Redirection December 2014
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"
}
}
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:
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"
}
}
4.8. Loop detection & prevention
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
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 24]
Internet-Draft Request Routing Redirection December 2014
if the number of CDN Provider IDs in cdn-path (before adding its own
Provider ID) is equal to or greater than max-hops.
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".
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.
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.
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.
5. Security Considerations
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.
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.
The same information could be obtained in the absence of the RI
interface, but it could be more difficult to gather as it would
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 25]
Internet-Draft Request Routing Redirection December 2014
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.
In order to prevent passive interception of RI messages the RI
communications channel MUST be suitably secured (e.g. use of TLS).
In order to reduce the risk of information leakage to unauthorized
parties, RI clients and servers MUST use suitable authentication
prior to trusting the contents of RI messages.
6. IANA Considerations
6.1. Media type registrations
6.1.1. CDNI RI requests
The MIME media type for CDNI RI requests is application/
cdni.redirectionrequest+json.
Type Name: application
Subtype name: cdni.redirectionrequest+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security Considerations: See [RFCthis], Section 5
Interoperability Considerations: Described in [RFCthis]
Published Specification: [RFCthis]
Applications that use this media type: No known applications
currently use this media type.
Additional Information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File Extensions: N/A
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 26]
Internet-Draft Request Routing Redirection December 2014
Macintosh file type code(s): TEXT
Person & email address to contact for further information: IESG
<iesg@ietf.org>
Intended Useage: COMMON
Restrictions on usage: None
Author: Ben Niven-Jenkins <ben.niven-jenkins@alcatel-lucent.com>
Change controller: IESG <iesg@ietf.org>
Note: No "charset" parameter is defined for this registration because
a charset parameter is not defined for application/json [RFC7159].
6.1.2. CDNI RI responses
The MIME media type for CDNI RI responses is application/
cdni.redirectionresponse+json.
Type Name: application
Subtype name: cdni.redirectionresponse+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security Considerations: See [RFCthis], Section 5
Interoperability Considerations: Described in [RFCthis]
Published Specification: [RFCthis]
Applications that use this media type: No known applications
currently use this media type.
Additional Information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File Extensions: N/A
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 27]
Internet-Draft Request Routing Redirection December 2014
Macintosh file type code(s): TEXT
Person & email address to contact for further information: IESG
<iesg@ietf.org>
Intended Useage: COMMON
Restrictions on usage: None
Author: Ben Niven-Jenkins <ben.niven-jenkins@alcatel-lucent.com>
Change controller: IESG <iesg@ietf.org>
Note: No "charset" parameter is defined for this registration because
a charset parameter is not defined for application/json [RFC7159].
6.2. RI Error response registry
This document establishes a new IANA registry for CDNI RI Error
response codes.
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
Section 4.7 of this document.
New registrations are required to provide the following information:
Code: A three-digit numeric error-code, in accordance with the
error classes defined in section Section 4.7 of this document.
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.
Description: A brief description of the error code semantics.
Specification: An optional reference to a specification that
defines in the error code in more detail.
The entries in Table 1 are registered by this document.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 28]
Internet-Draft Request Routing Redirection December 2014
7. Contributors
[RFC Editor Note: Please move the contents of this section to the
Authors' Addresses section prior to publication as an RFC.]
The following persons have participated as co-authors to this
document:
Wang Danhua, Huawei, Email: wangdanhua@huawei.com
He Xiaoyan, Huawi, Email: hexiaoyan@huawei.com
Ge Chen, China Telecom, Email: cheng@gsta.com
Ni Wei, China Mobile, Email: niwei@chinamobile.com
Yunfei Zhang, Email:hishigh@gmail.com
Spencer Dawkins, Huawei, Email: spencer@wonderhamster.org
8. Acknowledgements
The authors would like to thank Taesang Choi, Francois le Faucheur
and Scott Wainner for their valuable comments and input to this
document.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 29]
Internet-Draft Request Routing Redirection December 2014
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC6895] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, April 2013.
9.2. Informative References
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August
2014.
Authors' Addresses
Ben Niven-Jenkins (editor)
Velocix (Alcatel-Lucent)
3 Ely Road
Milton, Cambridge CB24 6DD
UK
Email: ben.niven-jenkins@alcatel-lucent.com
Ray van Brandenburg (editor)
TNO
Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Niven-Jenkins & van BrandeExpires June 13, 2015 [Page 30]