doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc7975.txt b/doc/rfc/rfc7975.txt
new file mode 100644
index 0000000..b450474
--- /dev/null
+++ b/doc/rfc/rfc7975.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)             B. Niven-Jenkins, Ed.
+Request for Comments: 7975                                         Nokia
+Category: Standards Track                        R. van Brandenburg, Ed.
+ISSN: 2070-1721                                                      TNO
+                                                            October 2016
+
+
+               Request Routing Redirection Interface for
+             Content Delivery Network (CDN) Interconnection
+
+Abstract
+
+   The Request Routing interface comprises (1) the asynchronous
+   advertisement of footprint and capabilities by a downstream Content
+   Delivery Network (CDN) that allows an upstream CDN to decide whether
+   to redirect particular user requests to that downstream CDN; and (2)
+   the synchronous operation of an upstream CDN requesting whether a
+   downstream CDN is prepared to accept a user request and of a
+   downstream CDN responding with how to actually redirect the user
+   request.  This document describes an interface for the latter part,
+   i.e., the CDNI Request Routing Redirection interface.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7975.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 1]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Interface Function and Operation Overview . . . . . . . . . .   4
+   4.  HTTP-Based Interface for the Redirection Interface  . . . . .   6
+     4.1.  Information Passed in RI Requests and Responses . . . . .   8
+     4.2.  JSON Encoding of RI Requests and Responses  . . . . . . .   9
+     4.3.  MIME Media Types Used by the RI Interface . . . . . . . .  11
+     4.4.  DNS Redirection . . . . . . . . . . . . . . . . . . . . .  12
+       4.4.1.  DNS Redirection Requests  . . . . . . . . . . . . . .  12
+       4.4.2.  DNS Redirection Responses . . . . . . . . . . . . . .  14
+     4.5.  HTTP Redirection  . . . . . . . . . . . . . . . . . . . .  17
+       4.5.1.  HTTP Redirection Requests . . . . . . . . . . . . . .  17
+       4.5.2.  HTTP Redirection Responses  . . . . . . . . . . . . .  19
+     4.6.  Cacheability and Scope of Responses . . . . . . . . . . .  22
+     4.7.  Error Responses . . . . . . . . . . . . . . . . . . . . .  24
+     4.8.  Loop Detection and Prevention . . . . . . . . . . . . . .  28
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
+     5.1.  Authentication, Authorization, Confidentiality, and
+           Integrity Protection  . . . . . . . . . . . . . . . . . .  29
+     5.2.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  30
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
+     6.1.  CDNI Payload Type Parameter Registrations . . . . . . . .  31
+       6.1.1.  CDNI RI Redirection Request Payload Type  . . . . . .  31
+       6.1.2.  CDNI RI Redirection Response Payload Type . . . . . .  31
+     6.2.  RI Error Response Registry  . . . . . . . . . . . . . . .  31
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  34
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  34
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 2]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+1.  Introduction
+
+   A Content Delivery Network (CDN) is a system built on an existing IP
+   network that 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] is comprised
+   of:
+
+   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 a CDN's
+      routing decision 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 Real
+      Time Messaging Protocol (RTMP) [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 (UA) 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.
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 3]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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):  The endpoint to which the User Agent is
+      redirected.  In CDNI, an 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.
+
+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
+   the 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); or
+
+   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
+   (endpoint) in the dCDN to send CDNI request routing queries.
+
+   The Redirection interface URI may be statically preconfigured,
+   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.
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 4]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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 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 document
+   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.
+
+   For both DNS and HTTP redirection, either HTTP or HTTPS could be used
+   to connect to the Redirection Target.  When HTTPS is used to connect
+   to the uCDN, if the uCDN uses DNS redirection to identify the RT to
+   the User Agent, then the new target domain name may not match the
+   domain in the URL dereferenced to reach the uCDN; without operational
+   precautions, and in the absence of DNSSEC, this can make a legitimate
+   redirection look like a DNS-based attack to a User Agent and trigger
+   security warnings.  When DNS-based redirection with HTTPS is used,
+   this specification assumes that any RT can complete the necessary
+   Transport Layer Security (TLS) handshake with the User Agent.  Any
+   operational mechanisms this requires, e.g., private key distribution
+   to surrogates and request routers in dCDNs, are outside the scope of
+   this document.
+
+   This document also defines an RI loop prevention and detection
+   mechanism as part of the Redirection interface.
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 5]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+4.  HTTP-Based Interface for the Redirection Interface
+
+   This document defines a simple interface for the Redirection
+   interface based on HTTP [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 RI between the uCDN and dCDN uses the same HTTP interface to
+   encapsulate the attributes of both DNS and HTTP requests received
+   from User Agents, 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 both 1) try to encapsulate or proxy DNS/HTTP/RTMP/
+   etc. requests and 2) 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) by defining
+   additional protocol-specific keys for RI requests and responses along
+   with a specification about how to process them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 6]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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, et al.        Standards Track                    [Page 7]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+4.1.  Information Passed in RI Requests and 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.
+
+   Generally, dCDNs can provide better routing decisions given
+   additional information about the content request, e.g., the URI of
+   the requested content or the User Agent's IP address or subnet.  The
+   information required to base a routing decision on can be highly
+   dependent on the type of content delivered.  A uCDN SHOULD only
+   include information that is absolutely necessary for delivering that
+   type of content.  Cookies in particular are especially sensitive from
+   a security/privacy point of view and in general SHOULD NOT be
+   conveyed in the RI Requests to the dCDN.  The information necessary
+   to be conveyed for a particular type of request is expected to be
+   conveyed out of band between the uCDN and dCDN.  See Section 5.2 for
+   more detail on the privacy aspects of using RI Requests to convey
+   information about UA requests.
+
+   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 about how to redirect the User Agent, the dCDN
+   may wish to return additional policy information to the uCDN.  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".
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 8]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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 a cacheable response signaled in the HTTP response
+      body of the RI response, for example, whether the response applies
+      to a wider range of IP addresses than what was included in the RI
+      request.
+
+   The cacheability of the response is indicated using the standard HTTP
+   Cache-Control mechanisms.
+
+4.2.  JSON Encoding of RI Requests and Responses
+
+   The body of RI requests and responses is a JSON object [RFC7159] that
+   contains a dictionary of key:value pairs that MUST conform to
+   [RFC7493].  Senders MUST encode all (top-level object and sub-object)
+   keys specified in this document in lowercase.  Receivers MUST ignore
+   any keys that are unknown or invalid.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                    [Page 9]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The following table defines the top-level keys and indicates whether
+   they are applicable to RI requests, RI responses, or both:
+
+   +----------+------------------+-------------------------------------+
+   | 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 an 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. See Section 4.8.          |
+   |          |                  |                                     |
+   | 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.                              |
+   +----------+------------------+-------------------------------------+
+
+             Table 1: Top-Level Keys in RI Requests/Responses
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 10]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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.
+
+   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 about encoding error information in RI responses.
+
+   All implementations that support IPv4 addresses MUST support the
+   encoding specified by the 'IPv4address' rule in Section 3.2.2 of
+   [RFC3986].  Likewise, implementations that support IPv6 addresses
+   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 as
+   specified in [RFC7736], with the Payload Type (ptype) parameter set
+   to 'redirection-request'.
+
+   RI responses MUST use a MIME media type of application/cdni as
+   specified in [RFC7736], with the Payload Type (ptype) parameter set
+   to 'redirection-response'.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 11]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+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.
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 12]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The preceding information 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.  The value of this |
+   |             |         |           | field SHALL be set to either  |
+   |             |         |           | 'A' or 'AAAA'.                |
+   |             |         |           |                               |
+   | 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 Classless Inter-    |
+   |             |         |           | Domain Routing (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 any successful  |
+   |             |         |           | RI response.  CDNs MUST       |
+   |             |         |           | include the dns-only property |
+   |             |         |           | set to True on any cascaded   |
+   |             |         |           | RI requests.  Defaults to     |
+   |             |         |           | False.                        |
+   +-------------+---------+-----------+-------------------------------+
+
+                                  Table 2
+
+   An RI request for DNS-based redirection MUST include a dns
+   dictionary.  This dns dictionary MUST contain the following keys:
+   resolver-ip, qtype, qclass, and qname; the value of each MUST be the
+   value of the appropriate part of the User Agent's DNS query/request.
+   For internationalized domain names containing non-ASCII characters,
+   the value of the qname field MUST be the ASCII-compatible encoded
+   (ACE) representation (A-label) of the domain name [RFC5890].
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 13]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   An example RI request (uCDN->dCDN) for DNS-based redirection is as
+   follows:
+
+   POST /dcdn/ri HTTP/1.1
+   Host: rr1.dcdn.example.net
+   Content-Type: application/cdni; ptype=redirection-request
+   Accept: application/cdni; ptype=redirection-response
+
+   {
+     "dns" : {
+       "resolver-ip" : "192.0.2.1",
+       "c-subnet" : "198.51.100.0/24",
+       "qtype" : "A",
+       "qclass" : "IN",
+       "qname" : "www.example.com"
+     },
+     "cdn-path": ["AS64496:0"],
+     "max-hops": 3
+   }
+
+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 an RT that is a Request Router if the dns-
+      only key is set to True in the RI request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 14]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The preceding information 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 (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.                     |
+   +-------+-----------+-----------+-----------------------------------+
+
+                                  Table 3
+
+   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 the rcode and name keys and it MUST include
+   at least one of the following keys: a, aaaa, or 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.
+   For internationalized domain names containing non-ASCII characters,
+   the value of the cname field MUST be the ACE representation (A-label)
+   of the domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 15]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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; ptype=redirection-response
+
+   {
+     "dns" : {
+       "rcode" : 0,
+       "name" : "www.example.com",
+       "a" : ["203.0.113.200", "203.0.113.201", "203.0.113.202"],
+       "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
+       "ttl" : 60
+     }
+   }
+
+   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; ptype=redirection-response
+
+   {
+     "dns" : {
+       "rcode" : 0,
+       "name" : "www.example.com",
+       "cname" : ["rr1.dcdn.example"],
+       "ttl" : 20
+     }
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 16]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+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, et al.        Standards Track                   [Page 17]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The preceding information 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 from  |
+   |                   |        |           | the UA request.          |
+   +-------------------+--------+-----------+--------------------------+
+
+                                  Table 4
+
+   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; 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.
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 18]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   In the case where the User Agent request includes multiple HTTP
+   header fields with the same field-name, it is RECOMMENDED that the
+   uCDN combine 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 the 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 might only
+   send the contents of the first occurrence of the HTTP Headers
+   instead.
+
+   An example RI request (uCDN->dCDN) for HTTP-based redirection is as
+   follows:
+
+   POST /dcdn/rrri HTTP/1.1
+   Host: rr1.dcdn.example.net
+   Content-Type: application/cdni; ptype=redirection-request
+   Accept: application/cdni; ptype=redirection-response
+
+   {
+     "http": {
+       "c-ip": "198.51.100.1",
+       "cs-uri": "http://www.example.com",
+       "cs-version": "HTTP/1.1",
+       "cs-method": "GET"
+     },
+     "cdn-path": ["AS64496:0"],
+     "max-hops": 3
+   }
+
+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).
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 19]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The preceding information 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-(<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.                 |
+   +-------------------+---------+-----------+-------------------------+
+
+                                  Table 5
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 20]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   Note: The sc-(location) key in the preceding table is an example of
+   sc-(<headername>) that has been called out separately as its presence
+   is mandatory in RI responses.
+
+   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, and 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
+   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 behavior.  As an
+   example, the dCDN might include sc-(cache-control),
+   sc-(last-modified), and sc-(expires) keys in the http dictionary,
+   through which the dCDN may try to influence the cacheability of the
+   response by the UA.  If the uCDN would pass these HTTP headers on to
+   the UA, this could mean that further requests from the uCDN would go
+   directly to the dCDN, bypassing the uCDN and any logging it may
+   perform on incoming requests.  Therefore, the uCDN is 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 is a follows:
+
+   HTTP/1.1 200 OK
+   Date: Mon, 06 Aug 2012 18:41:38 GMT
+   Content-Type: application/cdni; ptype=redirection-response
+
+   {
+     "http": {
+       "sc-status": 302,
+       "sc-version": "HTTP/1.1",
+       "sc-reason": "Found",
+       "cs-uri": "http://www.example.com"
+       "sc-(location)":
+         "http://sur1.dcdn.example/ucdn/example.com",
+     }
+   }
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 21]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+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
+   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.                             |
+   +---------+--------+-----------+------------------------------------+
+
+                                  Table 6
+
+   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 appropriate RI
+   response to use.
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 22]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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; ptype=redirection-response
+   Cache-Control: public, max-age=30
+
+   {
+     "dns" : {
+       "rcode" : 0,
+       "name" : "www.example.com",
+       "a" : ["203.0.113.200", "203.0.113.201"],
+       "aaaa" : ["2001:DB8::C8", "2001:DB8::C9"],
+       "ttl" : 60
+     }
+     "scope" : {
+       "iprange" : ["198.51.100.0/24"]
+     }
+   }
+
+   The following is an example of an 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; ptype=redirection-response
+   Cache-Control: public, max-age=60
+
+   {
+     "http": {
+       "sc-status": 302,
+       "cs-uri": "http://www.example.com"
+       "sc-(location)":
+         "http://sur1.dcdn.example/ucdn/example.com",
+       "sc-(cache-control)" : "public, max-age=30"
+     }
+     "scope" : {
+       "iprange" : ["198.51.100.0/24"]
+     }
+   }
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 23]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+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:
+
+   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 | Yes       | 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.                         |
+   +------------+---------+-----------+--------------------------------+
+
+                                  Table 7
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 24]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The first digit of the error-code defines the class of error.  There
+   are 5 classes of errors 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.
+
+      3xx: Reserved.
+
+      4xx: uCDN error: The dCDN cannot 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 successfully 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.
+
+   +------+--------------+---------------------------------------------+
+   | 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 cannot 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.                        |
+   |      |              |                                             |
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 25]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   | 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 that the content requested by the  |
+   |      |              | UA does not exist.                          |
+   |      |              |                                             |
+   | 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 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   |
+   |      |              | supported or is not prepared to return an   |
+   |      |              | RT of a surrogate directly.                 |
+   +------+--------------+---------------------------------------------+
+
+                                  Table 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 26]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   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; ptype=redirection-response
+   Cache-Control: private, no-cache
+
+   {
+     "error" : {
+       "error-code" : 504,
+       "description" : "Out of capacity"
+     }
+   }
+
+   The following is an example of a successful RI response (dCDN->uCDN)
+   for an 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; ptype=redirection-response
+   Cache-Control: private, no-cache
+
+   {
+      "http": {
+       "sc-status": 302,
+       "sc-version": "HTTP/1.1",
+       "sc-reason": "Found",
+       "cs-uri": "http://www.example.com"
+       "sc-(location)":
+         "http://sur1.dcdn.example/ucdn/example.com",
+      },
+      "error" : {
+       "error-code" : 100,
+       "description" :
+         "This is a human-readable message meant for debugging purposes"
+     }
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 27]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+4.8.  Loop Detection and 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 that already contain
+   the dCDN's Provider ID in the cdn-path.  Transit CDNs MUST NOT
+   propagate to any downstream CDNs if the number of CDN Provider IDs in
+   cdn-path (before adding its own Provider ID) is equal to or greater
+   than max-hops.
+
+   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 MUST send an RI error response that
+   SHOULD include 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 MUST send an RI error
+   response that SHOULD include an error-code of 503.
+
+   It should be noted that the loop detection and prevention mechanisms
+   described above only cover preventing and detecting loops within the
+   RI itself.  Besides 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 continuously 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 28]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+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
+   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.
+
+5.1.  Authentication, Authorization, Confidentiality, and Integrity
+      Protection
+
+   An implementation of the CDNI Redirection interface MUST support TLS
+   transport as per [RFC2818] and [RFC7230].  The use of TLS for
+   transport of the CDNI Redirection interface messages allows the dCDN
+   and uCDN to authenticate each other.  Once they have mutually
+   authenticated each other, it allows:
+
+   o  The dCDN and uCDN to authorize each other (to ensure they are
+      transmitting/receiving CDNI Redirection messages to/from an
+      authorized CDN);
+
+   o  CDNI Redirection interface messages to be transmitted with
+      confidentiality; and
+
+   o  The integrity of the CDNI Redirection interface messages to be
+      protected during the exchange.
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 29]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   In an environment where any such protection is required, mutually
+   authenticated encrypted transport MUST be used to ensure
+   confidentiality of the redirection information; to do so, TLS MUST be
+   used (including authentication of the remote end) by the server side
+   (dCDN) and the client side (uCDN) of the CDNI Redirection interface.
+
+   When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
+   followed.
+
+5.2.  Privacy
+
+   Information passed over the RI ought to be considered personal and
+   sensitive.  In particular, parts of a User Agent's original request,
+   most notably the UA's IP address and requested URI, are transmitted
+   over the RI to the dCDN.  The use of mutually authenticated TLS, as
+   described in the previous section, prevents any other party than the
+   authorized dCDN from gaining access to this information.
+
+   Regardless of whether the uCDN and dCDN use the RI, a successful
+   redirect from a uCDN to a dCDN will make that dCDN aware of the UA's
+   IP address.  As such, the fact that this information is transmitted
+   across the RI does not allow the dCDN to learn new information.  On
+   the other hand, if a uCDN uses the RI to check with multiple
+   candidate dCDNs, those candidates that do not end up getting
+   redirected to do obtain information regarding end-user IP addresses
+   and requested URIs that they would not have if the RI not been used.
+
+   While it is technically possible to mask some information in the RI
+   Request, such as the last bits of the UA IP address, it is important
+   to note that this will reduce the effectiveness of the RI in certain
+   cases.  CDN deployments need to strike a balance between end-user
+   privacy and the features impacted by such masking.  This balance is
+   likely to vary from one deployment to another.  As an example, when
+   the UA and its DNS resolver is behind a Carrier-grade NAT, and the RI
+   is used to find an appropriate delivery node behind the same NAT, the
+   full IP address might be necessary.  Another potential issue when
+   using IP anonymization is that it is no longer possible to correlate
+   an RI Request with a subsequent UA request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 30]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+6.  IANA Considerations
+
+6.1.  CDNI Payload Type Parameter Registrations
+
+   IANA has registered the following two new Payload Types in the
+   "Content Delivery Network Interconnection (CDNI) Parameters" registry
+   for use with the application/cdni MIME media type.
+
+                 +----------------------+---------------+
+                 | Payload Type         | Specification |
+                 +----------------------+---------------+
+                 | redirection-request  | RFC 7975      |
+                 |                      |               |
+                 | redirection-response | RFC 7975      |
+                 +----------------------+---------------+
+
+                                  Table 9
+
+6.1.1.  CDNI RI Redirection Request Payload Type
+
+   Purpose: The purpose of this payload type is to distinguish RI
+   request messages.
+
+   Interface: RI
+
+   Encoding: See Section 4.4.1 and Section 4.5.1
+
+6.1.2.  CDNI RI Redirection Response Payload Type
+
+   Purpose: The purpose of this payload type is to distinguish RI
+   response messages.
+
+   Interface: RI
+
+   Encoding: See Section 4.4.2 and Section 4.5.2
+
+6.2.  RI Error Response Registry
+
+   IANA has created a new "CDNI RI Error response code" subregistry
+   within the "Content Delivery Network Interconnection (CDNI)
+   Parameters" registry.  The "CDNI RI Error response code" namespace
+   defines the valid values for the error-code key in RI error
+   responses.  The CDNI RI Error response code MUST be a three-digit
+   integer.
+
+   Additions to the "RI Error response registry" will be made via
+   "Specification Required" as defined in [RFC5226].
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 31]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   The Designated Expert will verify that new error-code registrations
+   do not duplicate existing error-code definitions (in name or
+   functionality), ensure that the new error-code is in accordance with
+   the error classes defined in Section 4.7 of this document, prevent
+   gratuitous additions to the namespace, and prevent any additions to
+   the namespace that would impair the interoperability of CDNI
+   implementations.
+
+   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 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: Reference to the specification that defines the
+      error-code in more detail.
+
+   The entries in Table 8 are registered by this document, with the
+   value of the 'Specification' field set to RFC 7975 (this document).
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+              2006, <http://www.rfc-editor.org/info/rfc4291>.
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 32]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952,
+              DOI 10.17487/RFC5952, August 2010,
+              <http://www.rfc-editor.org/info/rfc5952>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
+              2014, <http://www.rfc-editor.org/info/rfc7159>.
+
+   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
+              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
+              April 2013, <http://www.rfc-editor.org/info/rfc6895>.
+
+   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
+              DOI 10.17487/RFC7493, March 2015,
+              <http://www.rfc-editor.org/info/rfc7493>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+              2015, <http://www.rfc-editor.org/info/rfc7525>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
+              Distribution Network Interconnection (CDNI) Problem
+              Statement", RFC 6707, DOI 10.17487/RFC6707, September
+              2012, <http://www.rfc-editor.org/info/rfc6707>.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
+              DOI 10.17487/RFC2818, May 2000,
+              <http://www.rfc-editor.org/info/rfc2818>.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, DOI 10.17487/RFC5890, August 2010,
+              <http://www.rfc-editor.org/info/rfc5890>.
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 33]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+   [RTMP]     Adobe Systems Incorporated, "Real-Time Messaging Protocol
+              (RTMP) specification", December 2012,
+              <http://www.adobe.com/go/spec_rtmp>.
+
+7.2.  Informative References
+
+   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
+              Network Interconnection (CDNI) Requirements", RFC 7337,
+              DOI 10.17487/RFC7337, August 2014,
+              <http://www.rfc-editor.org/info/rfc7337>.
+
+   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
+              "Framework for Content Distribution Network
+              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
+              August 2014, <http://www.rfc-editor.org/info/rfc7336>.
+
+   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
+              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
+              December 2015, <http://www.rfc-editor.org/info/rfc7736>.
+
+Acknowledgements
+
+   The authors would like to thank Taesang Choi, Francois Le Faucheur,
+   Matt Miller, Scott Wainner, and Kevin J. Ma for their valuable
+   comments and input to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 34]
+
+RFC 7975               Request Routing Redirection          October 2016
+
+
+Contributors
+
+   The following persons have participated as co-authors to this
+   document:
+
+   Wang Danhua
+   Huawei
+   Email: wangdanhua@huawei.com
+
+   He Xiaoyan
+   Huawei
+   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
+
+Authors' Addresses
+
+   Ben Niven-Jenkins (editor)
+   Nokia
+   3 Ely Road
+   Milton, Cambridge  CB24 6DD
+   United Kingdom
+
+   Email: ben.niven-jenkins@nokia.com
+
+
+   Ray van Brandenburg (editor)
+   TNO
+   Anna van Buerenplein 1
+   The Hague  2595DA
+   The Netherlands
+
+   Phone: +31-88-866-7000
+   Email: ray.vanbrandenburg@tno.nl
+
+
+
+
+Niven-Jenkins, et al.        Standards Track                   [Page 35]
+