Network Working Group B. Niven-Jenkins, Ed.
Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Standards Track R. van Brandenburg, Ed.
Expires: May 14, 2015 TNO
November 10, 2014

Request Routing Redirection Interface for CDN Interconnection
draft-ietf-cdni-redirection-05

Abstract

The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI Request Routing Redirection interface.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 14, 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 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

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:

  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.
  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 (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 downstream CDN or a surrogate in a downstream CDN, etc.

3. Interface function and operation overview

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.

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 and depending on the returned Redirection Target, the User Agent's request may be redirected to:

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.

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.

CDNI solutions are required to support both of the request routing mechanisms illustrated in section 2.1 of [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.

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.

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.

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.

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 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.

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 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.

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 attributes of |
    |                         |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 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).
  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 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).
  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.

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 upstream CDN.
  2. Properties/parameters that the uCDN can use to control the dCDN’s response or that can help the dCDN make its decision.

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.

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.

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 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”.

These additional policies split into two basic categories:

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):

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:

Top-Level keys in RI requests/responses
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 the CDN Provider IDs of previous CDNs this RI request has passed through.
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 crudely constrain the latency of the request routing chain.

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.

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).

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 SHOULD use a MIME Media Type of application/cdni.redirectionrequest+json.

RI responses SHOULD use a MIME Media Type of application/cdni.redirectionresponse+json.

4.4. DNS redirection

The following sections provide more detailed descriptions of the information that should be passed in RI requests and responses for DNS redirection.

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:

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 to a surrogate and MUST include the dns-only property set to True on any cascaded RI requests. Defaults to False.

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.

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:

The information above is encoded as a set of key:value pairs within the dns dictionary as follows:

Key Value Mandatory Description
rcode Integer Yes DNS response code.
name String Yes The fully qualified domain name the response relates to.
a List of String No Set of IPv4 Addresses of RT(s).
aaaa List of String No Set of IPv6 Addresses of RT(s).
cname List of String No Set of fully qualified domain names of RT(s).
ttl Integer No TTL 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"],
    "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.

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 more detailed descriptions of the information that should be passed in RI requests and responses for HTTP redirection.

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:

The uCDN may also decide to pass the presence and value of particular HTTP headers included in the User Agent request to the dCDN.

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 URI 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.

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.

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 Section 3.2.2 of [RFC7230].

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:

The information above is encoded as a set of key:value pairs within the http dictionary as follows:

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 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.

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.

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 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.

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).

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 of String No A List of IP subnets in CIDR notation that this RI response can 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.

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.

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: 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.

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.

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:

The following error codes are defined and maintained by IANA (see Section 6):

Code Reason Description
100 <reason> (see Description) Generic informational error-code meant for carrying a human-readable string
400 <reason> (see Description) 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.
500 <reason> (see Description) 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.
501 Unable to retrieve metadata 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.
502 Loop detected The dCDN detected a redirection loop (see Section 4.8).
503 Maximum hops exceeded The dCDN detected the maximum number of redirection hops exceeding max-hops (see Section 4.8).
504 Out of capacity The dCDN does not currently have sufficient capacity to handle the UA request.
505 Delivery protocol not supported The dCDN does not support the (set of) delivery protocols indicated in the CDNI Metadata of the content requested content by the UA.

The following is an example of an unsuccessful RI response (dCDN->uCDN) for a DNS based User Agent request:

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 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.

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 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.

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.

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.

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 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.

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.

In order to prevent passive interception of RI messages the RI communications channel should be suitably secured (e.g. use of TLS).

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.

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
  • 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
  • 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.

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.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.

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